They usually happen during the early hours of the morning, shortly before the code needs to ship: exception errors. . . .

Take the following , for example. Ever seen this before?

Exception in thread "main" java.lang.OutOfMemoryError
at OutMem.main(OutMem.java, Co

In the past, developers didn't have much control over garbage collection or memory management. Java2 has changed that by introducing the java.lang.ref package. The abstract base class Reference is inherited by classes SoftReference, WeakReference and PhantomReference. SoftReferences are well suited for use in applications needing to perform caching. WeakReferences are generally used to canonicalize several references to a single object. PhantomReferences are the "weakest" type of reference and can be used for referents that require additional cleanup after finalization.

In this article I'm going to focus on the SoftReference class and demonstrate how to use it to implement caching.

Creating a SoftReference
SoftReferences are created by passing an object to SoftReference's constructor:

Object obj = new Object();
SoftReference softRef = new SoftReference(obj);
obj = null;

Please note the setting of obj to null. This is critical to proper performance of the garbage collector. A problem arises if no other stack frame places a value at that location - the garbage collector will still believe that an active (strong) reference to the object exists.

Retrieving a Reference
The following code can be used to retrieve a reference to an object:

Object obj2;
obj2 = sr.get();
if (obj2 == null) // GC freed this
sr = new SoftReference(obj2 = new Object());

Two items from the foregoing code are important to note. First, notice that SoftReference is immutable - you must create a new SoftReference that refers to the new referent. Second, the following code may appear to accomplish the same goal:

Object obj2;
obj2 = sr.get();
if (obj2 == null) {
sr = new SoftReference(new Object());
obj2 = sr.get();
}

Hopefully the problem with this code is obvious: the garbage collector could run between the creation of the new Object and the call to get(). obj2 would still be null.

Where would you use a SoftReference? SoftReferences are excellent for use in memory-intensive applications that can benefit from caching. Take, for instance, a user interface such as a button with a picture on it. Typically these are implemented by subclassing Button. The paint method is then usually overridden (see Listing 1).

Reference Queues
Sometimes it may be important to know which references the garbage collector has cleared. Good-natured daemon that it is, the collector will happily place these references into a queue. All you have to do is supply the ReferenceQueue when you create the reference.

ReferenceQueue rq = new ReferenceQueue();
Object o = new Object();
SoftReference sr = new SoftReference(o,rq);
o = null;

Later your program can query the queue by calling the nonblocking method poll. This will return a reclaimed reference or null if the queue is empty. Many cache implementations will loop through the queue during a call placing or retrieving items in the cache. Alternatively, ReferenceQueue provides two versions of the blocking method remove. One blocks indefinitely and the other will return after a timeout. Remove can be used instead of poll by a thread that blocks until items enter the queue, as in our next example.

Using SoftReferences to Implement a Cache
Programs can usually increase efficiency by reusing objects that are expensive to create. Objects such as database connections and distributed objects - like those in RMI and CORBA - incur significant overhead in object creation, as well as create and destroy network connections. While caching is nothing new, SoftReferences allow us to grow the cache almost without bound. The guarantee that the garbage collector gives us is that it will always clear SoftReferences before throwing the dreaded OutOfMemoryError.

Listing 2 provides a class that can store instances of an object until they're needed. The cache's get method will return an object if one exists in the queue. If not, null will be returned and the program will need to create a new instance. When the program has finished using an instance, it simply passes the object to the cache's put method, where it will be available for future use.

The inner class Remover subclasses Thread and waits on the ReferenceQueue. To test the program, I wrote a cruel driver that attempts to flood the cache to ensure that items will be dropped rather than exhaust memory.

SoftCache sc = new SoftCache();
for (int i=0; i < 1000000; i++) {
sc.put(new Object());
if (i%10 == 0) {
System.gc();
Thread.yield();
System.out.println("i=" + i);
}
}

This is a bit like offering the cache a sip of water from a fire hose but it does the trick. To simulate the out-of-memory condition, an explicit call to gc() was added as well as a yield() to give the cache's Remover thread a chance to delete items from its vector. To coerce the garbage collector into removing some of the reference, I set the maximum heap size to a low value. Under Linux (kernel 2.2.12, JDK 1.2.2-RC3) the maximum heap size was set to 360K. The initial heap size defaults to over one megabyte, so it must be set as well. These options are set via Java's mysterious new -X parameters:

java -Xmx360k -Xms263k AbuseCache

Conclusion
Hopefully this article has demonstrated some techniques that can be useful to satiate an application's voracious appetite for memory. SoftReferences provide a way for the virtual machine to release memory held by large or infrequently used objects. Consider subclassing SoftCache to create new instances of an object you use. It could then also ensure that only objects of the proper type can be added.

• Source Code