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

目前,我更感兴趣的是,无论是在内存方面还是在对象分配时间方面,可终结化的实际直接成本是多少。我在许多地方都看到过这种成本存在的倾斜引用,例如Oracle's article on finalization memory retention issues注意:



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

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

我们生产并保留数以百万计的重量轻的物体;向这些对象添加单个指针的成本非常高,因此我们做了很多工作来从其中删除指针,而不是使用打包在字段位子集中的较小数字ID。解开数字后,便可以从使用Map存储它们的Pool中检索具有该ID的共享不可变属性。

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

已经考虑的一种策略是使用引用计数。创建对象并检索某个值的合并ID时,该值的引用计数会增加;当它不再使用时,必须递减。

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

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

但是,如果可终结性的行为本身就意味着必须保留指向该对象的附加指针,那么对于此应用程序而言,可终结性的前期成本将被认为很高。如果这意味着必须分配其他对象,那么几乎肯定会太高……因此,我的问题是:可终结性的直接前期成本是多少?

最佳答案

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

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

所有终结器都分两步在对象构造函数的末尾注册:调用from Java to VM,然后调用Finalizer.register()。 JIT编译器无法内联这种Java-> VM-> Java的双重过渡。但是最糟糕的是,终结器的构造函数在global lock下创建了一个链表! (facepalm)

终结器在内存占用方面也很糟糕:除了所有引用字段之外,终结器还具有two extra fields:nextprev

PhantomReferences比终结器要好得多:

  • 它们的构造不需要过渡到VM,也可以过渡到内联;
  • 除了从java.lang.ref.Reference继承外,它们没有其他字段;
  • 不进行全局同步。

  • This benchmark比较可终结对象和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
    

    关于java - 可终结对象的前期成本是多少?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/30131021/

    10-10 19:54