java - 可终结对象的前期成本是多少？

Question

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

目前，我更感兴趣的是，在内存方面和对象分配时间方面，最终化的实际直接成本是多少。我在很多地方看到过对这种成本存在的间接引用，例如 Oracle's article on finalization memory retention issues备注:

When obj is allocated, the JVM internally records that obj is finalizable. This typically slows down the otherwise fast allocation path that modern JVMs have.

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

对于那些对我的具体应用感兴趣的人:

我们生产并保留了数以百万计的重量极轻的元素；向这些对象添加一个指针的成本非常高，因此我们做了一些工作来从它们中删除指针，而不是使用更小的数字 ID 打包到一个字段的位的子集中。解包数字允许从使用 Map 存储它们的池中检索具有该 ID 的共享不可变属性。

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

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

确保此递减发生的一个选项是添加以下 finalize 方法:

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

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

Answer 1

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

在 Oracle JDK/OpenJDK 中，具有 finalize 方法的对象由 Finalizer 的实例支持, java.lang.ref.Reference 的子类。

所有终结器都在对象构造函数的末尾注册，分为两步:调用 from Java to VM随后调用 Finalizer.register() .这种双重转换 Java->VM->Java 不能被 JIT 编译器内联。但最糟糕的是，Finalizer 的构造函数在 global lock 下创建了一个链表。 ! (捂脸)

终结器在内存占用方面也很糟糕:除了所有引用字段外，它们还有 two extra fields : next 和 prev。

PhantomReferences 比终结器好得多:

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

This benchmark比较 finalizable 对象和 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