final，finally，finalize有什么区别

初步了解

这是一道非常典型的面试题，而它也是有一系列的典型回答的：

final可以用来修饰类、方法、变量，分别有不同的意义所在，final修饰的class代表不可继续扩展，final修饰的变量代表不可修改，final修饰的方法代表不可重写。
 
finally则是java保证某一段重点代码一定要被执行的修饰符，例如：我们需要用try块让JDBC保证连接，保证unlock锁等动作
 
finalize是基础类java.lang.Object的一个方法，它的设计目的是为了保证对象在垃圾回收之前完成特定资源的回收

如果你有关注过JAVA核心类库的基本API就会发现lang包下的很多类，相当一部分都被声明为了final class，就是因为一些安全问题的存在，让其他人在调用API的时候避免修改基础功能，可以保证平台的安全性。

而用final修饰变量也是同理，防止意外的去修改一些变量的值。

而从性能上来讲：
有助于JVM将方法进行内联，改善编译器进行条件编译的能力。

对于finally，明确知道如何使用即可，一般都是结合try块进行联合使用。

对于fnalize，我们要明确它是不推荐使用的，业界实践一再证明它不是个好的办法，在Java 9中，甚至明确将Object.fnalize()标记为deprecated！如果没有特别的原因，不要实 现fnalize方法，也不要指望利用它来进行资源回收。
为什么呢？简单说，你无法保证fnalize什么时候执行，执行的是否符合预期。使用不当会影响性能，导致程序死锁、挂起等。

知识扩展

1.final不是immutable

之前在前面简单介绍了final，但是final不等同于immutable，比如下面这段代码：

然后运行，在第13行报错

说是不支持第13行的操作，可见，虽然被final修饰，但是还是可以改变其长度的，但如果我们将其本身的对象定义为immutable，那么才是真的不可变长。

Immutable在很多场景都是都是非常棒的选择，某种意义上来说，Java语言没有原生的不可变支持，如果要实现immutable，那么我们需要

1. 用final修饰class
2. 将所有成员属性修饰为private和final并且不实现setter方法
3. 构造对象使用深度拷贝来初始化
4. 用copy-on-write实现getter方法，创建私有copy

2.finalize是否真的那么不堪

finalize一般和垃圾回收绑定在一起，一旦实现了非空的finalize，那么就会导致相应对象回收呈现数量级上的变慢，有人专门做过benchmark，大概是40-50倍的下降。

因为finalize被设计成了在垃圾回收之前就已经生效了，代表着，JVM要对它进行特殊处理，也就成为了快速回收的阻碍者，可能会反而导致垃圾经过几个周期才能被回收干净。

也许会有人问，我用System.runFinalization​()告诉JVM积极一点，是不是就可以了？也许有点用，但是问题在于，这还是不可预测、不能保证的，所以本质上还是不能指望。实践 中，因为fnalize拖慢垃圾收集，导致大量对象堆积，也是一种典型的导致OOM的原因。

从另一个角度，我们要确保回收资源就是因为资源都是有限的，垃圾收集时间的不可预测，可能会极大加剧资源占用。这意味着对于消耗非常高频的资源，千万不要指望fnalize去承 担资源释放的主要职责，最多让fnalize作为最后的“守门员”，况且它已经暴露了如此多的问题。这也是为什么我推荐，资源用完即显式释放，或者利用资源池来尽量重用。

下面贴出取自java.lang.ref.Finalizer的某段代码

我们可以看出，最后的clear将Throwable的Exception清除了，换句话说，如果我们得到了异常，是无法知道这个异常确实出现的。
并且其本身也没有什么好的方法对异常进行什么其他的处理，所以我们一般会用一种其他的机制来改善这种做法。

3.替换finalize

java平台将finalize进行了一定的替代。Cleanner的实现利用了幻象引用（PhantomReference）。
幻象引用（PhantomReference）：不能通过它来访问对象， 幻想引用仅仅是提供了一种确保对象被 finalize 以后，做某些事情的机制。，比如，通常用来做所谓的 Post-Mortem 清理机制， Java 平台自身 Cleaner 机制等，也有人利用幻想引用监控对象的创建和销毁。

吸取了finalize一定的教训，每一个cleanner的操作都是独立的，它有自己的运行现成，所以避免了意外死锁。

注意，从可预测性的角度来判断，Cleaner或者幻象引用改善的程度仍然是有限的，如果由于种种原因导致幻象引用堆积，同样会出现问题。所以，Cleaner适合作为一种最后的保 证手段，而不是完全依赖Cleaner进行资源回收，不然我们就要再做一遍fnalize的噩梦了。

我也注意到很多第三方库自己直接利用幻象引用定制资源收集，比如广泛使用的MySQL JDBC driver之一的mysql-connector-j，就利用了幻象引用机制。幻象引用也可以进行类 似链条式依赖关系的动作，比如，进行总量控制的场景，保证只有连接被关闭，相应资源被回收，连接池才能创建新的连接。

另外，这种代码如果稍有不慎添加了对资源的强引用关系，就会导致循环引用关系，前面提到的MySQL JDBC就在特定模式下有这种问题，导致内存泄漏。上面的示例代码中， 将State定义为static，就是为了避免普通的内部类隐含着对外部对象的强引用，因为那样会使外部对象无法进入幻象可达的状态。