java Finals 是否有助于编译器创建更高效​​的字节码？ [复制]

可能的重复：
Java中使用final关键字会提高性能吗？ https://stackoverflow.com/questions/4279420/does-use-of-final-keyword-in-java-improve-the-performance

The final修饰符有不同的后果 http://en.wikipedia.org/wiki/Final_%28Java%29在java中取决于你应用它的目的。我想知道的是如果此外它可能有助于编译器创建更高效​​的字节码。我想这个问题深入到 JVM 如何工作，并且可能是 JVM 特定的。

那么，根据您的专业知识，以下任何内容是否对编译器有帮助，或者您仅出于正常的 java 原因才使用它们？

• 期末课程
• 最终方法
• 最终字段
• 最终方法参数

Thanks!

编辑：感谢您的所有回答！请注意，正如 @Zohaib 所建议的，我的问题是重复的this https://stackoverflow.com/questions/4279420/does-use-of-final-keyword-in-java-improve-the-performance。发帖前我搜索得不够仔细。我不会删除它，因为你们做出了很好的贡献，但答案可以合并。除非另有说明，我会让“投票结束”系统来决定。

The bytecodes are not significantly more or less efficient if you use final because Java bytecode compilers typically do little in the way optimization. The efficiency bonus (if any) will be in the native code produced by the JIT compiler¹.

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

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

• 将变量声明为final防止您意外更改它。 （并向读者表达你的意图。）
• 将方法声明为final防止在子类中重写。
• 将一个类声明为final完全阻止子类化。
• 将字段声明为final阻止子类更改它。
• 将字段声明为final对线程安全有重要影响；看JLS 17.5 http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.

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

所以好的做法是使用final（广义上来说）表达您的设计意图，并实现您需要的其他语义效果。如果你使用final仅作为优化提示，您不会取得多大成果。

有一些例外情况final could导致某些平台上的性能略有提高。

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

• 可以想象，将字段或局部参数声明为final可能允许进行较小的 JIT 编译器优化，否则不会进行这种优化。但是，任何可以声明为 Final 的字段couldJIT 编译器也可以推断其实际上是最终的。 （只是不清楚 JIT 编译器实际上是否执行此操作，以及这是否会影响生成的本机代码。）

但底线保持不变。你应该使用final表达您的设计意图，而不是作为优化提示。

^{1 - This answer assumes that we are talking about a recent JVM with a good JIT or AOT compiler. 1) The earliest Sun Java implementations didn't have a JIT compiler at all. 2) Early Android Java implementations had compilers which did a poor job of optimizing. Indeed the early Android developer documentation advised various source-level micro-optimizations to compensate. This advice has since been removed.}