Why are Java objects assigned null when they are no longer in use?

preface

Many Java developers have heard the phrase “unused objects should be manually assigned to null”, and many developers have always believed it; The answer to this question is “it helps GC reclaim memory earlier and reduce memory footprint”, but you can’t answer this question further.

In view of the misleading information about this issue, this article will take an in-depth analysis of the existence of the operation “object is no longer in use when assigned to null” by the JVM. This article tries not to use jargon, but you still need to have some idea of the JVM.

The sample code

Let’s look at a very simple piece of code:

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
    }
    System.gc();
}Copy the code

We instantiate an array placeHolder in the if and then pass system.gc () outside the if scope; The GC is manually triggered to reclaim the placeHolder because the placeHolder is no longer accessible. Take a look at the output:

65536 [GC 68239K->65952K, 0.0014820 secs] [Full GC 65952K->65881K, 0.0093860 secs]Copy the code

Full GC 65952K->65881K; Full GC 65952K->65881K; The placeHolder has not been reclaimed by the GC.

Let’s look at the case where “unused objects should be manually assigned to NULL” is followed:

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
        placeHolder = null;
    }
    System.gc();
}Copy the code

Its output is:

65536
[GC 68239K->65952K(125952K), 0.0014910 secs]
[Full GC 65952K->345K(125952K), 0.0099610 secs]Copy the code

After this GC, the memory footprint is reduced to 345K, i.e., placeHolder has been successfully reclaimed! Compare the two pieces of code. Simply assigning the placeHolder value to NULL solves the GC problem, thanks to “unused objects should be manually assigned to NULL”.

PlaceHolder {placeHolder}; placeHolder {placeHolder}; placeHolder {placeHolder}; placeHolder {placeHolder}; That is the crux of the matter.

The runtime stack

A typical runtime stack

If you know anything about compilation, or the underlying mechanics of program execution, you know that when a method executes, variables (local variables) in the method are allocated on the stack; Of course, in Java, the object that comes out of new is in the heap, but there’s also a pointer to that object in the stack, just like int.

For example, for this code:

public static void main(String[] args) {
    int a = 1;
    int b = 2;
    int c = a + b;
}Copy the code

The state of the runtime stack can be interpreted as:

Index variable 1 a 2 b 3 cCopy the code

The “index” indicates the number of variables in the stack, and variables are placed on the stack according to the order in which the code within the method is executed.

Such as:

public static void main(String[] args) {
    if (true) {
        int a = 1;
        int b = 2;
        int c = a + b;
    }
    int d = 4;
}Copy the code

The runtime stack is:

Index variable 1 A 2 b 3 C 4 DCopy the code

Easy to understand? In fact, if you think about this example, there is room for optimization in the runtime stack.

Java stack optimization

In the example above, the main() method takes up four stacks of index space when it runs, but it doesn’t need to. When the if execution is complete, variables A, B, and C are not reachable, so they can be recycled from the stack index 1 to 3, for example:

Index variable 1 a 2 b 3 C 1 dCopy the code

Variable D reuses the stack index of variable A, which saves memory.

remind

The above “runtime stack” and “index” are deliberately invented terms for ease of introduction, and in fact are called “local variable table” and “Slot” in the JVM, respectively. Moreover, the local variable scale is determined at compile time and does not need to wait until “run time”.

The GC glance

Here’s a quick look at a very simple piece of mainstream GC: how to determine that objects can be reclaimed. Another way of saying it is, how do you determine that an object is alive.

If you think about it, in the Java world, objects are related to objects, and we can access from one object to another. As shown in the figure.

If you think about it, the reference relationships between these objects are like a big picture; More specifically, it’s a lot of trees.

If we find all the roots, then we can go down from the roots and find all the living objects, then the objects that are not found are dead! This allows the GC to reclaim those objects.

Now the question is, how do you find the roots? The JVM already has rules, one of which is: objects referenced in the stack. That is, as long as the object in the heap has a reference in the stack, it is considered alive.

remind

The name of the algorithm described above for determining that objects can be reclaimed is “Reachability Analysis Algorithm.”

The JVM “bug”

Let’s go back to our original example:

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
    }
    System.gc();
}Copy the code

Take a look at the runtime stack:

LocalVariableTable:
Start  Length  Slot  Name   Signature
    0      21     0  args   [Ljava/lang/String;
    5      12     1 placeHolder   [BCopy the code

The first index in the stack is the method passing parameter args, which is of type String[]; The second index, placeHolder, is of type byte[].

PlaceHolder hasn’t been reclaimed: system.gc (); There are also references to args and placeHolder in the runtime stack of the main() method when the GC is triggered. The GC determines that both objects are alive and will not be collected. That is, the code in the placeHolder is out of the scope of the if, but there are no reads or writes to the runtime stack, and the index in the placeHolder has not been reused by other variables, so the GC determines it to be alive.

To verify this inference, we use system.gc (); Earlier, declare a variable that will reuse the placeHolder index, as mentioned earlier in “Java stack optimization.”

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
    }
    int replacer = 1;
    System.gc();
}Copy the code

Take a look at the runtime stack:

LocalVariableTable:
Start  Length  Slot  Name   Signature
    0      23     0  args   [Ljava/lang/String;
    5      12     1 placeHolder   [B
   19       4     1 replacer   ICopy the code

Not surprisingly, Replacer reuses placeHolder’s indexes. Let’s take a look at GC:

65536
[GC 68239K->65984K(125952K), 0.0011620 secs]
[Full GC 65984K->345K(125952K), 0.0095220 secs]Copy the code

PlaceHolder has been successfully reclaimed! And our theory was validated.

Int replacer = 1 from the run-time stack; Setting the placeHolder value to null does the same thing: it disconnects the heap from the stack, allowing the GC to determine that the placeHolder is dead.

Now that the principle that unused objects should be manually assigned to null is clear, it all stems from a BUG in the JVM that code is not automatically cut off from the heap when it leaves the variable scope. Why does this “bug” persist? Don’t you think the odds of that happening are small? It’s a tradeoff.

conclusion

Hopefully by this point you’ve understood the meaning behind the saying that unused objects should be manually assigned to NULL. I tend to agree with the author of Understanding the Java Virtual Machine: feel free to use “unused objects should be manually assigned to null,” but it should not be relied upon too much, and should not be generalized as a general rule.