我发现了一些参考文献（for example）建议尽可能多地使用final，我想知道它有多重要。这主要是在方法参数和局部变量的上下文中，而不是最终方法或类。对于常数，它显然是有道理的。
一方面，编译器可以进行一些优化，这使得程序员的意图更加清晰。另一方面，它增加了详细程度，优化可能是微不足道的。
这是我应该努力记住的事情吗？
痴迷于：
考虑但明智地使用：
忽略除非感觉肛门：
从问题中不清楚这是否显而易见，但制作方法参数final只影响方法的主体。它没有向调用者传达有关方法意图的任何有趣信息。传入的对象仍然可以在方法中变异（决赛不是consts），变量的范围在方法内。
为了回答你的确切问题，除非代码需要它（例如，从内部类引用变量），或者澄清一些非常复杂的逻辑，否则我不会费心去做一个实例或局部变量（包括方法参数）final。
对于实例变量，如果它们是逻辑常数，我会将它们作为最终变量。
变量final有很多用途。这里仅仅是少数
最终常数
public static class CircleToolsBetter {
public final static double PI = 3.141;
public double getCircleArea(final double radius) {
return (Math.pow(radius, 2) * PI);
}
}
这可以用于代码的其他部分，或者由其他类访问，如果你想要更改值，则不必逐个更改它们。
最终变量
public static String someMethod(final String environmentKey) {
final String key = "env." + environmentKey;
System.out.println("Key is: " + key);
return (System.getProperty(key));
}
}
在此类中，您将构建一个作用域的final变量，该变量为参数environmentKey添加前缀。在这种情况下，最终变量仅在执行范围内是最终的，在每次执行该方法时都是不同的。每次输入方法时，都会重建最终结果。一旦构造，就不能在方法执行的范围内更改它。这允许您在方法的持续时间内修改方法中的变量。见下文：
public class FinalVariables {
public final static void main(final String[] args) {
System.out.println("Note how the key variable is changed.");
someMethod("JAVA_HOME");
someMethod("ANT_HOME");
}
}
最终常数
public double equation2Better(final double inputValue) {
final double K = 1.414;
final double X = 45.0;
double result = (((Math.pow(inputValue, 3.0d) * K) + X) * M);
double powInputValue = 0;
if (result > 360) {
powInputValue = X * Math.sin(result);
} else {
inputValue = K * Math.sin(result); // <= Compiler error
}
当你有很长的代码行时，它们会特别有用，它会产生编译器错误，因此当有人意外更改了不应更改的变量时，你不会遇到逻辑/业务错误。
最终收藏
在我们讨论集合时，您需要将它们设置为不可修改的不同情况。
public final static Set VALID_COLORS;
static {
Set temp = new HashSet( );
temp.add(Color.red);
temp.add(Color.orange);
temp.add(Color.yellow);
temp.add(Color.green);
temp.add(Color.blue);
temp.add(Color.decode("#4B0082")); // indigo
temp.add(Color.decode("#8A2BE2")); // violet
VALID_COLORS = Collections.unmodifiableSet(temp);
}
否则，如果您不将其设置为不可修改：
Set colors = Rainbow.VALID_COLORS;
colors.add(Color.black); // <= logic error but allowed by compiler
最终类和最终方法不能分别扩展或覆盖。
编辑：解决关于封装的最终类别问题：
有两种方法可以让课程最终成功。第一种是在类声明中使用关键字final：
public final class SomeClass {
// . . . Class contents
}
使类最终成功的第二种方法是将其所有构造函数声明为private：
public class SomeClass {
public final static SOME_INSTANCE = new SomeClass(5);
private SomeClass(final int value) {
}
如果发现它确实是最终版本，那么将它标记为最终可以省去麻烦，以展示这个Test类。乍一看看起来很公开。
public class Test{
private Test(Class beanClass, Class stopClass, int flags)
throws Exception{
// . . . snip . . .
}
}
不幸的是，由于该类的唯一构造函数是私有的，因此无法扩展此类。对于Test类，没有理由认为该类应该是final。 Test类是隐式final类如何导致问题的一个很好的例子。
所以当你通过使它的构造函数私有来隐式地使类最终时，你应该将它标记为final。
你提到的有点权衡，但我更喜欢使用隐式使用的东西。这将有助于消除未来代码维护者的一些歧义 - 即使只是你。
如果您有内部（匿名）类，并且该方法需要访问包含方法的变量，则需要将该变量作为final。
除此之外，你所说的是对的。
如果要将变量设为final，请将immutable关键字用于变量
通过将变量声明为final，它可以帮助开发人员排除高度多线程环境中变量的可能修改问题。
在Java 8发布版中，我们还有一个名为“effectively final variable”的概念。非最终变量可以作为最终变量。
从lambda表达式引用的局部变量必须是最终的或有效的final
如果在本地块中初始化后未修改变量，则该变量被视为有效最终。这意味着您现在可以在匿名类或lambda表达式中使用没有final关键字的局部变量，前提是它们必须是有效的最终。
直到Java 7，您不能在匿名类中使用非最终局部变量，但是从Java 8可以
看看这个article
一个非常简单的答案我们有3个案例，其中Final有变量，Final有方法&& Final with classes ..
1.Final with variable：你不能多次分配这个变量..
2.Final with methods：你不能覆盖这个方法..
3.Final with classes：你不能扩展任何最后的课程
首先，final关键字用于使变量保持不变。常数意味着它不会改变。例如：
final int CM_PER_INCH = 2.54;
您将声明变量final，因为每英寸厘米不会改变。
如果您尝试覆盖最终值，则变量是首先声明的变量。例如：
final String helloworld = "Hello World";
helloworld = "A String"; //helloworld still equals "Hello World"
有一个编译错误，如：
local variable is accessed from inner class, must be declared final
如果您的变量不能被声明为final或者您不想将其声明为final，请尝试以下操作：
final String[] helloworld = new String[1];
helloworld[0] = "Hello World!";
System.out.println(helloworld[0]);
helloworld[0] = "A String";
System.out.println(helloworld[0]);
这将打印：
Hello World!
A String
这是我应该努力记住的事情吗？
不，如果您正在使用Eclipse，因为您可以配置“保存操作”以自动为您添加这些最终修饰符。然后，您可以轻松获得收益。
“最终”的开发时间优势至少与运行时间优势一样重要。它告诉未来的编辑代码有关你的意图。
将类标记为“final”表示您在设计或实现类时没有努力优雅地处理扩展。如果读者可以对课程进行更改，并希望删除“最终”修饰符，则他们可以自行承担风险。这取决于他们确保课程能够很好地处理扩展。
标记变量“final”（并在构造函数中赋值）对依赖项注入很有用。它表示变量的“协作者”性质。
标记方法“final”在抽象类中很有用。它清楚地描绘了扩展点的位置。
我发现标记方法参数和局部作为final可用作重构辅助，因为所讨论的方法是一个难以理解的混乱几页长。自由地撒上final，看看编译器（或你的IDE）抛出的“无法分配给最终变量”的错误，你可能会发现为什么名为“data”的变量最终为null，即使有几个（过时的）注释发誓不可能发生。
然后，您可以通过将重用的变量替换为更接近使用点的新变量来修复一些错误。然后你会发现你可以将方法的整个部分包装在范围大括号中，突然间你只需要一个远离“提取方法”的IDE键盘，你的怪物就会更容易理解。
如果你的方法还不是一个难以维护的残骸，我想最终可能会有一些东西可以阻止人们把它变成残骸。但如果它是一个简短的方法（参见：不是不可维护的），那么你冒着增加大量冗长的风险。特别是，Java函数签名非常难以适应80个字符，而不是每个参数增加6个字符！
我一直使用final来使Java更基于表达式。看Java的条件（if,else,switch）不是基于表达式的，我一直很讨厌，特别是如果你习惯于函数式编程（即ML，Scala或Lisp）。
因此，在使用条件时，您应该尝试始终（IMHO）使用最终变量。
让我给你举个例子：
final String name;
switch(pluginType) {
case CANDIDATE_EXPORT:
name = "Candidate Stuff";
break;
case JOB_POSTING_IMPORT:
name = "Blah";
break;
default:
throw new IllegalStateException();
}
现在如果添加另一个case语句并且不设置name，编译器将失败。如果你不打破每个案例（你设置变量），编译器也会失败。这允许你使Java非常类似于Lisp的let表达式，并使得代码不会大量缩进（因为词法作用域变量）。
正如@Recurse所指出的那样（但显然是-1我）你可以做前面的事情而不是制作String name final来获得编译器错误（我从来没有说过你不能）但你可以很容易地使编译器错误消失后设置名称switch语句抛弃了表达式语义，或者更糟糕的是忘记了break，你不能在不使用final的情况下导致错误（尽管@Recurse说的话）：
String name;
switch(pluginType) {
case CANDIDATE_EXPORT:
name = "Candidate Stuff";
//break; whoops forgot break..
//this will cause a compile error for final ;P @Recurse
case JOB_POSTING_IMPORT:
name = "Blah";
break;
}
// code, code, code
// Below is not possible with final
name = "Whoops bug";
由于bug设置名称（除了忘记break这也是另一个bug）我现在可以意外地做到这一点：
String name;
switch(pluginType) {
case CANDIDATE_EXPORT:
name = "Candidate Stuff";
break;
//should have handled all the cases for pluginType
}
// code, code, code
// Below is not possible with final
name = "Whoops bug";
最终变量强制单一评估应该是什么名称。类似于具有返回值的函数必须始终返回一个值（忽略异常），名称切换块必须解析名称，从而绑定到该切换块，这使得重构代码块变得更容易（即Eclipe重构：提取方法） 。
OCaml中的上述内容：
type plugin = CandidateExport | JobPostingImport
let p = CandidateExport
let name = match p with
| CandidateExport -> "Candidate Stuff"
| JobPostingImport -> "Blah" ;;
match ... with ...评估就像一个函数，即表达式。注意它看起来像我们的switch语句。
这是Scheme（球拍或鸡肉）中的一个例子：
(define name
(match b
['CandidateExport "Candidate Stuff"]
['JobPostingImport "Blah"]))
好吧，这一切都取决于你的风格...如果你想看到最后你不会修改变量，那么使用它。如果你不喜欢看到它...然后把它留下来。
我个人喜欢尽可能少的冗长，所以我倾向于避免使用非必要的额外关键字。
我喜欢动态语言，所以我喜欢避免冗长也就不足为奇了。
所以，我会说只是选择你倾向的方向，然后继续使用它（无论如何，尽量保持一致）。
作为旁注，我参与了使用和不使用这种模式的项目，我发现错误或错误的数量没有差别...我不认为这是一个巨大的模式改进你的错误计数或任何东西，但同样它是风格，如果你喜欢表达你不会修改它的意图，那么继续使用它。
在参数中有用是为了避免意外更改参数值并引入一个微妙的错误。我用了忽略这个建议，但花了4个小时后。在一个可怕的方法（有数百行代码和多个fors，嵌套ifs和各种不良做法）我建议你这样做。
public int processSomethingCritical( final int x, final int y ){
// hundreds of lines here
// for loop here...
int x2 = 0;
x++; // bug aarrgg...
// hundreds of lines there
// if( x == 0 ) { ...
}
当然，在一个完美的世界中，这不会发生，但是......好吧..有时你必须支持其他代码。 :(
如果你正在编写一个应用程序，有人必须在1年之后读取代码，那么是的，使用final不应该一直修改的变量。通过这样做，您的代码将更加“自我记录”，并且您还可以减少其他开发人员使用本地常量作为本地临时变量等愚蠢行为的机会。
如果你正在写一些一次性代码，那么，不，不要费心去识别所有的常数并使它们成为最终的。
我会尽可能多地使用final。如果您无意中更改了字段，则会执行此操作。我还将Method参数设置为final。这样做我已经从代码中找到了一些错误，当我们尝试“设置”一个忘记Java传递值的参数时，我已经接管了这个错误。