Understanding Java Reference Types: SoftReference, WeakReference, and PhantomReference Implementation Details

Java defines four reference types—strong, soft, weak, and phantom (plus some final references). Strong references are the default (e.g., Object a = new Object(); ) and have no dedicated Reference class. Soft, weak, and phantom references all inherit from the abstract Reference<T> class, whose core fields include the referent, a ReferenceQueue , and links for internal list management.

The lifecycle of a Reference object involves both native and Java layers. In the native GC phase, discovered references are moved from a DiscoveredList to a PendingList . The Java side processes pending references via the ReferenceHandler thread, which repeatedly calls tryHandlePending(true) to transfer references to their queues and invoke cleanup actions.

SoftReference adds two fields: a static clock and an instance timestamp . The clock is updated each GC cycle; when get() is called, the timestamp is set to the current clock. Whether a soft reference is cleared depends on the ReferencePolicy (e.g., LRUCurrentHeapPolicy or LRUMaxHeapPolicy ), which uses the time interval between the last access and the current GC to decide if memory is “insufficient”.

public abstract class Reference
{
    private T referent;
    volatile ReferenceQueue
queue;
    volatile Reference next;
    transient Reference
discovered;
    private static class Lock {}
    private static Lock lock = new Lock();
    private static Reference
pending = null;
}

WeakReference does not add extra fields; it simply inherits from Reference . The referent is cleared in the third GC phase when clear_referent is true, which is always the case for weak references.

public class WeakReference
extends Reference
{
    public WeakReference(T referent) { super(referent); }
    public WeakReference(T referent, ReferenceQueue
q) { super(referent, q); }
}

PhantomReference overrides get() to always return null . It is used primarily for post‑mortem cleanup; after the referent becomes unreachable, the phantom reference is enqueued, and developers can call clear() to break the link so the object can be reclaimed.

public class PhantomReference
extends Reference
{
    public T get() { return null; }
    public PhantomReference(T referent, ReferenceQueue
q) { super(referent, q); }
}

A demo shows that a phantom reference’s get() returns null , the reference is enqueued after System.gc() , and the original object remains alive until clear() is invoked.

public static void demo() throws InterruptedException {
    Object obj = new Object();
    ReferenceQueue
refQueue = new ReferenceQueue<>();
    PhantomReference
phanRef = new PhantomReference<>(obj, refQueue);
    System.out.println(phanRef.get()); // null
    obj = null;
    System.gc();
    Thread.sleep(3000);
    Reference
enqueued = refQueue.remove();
    System.out.println(enqueued == phanRef); // true
}

The article also answers three common interview questions: (1) “Memory insufficient” for soft references is defined by the LRU policy using the clock and available heap size; (2) phantom references do affect object lifetime because the referent is not cleared automatically—developers must call clear() ; (3) a typical use case is the Cleaner in DirectByteBuffer for off‑heap memory reclamation.