java - Java 中的 "final"类是否可以在某些 JVM 中进行不同的分配？

Question

有没有人知道大多数 JVM 在遇到最终对象时会进行哪些优化(我知道这是特定于实现的)？特别是 Java 中的最终对象数组？例如:

final class A { }
A myArray[] = new A[10];

如果类“A”是final那么它就不能有子类，所以看起来可以分配(而不是调用构造函数)整个数组(即malloc(sizeof(A)* 10))并保存关于垃圾收集/簿记。

Answer 1

我严重怀疑是否有任何 JVM 愿意这样做。部分原因是它可能会产生额外的簿记。任何同时包含在数组中和其他位置的实例都必须进行双重修改以符合 JVM 的规则。

例如。

final class A {
    String value = "default";
}

A instance = new A();
A[] array = new A[] {instance};
instance.value = "another value";
assert instance == array[0];
assert instance.value == array[0].value;

您建议的实现将强制在创建数组时创建 instance 的副本，从而强制 JVM 记住更改 value 的内容，无论何时在 A 的另一个实例中被更改。

---

回应您的评论:

这是一个有趣的想法，在一定程度上会奏效。但是，您的想法会破坏垃圾收集器的性能。原因是最好的 JVM 不使用引用计数。最好的 JVM 使用 moving garbage collector .该技术从所有根节点(例如线程)进行跟踪，以查看引用了哪些对象。引用链中的所有对象都被移动到一个连续的 block 中。该 block 之外的任何内存都被认为是空闲的。没有调用 dealloc 或 finalize 或任何东西。这种技术非常快(部分原因是 GCed 语言中对象的高“婴儿死亡率”)。更重要的是，这种技术不必费心检查循环引用。

回到重点:当数组超出范围时，JVM 必须检查是否有任何其他对数组元素的引用，并为这些对象分配新空间，然后才能释放数组的内存。这阻止了“移动垃圾收集器”的使用，我们不得不回到低效的 GC 技术，如引用计数。因此，虽然您的想法乍一看似乎不错(并且仅适用于特定的边缘情况)，但它阻止了其他可以更广泛应用并提供更大效率节省的 GC 策略。