Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Java reference objects let an application observe certain garbage-collector reachability changes, but they do not provide deterministic control over when memory is reclaimed. A SoftReference can support a memory-sensitive cache, a WeakReference can support canonicalizing mappings, and a PhantomReference can support post-mortem cleanup coordination through a ReferenceQueue.

What reference objects change

An ordinary strong reference keeps its object reachable. The java.lang.ref API adds wrappers that let an object remain eligible for eventual reclamation even while code holds the wrapper. The API describes progressively weaker reachability states: soft, weak, and phantom. In each case, the wrapper does not make reclamation happen on a schedule.

Eligibility is not a promise that collection, clearing, or queue notification will happen immediately. Those events are tied to garbage-collector activity, not a real-time cleanup deadline. The Java reference package documentation defines these reachability concepts and the queue mechanism.

What is the difference between soft, weak, and phantom references?

Type Reachability relationship Documented common use Referent access and notification
SoftReference Not strongly reachable, but reachable through a soft reference Memory-sensitive caches get() can return the referent until the reference is cleared. Clearing is at the collector’s discretion in response to memory demand; a registered reference can also be associated with a queue.
WeakReference Neither strongly nor softly reachable, but reachable through a weak reference Canonicalizing mappings The collector clears weak references when it determines the referent is weakly reachable; a registered reference may be enqueued at the same time or later.
PhantomReference Neither strongly, softly, nor weakly reachable, and finalized Post-mortem cleanup coordination get() always returns null. Use queue notification to learn when the reference reaches the relevant state.

These are Java API descriptions, not promises about a particular collector algorithm. See Oracle’s Java SE 26 documentation for SoftReference, WeakReference, and PhantomReference.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Can a SoftReference guarantee that an object stays cached until memory is low?

No. Java SE 26 specifies that soft references are cleared at the garbage collector’s discretion in response to memory demand. It guarantees that soft references to softly reachable objects will have been cleared before the VM throws OutOfMemoryError, but it does not specify exactly when a reference is cleared or the eviction order among objects. The API encourages implementations to favor recently created or recently used soft references, but that is not a predictable cache policy.

Use soft references only when cache contents are opportunistic and can be recomputed or reloaded. If an application needs explicit limits, expiration, or eviction ordering, use a cache design that implements those rules rather than relying on collector decisions. See the Java SE 26 SoftReference contract.

How WeakReference behaves

A weak reference does not prevent its referent from becoming finalizable and then being reclaimed. The collector clears weak references when it determines that an object is weakly reachable; registered references can be enqueued at that point or later. “The last strong reference disappeared” therefore does not mean that a weak reference is cleared or queued immediately.

Canonicalizing mappings are a documented common use: a mapping can allow an otherwise unreferenced canonical object to become collectible. If code needs a notification when a reference is cleared, it can register the reference with a ReferenceQueue and retain the reference-object wrapper itself while the notification is still needed. The WeakReference API documents the collector behavior and common use.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How ReferenceQueue works

A ReferenceQueue receives reference objects after the collector detects the applicable reachability change and clears them. Application code can check for an entry with poll() or wait for one with remove(). Queue delivery is not a deadline, so it should not be used as a prompt cleanup timer.

The queue does not keep registered reference objects alive. Your application must maintain a strong path to each wrapper for as long as it needs the corresponding notification; otherwise the wrapper itself can be reclaimed before it is enqueued. The reference package documentation explains this retention requirement.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Why PhantomReference.get() returns null

A phantom reference is not a way to recover its referent. Its get() method always returns null; the reference is useful because its associated queue can signal that the collector has determined the referent may otherwise be reclaimed. Phantom references are most often used to coordinate post-mortem cleanup, rather than to access the object during cleanup.

Oracle’s Java SE 26 PhantomReference API defines this behavior. As with other reference types, queue delivery is part of garbage-collector interaction, not a guarantee of immediate execution.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Cleaner and finalization

Java SE 26 marks Object.finalize() deprecated for removal. Do not adopt finalizers as a current cleanup technique. The Object API documentation states the status of finalize().

For managed cleanup, Oracle’s HotSpot Release 26 tuning guide discusses Cleaner. Its implementation guidance recommends sharing Cleaner instances and keeping the cleaning-action class a private implementation detail, immutable where practical. This is HotSpot guide advice, not a guarantee that a Cleaner action will run promptly or at a fixed time. See the HotSpot Virtual Machine Garbage Collection Tuning Guide.

Where reference APIs end and collector tuning begins

The contracts above describe Java reference APIs. Collector selection, flags, and tuning behavior depend on the runtime and version; Oracle’s Release 26 guide covers HotSpot specifically, not every JVM implementation. For broader JVM performance investigation, Oracle’s JDK 26 documentation index also lists monitoring and management guidance.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.