See: Description
Class | Description |
---|---|
PhantomReference<T> | Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. |
Reference<T> | Abstract base class for reference objects. |
ReferenceQueue<T> | Reference queues, to which registered reference objects are appended by the garbage collector after the appropriate reachability changes are detected. |
SoftReference<T> | Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. |
WeakReference<T> | Weak reference objects, which do not prevent their referents from being made finalizable, finalized, and then reclaimed. |
Each reference-object type is implemented by a subclass of the abstract base
class. An instance of one of these subclasses encapsulates a single reference to a particular object, called the referent. Every reference object provides methods for getting and clearing the reference. Aside from the clearing operation reference objects are otherwise immutable, so no Reference
set
operation is provided. A program may further subclass these subclasses, adding whatever fields and methods are required for its purposes, or it may use these subclasses without change.
ReferenceQueue
class. The relationship between a registered reference object and its queue is one-sided. That is, a queue does not keep track of the references that are registered with it. If a registered reference becomes unreachable itself, then it will never be enqueued. It is the responsibility of the program using reference objects to ensure that the objects remain reachable for as long as the program is interested in their referents.
While some programs will choose to dedicate a thread to removing reference objects from one or more queues and processing them, this is by no means necessary. A tactic that often works well is to examine a reference queue in the course of performing some other fairly-frequent action. For example, a hashtable that uses weak references to implement weak keys could poll its reference queue each time the table is accessed. This is how the
class works. Because the WeakHashMap
method simply checks an internal data structure, this check will add little overhead to the hashtable access methods. ReferenceQueue.poll
Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2025, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.