9

Java 中可终结对象的讨论通常会讨论当可终结对象（及其相关资源）无法快速垃圾回收时发生的常见间接成本。

目前，我对最终化的实际直接成本更感兴趣，无论是在内存方面还是在对象分配时间方面。我在很多地方都看到过对这种成本存在的间接引用，例如，Oracle 关于终结内存保留问题的文章指出：

分配时obj，JVM 内部记录是obj可终结的。这通常会减慢现代 JVM 拥有的其他快速分配路径。

JVM 如何记录对象实例是可终结的，这样做的内存和性能成本是多少？

对于那些对我的特定应用感兴趣的人：

我们生产并保留了数百万个令人难以置信的轻量级物体；向这些对象添加单个指针的成本非常高，因此我们做了相当多的工作来从它们中删除指针，而不是使用更小的数字 id 打包到字段的位子集中。解包数字允许从使用 Map 存储它们的池中检索具有该 id 的共享不可变属性。

剩下的问题是如何处理不再使用的属性值的垃圾收集。

已考虑的一种策略是使用引用计数。当创建对象并检索一个值的池 id 时，该值的引用计数会增加；当不再使用时，必须递减。

确保发生这种递减的一种选择是添加以下 finalize 方法：

public void finalize() {
    Pool.release(getPropertyId());
}

但是，如果可终结的行为本身就意味着必须保留一个指向对象的附加指针，那么对于此应用程序而言，可终结的前期成本将被认为是高昂的。如果这意味着必须分配额外的对象，那几乎肯定会太高......因此，我的问题是：最终化的直接前期成本是多少？

4

1 回答 1

8

终结器很糟糕 ，不仅因为保留问题，而且从性能角度来看也是如此。

在 Oracle JDK/OpenJDK 中，具有方法的对象由Finalizerfinalize的实例支持，它是.java.lang.ref.Reference

所有的终结器都在对象的构造函数的末尾分两步注册：从 Java 到 VM的调用，然后是Finalizer.register()的调用。这种双重转换 Java->VM->Java 不能被 JIT 编译器内联。但最糟糕的是，Finalizer 的构造函数在全局锁下做了一个链表！（捂脸）

终结器在内存占用方面也很糟糕：除了所有 Reference 字段外，它们还有两个额外的字段:next和prev.

PhantomReferences 比终结器好得多：

  • 它们的构造不需要过渡到 VM 并返回，并且可以内联；
  • 除了继承自之外，它们没有额外的字段java.lang.ref.Reference；
  • 没有进行全局同步。

该基准比较了可终结对象和 PhantomReference 支持的对象的分配速度：

Benchmark               Mode  Cnt       Score      Error   Units
Finalizer.finalizable  thrpt    5    2171,312 ± 1469,705  ops/ms
Finalizer.phantom      thrpt    5   61280,612 ±  692,922  ops/ms
Finalizer.plain        thrpt    5  225752,307 ± 7618,304  ops/ms
于 2015-05-08T21:12:43.320 回答