在Java中，我们看到很多地方可以使用final关键字，但它的使用并不常见。
例如:
String str = "abc";
System.out.println(str);
在上面的例子中，str可以是final，但通常不使用。
当一个方法永远不会被覆盖时，我们可以使用final关键字。类似地，类不会被继承。
在任何或所有这些情况下使用final关键字真的能提高性能吗?如果是，那该怎么做?请解释一下。如果final的正确使用确实关系到性能，那么Java程序员应该养成什么样的习惯才能最好地利用这个关键字呢?
当前回答
简单的回答:不用担心!
长一点的回答:
在讨论final局部变量时，请记住使用关键字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局部变量时，请记住使用关键字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。编译器的第一次传递将代码更改为如下内容:
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。 这证明了最终变量对性能有影响，至少在这个简单的情况下是这样。
令我惊讶的是，居然没有人发布一些经过反编译的真实代码，以证明至少有一些小的差异。
作为参考，已经在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将提高性能。
正如在其他地方提到的，“final”用于局部变量，在较小程度上用于成员变量，更多的是一种风格问题。
'final'是一个声明，你希望变量不变(即，变量不会变化!)然后，如果你违反了自己的约束，编译器可以通过报错来帮助你。
我也认为，如果标识符(对不起，我只是不能把一个不变的东西称为“变量”)默认为final，并且要求你显式地说它们是变量，那么Java将是一种更好的语言。但话虽如此，我通常不会在初始化且从未赋值的局部变量上使用'final';好像太吵了。
(我确实在成员变量上使用final)
final关键字在Java中有五种使用方式。
一门课是最终的 引用变量是最终变量 局部变量是final 方法是最终的
类是最终的:类是最终的意味着我们不能被扩展，继承意味着继承是不可能的。
类似地-一个对象是最终对象:有时我们不修改对象的内部状态，所以在这种情况下，我们可以指定对象是最终对象。Object final意味着不是变量也是final。
一旦引用变量成为final，它就不能被重新分配给其他对象。但是可以改变对象的内容，只要它的字段不是final的
