一、概述
将资源释放和清理放在finalize方法中非常不好，非常影响性能，严重时甚至会引起OOM（Out Of Memory），从Java9开始就被标注为@Deprecated，不建议被使用了。
二、两个重要的队列
1、unfinalized 队列
当重写了finalize方法的对象，在构造方法调用之时，JVM都会将其包装成一个Finalizer 对象，并加入unfinalized 队列中(静态成员变量、双向链表结构)
2、ReferenceQueue队列
第二个重要的队列，也是Finalizer类中一个静态成员变量，名为queue(是一个单向链表构)，刚开始它是空的。当狗对象可以被当作垃圾回收时，就会把这些狗对象对应的Finalizer对象加入这个队列。
三、真正的回收时刻
- 即使Dog对象没人引用，垃圾回收时也没法立刻回收它，因为Finalizer还在引用它嘛，为的是（先别着急回收啊,等我调完finalize方法，再回收）
- 查看FinalizerThread线程内的代码，这个线程从ReferenceQueue 中逐一取出每个 Finalizer对象，把它们从链表断开，这样没谁能引用到它，以及其对应的狗对象，所以下次gc时就可以被回收了
四、为什么finalize方法非常不好，非常影响性能
1、非常不好
- FinalizerThread是守护线程，代码很有可能没来得及执行完，线程就结束了，造成资源没有正确释放
- 异常被吞掉这个就太糟了，你甚至不能判断有没有在释放资源时发生错误
2、影响性能
- 重写了finalize 方法的对象在第一次被gc时，并不能及时释放它占用的内存，因为要等着FinalizerThread调用完finalize,把它从第一-个unfinalized队列移除后，第二次gc时才能真正释放内存.
- 可以想象gc本就因为内存不足引起，finalize 调用又很慢( 两个队列的移除操作，都是串行执行的，用来释放连接类的资源也应该不快)，不能及时释放内存，对象释放不及时就会逐渐移入老年代,老年代垃圾积累过多就会容易full gc, full gc后释放速度如果仍跟不上创建新对象的速度,就会OOM.
3、质疑
- 有的文章提到【Finalizer线程会和我们的主线程进行竞争，不过由于它的优先级较低，获取到的CPU时间较少，因此它永远也赶不上主线程的步伐】这个显然是错误的，FinalizerThread的优先级较普通线程更高，赶不上步伐的原因应该是finalize 执行慢等原因综合导致
