Java 8 中可访问对象的 JVM 终结：探索
尽管遵循不鼓励使用 Finalize() 的最佳实践，最近从 Java 7 升级到 Java 8 发现了一个意想不到的问题。在这种情况下，当前线程堆栈仍可强访问的对象将在 Java 8 运行时中进行终结。
理解代码和异常
有问题的代码涉及自定义 MIME 库，其中 MIMEBodyPart 类扩展了 HTTPMessage。 HTTPMessage 实现了一个 Finalize() 方法，该方法尝试关闭其关联的输入流，当流在活动 writePart() 操作期间已关闭时会导致异常。
调查原因
由于对意外的最终确定感到困惑，开发人员深入研究了代码和 JVM 行为。发现 MIMEBodyPart 对象确实可以从当前线程的堆栈访问，因此不应该被最终确定。
假设无法访问的可能性
尽管如此尽管该对象明显可达，但理论上 Java 虚拟机 (JVM) 仍然可以将其视为不可访问如果后续代码中没有显式引用。这种“不可达能力”的概念甚至扩展到堆栈上的活动方法调用。
演示不可达性的示例
为了说明此行为，提供了一个简化的代码示例：
class FinalizeThis {
@Override
protected void finalize() {
System.out.println("finalized!");
}
void loop() {
System.out.println("loop() called");
for (int i = 0; i < 1,000,000,000; i++) {
if (i % 1,000,000 == 0)
System.gc();
}
System.out.println("loop() returns");
}
public static void main(String[] args) {
new FinalizeThis().loop();
}
}在此示例中，loop() 方法包含一个定期触发垃圾回收的大规模循环。尽管循环方法主动调用 FinalizeThis 对象的实例方法，但由于该对象明显不可达，JVM 仍会完成该对象并对其进行垃圾回收。
将假设应用到原始场景
据推测，MIMEBodyPart 对象可能会出现类似的情况。如果它存储在局部变量中而没有任何后续引用，则它可能会变得无法访问并容易被最终确定。
更新和其他观察
通过进一步的测试和分析，很明显，JIT 编译器在这种行为中发挥了作用。通过强制方法在执行前进行 JIT 编译（-Xcomp 选项），过早终结的问题再次出现。这表明简化示例中最初缺乏最终确定是由于解释而不是编译，后者执行更积极的可达性分析。
结论
虽然问题的具体情况可能会因具体的代码结构和执行环境而异，但即使对于可到达的对象，由于感知到的不可达性，潜在最终确定的基本概念也值得注意。它强调了理解对象可达性以及活动对象上终结调用的潜在后果的重要性。
以上是为什么可访问的 Java 对象在 Java 8 中最终确定，尽管最佳实践不鼓励'finalize()”？的详细内容。更多信息请关注PHP中文网其他相关文章！
