垃圾收集器的行为-“标记对象”如何工作？

Question

I've found an interesting question about garbage collector.
For the following code:

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
    }
}

How many objects will be marked as ready to destroy for GC when the program reaches // here?

The correct answer is 2 but for similar code:

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
    }
}

the correct answer is 1.

JVM small values caching comes to my mind but i'm not sure.
Can anyone explain this behaviour of GC?

Answer 1

The GC will typically use all your global variables and the variables on all your threads as roots, mark them as alive (reachable) and then recursively follow the references they contain and mark those referenced objects as alive, and so on. The objects that weren't marked as alive will be assumed dead (unreachable) and will be collected.

For boxed types, which are classes and, therefore, their instances are subject to GC cycles, a JVM implementation is required to cache at least a particular range of numerical values around zero:

If the value p being boxed is true, false, a byte, or a char in the range \ to \, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Therefore, these cached instances, even if they aren't reachable from GC roots in the user code, are always marked as alive by the JVM itself and thus they won't be collected.

Needless to say, you should't rely on this for equality checks, as the exact range of values that the JVM caches is determined by each particular implementation:

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

Answer 2

For the first example:

The correct answer is 2 ...

Actually, I think that depending on various factors, any number between 0 and 4 could be correct.

• First of all, it is not clear how many objects have been created in the first place. There are clearly two Test objects created. But the number of Short objects that were created could be 0, 1 or 2. The specs say that Short may keep a cache of values, but for 200, it is not required to. If it doesn't cache them, 2 Short(2) objects may be created. If it does, then either 0 or 1 will be created. (None will be created if some other code has already cached a Short(200) ).

• Next there is the issue of what variables are really "live" at the indicated point. Clearly, a1 and a2 are still in scope. However, the GC would be allow to treat both a1 and a2 as "dead" because they cannot influence the observable behavior method at that point. Hence we cannot say whether the second Test instance would be treated as reachable by the GC.

• Finally, since the assignment of null to a1 does not influence the observable behavior of the method, it is (arguably) legitimate for the optimizer to optimize that assignment away. Hence, you might get the situation where a1 still contains reference to a Test instance that is visible to the GC.

In the second case, the JLS guarantees that Short(5) will be cached (by autoboxing), so we can be sure that the code will create at most 1 Short(5) instance. However, the other sources of uncertainty still apply.