Why Setting Unused Objects to null Can Boost Java GC – The Real Reason

Preface

Many Java developers have heard the advice “set unused objects to null”, believing it helps the GC reclaim memory earlier, but often cannot explain why.

Example Code

First we show a simple program that allocates a large byte array inside an if block, prints its size, and then calls System.gc() without nulling the reference.

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

The GC output shows that the memory used by placeHolder is not reclaimed.

Assigning null

When we add placeHolder = null; before the GC call, the same program produces a Full GC log where the memory drops dramatically, confirming that the explicit null assignment makes the object collectible.

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();
}

Runtime Stack

Typical Stack Layout

Local variables are stored in the JVM’s stack frame. When a method executes, each variable occupies a slot (called a “Slot” in the JVM specification). After the if block finishes, the slots for a, b, and c are still present until the method returns.

Java Stack Optimisation

The JVM can reuse slots that are no longer needed. In the second example we introduce an extra variable replacer after the if block; the compiler reuses the slot previously held by placeHolder, effectively breaking the reference to the heap object.

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();
}

The GC log now shows that the memory is reclaimed, demonstrating that slot reuse has the same effect as assigning null.

GC Overview

The GC determines object liveness by reachability from “GC roots”, one of which is the set of references stored in stack frames. If a reference remains in a slot, the object is considered alive.

JVM “Bug”

When a variable goes out of scope, the JVM does not automatically clear its slot, so the object may stay reachable until the slot is overwritten or the method returns. This is a trade‑off rather than a bug, because the probability of premature collection is low.

Conclusion

Explicitly setting large, short‑lived objects to null can help the GC in certain situations, but it should not be treated as a universal rule.

Zhou Zhimin. Deep Understanding of the Java Virtual Machine: Advanced Features and Best Practices . Mechanical Industry Press, 2013.