是的,真的那么不堪! 业界实践一再证明java.lang.Object中的finalize不是个好的办法,在Java 9中,甚至明确将它标记为deprecated!如果没有特别的原因,不要实现finalize方法,也不要指望利用它来进行资源回收。为什么呢?简单说,你无法保证finalize什么时候执行,执行的是否符合预期。相反使用不当会影响性能,导致程序死锁、挂起等。 finalize的执行是和垃圾收集关联在一起的,一旦实现了非空的finalize方法,就会导致相应对象回收呈现数量级上的变慢,有人专门做过benchmark,大概是40-50倍的下降。 因为,finalize被设计成在对象被垃圾收集前调用,这意味着实现了finalize方法的对象是个“特殊公民”,JVM要对它进行额外处理。也就是说,finalize成为了快速回收的阻碍者,可能导致你的对象经过多个垃圾收集周期才能被回收。 有人也许会问,我用System.runFinalization()告诉JVM积极一点,是不是就可以了?也许有点用,但是问题在于,这还是不可预测、不能保证的。所以本质上还是不能指望。实践中,由于finalize拖慢垃圾收集,导致大量对象堆积,也是一种典型的导致OutOfMemeryError的原因。 从另一个角度,我们要确保回收资源就是因为资源是有限的,垃圾收集时间的不可预测,可能会极大加剧资源占用。这意味着对于消耗非常高频的资源,千万不要指望finalize去承担资源释放的主要职责,最多让finalize作为最后的“守门员”,况且它已经暴露了如此多的问题。这也是为什么推荐,资源用完即显式释放,或者利用资源池来尽量重用。 finalize还有一个负作用,就是当在进行资源回收的时候,如果出错似乎除了生吞异常,没有什么好办法。也就是说,你很可能得不到关于此时发生错误的任何有效信息。 既然如此不堪,有什么机制可以替换finalize吗? Java平台从Java 9开始正在逐步使用java.lang.ref.Cleaner来替换掉原有的finalize实现。Cleaner的实现利用了幻象引用(PhantomReference),这是一种常见的所谓post-mortem清理机制。 |
finalize真的那么不堪?
最新推荐文章于 2022-10-23 22:51:11 发布