And if you're working in the JRE, itself trying to use the technique on
the thread class doesn't always work too well as the Reference static
initialiser attempts to starts a new thread...

Tom Hawtin

   First of all, we should clear up some terminology and basic concepts.
Java has variables which have values. These values are sometimes primitives:
e.g. when you have a variable of type int, then the value of the variable is
the value of that int itself, such as the value 3. Other times, the
variables act as references to objects. They "point" to the address in
memory where an object is located. So for example, with this code snippet:

<code>
Foo a;
Foo b;
a = new Foo();
b = a;
</code>

   You've got 2 variables, but only 1 object. Both variables point, or
refer to, the same object. The variables have names. There's a variable call
"a", and a variable called "b". Objects don't have names.

   Objects have classes. SoftReference is a class. So you can have an
object of type SoftReference. Consider now the following code:

<code>
SoftReference cache = new SoftReference(new Foo());
</code>

   There are 2 objects and 1 variable. There's an instance of Foo, an
instance of SoftReference, and a variable called "cache".

   Cache will never "magically" become null. If you want cache to be null,
you (or some other code) has to explicitly set it to null. So this following
code snippet will always print "Hello world!":

<code>
SoftReference cache = new SoftReference(new Foo());
if (cache == null) {
 System.out.println("This should never happen.");
} else {
 System.out.println("Hello world!");
}
</code>

However, this code may sometimes print "Hello world!", sometimes print
"Goodbye world!":

<code>
SoftReference cache = new SoftReference(new Foo());
if (cache.get() == null) {
 System.out.println("Goodbye world!");
} else {
 System.out.println("Hello world!");
}
</code>

See
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/package-summary.html#reach
ability

The SoftReference object in the code above is strongly reachable. Why?
Because you can directly reach it using the variable called "cache". So the
SoftReference object itself will not get garbage collected. However, the
Fooobject is softly reachable. That is, it is not strongly reachable (since
you don't have a variable which points to it), but you DO have a
SoftReference which holds it.

(This next part starts talking about underlying implementation. It makes a
bunch of simplifying assumptions, like avoiding the whole concept of "weakly
reachable" and "phantom reachable" and might not reflect what the JVM is
"really" doing under the covers, but hopefully it'll still help you
understand the external observable behaviour.)

So the garbage collector may decide it wants to collect that Foo object. The
first step in doing so is that it will tell the SoftReference to release it.
Once that happens, whenever you call the .get() method on the SoftReference
object, that method will return null. However, the Foo object has not yet
been garbage collected. It's just floating around in memory somewhere, with
no way to access it.

Now, the garbage collector can garbage collect the Foo object, without
worrying about deleting an object while it's still being used. It doesn't
have to worry, because the Foo object is unreachable. There's no
strong-references to it, and there's no soft-references to it either.

   - Oliver

When using ReferenceQueues, you typically subclass the Reference
implementation and add fields to that so you know what disappeared.
Alternatively you can do it on object identity of the Reference with a
map of some description.

Tom Hawtin