为什么从 java 9 PhantomReference java doc 开始，它就专门用于 POST-mortem 清理操作，尽管它之前是 PRE-mortem

PhantomReference java 8 的 java 文档更少看起来像这样：

幻像引用对象，在收集器之后排队 确定它们的引用对象可以以其他方式被回收。幻影 参考最常用于调度事前清理 行动以比 Java 更灵活的方式 最终确定机制。如果垃圾收集器确定 幻影引用的所指对象是某个时间点 幻影可达，那么在那时或稍后的某个时间它将 将引用排队。

为了确保可回收对象保持这样的状态，引用对象 幻影引用的 get 方法可能无法被检索： 幻像引用始终返回 null。

与软引用和弱引用不同，幻像引用不是 当它们排队时，垃圾收集器会自动清除它们。 可通过幻像引用访问的对象将保持不变 直到所有此类引用被清除或它们本身变得无法访问

PhantomReference java 9 的 java 文档更高的看起来像这样：

幻像引用对象，在收集器之后排队 确定它们的引用对象可以以其他方式被回收。幻影 参考文献最常用于安排死后清理 行动。假设垃圾收集器在某个点确定 当某个对象虚拟可达时。到时候就会 以原子方式清除对该对象和所有幻像的所有幻像引用 对任何其他幻像可达对象的引用 对象是可达的。同时或稍后的某个时间 将那些新清除的已注册的幻像引用排入队列 与参考队列。

为了确保可回收对象保持这样的状态，引用对象 幻影引用的 get 方法可能无法被检索： 幻像引用始终返回 null。

有什么变化吗虚拟参考java 9 中的行为？或者只是java创始人重新考虑了该类的奉献？

从 Java 9 开始，PhantomReference（公关）是自动清除。您看到的是由于该更改而产生的 Javadoc 更改。

在 Java 9 之前，PR 引用的对象保持活动状态，即使其get()会回来null。因此，在 PR 本身死亡之前，所指对象在技术上仍然是活着的，尽管您无法获取对它的引用。这种行为的好处还不是很清楚。无论如何，公关处理将是“事前清理”。

在 Java 9 之后，PR 在入队之前被清除（就像其他类型的弱/软引用一样），在应用程序代码处理 PR 之前，引用对象本身就完全死亡，这将是“事后清理”。