一、概述
将资源释放和清理放在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 执行慢等原因综合导致