在Java中，我们可以看到许多地方都可以使用final关键字，但实际上它的使用并不常见。
比如：
String str = "abc";
System.out.println(str);
final，因为它使代码更易于理解，并有助于查找错误（因为它明确了程序员的意图）。PMD可能建议使用final是因为这些样式问题，而不是出于性能原因。 - sleskefinal应该强调开发人员倾向于不可变性的意图，而不是为了“优化”代码。我鼓励您阅读这一章节，非常有趣！ - Louis F.final关键字可以减少字节码的数量，这可能会对性能产生影响。 - Julien Kronegg简短回答：不要担心！
长话短说：
谈及“最终本地变量”时，请记住使用关键字 final 可以帮助编译器静态地优化代码，这可能最终会产生更快的代码。例如，下面例子中的最终字符串 a + b 在编译时静态拼接。
public class FinalTest {
public static final int N_ITERATIONS = 1000000;
public static String testFinal() {
final String a = "a";
final String b = "b";
return a + b;
}
public static String testNonFinal() {
String a = "a";
String b = "b";
return a + b;
}
public static void main(String[] args) {
long tStart, tElapsed;
tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testFinal();
tElapsed = System.currentTimeMillis() - tStart;
System.out.println("Method with finals took " + tElapsed + " ms");
tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testNonFinal();
tElapsed = System.currentTimeMillis() - tStart;
System.out.println("Method without finals took " + tElapsed + " ms");
}
}
结果是什么？
Method with finals took 5 ms
Method without finals took 273 ms
在Java Hotspot VM 1.7.0_45-b18上进行了测试。
那么实际的性能提升是多少呢？我不敢说。在大多数情况下可能只会有轻微改善(在这个合成测试中，由于完全避免了字符串连接操作，所以只有约270纳秒——这是一个罕见的情况)，但在高度优化的工具代码中，它可能是一个因素。无论如何，对最初的问题的回答是是的，它可能会改善性能，但充其量只是轻微的改善。
除了编译时的好处外，我找不到使用关键字final对性能有任何可衡量影响的证据。
是的，它可以。以下是final可以提高性能的实例：
条件编译是一种技术，在这种技术中，根据特定条件，代码行不会被编译进类文件中。这可用于在生产构建中删除大量调试代码。
考虑以下内容：
public class ConditionalCompile {
private final static boolean doSomething= false;
if (doSomething) {
// do first part.
}
if (doSomething) {
// do second part.
}
if (doSomething) {
// do third part.
}
if (doSomething) {
// do finalization part.
}
}
将doSomething属性转换为final属性后，您告诉编译器无论何时看到doSomething，都应根据编译时替换规则将其替换为false。 编译器的第一次通过将代码更改为像something这样：
public class ConditionalCompile {
private final static boolean doSomething= false;
if (false){
// do first part.
}
if (false){
// do second part.
}
if (false){
// do third part.
}
if (false){
// do finalization part.
}
}
完成后，编译器会再次检查代码并发现存在无法到达的语句。由于你正在使用高质量的编译器，它不喜欢所有那些无法到达的字节码。因此，它会将其删除，最终你得到：
public class ConditionalCompile {
private final static boolean doSomething= false;
public static void someMethodBetter( ) {
// do first part.
// do second part.
// do third part.
// do finalization part.
}
}
从而减少任何过多的代码或不必要的条件检查。
Edit： 例如，让我们看下面的代码：
public class Test {
public static final void main(String[] args) {
boolean x = false;
if (x) {
System.out.println("x");
}
final boolean y = false;
if (y) {
System.out.println("y");
}
if (false) {
System.out.println("z");
}
}
}
使用Java 8编译此代码并使用javap -c Test.class反编译，我们得到：
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public static final void main(java.lang.String[]);
Code:
0: iconst_0
1: istore_1
2: iload_1
3: ifeq 14
6: getstatic #16 // Field java/lang/System.out:Ljava/io/PrintStream;
9: ldc #22 // String x
11: invokevirtual #24 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
14: iconst_0
15: istore_2
16: return
}
我们可以注意到编译后的代码仅包括非final变量x。这证明了final变量对性能有影响，至少对于这种简单情况是如此。
我很惊讶没有人发布一些真正的反编译代码来证明至少存在一些微小的差异。
参考文献：此测试已针对javac版本8、9和10进行。
假设有这个方法：
public static int test() {
/* final */ Object left = new Object();
Object right = new Object();
return left.hashCode() + right.hashCode();
}
final关键字的代码完全相同（final Object left = new Object();）。public static int test() {
/* final */ int left = 11;
int right = 12;
return left + right;
}
生成：
0: bipush 11
2: istore_0
3: bipush 12
5: istore_1
6: iload_0
7: iload_1
8: iadd
9: ireturn
留下 final 存在会产生：
0: bipush 12
2: istore_1
3: bipush 11
5: iload_1
6: iadd
7: ireturn
bipush 12; istore_0; iload_0），这在某种程度上是有道理的，因为没有人能够更改它。istore_0 ... iload_0，我不知道，毕竟那个位置 0 没有被以任何方式使用（这样可以缩小变量数组，但可能我错过了一些内部细节，无法确定）。javac 的优化很少。至于我们是否应该总是使用 final？我甚至不会写一个 JMH 测试（最初我想这样做），我确信差异在 ns 的数量级上（如果可能被捕获的话）。唯一可能出现问题的地方是当一个方法由于其大小而不能被内联（并且声明 final 将使其大小缩小几个字节）时。
还有两个需要解决的final问题。首先是当方法被认为是final时（从JIT的角度来看），这样的方法是单态的——这些方法是JVM中最受喜爱的方法。
然后是final实例变量（必须在每个构造函数中设置）；这些变量非常重要，因为它们将保证正确发布引用，稍微提到了一下并且也由JLS准确指定。
话虽如此：这里还有一件事情是对每一个回答都不可见的：垃圾回收。需要花费很多时间来解释，但是当你读取一个变量时，GC会为该读取设置所谓的屏障。每个aload和getField都通过这样一个屏障进行“保护”，这里有更多细节。理论上，final字段不需要这样的“保护”（它们可以完全跳过屏障）。因此，如果GC这样做了-final将提高性能。
javac -g FinalTest.java)，使用javap -c FinalTest.class反编译了代码，但没有获得相同的结果(在final int left=12的情况下，我得到了bipush 11; istore_0; bipush 12; istore_1; bipush 11; iload_1; iadd; ireturn)。因此，生成的字节码取决于许多因素，很难说final是否对性能产生影响。但是由于字节码不同，可能存在一些性能差异。 - Julien Kroneggjavac更好地进行优化。但这只是猜测。 - sleskefinal 变量是原始类型或类型为 String 并且立即被分配为编译时常量，就像问题的示例一样，编译器 必须 将其内联，因为该变量是规范上的编译时常量。但对于大多数用例，代码可能看起来不同，但从性能上讲，无论常量是内联还是从本地变量读取，都没有区别。 - Holger注意：不是java专家
如果我记得正确的话，使用final关键字很难提高性能。我一直知道它存在于“好代码”-设计和可读性。
final关键字使事物变得不可变，并且至少有三种方法可以使不可变性在代码性能方面产生实际差异。这三个点都源于编译器或开发人员做出更好的假设：
final，如果您意外地使用相同的名称用于变量，或重新分配它的值（使参数不再可访问），则编译器会发出警告。
public class FinalTest {
private static final int N_ITERATIONS = 1000000;
private static String testFinal() {
final String a = "a";
final String b = "b";
return a + b;
}
private static String testNonFinal() {
String a = "a";
String b = "b";
return a + b;
}
private static String testSomeFinal() {
final String a = "a";
String b = "b";
return a + b;
}
public static void main(String[] args) {
measure("testFinal", FinalTest::testFinal);
measure("testSomeFinal", FinalTest::testSomeFinal);
measure("testNonFinal", FinalTest::testNonFinal);
}
private static void measure(String testName, Runnable singleTest){
final long tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
singleTest.run();
final long tElapsed = System.currentTimeMillis() - tStart;
System.out.printf("Method %s took %d ms%n", testName, tElapsed);
}
}
使用openjdk17编译它：javac FinalTest.java
然后反编译：javap -c -p FinalTest.class
导致这个字节码：
private static java.lang.String testFinal();
Code:
0: ldc #7 // String ab
2: areturn
private static java.lang.String testNonFinal();
Code:
0: ldc #9 // String a
2: astore_0
3: ldc #11 // String b
5: astore_1
6: aload_0
7: aload_1
8: invokedynamic #13, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
13: areturn
private static java.lang.String testSomeFinal();
Code:
0: ldc #11 // String b
2: astore_0
3: aload_0
4: invokedynamic #17, 0 // InvokeDynamic #1:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
9: areturn
// omitted bytecode for the measure() method, which is not interesting
final 关键字确实会有影响。尽管这些时间看起来微不足道（因为我们执行了一百万个任务），但我认为经过一段时间后，JIT 优化会发挥它的作用，平滑掉差异。但即使如此，在考虑到对于方法 testFinal 耗时 5 毫秒
方法 testSomeFinal 耗时 13 毫秒
方法 testNonFinal 耗时 20 毫秒
testNonFinal 这个测试场景，JVM 已被前面的测试热身并且共同的代码应该已经被优化的情况下，4 倍的性能提升也已经不容忽视。
final class 是否也是如此，因为 mutable class 对我来说并没有太多意义。如其他地方所提到的，对于局部变量和稍微次要的成员变量而言，'final' 更多的是一种风格问题。
'final' 是表明你想要这个变量不可改变（即该变量不会变动！）。编译器则可以通过报错来帮助你避免违反自己的约束。
我认为如果Java默认情况下将标识符（抱歉，我只能叫一个不可变的东西为“变量”）设为final，并要求你明确表示它们是变量，那么它将成为一种更好的语言。但话虽如此，对于已初始化并且从未分配过的局部变量，我通常不使用 'final'；因为这样会显得太繁琐。
（对于成员变量，我会使用 'final' ）
对于成员变量和参数来说，Final（至少是）更多地为人类服务，而不是机器。
在可能的情况下，将变量设置为final是一个好习惯。我希望Java默认把“变量”设置为final，并使用“Mutable”关键字来允许更改。不可变类会导致更好的线程安全代码，只需看一眼带有“final”前缀的类的每个成员变量，就可以快速确定其是否是不可变的。
另一种情况是：我一直在将很多代码转换为使用@NonNull/@Nullable注释（您可以说方法参数不能为空，然后IDE可以警告您未标记@NonNull的变量的所有位置-整个过程扩散到荒谬的程度）。当成员变量或参数被标记为final时，可以更容易地证明它们不可能为空，因为您知道它们没有被重新分配给其他地方。
我的建议是：默认情况下将成员和参数应用final，这只是几个字符，但即使没有其他任何东西，也会促使您改进编码风格。
对于方法或类来说，Final是另一个概念，因为它禁止了一种非常有效的重用形式，并且并不能真正告诉读者太多信息。最好的用法可能是它们将String和其他内部类型设置为final，以便您可以在任何地方依赖一致的行为-这防止了很多错误（尽管有时我真的很想扩展字符串....哦，那些可能性）。
final会使其变得更大...但这真的会让它变得更好吗？ - Ashley Friezefinal代码存在深层次的问题，而且我也见过很简单的没有使用final修饰符的代码。final相比其他做法具体如何有所帮助呢？例如，如果你只编写非常短的函数，很少使用临时变量，那么final并没有多大的帮助，看起来只像是喊话！;) - Ashley Frieze