No
- 无论如何，JIT 编译器可能会将字节码“转换”成完全不同的东西。
- 它将导致您进行过早的优化。
Yes
- 您不知道 JIT 将编译哪种方法，因此最好将它们全部优化。
- 它会让你成为一个更好的Java程序员。
我是在不知道（显然）的情况下问的，所以请随意重定向到 JIT 超链接。
问问题
529 次
4 回答
17
是的，但在一定程度上——这是一个很好的教育机会，可以了解幕后发生的事情，但可能应该适度进行。
这可能是一件好事，因为查看字节码可能有助于理解如何将 Java 源代码编译成 Java 字节码。此外，它可能会给出一些关于编译器将执行哪种优化的想法，并且可能对编译器可以执行的优化量有一些限制。
例如，如果执行字符串连接，javac将优化连接以使用 aStringBuilder和执行append方法连接Strings。
但是，如果在循环中执行字符串连接，则可能会在每次迭代时实例化一个 new ，与手动在循环外实例化 a 并仅在循环内执行 sStringBuilder相比，可能会导致性能下降。StringBuilderappend
关于 JIT 的问题。即时编译将是特定于 JVM 实现的，因此当字节码转换为本机代码时，要找出字节码实际发生了什么并不容易，而且我们无法分辨哪些部分正在被 JIT 化（至少没有一些特定于 JVM 的工具来查看正在执行哪种 JIT 编译——我不知道这方面的任何细节，所以我只是推测。）
也就是说，JVM 无论如何都会执行字节码，它的执行方式对开发人员来说或多或少是不透明的，而且还是特定于 JVM 的。可能有一些性能技巧，一个 JVM 执行而另一个不执行。
当涉及查看生成的字节码的问题时，归结为了解源代码在编译为字节码时实际发生了什么。能够看到编译器执行的优化类型，同时也了解编译器执行优化的方式是有限的。
综上所述，我不认为沉迷于字节码生成并尝试编写能够发出最优化字节码的程序并不是一个好主意。更重要的是编写可供他人阅读和维护的 Java 源代码。
于 2009-04-29T04:52:50.347 回答
4
这完全取决于你想要做什么。如果您正在尝试优化方法/模块，那么查看字节码将浪费您的时间。始终首先分析以找到瓶颈所在，然后优化瓶颈。如果你的瓶颈看起来很紧，并且你需要让它更快，你可能别无选择，只能用本机代码重写它并与 JNI 接口。
尝试优化生成的字节码将无济于事，因为 JIT 编译器会做很多工作，而且你不会知道它到底在做什么。
于 2009-04-29T04:50:01.070 回答
1
我不会这么认为。由于不必调试 javac 编译器或想知道感兴趣的问题，我想不出一个很好的理由为什么有人会关心生成什么字节码。
了解字节码不会让你成为更好的 Java 程序员，就像了解内燃机的工作原理会让你成为更好的司机一样。
从抽象的角度思考。当你试图计算行星的轨道时，你不需要知道夸克或原子的作用。要成为一名优秀的 Java 程序员，您可能应该学习……嗯……Java。是的，Java，就是这样 :-)
于 2009-04-29T05:01:20.060 回答
0
除非您正在开发某种高容量服务器，否则您可能永远不需要检查字节码，除非出于好奇。遵循组织中可接受的编码实践的源代码将为大多数应用程序提供充足的性能。
在对应用程序进行负载测试后发现问题之前，不要担心性能问题（或者整个客户服务团队会为那个需要“永远”加载的屏幕私刑）。然后，消除瓶颈，不理会其余代码。
字节码需要适度的学习曲线才能理解。当然，了解更多信息永远不会有坏处，但实用主义建议将其推迟到有必要的时候。（如果那一刻到来，我建议找人指导你。）
于 2009-04-29T06:41:16.797 回答