为:

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会让编码员和代码读者感到非常恼火。

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

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

我一直用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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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