Phantom References, ReferenceQueue & Cleaner

## Reachability: the foundation The garbage collector keeps an object alive based on how it can be **reached** from the running program's roots (live thread stacks, statics). Java defines four **reference strengths**, from strongest to weakest. The strongest reachability path to an object decides its fate. ## 1. Strong reference (the default) Any ordinary variable or field — `Foo f = new Foo();` — is a **strong reference**. While *any* strong reference chain reaches an object, the GC will **never** collect it. This is what you use 99% of the time. Memory leaks usually come from accidental strong references (e.g. a static list that keeps growing). ## 2. SoftReference — memory-sensitive `SoftReference<T>` (in `java.lang.ref`) lets the GC keep the object **as long as memory allows**. The object is cleared **only when the JVM is under memory pressure** and about to throw `OutOfMemoryError`. `get()` returns the referent until then, or null afterwards. - **Use:** memory-sensitive **caches** — values that are nice to keep but can be recomputed if reclaimed. - **Caveat:** behavior depends on heap size and GC; not a precise cache policy. ## 3. WeakReference — collected eagerly `WeakReference<T>` is cleared **as soon as the object is no longer strongly or softly reachable** — typically at the very next GC. `get()` returns the referent or null once cleared. - **Use:** **canonicalizing maps** and `WeakHashMap` (keys that shouldn't keep entries alive), listener registries, metadata side-tables that must not pin the subject object. - **Contrast with soft:** weak doesn't wait for memory pressure; it lets go promptly. ## 4. PhantomReference — post-mortem only `PhantomReference<T>` is the **weakest**. `get()` **always returns null** by design, so you can never reach or resurrect the referent. Its only role is to be **enqueued onto a ReferenceQueue after the object has been collected**, signalling that it's safe to release **native/off-heap resources**. - **Use:** deterministic, finalizer-free cleanup — directly, or via `Cleaner` which wraps it. - It must be created with a ReferenceQueue (otherwise it's useless). ## The ReferenceQueue link All three non-strong types may be paired with a `ReferenceQueue`; after the GC clears the reference, it **enqueues** it so your code can react. For soft/weak this is optional (you can poll `get()` for null); for phantom it's the **only** signal. ## Ordering during collection Within one GC pass the order is: clear weakly-reachable-only objects, then softly, then enqueue phantoms (after any finalization). The practical mental model: **strong = never collected; soft = collected under memory pressure; weak = collected ASAP; phantom = already collected, here's your cleanup ping.** ## Summary table | Type | get() | Cleared when | Typical use | |---|---|---|---| | Strong | n/a | never (while reachable) | normal code | | Soft | referent/null | under memory pressure | memory-sensitive cache | | Weak | referent/null | next GC once not strong/soft | WeakHashMap, canonical maps | | Phantom | always null | n/a (enqueued post-collection) | native-resource cleanup / Cleaner | ## Key takeaways - Four strengths; weaker = reclaimed sooner. - Soft = cache (memory-pressure), Weak = don't-pin (eager), Phantom = cleanup signal (null get). - ReferenceQueue is optional for soft/weak, mandatory for phantom.