优化java帮助编译器创建更高效的字节码吗？

Question

Possible Duplicate:
Does use of final keyword in Java improve the performance?

final修饰符在java中有different consequences，具体取决于应用它的对象。我想知道的是，如果另外它可能会帮助编译器创建更高效的字节码。我想问题深入到JVM是如何工作的，可能是JVM特有的

那么，在您的专业知识中，以下哪一项对编译器有帮助，或者您只是出于正常的java原因才使用它们

• 期末班
• 最终方法
• 最终字段
• 最终方法参数

谢谢

编辑：谢谢你的回答！请注意，正如@Zohaib所建议的，我的问题是this的重复。我在发帖前搜索得不够好。我不会删除它，因为你们做出了很好的贡献，但答案可以合并。除非另有说明，否则我将由“投票赞成关闭”系统决定

Answer 1

这个问题已经被问了很多次了，答案通常是：编译器可能会进行一些优化（例如，内联常量是最终的静态字段），但一般来说，您不应该为此而烦恼，因为这些性能提升可能实际上并不明显。出于“正常”的Java原因，只需使用final关键字（使字段或参数不可变，防止方法的子类化或重写）

Answer 2

如果使用final，字节码的效率不会显著提高或降低，因为Java字节码编译器通常很少进行优化。效率奖励（如果有的话）将在JIT编译器¹生成的本机代码中

理论上，使用final可以向JIT编译器提供一个提示，帮助它进行优化。实际上，最近的HotSpot JIT编译器可以通过忽略提示来做得更好。例如，现代JIT编译器通常会执行全局分析，以确定给定的方法调用是否是在应用程序当前加载的类的上下文中对叶方法的调用。这种分析比final提示更准确，运行时甚至可以检测何时加载了使分析无效的新类。。。并对受影响的代码重新进行分析和本机代码生成

使用final还有其他语义后果：

• 将变量声明为final可以防止意外更改它。（并向读者表达你的意图。）
• 将方法声明为final可以防止子类中的重写
• 将类声明为final可以防止完全子类化
• 将字段声明为final会阻止子类更改它
• 将字段声明为final对线程安全有重要影响；见JLS 17.5

在适当的情况下，这些都是好的。然而，很明显，它们通过创建子类来限制重用选项。在决定是否使用final时，需要考虑这一点

因此，好的做法是使用final来（广义地说）表达您的设计意图，并实现您需要的其他语义效果。如果只将final用作优化提示，则不会取得太大效果

---

有几个例外情况final可能会在某些平台上导致性能的微小改进

• 在某些情况下，将字段声明为final会改变字节码编译器处理它的方式。我在上面举了一个例子。另一种是“常量变量”情况（JLS 4.12.4），其中static final字段的值将由字节码编译器在当前类和其他类中内联，这可能会影响观察到的代码行为。（例如，引用常量变量不会触发类初始化。因此，添加final可能会改变类初始化的顺序。）

• 可以想象，将一个字段或局部参数声明为final可能会允许较小的JIT编译器优化，否则将无法完成。然而，任何可以声明为final的字段也可以被JIT编译器推断为final。（只是不清楚JIT编译器是否真的做到了这一点，以及这是否会影响生成的本机代码。）

然而，底线仍然是一样的。您应该使用final来表达您的设计意图，而不是作为优化提示

---

^{1-这个答案假设我们讨论的是一个具有良好的JIT或AOT编译器的最新JVM。1） 最早的Sun Java实现根本没有JIT编译器。2） 早期的Android Java实现中，编译器的优化效果很差。事实上，早期的Android开发者文档建议进行各种源代码级别的微优化以弥补不足。这个建议后来被删除了}

Answer 3

我建议你用你的代码测试一下。在某些情况下，它可能对编译器产生不同的影响，但更可能对JIT产生不同的影响。当涉及到微基准测试和微调整时，什么应该产生差异，什么实际产生差异，往往不是一回事，只有好的测试才能确保

另一个问题是，JVM一直在改进，而一个在以前发挥了巨大作用的技巧可能不再适用。e、 g.在Java 5.0中Lock比synchronized快得多，但是在Java 6中，差异要小得多，而且synchronized可以更快

总的来说，让代码简单、清晰、易于维护是一个好主意，这也将产生高效的代码