java - 垃圾收集器行为 - "marking the objects"如何工作？

Question

我发现了一个关于垃圾收集器的有趣问题。
对于以下代码:

class Test {
      Short x = 200;
}

public class MyTest {
    public static void main(String[] args) {
         Test a1 = new Test();
         Test a2 = new Test();
         a1 = null;
         // here
    }
}

当程序到达//这里时，有多少对象将被标记为准备销毁以供 GC？

正确答案是 2，但对于类似的代码:

class Test {
      Short x = 5;
}

public class MyTest {
    public static void main(String[] args) {
         Test a1 = new Test();
         Test a2 = new Test();
         a1 = null;
         // here
    }
}

正确答案是1。

我想到了 JVM 小值缓存，但我不确定。
谁能解释一下 GC 的这种行为吗？

Answer 1

第一个例子:

The correct answer is 2 ...

实际上，我认为根据各种因素，0 到 4 之间的任何数字都可能是正确的。

• 首先，并不清楚首先创建了多少对象。显然创建了两个 Test 对象。但创建的 Short 对象的数量可以是 0、1 或 2。规范规定 Short可以保留值的缓存，但对于 200 个则不需要这样做。如果它不缓存它们，则可能会创建 2 个 Short(2) 对象。如果是，则将创建 0 或 1。 (如果其他代码已经缓存了 Short(200)，则不会创建任何内容)。

• 接下来的问题是哪些变量在指定点真正“Activity ”。显然，a1 和 a2 仍在范围内。但是，GC 将允许将 a1 和 a2 视为“死亡”，因为它们此时无法影响可观察的行为方法。因此，我们无法确定第二个 Test 实例是否会被 GC 视为可访问。

• 最后，由于将 null 分配给 a1 不会影响该方法的可观察行为，因此优化器优化该分配是(可以说)合法的。因此，您可能会遇到这样的情况:a1 仍然包含对 GC 可见的 Test 实例的引用。

在第二种情况下，JLS 保证 Short(5) 将被缓存(通过自动装箱)，因此我们可以确定代码将创建最多 1 个 Short(5) 实例。然而，其他不确定性来源仍然存在。