final、 finally、 finalize的区别

初步了解

典型回答

final可以用来修饰类、方法、变量，分别有不同的意义， final修饰的class代表不可以继承扩展， final的变量是不可以修改的，而final的方法也是不可以重写的（ override）。
finally则是Java保证重点代码一定要被执行的一种机制。我们可以使用try-finally或者try-catch-finally来进行类似关闭JDBC连接、保证unlock锁等动作。
finalize是基础类java.lang.Object的一个方法，它的设计目的是保证对象在被垃圾收集前完成特定资源的回收。 finalize机制现在已经不推荐使用，并且在JDK 9开始被标记为deprecated。

问题解析
这是一个非常经典的Java基础问题，上面的回答主要是从语法和使用实践角度出发的，其实还有很多方面可以深入研究讨论，还可能会考察队性能、并发、对象生命周期收集基本过程等方面的理解。

推荐使用final关键字来明确表示代码的语义、逻辑意图，已经被证明是在很多场景下是非常好的实践，如：

• 可以将方法或者类声明为final，这样可以明确告知这些行为是不可以修改的
  如果关注过Java核心类库的定义或源码， 有没有发现java.lang包下面的很多类，很多都被声明成为final class？在第三方类库的一些基础类中同样如此，这可以有效避免API使用者更改基础功能，某种程度上，这是保证平台安全的必要手段。
• 使用final修饰参数或者变量，可以清楚的避免意外赋值导致的编程错误，甚至有人明确推荐将所有方法参数、本地变量、成员变量声明成final
• final变量产生了某种程度的不可变的效果，所以可用于保护只读数据，尤其是在并发编程中，因为明确的不能再复制final变量，有利于减少额外的开销，也可以省去一些防御性拷贝的必要

final可能会有性能的好处，很多的文章或书籍中都介绍了可以在特定场景下提高性能，如利用final可能有利于JVM将方法进行内联，可以改善编译器进行条件编译能力等等。但是很多类似的结论都是基于假设得出的，比如现代高性能JVM(如HotSpot)判断内联未必依赖final的提示，相信JVM还是很智能的。

对于finally，明确知道怎么使用就足够了。需要关闭的连接等资源，更推荐使用Java 7中添加的try-with-resources语句，因为通常Java平台能够更好地处理异常情况，编码量也要少很多，何乐而不为呢。

另外有一些常被考到的finally(比较偏门)，至少需要了解一下。

	try {
		// do something
		Sysem.exit(1);
	} fnally{
		Sysem.out.println(“Print from fnally”);
	}

上面finally里面的代码可不会被执行的哦，这是一个特例。

对于finalize，我们要明确它是不推荐使用的，业界实践一再证明它不是个好的办法，在Java 9中，甚至明确将Object.fnalize()标记为deprecated！如果没有特别的原因，不要实现finalize方法，也不要指望利用它来进行资源回收。

这是因为你无法保证fnalize什么时候执行，执行的是否符合预期。使用不当会影响性能，导致程序死锁、挂起等。

通常来说，利用上面的提到的try-with-resources或者try-finally机制，是非常好的回收资源的办法。如果确实需要额外处理，可以考虑Java提供的Cleaner机制或者其他替代方法。

深入了解

1、注意，final不是immutable！！！
在前面已经介绍了final在实践中的好处，需要注意的是，final并不等同于immutable，例如下面的这段代码：

	final List<String> list = new ArrayList<>();
	list.add("Hello");
	list.add("world");
	List<String> unmodifableStrList = List.of("hello", "world");
	unmodifableStrList.add("again");

final只能约束list这个引用不可以被赋值，但是list对象行为不被final影响，添加元素等操作完全是正常的。如果真的希望对象本身是不可变的，那么需要相应的类支持不可变的行为。上面的例子中，List.of方法创建的本身就是不可变的list，最后add是会在运行时抛出异常的，是JDK 9新增的方法。

Immutable在很多场景是非常棒的选择，某种意义上说， Java语言目前并没有原生的不可变支持，如果要实现immutable的类，需要做到：

• 将class自身声明成final，这样别人就不能扩展来绕过限制了
• 将所有成员变量定义为private和final，并且不要实现setter方法
• 通常构造对象时，成员变量使用深度拷贝来初始化，而不是直接赋值，这是一种防御措施，因为无法确认输入对象不被其他人修改
• 如果确实需要实现getter方法，或者其他可能会返回内部状态的方法，使用copy-on-write原则，创建私有的copy，
  这些原则在并发编程实践中经常被提到。
  关于setter/getter方法，很多人喜欢直接用idea一次全部生成，但是这里建议最好确定有需要时再实现。

2、finalize真的向前面所说的那么不好用？？？
前面已经简单介绍了一些非常不好的实践，但是为什么会导致这些问题呢？？？

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

这是因为finalize被设计成在对象被垃圾收集前调用，这也就意味着实现了finalize方法的对象是个“特殊公民”，JVM要对他进行额外处理。finalize本质上成为了快速回收的阻碍者，可能导致对象经过多个垃圾收集周期才能被回收。

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

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

finalize还会掩盖资源回收时的出错信息，看下面一段jdk的源码，截取自java.lang.ref.Finalizer

	private void runFinalizer(JavaLangAccess jla) {
	// ... 省略部分代码
	try {
		Object finalizee = this.get();
		if (finalizee != null && !(finalizee insanceof java.lang.Enum)) {
			jla.invokeFinalize(finalizee);
			// Clear sack slot containing this variable, to decrease
			// the chances of false retention with a conservative GC
			finalizee = null;
		}
	} catch (Throwable x) { }
	super.clear();
}

这段代码的问题是：这里的Throwable是被生吞了的！ 也就意味着一旦出现异常或者出错，你得不到任何有效信息。况且， Java在finalize阶段也没有好的方式处理任何信息，不然更加不可预测。

3、有什么机制可以替换finalize吗？？？
Java平台目前在逐步使用java.lang.ref.Cleaner来替换掉原有的finalize实现。 Cleaner的实现利用了幻象引用（ PhantomReference），这是一种常见的所谓post-mortem清理机制。会在后面的专栏系统中介绍Java的各种引用，利用幻象引用和引用队列，我们可以保证对象被彻底销毁前做一些类似资源回收的工作，比如关闭文件描述符（操作系统有限的资源），它比finalize更加轻量、更加可靠。

吸取了finalize里的教训，每个Cleaner的操作都是独立的，有自己的运行线程，因此可以避免意外死锁等问题。

实践中，可以为自己的模块构建一个cleaner，然后实现相应的清理逻辑。下面是jdk自身提供的样例程序。

	public class CleaningExample implements AutoCloseable {
		// A cleaner, preferably one shared within a library
		private static final Cleaner cleaner = <cleaner>;
		static class State implements Runnable {
			State(...) {
			// initialize State needed for cleaning action
			}
			public void run() {
			// cleanup action accessing State, executed at mos once
			}
		}
		private final State;
		private final Cleaner.Cleanable cleanable
		public CleaningExample() {
			this.state = new State(...);
			this.cleanable = cleaner.regiser(this, sate);
		}
		public void close() {
		cleanable.clean();
		}
	}

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

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

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