Class Reference<T>

public T get()

API Note:

This method returns a strong reference to the referent. This may cause the garbage collector to treat it as strongly reachable until some later collection cycle. The refersTo method can be used to avoid such strengthening when testing whether some object is the referent of a reference object; that is, use ref.refersTo(obj) rather than ref.get() == obj.

Returns:

The object to which this reference refers, or null if this reference object has been cleared

See Also:

• refersTo(T)

public final boolean refersTo(T obj)

Parameters:

obj - the object to compare with this reference object's referent

Returns:

true if obj is the referent of this reference object

Since:

16

public void clear()

API Note:

There is a potential race condition with the garbage collector. When this method is called, the garbage collector may already be in the process of (or already completed) clearing and/or enqueueing this reference. Avoid this race by ensuring the referent remains strongly reachable until after the call to clear(), using reachabilityFence(Object) if necessary.

@Deprecated(since="16") public boolean isEnqueued()

Returns:

true if and only if this reference object is in its associated queue (if any).

public boolean enqueue()

API Note:

Use of this method allows the registered queue's ReferenceQueue.poll() and ReferenceQueue.remove(long) methods to return this reference even though the referent may still be strongly reachable.

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

protected Object clone() throws CloneNotSupportedException

Overrides:

clone in class Object

Returns:

never returns normally

Throws:

CloneNotSupportedException - always

See Also:

• Cloneable

public static void reachabilityFence(Object ref)

API Note:

Reference processing or finalization can occur after an object becomes unreachable. An object can become unreachable when the virtual machine detects that there is no further need for the object (other than for running a finalizer). In the course of optimization, the virtual machine can reorder operations of an object's methods such that the object becomes unneeded earlier than might naively be expected — including while a method of the object is still running. For instance, the VM can move the loading of values from the object's fields to occur earlier. The object itself is then no longer needed and becomes unreachable, and the method can continue running using the obtained values. This may have surprising and undesirable effects when using a Cleaner or finalizer for cleanup: there is a race between the program thread running the method, and the cleanup thread running the Cleaner or finalizer. The cleanup thread could free a resource, followed by the program thread (still running the method) attempting to access the now-already-freed resource. Use of reachabilityFence can prevent this race by ensuring that the object remains strongly reachable.

The following is an example in which the bookkeeping associated with a class is managed through array indices. Here, method action uses a reachabilityFence to ensure that the Resource object is not reclaimed before bookkeeping on an associated ExternalResource has been performed; specifically, to ensure that the array slot holding the ExternalResource is not nulled out in method Object.finalize(), which may otherwise run concurrently.

class Resource {
  private static ExternalResource[] externalResourceArray = ...

  int myIndex;
  Resource(...) {
    this.myIndex = ...
    externalResourceArray[myIndex] = ...;
    ...
  }
  protected void finalize() {
    externalResourceArray[this.myIndex] = null;
    ...
  }
  public void action() {
    try {
      // ...
      int i = this.myIndex; // last use of 'this' Resource in action()
      Resource.update(externalResourceArray[i]);
    } finally {
      Reference.reachabilityFence(this);
    }
  }
  private static void update(ExternalResource ext) {
    ext.status = ...;
  }
}

The invocation of reachabilityFence is placed after the call to update, to ensure that the array slot is not nulled out by Object.finalize() before the update, even if the call to action was the last use of this object. This might be the case if, for example, a usage in a user program had the form new Resource().action(); which retains no other reference to this Resource. The reachabilityFence call is placed in a finally block to ensure that it is invoked across all paths in the method. A more complex method might need further precautions to ensure that reachabilityFence is encountered along all code paths.

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 class Resource (including finalize) were enclosed in synchronized (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, method reachabilityFence remains a better option in cases where synchronization is not as efficient, desirable, or possible; for example because it would encounter deadlock.

Parameters:

ref - the reference to the object to keep strongly reachable. If null, this method has no effect.

Since:

9