What Are Weak, Soft, and Phantom References?

All three are ways of holding a reference to an object without preventing the garbage collector from reclaiming it. The difference is how eagerly the collector is allowed to reclaim the referent.

A weak reference is cleared as soon as the object is only weakly reachable — that is, as soon as no strong reference remains. There is no guarantee about when it happens, but it happens promptly, because a weak reference is only useful for something you are happy to lose. The canonical use is a cache keyed by an object you do not control, where losing the entry is fine but leaking it is not.

A soft reference is cleared only when the collector is running out of memory. That makes it a gentler cache: the entries survive as long as there is room for them, and are dropped under pressure. The catch is that the timing is not deterministic, so you still need an eviction policy for a bounded cache — a soft reference makes the cache self-limiting under pressure but does not make it bounded.

A phantom reference is never cleared in the useful sense. The referent stays allocated until the phantom reference is enqueued, and get always returns null. It exists for one job: knowing when an object has been determined to be unreachable, which is the closest a Java program can get to a finalisation hook that actually runs reliably. The ReferenceQueue is what tells you the object is gone.

The rule of thumb: weak for a cache you can afford to lose, soft for a cache you want to keep if possible, phantom for post-mortem cleanup such as native resources.

The pattern is a cache whose keys are held weakly, so that an entry disappears when the key object becomes unreachable elsewhere. That way the cache does not keep its own keys alive and cannot become the reason a key is never collected.

import java.lang.ref.WeakReference;
import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        // A cache keyed by weak references: entries disappear when the
        // key is no longer strongly reachable elsewhere.
        List<WeakReference<String>> keys = new ArrayList<>();

        for (int i = 0; i < 5; i++) {
            keys.add(new WeakReference<>(new String("key " + i)));
        }

        System.out.println("references  : " + keys.size());
        int alive = 0;
        for (WeakReference<String> ref : keys) {
            if (ref.get() != null) {
                alive++;
            }
        }
        System.out.println("still alive : " + alive);

        // A reference queue lets you notice when a referent is collected.
        java.lang.ref.ReferenceQueue<String> queue = new java.lang.ref.ReferenceQueue<>();
        java.lang.ref.WeakReference<String> watched =
                new java.lang.ref.WeakReference<>("watched", queue);
        System.out.println("watched     : " + watched.get());
        System.gc();
        System.out.println("queue empty : " + (queue.poll() == null));
    }
}

The output shows the references still holding their referents at the moment of the check, and the reference queue still empty. Whether the referents have been collected by the time you look is up to the collector, which is the whole reason you attach a queue rather than polling.

The ReferenceQueue is what makes the pattern practical. Instead of polling get to find out whether something was collected, you register the reference with a queue and then remove the stale entries from your map when the queue hands them back. That is exactly how the weak-keyed caches in the standard library are implemented.

Two cautions. Do not hold a strong reference to the referent anywhere in the same method — a local variable that shadows it keeps it alive for the whole method and defeats the purpose. And a weak reference alone is not enough for a cache, because the reference objects themselves accumulate; you still need to remove the entries when they are enqueued, which is what the queue is for.