Since Java passes copies of arguments I feel the relevance of final is rather limited. I guess the habit comes from the C++ era where you could prohibit reference content from being changed by doing a const char const *. I feel this kind of stuff makes you believe the developer is inherently stupid as f*** and needs to be protected against truly every character he types. In all humbleness may I say, I write very few bugs even though I omit final (unless I don't want someone to override my methods and classes). Maybe I'm just an old-school dev.

让我来解释一下你必须使用final的一种情况，Jon已经提到过:

如果你在你的方法中创建了一个匿名的内部类，并且在这个类中使用了一个局部变量(比如一个方法参数)，那么编译器会强制你将参数设为final:

public Iterator<Integer> createIntegerIterator(final int from, final int to)
{
    return new Iterator<Integer>(){
        int index = from;
        public Integer next()
        {
            return index++;
        }
        public boolean hasNext()
        {
            return index <= to;
        }
        // remove method omitted
    };
}

这里的from和to参数需要是final，这样它们才能在匿名类中使用。

这种需求的原因是:局部变量存在于堆栈中，因此它们只在方法执行时存在。但是，匿名类实例是从方法返回的，因此它可能存在更长的时间。不能保留堆栈，因为后续的方法调用需要它。

因此，Java所做的是将这些局部变量的副本作为隐藏的实例变量放入匿名类中(如果检查字节代码，您可以看到它们)。但如果它们不是最终的，人们可能会期望匿名类和方法看到另一个对变量所做的更改。为了保持只有一个变量而不是两个副本的错觉，它必须是最终的。

就我个人而言，我不会在方法参数上使用final，因为它给参数列表增加了太多的混乱。 我更倾向于强制方法参数不通过Checkstyle之类的东西改变。

对于局部变量，我尽可能使用final，我甚至让Eclipse在个人项目的设置中自动执行该操作。

我当然喜欢更强的语言，比如C/ c++ const。

简短的回答:最终有一点帮助，但是……在客户端使用防御性编程。

实际上，final的问题在于它只强制引用不变，允许被引用的对象成员发生变化，而调用者不知道。因此，在这方面的最佳实践是在调用方进行防御性编程，创建深度不可变的实例或对象的深度副本，这些实例或对象有被肆无忌惮的api窃取的危险。

是的，除去匿名类、可读性和意图声明，它几乎毫无价值。但这三样东西毫无价值吗?

就我个人而言，我倾向于不对局部变量和参数使用final，除非我在匿名内部类中使用变量，但我当然可以看到那些想要明确参数值本身不会改变的人的观点(即使它引用的对象改变了其内容)。对于那些发现这增加了可读性的人来说，我认为这是一件完全合理的事情。

如果有人真的声称它确实以某种方式保持数据不变，那么你的观点将更加重要——但我不记得看到过任何这样的说法。你的意思是有很多开发者认为final的效果比实际效果更大?

编辑:我真的应该用Monty Python的参考来总结所有这些;这个问题似乎有点类似于问“罗马人为我们做过什么?”

我总是在参数上使用final。

加了那么多吗?不是真的。

我会把它关掉吗?不。

原因:我发现了3个错误，人们编写了草率的代码，未能在访问器中设置成员变量。所有的漏洞都被证明很难找到。

我希望在未来的Java版本中将此设置为默认值。通过值/引用传递的东西绊倒了很多初级程序员。

还有一件事…我的方法倾向于参数数量较少，因此方法声明上的额外文本不是问题。