- Direct Known Subclasses:
PhantomReference
,SoftReference
,WeakReference
public abstract class Reference<T> extends Object
- Since:
- 1.2
-
Method Summary
Modifier and Type Method Description void
clear()
Clears this reference object.protected Object
clone()
ThrowsCloneNotSupportedException
.boolean
enqueue()
Clears this reference object and adds it to the queue with which it is registered, if any.T
get()
Returns this reference object's referent.boolean
isEnqueued()
Tells whether or not this reference object has been enqueued, either by the program or by the garbage collector.static void
reachabilityFence(Object ref)
Ensures that the object referenced by the given reference remains strongly reachable, regardless of any prior actions of the program that might otherwise cause the object to become unreachable; thus, the referenced object is not reclaimable by garbage collection at least until after the invocation of this method.
-
Method Details
-
get
Returns this reference object's referent. If this reference object has been cleared, either by the program or by the garbage collector, then this method returnsnull
.- Returns:
- The object to which this reference refers, or
null
if this reference object has been cleared
-
clear
public void clear()Clears this reference object. Invoking this method will not cause this object to be enqueued.This method is invoked only by Java code; when the garbage collector clears references it does so directly, without invoking this method.
-
isEnqueued
public boolean isEnqueued()Tells whether or not this reference object has been enqueued, either by the program or by the garbage collector. If this reference object was not registered with a queue when it was created, then this method will always returnfalse
.- Returns:
true
if and only if this reference object has been enqueued
-
enqueue
public boolean enqueue()Clears this reference object and adds it to the queue with which it is registered, if any.This method is invoked only by Java code; when the garbage collector enqueues references it does so directly, without invoking this method.
- Returns:
true
if this reference object was successfully enqueued;false
if it was already enqueued or if it was not registered with a queue when it was created
-
clone
ThrowsCloneNotSupportedException
. AReference
cannot be meaningfully cloned. Construct a newReference
instead.- Overrides:
clone
in classObject
- Returns:
- never returns normally
- Throws:
CloneNotSupportedException
- always- Since:
- 11
- See Also:
Cloneable
-
reachabilityFence
Ensures that the object referenced by the given reference remains strongly reachable, regardless of any prior actions of the program that might otherwise cause the object to become unreachable; thus, the referenced object is not reclaimable by garbage collection at least until after the invocation of this method. Invocation of this method does not itself initiate garbage collection or finalization.This method establishes an ordering for strong reachability with respect to garbage collection. It controls relations that are otherwise only implicit in a program -- the reachability conditions triggering garbage collection. This method is designed for use in uncommon situations of premature finalization where using
synchronized
blocks or methods, or using other synchronization facilities are not possible or do not provide the desired control. This method is applicable only when reclamation may have visible effects, which is possible for objects with finalizers (See Section 12.6 of The Java™ Language Specification) that are implemented in ways that rely on ordering control for correctness.- API Note:
- Finalization may occur whenever the virtual machine detects that no
reference to an object will ever be stored in the heap: The garbage
collector may reclaim an object even if the fields of that object are
still in use, so long as the object has otherwise become unreachable.
This may have surprising and undesirable effects in cases such as the
following example in which the bookkeeping associated with a class is
managed through array indices. Here, method
action
uses areachabilityFence
to ensure that theResource
object is not reclaimed before bookkeeping on an associatedExternalResource
has been performed; in particular here, to ensure that the array slot holding theExternalResource
is not nulled out in methodObject.finalize()
, which may otherwise run concurrently.class Resource { private static ExternalResource[] externalResourceArray = ... int myIndex; Resource(...) { myIndex = ... externalResourceArray[myIndex] = ...; ... } protected void finalize() { externalResourceArray[myIndex] = null; ... } public void action() { try { // ... int i = myIndex; Resource.update(externalResourceArray[i]); } finally { Reference.reachabilityFence(this); } } private static void update(ExternalResource ext) { ext.status = ...; } }
reachabilityFence
is nonintuitively placed after the call toupdate
, to ensure that the array slot is not nulled out byObject.finalize()
before the update, even if the call toaction
was the last use of this object. This might be the case if, for example a usage in a user program had the formnew Resource().action();
which retains no other reference to thisResource
. While probably overkill here,reachabilityFence
is placed in afinally
block to ensure that it is invoked across all paths in the method. In a method with more complex control paths, you might need further precautions to ensure thatreachabilityFence
is encountered along all of them.It is sometimes possible to better encapsulate use of
reachabilityFence
. Continuing the above example, if it were acceptable for the call to methodupdate
to proceed even if the finalizer had already executed (nulling out slot), then you could localize use ofreachabilityFence
:public void action2() { // ... Resource.update(getExternalResource()); } private ExternalResource getExternalResource() { ExternalResource ext = externalResourceArray[myIndex]; Reference.reachabilityFence(this); return ext; }
Method
reachabilityFence
is not required in constructions that themselves ensure reachability. For example, because objects that are locked cannot, in general, be reclaimed, it would suffice if all accesses of the object, in all methods of classResource
(includingfinalize
) were enclosed insynchronized (this)
blocks. (Further, such blocks must not include infinite loops, or themselves be unreachable, which fall into the corner case exceptions to the "in general" disclaimer.) However, methodreachabilityFence
remains a better option in cases where this approach is not as efficient, desirable, or possible; for example because it would encounter deadlock. - Parameters:
ref
- the reference. Ifnull
, this method has no effect.- See Java Language Specification:
-
12.6 Finalization of Class Instances
- Since:
- 9
-