我应该查看java编译器生成的字节码吗?

Bou*_*une 6 java compiler-construction jit jvm bytecode

No

  • 无论如何,JIT编译器可以将字节码"转换"为完全不同的东西.
  • 它会引导你做过早的优化.

Yes

  • 您不知道JIT将编译哪种方法,因此如果您优化它们会更好.
  • 它将使您成为更好的Java程序员.

我问的是没有真正知道(显然)所以随意重定向到JIT超链接.

coo*_*ird 17

是的,但在某种程度上 - 作为一个教育机会,看看幕后发生了什么是好的,但可能应该适度地完成.

这可能是一件好事,因为查看字节码可能有助于理解如何将Java源代码编译成Java字节码.此外,它可能会给出一些关于编译器将执行何种优化的想法,以及编译器可以执行的优化量的一些限制.

例如,如果执行字符串连接,javac则将串联优化为使用a StringBuilder和执行append连接Strings的方法.

但是,如果在循环中执行字符串连接,StringBuilder则可以在每次迭代时实例化新的,与手动实例化StringBuilder循环外部并且仅append在循环内执行s 相比,导致可能的性能降级.

关于JIT的问题.在即时编译将是JVM实现特定的,所以它不是很容易找出什么是真正发生的事情,当它被转换为本地代码的字节码,而且,我们无法分辨哪些部分正在进行JIT(至少没有一些特定于JVM的工具,看看正在执行什么样的JIT编译 - 我不知道这个领域有什么细节,所以我只是在猜测.)

也就是说,无论如何,JVM将执行字节码,它的执行方式对开发人员来说或多或少是不透明的,同样也是JVM特有的.一个JVM可能会执行一些性能技巧,而另一个则不会.

当涉及到查看生成的字节码的问题时,它归结为在编译为字节码时学习源代码实际发生的事情.能够看到编译器执行的各种优化,但也了解编译器可以执行优化的方式有限.

总而言之,我不认为对字节码生成过敏并试图编写将发出最优化字节码的程序是一个非常好的主意.更重要的是编写其他人可读和可维护的Java源代码.