java - 应该优先使用Java 9 Cleaner而不是定稿吗？

Question

在Java中，重写finalize方法会带来糟糕的说唱效果，尽管我不明白为什么。诸如FileInputStream之类的类使用它来确保在Java 8和Java 10中都调用close。但是，Java 9引入了java.lang.ref.Cleaner，它使用PhantomReference机制而不是GC终结。起初，我认为这只是将终结处理添加到第三方类中的一种方法。但是，its javadoc中给出的示例显示了一个用终结器可以轻松重写的用例。

是否应该按照Cleaner重写所有的finalize方法？ (当然，我没有很多。只有一些使用OS资源的类，尤其是用于CUDA互操作的类。)

如我所知，Cleaner(通过PhantomReference)避免了finalizer的某些危险。特别是，您无权访问已清除的对象，因此您无法复活该对象或其任何字段。

但是，这是我所能看到的唯一优势。清洁也很重要。实际上，它和终结处理都使用ReferenceQueue! (您不只是喜欢阅读JDK多么容易吗？)它比定稿要快吗？是否避免等待两个GC？如果有许多对象排队进行清理，它将避免堆耗尽吗？ (所有这些答案在我看来都是“否”。)

最后，实际上并不能保证阻止您在清理操作中引用目标对象。请仔细阅读较长的API注意!如果最终引用了该对象，则整个机制将无声地中断，这与完成过程总是试图li行一样。最后，虽然终结处理线程由JVM管理，但是创建和保留Cleaner线程是您自己的责任。

Answer 1

您不应将所有finalize()方法替换为Cleaner。弃用finalize()方法和引入(a public)Cleaner是在同一Java版本中发生的事实，仅表明发生了有关该主题的常规工作，而不是一个应被认为可以替代另一个。

该Java版本的其他相关工作是删除不自动清除PhantomReference的规则(是的，在Java 9之前，使用PhantomReference而不是finalize()仍需要两个GC周期来回收对象)并引入 Reference.reachabilityFence(…) 。
finalize()的第一种选择是根本不依赖垃圾回收。如果您说自己没有很多，那很好，但是我在野外看到了完全过时的finalize()方法。问题在于finalize()看起来像是一种普通的protected方法，顽强的神话认为finalize()是某种析构函数仍然散布在某些互联网页面上。将其标记为不赞成使用可向开发人员发出信号，说明情况并非如此，而不会破坏兼容性。使用需要显式注册的机制有助于理解这不是正常的程序流程。当它看起来比覆盖单个方法复杂时，它也不会受到伤害。

如果您的类确实封装了非堆资源，the documentation指出:

Classes whose instances hold non-heap resources should provide a method to enable explicit release of those resources, and they should also implement AutoCloseable if appropriate.

(因此这是首选的解决方案)

The Cleaner and PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable.

因此，当您确实需要与垃圾收集器进行交互时，即使是简短的文档注释也提供了两种选择，因为此处并未将PhantomReference称为Cleaner的对开发人员隐藏的后端；直接使用PhantomReference是Cleaner的替代方法，它使用起来可能更加复杂，但是它还提供了对时序和线程的更多控制，包括在使用资源的同一线程中进行清理的可能性。 (与WeakHashMap相比，它具有这种清理方式，避免了线程安全构造的开销)。它也允许以比静静吞咽它们更好的方式处理清理期间抛出的异常。

但是，即使Cleaner也可以解决您所意识到的更多问题。

一个重要的问题是注册时间。

在执行了finalize()构造函数后，将注册具有非平凡Object()方法的类的对象。此时，该对象尚未初始化。如果初始化异常终止，则仍将调用finalize()方法。用对象的数据来解决这个问题可能很诱人，例如将initialized标志设置为true，但是您只能针对您自己的实例数据说这句话，而不能针对子类的数据说此话，子类的数据在构造函数返回时仍未初始化。

注册一个清理器需要一个完整的Runnable，其中包含用于清理的所有必要数据，而无需引用正在构造的对象。甚至当构造器中没有发生资源分配时，您甚至可以推迟注册(例如未绑定(bind)的Socket实例或未原子连接到显示器的Frame)

可以重写finalize()方法，而无需调用父类(super class)方法或在特殊情况下不这样做。通过将其声明为final来防止该方法被覆盖，这根本不允许子类具有此类清除操作。相反，每个阶层都可以注册清洁工，而不会干扰其他清洁工。

当然，您可以使用封装的对象解决此类问题，但是，可以为每个指向另一个错误方向的类提供finalize()方法的设计。

您已经发现，有一个clean()方法，该方法可以立即执行清理操作并删除清理器。因此，当提供显式的close方法甚至实现AutoClosable时，这是清除，及时处理资源并摆脱所有基于垃圾收集器的清除问题的首选方法。

注意，这与上述要点保持一致。一个物体可以有多个清洁剂，例如由层次结构中的不同类注册。它们中的每一个都可以使用有关访问权限的内在解决方案单独触发，只有注册了清洁程序的人才能使用相关的Cleanable来调用clean()方法。

就是说，经常被忽略的是，使用垃圾收集器管理资源时可能发生的最糟糕的事情不是清理 Action 可能稍后运行或根本不会运行。可能发生的最糟糕的事情是，它运行得太早了。例如，参见finalize() called on strongly reachable object in Java 8。或者，一个非常好的JDK-8145304, Executors.newSingleThreadExecutor().submit(runnable) throws RejectedExecutionException，其中终结器关闭仍在使用的执行程序服务。

当然，仅使用Cleaner或PhantomReference不能解决此问题。但是，在真正需要时删除终结器并实现替代机制是一个机会，可以仔细考虑该主题，并在需要时插入 reachabilityFence s。您可能遇到的最糟糕的事情是一种看起来易于使用的方法，而实际上，该主题非常复杂，其使用的99％可能有一天会中断。

此外，尽管替代方案比较复杂，但您自己说，很少需要它们。这种复杂性仅会影响代码库的一小部分。为什么java.lang.Object(所有类的基类)为什么要托管一种方法来解决Java编程的一种罕见情况？