正如在其他地方提到的，“final”用于局部变量，在较小程度上用于成员变量，更多的是一种风格问题。

'final'是一个声明，你希望变量不变(即，变量不会变化!)然后，如果你违反了自己的约束，编译器可以通过报错来帮助你。

我也认为，如果标识符(对不起，我只是不能把一个不变的东西称为“变量”)默认为final，并且要求你显式地说它们是变量，那么Java将是一种更好的语言。但话虽如此，我通常不会在初始化且从未赋值的局部变量上使用'final';好像太吵了。

(我确实在成员变量上使用final)

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

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

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

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

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

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

编辑:

实际上，根据Timo Westkämper的回答，final在某些情况下可以提高类字段的性能。我接受纠正。

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

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

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

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

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

我不是专家，但我认为你应该在类或方法中添加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。编译器的第一次传递将代码更改为如下内容:

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。 这证明了最终变量对性能有影响，至少在这个简单的情况下是这样。

根据IBM的说法——它不用于类或方法。

http://www.ibm.com/developerworks/java/library/j-jtp04223.html