final
中文翻译:最终的；决定性的；不可更改的，可以用来修饰类、方法、变量，分别有不同的意义
- 修饰类：当用final修饰一个类时，表明这个类不能被继承。也就是说，这个类不能其他类继承(反向说如果不想让这个类被继承就使用final进行修饰类)。final类中的成员变量可以根据需要设为final，但是要注意final类中的所有成员方法都会被隐式地指定为final方法
注意：final类中的所有成员方法都会被隐式地指定为final方法也就是方法不能被重写（既然都不能有子类也不会重写，上似乎谁说的有点多余）。一般这个类确定在以后不会用来继承或者出于安全的考虑，尽量不要将类设计为final类。
修饰方法：final 修饰方法也是不可以重写的（override）
修饰变量：如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。注意变量为引用类型时，只是不能改变引用，是可以改变应用类型里的值的，比如引用类型的内部变量
如果你关注过 Java 核心类库的定义或源码， 有没有发现 java.lang 包下面的很多类，相当一部分都被声明成为 final class？在第三方类库的一些基础类中同样如此，这可以有效避免 API 使用者更改基础功能，某种程度上，这是保证平台安全的必要手段。（以下来自：极客时间）
- 使用 final 修饰参数或者变量，也可以清楚地避免意外赋值导致的编程错误，甚至，有人明确推荐将所有方法参数、本地变量、成员变量声明成 final。
- final 变量产生了某种程度的不可变（immutable）的效果，所以，可以用于保护只读数据，尤其是在并发编程中，因为明确地不能再赋值 final 变量，有利于减少额外的同步开销，也可以省去一些防御性拷贝的必要。
final 也许会有性能的好处，很多文章或者书籍中都介绍了可在特定场景提高性能，比如，利用 final 可能有助于 JVM 将方法进行内联，可以改善编译器进行条件编译的能力等等。坦白说，很多类似的结论都是基于假设得出的，比如现代高性能 JVM（如 HotSpot）判断内联未必依赖 final 的提示，要相信 JVM 还是非常智能的。类似的，final 字段对性能的影响，大部分情况下，并没有考虑的必要。
从开发实践的角度，我不想过度强调这一点，这是和 JVM 的实现很相关的，未经验证比较难以把握。我的建议是，在日常开发中，除非有特别考虑，不然最好不要指望这种小技巧带来的所谓性能好处，程序最好是体现它的语义目的。如果你确实对这方面有兴趣，可以查阅相关资料，我就不再赘述了，不过千万别忘了验证一下。
将 class 自身声明为 final，这样别人就不能扩展来绕过限制了。
如上文说道当引用类型变量为final时可以修改其内部值，那说明final不是不可变的。如果我们真的希望对象本身是不可变的，那么需要相应的类支持不可变的行为。如何编写一个不可变的类请参考:JAVA不可变类(immutable)机制与String的不可变性
finally
finally 则是 Java 保证重点代码一定要被执行的一种机制。我们可以使用 try-finally 或者 try-catch-finally 来进行类似关闭 JDBC 连接、保证 unlock 锁等动作。可参考：Exception和Error有什么区别？
注意如下代码finally是不会执行的，特殊例子
try {
// do something
System.exit(1);
} finally{
System.out.println(“Print from finally”);
}finalize
finalize 是基础类 java.lang.Object 的一个方法，它的设计目的是保证对象在被垃圾收集前完成特定资源的回收。finalize 机制现在已经不推荐使用，并且在 JDK 9 开始被标记为 deprecated。
- 使用问题: 你无法保证 finalize 什么时候执行，执行的是否符合预期。使用不当会影响性能，导致程序死锁、挂起等。
Java 平台目前在逐步使用 java.lang.ref.Cleaner 来替换掉原有的 finalize 实现。Cleaner 的实现利用了幻象引用（PhantomReference），这是一种常见的所谓 post-mortem 清理机制。利用幻象引用和引用队列，我们可以保证对象被彻底销毁前做一些类似资源回收的工作，比如关闭文件描述符（操作系统有限的资源），它比 finalize 更加轻量、更加可靠。
Finalizer和DirectBuffer的回收问题