在方法形参中使用final与调用方的实参发生了什么无关。它只是为了将其标记为在该方法中没有更改。当我尝试采用更函数式的编程风格时，我看到了其中的价值。

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

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

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可以省去一些麻烦:

public void setTest(String test) {
    test = test;
}

如果你在setter上忘记了'this'关键字，那么你想设置的变量就不会被设置。但是，如果在参数上使用了final关键字，则在编译时就会捕获错误。

我从不在参数列表中使用final，它只会像之前的受访者所说的那样增加混乱。另外，在Eclipse中，你可以设置参数赋值来生成错误，所以在参数列表中使用final对我来说似乎是多余的。 有趣的是，当我启用Eclipse参数赋值设置时，它生成了一个错误，捕获了这段代码(这只是我记住流程的方式，而不是实际的代码)。：－

private String getString(String A, int i, String B, String C)
{
    if (i > 0)
        A += B;

    if (i > 100)
        A += C;

    return A;
}

唱反调，这样做到底有什么错?

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

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

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