Java 字节码 iconst_0 iadd 序列

Question

这是一个有趣的三元运算符测试:

public int so( final int a ) {
    int r = (int) System.currentTimeMillis();
    r += a == 2 ? 1 : 0;
    return r;
}

这是生成的字节码:

public int doIt(int);
  Code:
   0:   invokestatic    #2; //Method java/lang/System.currentTimeMillis:()J
   3:   l2i
   4:   istore_2
   5:   iload_2
   6:   iload_1
   7:   iconst_2
   8:   if_icmpne       15
   11:  iconst_1
   12:  goto    16
   15:  iconst_0
   16:  iadd
   17:  istore_2
   18:  iload_2
   19:  ireturn

看到它没有删除“+ 0”的“其他”大小写，我有点惊讶。我更期待这个:

public int doIt(int);
  Code:
   0:   invokestatic    #2; //Method java/lang/System.currentTimeMillis:()J
   3:   l2i
   4:   istore_2
   5:   iload_1
   6:   iconst_2
   7:   if_icmpne       13
   10:  iinc    2, 1
   13:  iload_2
   14:  ireturn

所以我的问题来了:规范是否强制要求:

goto ...
iconst_0

序列是因为我使用了三元运算符，还是这只是编译器的问题？

显然这个问题不是关于写作 'r += ... 的相关性？ 1:0'。但我很惊讶，因为在其他情况下，编译器会进行相当多的优化，而在这里它没有进行任何优化。

生成选项 2 的 Java 编译器是否仍然是有效的 Java 编译器(如果我没有搞砸我的示例，但重点是:在生成的代码中有一个不必要的 0 和一个不必要的 goto，编译器会不会删除它仍然是一个有效的 .java 编译器)？

Answer 1

要记住的一件事是 javac(Java 源代码到字节码编译器)不是优化编译器。事实上，它的代码生成相对简单，只生成任何给定源代码的最直接的字节码实现。

这完全是设计使然。通过这种方式，负责所有实际优化的 JVM 拥有最大量的可用信息来作为其决策的基础。在这种特殊情况下，这些信息如何使 JIT 编译器受益可能并不明显，但由于 HotSpot 等优化的性质，每一点信息都可以提供帮助。

例如，可能有一些智能模式匹配可以识别常见的代码片段并在高度优化的版本中实现它们。现在，如果 javac 也尝试进行一些优化，那么这些模式可能更难检测。