注意:不是java专家

如果我没有记错我的java，使用final关键字几乎没有办法提高性能。 我一直知道它的存在是为了“好代码”——设计和可读性。

Final(至少对于成员变量和参数)更适合人类，而不是机器。

在任何可能的情况下使变量为final是一个很好的实践。我希望Java默认设置“变量”为final，并有一个“可变”关键字来允许更改。不可变类会带来更好的线程代码，只要看一眼每个成员前面都有“final”的类，就会很快显示它是不可变的。

另一种情况——我已经转换了很多代码来使用@NonNull/@Nullable注释(你可以说一个方法参数必须不是null，然后IDE可以警告你每一个地方你传递一个没有@NonNull标记的变量——整个事情蔓延到一个荒谬的程度)。当一个成员变量或形参被标记为final时，证明它不能为空要容易得多，因为你知道它没有在其他任何地方被重新赋值。

我的建议是养成在默认情况下为成员和参数应用final的习惯，它只是几个字符，但如果没有其他的话，将推动您改进您的编码风格。

方法或类的Final是另一个概念，因为它不允许非常有效的重用形式，并且没有真正告诉读者很多东西。最好的使用可能是他们使String和其他内在类型为final的方式，这样你就可以在任何地方依赖一致的行为——这防止了很多错误(尽管有时我很喜欢扩展String ....)哦，可能性)

你实际上在问两种(至少)不同的情况:

局部变量的Final 方法/类的Final

Jon Skeet已经回答了2)。关于1):

我不认为这有什么区别;对于局部变量，编译器可以推断该变量是否是final变量(只需检查它是否被多次赋值)。因此，如果编译器想要优化只赋值一次的变量，无论变量是否声明为final，它都可以这样做。

Final可能会对protected/public类字段产生影响;在那里，编译器很难发现字段是否被设置了不止一次，因为它可能发生在不同的类中(甚至可能没有被加载)。但即使这样，JVM也可以使用Jon描述的技术(乐观地优化，如果加载了更改字段的类，则恢复)。

总之，我看不出有任何理由它应该有助于性能。 所以这种微观优化不太可能有帮助。您可以尝试对其进行基准测试以确定，但我怀疑它是否会产生影响。

编辑:

实际上，根据Timo Westkämper的回答，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留给present会产生:

   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时(从JIT的角度来看)，这样的方法是单形的——JVM最喜欢这种方法。

然后是最后一个实例变量(必须在每个构造函数中设置);这些是重要的，因为它们将保证一个正确发布的引用，正如这里提到的一点，也由JLS精确指定。

话虽如此，这里还有一件事是每个答案都看不见的:垃圾收集。这将花费大量时间来解释，但是当您读取一个变量时，GC对该读取有一个所谓的障碍。每个loadad和getField都通过这样的屏障“保护”，这里有更多细节。理论上，最终场不需要这样的“保护”(它们可以完全跳过屏障)。因此，如果GC这样做- final将提高性能。

实际上，在测试一些opengl相关代码时，我发现在私有字段上使用final修饰符会降低性能。下面是我测试的类的开头:

public class ShaderInput {

    private /* final */ float[] input;
    private /* final */ int[] strides;


    public ShaderInput()
    {
        this.input = new float[10];
        this.strides = new int[] { 0, 4, 8 };
    }


    public ShaderInput x(int stride, float val)
    {
        input[strides[stride] + 0] = val;
        return this;
    }

    // more stuff ...

这是我用来测试各种替代方案的性能的方法，其中包括ShaderInput类:

public static void test4()
{
    int arraySize = 10;
    float[] fb = new float[arraySize];
    for (int i = 0; i < arraySize; i++) {
        fb[i] = random.nextFloat();
    }
    int times = 1000000000;
    for (int i = 0; i < 10; ++i) {
        floatVectorTest(times, fb);
        arrayCopyTest(times, fb);
        shaderInputTest(times, fb);
        directFloatArrayTest(times, fb);
        System.out.println();
        System.gc();
    }
}

在第三次迭代之后，随着VM的升温，我始终得到了这些没有最后关键字的数据:

Simple array copy took   : 02.64
System.arrayCopy took    : 03.20
ShaderInput took         : 00.77
Unsafe float array took  : 05.47

最后一个关键字:

Simple array copy took   : 02.66
System.arrayCopy took    : 03.20
ShaderInput took         : 02.59
Unsafe float array took  : 06.24

注意ShaderInput测试的图。

将字段设置为公共或私有并不重要。

顺便说一句，还有一些更令人困惑的事情。ShaderInput类的性能优于所有其他变量，即使是final关键字。这是非常了不起的b/c，它基本上是一个包装浮点数组的类，而其他测试直接操作数组。必须把这个弄清楚。可能与ShaderInput的流畅界面有关。

同时系统。arrayCopy对于小数组显然比在for循环中简单地将元素从一个数组复制到另一个数组要慢一些。使用sun.misc.Unsafe(以及直接使用java.nio。FloatBuffer(这里没有显示)执行得非常糟糕。

是的，它可以。下面是一个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。编译器的第一次传递将代码更改为如下内容:

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. 

  }
}

从而减少任何过多的代码，或任何不必要的条件检查。

编辑: 以下面的代码为例:

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
}

我们可以注意到，编译后的代码只包含非最终变量x。 这证明了最终变量对性能有影响，至少在这个简单的情况下是这样。