我从来没有遇到过在变量上有最后一个关键字就能阻止我犯错误的情况，所以目前我认为这是一种巨大的浪费时间。

除非有真正的理由这样做(比如你想要明确指出变量是final的)，否则我宁愿不这样做，因为我发现这样做会使代码的可读性降低。

但是，如果您没有发现它会使代码更难阅读或更长时间地编写，那么无论如何都可以使用它。

编辑:作为一个澄清(并试图赢回反对票)，我不是说不要将常量标记为最终值，我是说不要做这样的事情:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

在我看来，这只是让代码更难阅读。

同样值得记住的是，所有final的作用都是防止你重新分配变量，它并没有使它成为不可变或类似的东西。

在使用final关键字之前，您确实需要了解它的全部用途。它可以应用于变量、字段、方法和类，并对它们产生不同的影响

我建议你看看下面链接的文章，了解更多细节。

关于最后的关键字

我很少在方法或类上使用final，因为我喜欢允许人们重写它们。

否则，我只使用finally如果它是一个公共/私有静态最终类型SOME_CONSTANT;

有效的Java有一个条目写着“偏爱不可变对象”。将字段声明为final可以帮助您在这方面迈出一小步，但是对于真正的不可变对象来说，当然还有更多的事情要做。

如果您知道对象是不可变的，那么可以在多个线程/客户端之间共享它们以供读取，而无需担心同步问题，并且更容易推断程序的运行方式。

我认为这一切都与良好的编码风格有关。当然，你可以编写出好的、健壮的程序，而不需要在任何地方使用大量的最终修饰符，但当你考虑到……

将final添加到所有不应该更改的内容中，只会减少您(或下一个编写代码的程序员)误解或误用导致代码生成的思维过程的可能性。至少当他们现在想要改变你以前不变的东西时，它应该敲响一些警钟。

一开始，在你的代码中看到很多最终的关键字看起来有点尴尬，但很快你就会不再注意这个词本身，只会简单地想，从现在开始，这个东西永远不会改变(你可以从我这里得到;-)

我认为这是很好的练习。我并不是一直都在用它，但当我可以并且有意义的时候，我就会这样做。

当在Java中与变量一起使用时，Final提供了c++中常量的替代品。所以当final和static被用于一个变量时，它就变成了不可变的。同时让迁移的c++程序员非常开心;-)

当与引用变量一起使用时，它不允许您重新引用对象，尽管对象可以被操作。

当final与方法一起使用时，它不允许子类重写该方法。

一旦用法非常清楚，就应该谨慎使用。这主要取决于设计，因为在方法上使用final不利于多态性。

只有当你非常确定变量的值不会/不应该被改变时，才应该将它用于变量。还要确保您遵循SUN鼓励的编码约定。int COLOR_RED = 1;(大写字母以下划线分隔)

对于引用变量，只在需要对特定对象的不可变引用时使用它。

关于可读性部分，在使用最终修饰语时，注释起着非常重要的作用。

为事件监听器使用匿名本地类等是Java中的常见模式。 final关键字最常见的用法是确保偶数侦听器可以访问作用域内的变量。

但是，如果您发现自己被要求在代码中放入大量的最终语句。这可能是你做错事的好暗示。

上面的文章给出了这样一个例子:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

我将它用于方法内部和外部的常量。

我有时只将它用于方法，因为我不知道子类是否不想覆盖给定的方法(无论出于什么原因)。

至于类，我只对一些基础类使用了final类。

IntelliJ IDEA会在函数参数被写入函数内部时发出警告。我已经停止使用final作为函数参数了。我在java运行库中也没有看到它们。

强烈鼓励使用final作为常量。但是，我不会将它用于方法或类(或者至少考虑一下)，因为它使测试更加困难，如果不是不可能的话。如果一定要让一个类或方法成为final，请确保这个类实现了一些接口，这样就可以让一个模拟实现相同的接口。

最后一个修饰符，特别是对于变量，是一种让编译器强制执行通常合理的约定的方法:确保一个(局部或实例)变量只被赋值一次(不多不少)。通过确保变量在使用之前被明确赋值，你可以避免常见的NullPointerException:

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

通过防止变量被多次赋值，可以防止过宽的作用域。而不是这样:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

我们鼓励你这样做:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

一些链接:

最后的故事(《Hardcore Java》一书的免费章节) 一些最终的模式 明确的任务

我一直用final来表示对象属性。

final关键字在对象属性上使用时具有可见性语义。基本上，设置最终对象属性的值发生在构造函数返回之前。这意味着只要不让This引用脱离构造函数，并且对所有属性使用final，对象(在Java 5语义下)就可以保证正确构造，而且由于它也是不可变的，所以可以安全地发布到其他线程。

不可变对象不仅仅是关于线程安全。它们还使您更容易推断程序中的状态转换，因为可以更改的空间是故意的，如果始终使用，则完全限制在应该更改的内容上。

I sometimes also make methods final, but not as often. I seldomly make classes final. I generally do this because I have little need to. I generally don't use inheritance much. I prefer to use interfaces and object composition instead - this also lends itself to a design that I find is often easier to test. When you code to interfaces instead of concrete classes, then you don't need to use inheritance when you test, as it is, with frameworks such as jMock, much easier to create mock-objects with interfaces than it is with concrete classes.

我想我应该把大部分课程都定为期末考试，但我还没有养成这个习惯。

I have to read a lot of code for my job. Missing final on instance variables is one of the top things to annoy me and makes understanding the code unnecessarily difficult. For my money, final on local variables causes more clutter than clarity. The language should have been designed to make that the default, but we have to live with the mistake. Sometimes it is useful particularly with loops and definite assignment with an if-else tree, but mostly it tends to indicate your method is too complicated.

为:

Final fields - Marking fields as final forces them to be set by end of construction, making that field reference immutable. This allows safe publication of fields and can avoid the need for synchronization on later reads. (Note that for an object reference, only the field reference is immutable - things that object reference refers to can still change and that affects the immutability.) Final static fields - Although I use enums now for many of the cases where I used to use static final fields.

考虑但审慎地使用:

最终类——框架/API设计是我唯一考虑的情况。 Final方法——基本上与Final类相同。如果你疯狂地使用模板方法模式，并把东西标记为final，你可能太依赖继承而不是委托。

忽略，除非感觉肛门:

Method parameters and local variables - I RARELY do this largely because I'm lazy and I find it clutters the code. I will fully admit that marking parameters and local variables that I'm not going to modify is "righter". I wish it was the default. But it isn't and I find the code more difficult to understand with finals all over. If I'm in someone else's code, I'm not going to pull them out but if I'm writing new code I won't put them in. One exception is the case where you have to mark something final so you can access it from within an anonymous inner class.

我从不在局部变量上使用它们，没有什么意义。即使您不认为变量应该被重新赋值，这对于下一个改变代码的人来说也没有什么区别，而且由于代码正在被更改，任何使其最终的原始目的都可能不再有效。如果只是为了清晰，我认为它失败了，因为冗长的负面影响。

对于成员变量也是如此，因为它们提供的好处很少，除了常量的情况。

它也与不可变无关，因为不可变的最好指标是它被这样记录并且/或没有可以改变对象的方法(这与使类为final是保证它是不可变的唯一方法)。

但是，嘿，这只是我的观点:-)

我设置Eclipse在所有未修改的字段和属性上添加final。使用Eclipse“save actions”在保存文件时添加这些最终修饰符(以及其他东西)，效果非常好。

强烈推荐。

请查看我关于Eclipse Save Actions的博客文章。

Final显然应该用在常量上，并加强不可变性，但在方法上还有另一个重要的用途。

Effective Java在这方面有一个完整的项目(项目15)，指出了意外继承的陷阱。实际上，如果您没有为继承而设计和记录您的类，那么从它继承可能会带来意想不到的问题(该项目提供了一个很好的例子)。因此，建议在不打算继承的任何类和/或方法上使用final。

That may seem draconian, but it makes sense. If you are writing a class library for use by others then you don't want them inheriting from things that weren't designed for it - you will be locking yourself into a particular implementation of the class for back compatibility. If you are coding in a team there is nothing to stop another member of the team from removing the final if they really have to. But the keyword makes them think about what they are doing, and warns them that the class they are inheriting from wasn't designed for it, so they should be extra careful.

Final应该总是用于常量。当定义变量的规则很复杂时，它甚至对于短期存在的变量(在单个方法中)也很有用。

例如:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

将类标记为final还可以使一些方法绑定发生在编译时而不是运行时。 考虑下面的“v2.foo()”——编译器知道B不能有子类，所以foo()不能被重写，所以要调用的实现在编译时是已知的。如果类B没有被标记为final，那么v2的实际类型可能是某个扩展B并重写foo()的类。

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

另一个注意事项是，许多人将final混淆为实例变量的内容不能更改，而不是引用不能更改。

对于将所有可能的变量都声明为final，我非常武断。这包括方法参数、局部变量，以及很少的值对象字段。我有三个在任何地方声明最终变量的主要原因:

Declaring Intention: By declaring a final variable, I am stating that this variable is meant to be written to only once. It's a subtle hint to other developers, and a big hint to the compiler. Enforcing Single-use Variables: I believe in the idea that each variable should have only one purpose in life. By giving each variable only one purpose, you reduce the time it takes to grok the purpose of that particular variable while debugging. Allows for Optimization: I know that the compiler used to have performance enhancement tricks which relied specifically on the immutability of a variable reference. I like to think some of these old performance tricks (or new ones) will be used by the compiler.

然而，我确实认为final类和方法远不如final变量引用有用。最后一个关键字，当与这些声明一起使用时，只是为自动化测试和以您从未预料到的方式使用代码提供了障碍。

Even for local variables, knowing that it is declared final means that I don't need to worry about the reference being changed later on. This means that when debugging and I see that variable later on, I am confident that it is referring to the same object. That is one less thing I need to worry about when looking for a bug. A bonus is that if 99% of variables are declared final, then the few variables which really are variable stand out better. Also, the final lets the compiler find some more possible stupid mistakes that might otherwise go unnoticed.

对于争论，我认为不需要。大多数情况下，它们只会损害可读性。重新分配一个参数变量是如此疯狂的愚蠢，我应该相当有信心，他们可以被视为常量。

Eclipse将最终结果显示为红色，这使得在代码中更容易发现变量声明，我认为这在大多数情况下提高了可读性。

我试图强制执行规则，任何和所有变量都应该是最终的，没有一个非常有效的理由不这样做。如果你只需要找到初始化并确信这就是初始化，那么回答“这个变量是什么?”的问题就容易得多了。

实际上，我现在对非最终变量相当紧张。这就像把刀挂在你的头上，还是把它放在厨房抽屉里的区别……

final变量是标记值的好方法。

一个非最终变量被绑定到一些容易出错的算法的一部分。

一个很好的特性是，当一个算法无法选择使用变量时，大多数情况下解决方案是编写一个方法，这通常会显著改善代码。

我已经编写了一段时间的代码，并尽可能使用final。这样做了一段时间后(对于变量、方法参数和类属性)，我可以说90%(或更多)的变量实际上是最终的。我认为在你不想修改变量的时候不修改变量的好处(我以前看到过，有时这很痛苦)是为了在你的代码中额外的输入和额外的“final”关键字。

也就是说，如果我要设计一种语言，我将使每个变量都是final，除非被其他一些关键字修改。

对于类和方法，我不太使用final。这是一个或多或少复杂的设计选择，除非您的类是一个实用程序类(在这种情况下，您应该只有一个私有构造函数)。

我也使用Collections.unmodifiable…在我需要的时候创建不可修改的列表

听起来，反对使用最后一个关键字的最大论点之一是“这是不必要的”，而且它“浪费空间”。

如果我们承认“final”的许多好处，同时承认它需要更多的输入和空间，我认为Java应该默认将变量设置为“final”，并且如果编码器想要的话，就要求将变量标记为“mutable”。

选择为每个方法中的每个参数输入final会让编码员和代码读者感到非常恼火。

一旦愤怒超出合理范围，切换到Scala，默认情况下参数是最终的。

或者，您总是可以使用代码样式工具，它将自动为您完成这些工作。所有ide都实现了它们或作为插件。