Detailed explanation
Java reference types express different relationships between an object and the garbage collector (GC). The important distinction is reachability: whether an object can be reached from GC roots, such as active thread stacks and static fields of loaded classes. A strong reference is the ordinary reference created by assignments such as Object value = new Object(). While an object is strongly reachable, GC cannot reclaim it. However, strong references inside an unreachable object graph do not prevent collection, so even cycles can be reclaimed.
Soft references, represented by SoftReference<T>, allow objects to survive some collections when they are no longer strongly reachable. The collector decides when to clear them according to memory demand and implementation policy; they are not cleared exclusively when memory is low. Java guarantees that soft references to softly reachable objects are cleared before an OutOfMemoryError is thrown. They can support memory-sensitive caches, but their unpredictable retention makes explicitly bounded caches preferable when predictable behaviour matters. Calling get() returns the referent if it has not been cleared; otherwise, it returns null.
WeakReference<T> does not keep a weakly reachable object alive. When GC determines that an object is weakly reachable, its weak references are cleared without requiring memory pressure. Saying “at the next GC” is shorthand, not a timing guarantee: collection scope and scheduling matter. Weak references are useful for associations that should not extend object lifetime. WeakHashMap uses weak keys, but its values are strongly referenced; a value that retains its key can prevent that entry from disappearing. In the supplied example, the object has no lasting strong reference and can become eligible for collection immediately.
PhantomReference<T> supports tracking phantom reachability through a ReferenceQueue; get() always returns null. Cleanup code retains the reference object and polls or waits on the queue, without accessing the collected referent. Historically associated with post-finalization cleanup, phantom references should not be explained as requiring a finalizer: finalization is deprecated for removal. Modern Java provides Cleaner for this pattern. Neither approach guarantees prompt cleanup, so external resources should normally use AutoCloseable and try-with-resources.
Key points to remember
- Strong reachability prevents reclamation; unreachable cycles of strong references remain collectible.
- Soft references offer GC-controlled retention, not predictable cache eviction.
- Weak references are cleared when GC detects weak reachability, independently of memory pressure.
- SoftReference.get() and WeakReference.get() can return null; PhantomReference.get() always does.
- Phantom references and Cleaner support fallback cleanup; try-with-resources provides timely resource release.
Common mistakes candidates make
- Claiming every strong reference prevents collection, even when its owning object is unreachable.
- Treating soft-reference clearing as exclusively low-memory behaviour or weak-reference clearing as guaranteed at the very next GC.
- Assuming phantom references expose the referent, require finalization, or guarantee immediate cleanup.
Likely follow-up questions
How should you safely read a weak reference?
Call get() once and store its result in a local variable, then check that variable for null. If non-null, the local provides a strong reference while you use the object; separate get() calls can produce different results.
What is the role of ReferenceQueue?
A ReferenceQueue receives registered reference objects when the collector processes their referents' reachability, allowing application code to react. It can be used with soft, weak, or phantom references, and queue notification does not itself execute cleanup code.
How does Cleaner differ from try-with-resources?
Cleaner runs a registered action after the associated object becomes phantom reachable, with no guarantee of prompt execution; its action must not retain that object. Try-with-resources invokes close() when the block exits, making it the preferred mechanism for timely resource cleanup.
Interview tip: Compare the four types by reachability, get() behaviour, and use case, then qualify any claims about GC timing.