对象最终化的前期成本是多少？

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

目前，我更感兴趣的是可终结的实际直接成本是多少，无论是在内存方面还是在对象分配时间方面。我在很多地方都看到过间接提及这种成本的存在，例如，Oracle 关于终结内存保留问题的文章 http://www.oracle.com/technetwork/java/javamail/finalization-137655.html notes:

When obj分配后，JVM 内部记录obj是可最终确定的。这通常会减慢现代 JVM 所具有的快速分配路径。

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

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

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

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

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

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

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

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

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

在 Oracle JDK / OpenJDK 中，对象具有finalize方法由以下实例支持终结器 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/a006fa0a9e8f/src/share/classes/java/lang/ref/Finalizer.java，子类java.lang.ref.Reference.

所有终结器都通过两个步骤在对象构造函数的末尾注册：调用从Java到VM http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/ade5be2b1758/src/share/vm/opto/parse1.cpp#l1938随后调用终结器.register() http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/a006fa0a9e8f/src/share/classes/java/lang/ref/Finalizer.java#l85。这种双重转换 Java->VM->Java 无法由 JIT 编译器内联。但最糟糕的是 Finalizer 的构造函数在全局锁 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/a006fa0a9e8f/src/share/classes/java/lang/ref/Finalizer.java#l50！ （捂脸）

终结器在内存占用方面也很糟糕：除了它们拥有的所有引用字段之外两个额外字段 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/a006fa0a9e8f/src/share/classes/java/lang/ref/Finalizer.java#l42: next and prev.

幻像引用比终结器要好得多：

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

这个基准 http://pastebin.com/X3C2MMCx比较可终结对象和 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