You can find out that the garbage collector has determined that a reference object's referent is not strongly reachable after the fact, however. To do so, register your reference objects with a ReferenceQueue. The garbage collector will put the reference object in that queue after it clears the reference. You can use the queue's poll method to check for any enqueued references, or use the queue's remove method to wait until a reference is enqueued. I will use both approaches in the third and fourth VectorModel implementations.
To illustrate typical garbage collection in my simple example application, I will encourage the garbage collector a bit. The example uses very little memory; if this were not the case, the garbage collector would not collect any garbage. The application has a thread that updates the number of living views. Before doing so, however, this thread calls System.gc to encourage the garbage collector to collect garbage.
That's the theory. To see it in action, however, be sure to use JDK 1.2.2 or greater. JDK 1.2.2 fixed a bug in JDK 1.2.1 that prevented JFrame objects from being finalized and garbage-collected. Sun lists the bug under the bug IDs 4222516 and 4193023.
The first implementation: Using WeakReferences to implement VectorModel
By using WeakReference objects to hold the references to your data model's listeners, you avoid the problem of lapsed listeners. DefaultVectorModel holds direct, strong references to the listeners, which prevents them from being garbage-collected. The new WeakRefVectorModel implementation holds only indirect, weak references to the listeners. When the garbage collector determines that a listener is only weakly reachable, it finalizes the listener, frees its memory, and clears the weak reference to it. In this example, when the user closes the VectorListFrame, the frame is only weakly reachable from the data model, and can therefore be garbage-collected. Et voilà!
You can still add a listener to WeakRefVectorModel quite easily. You create a new WeakReference object inside the addListener method, with the listener as its referent. Then you add the reference object to your listener's vector. The client code never sees the WeakReference.
// in WeakRefVectorModel.java:
public void addListener (VectorModel.Listener l) {
WeakReference wr = new WeakReference (l);
listeners.addElement (wr);
}
Compare this to the standard implementation, shown below. You see that very little extra code was added:
// in DefaultVectorModel.java
public void addListener (VectorModel.Listener l) {
listeners.addElement (l);
}
When a view is discarded, the garbage collector clears the WeakReference object to the view. When the reference is cleared, you want to remove it from the listener's vector. The question is, when do you do so?
Whenever an event is fired from WeakRefVectorModel, you have to test the referents, the actual VectorModel.Listener objects, for null before you call their elementAdded or elementRemoved methods. Since you're testing anyway, you should also throw out references that have been cleared. The fireElementAdded method is now a bit more complicated. The code in boldface was added to the code of the standard implementation (see above). This code checks the VectorModel.Listener object for null, and, if it is indeed null, removes the reference object from the listener's vector:
// in WeakRefVectorModel.java:
protected void fireElementAdded (Object object) {
VectorModel.Event e = null;
int size = listeners.size();
int i = 0;
while (i < size) {
WeakReference wr = (WeakReference)listeners.elementAt(i);
VectorModel.Listener vml = (VectorModel.Listener)wr.get();
if (vml == null) {
listeners.removeElement (wr);
size--;
}
else {
if (e == null) // lazily create event
e = new VectorModel.Event (this, object);
vml.elementAdded (e);
i++;
}
}
}
Of course, fireElementRemoved works the same way. The disadvantage of this approach is that these two methods are now more complicated. If there were more fire<anything> methods, you would also implement them this way, further bloating the code.
The second implementation: Waiting for the garbage collector
You could also wait for the garbage collector to finalize and free a listener, and clear the references to it. ThreadedWRVectorModel is implemented this way. As mentioned earlier, you need a ReferenceQueue for the garbage collector to add the reference objects when they have been cleared. When you add a listener, you must register the WeakReference object with the queue:
// in ThreadedWRVectorModel.java:
//...
private ReferenceQueue queue;
private Thread cleanUpThread;
public ThreadedWRVectorModel() {
listeners = new Vector();
queue = new ReferenceQueue();
//...
}
public void addListener (VectorModel.Listener l) {
WeakReference wr = new WeakReference (l, queue);
listeners.addElement (wr);
}
When the garbage collector has finalized and freed the listener, it puts that listener's reference object in the queue. Therefore, you only have to wait on the queue for a reference object to be enqueued. You can dedicate a thread to this task, which you create in the ThreadedWRVectorModel's constructor:
// in ThreadedWRVectorModel.java:
Runnable cleanUp = new Runnable() {
public void run() {
Thread thisThread = Thread.currentThread();
WeakReference wr;
while (thisThread == cleanUpThread) {
try {
wr = (WeakReference)queue.remove();
listeners.removeElement (wr);
wr = null;
}
catch (InterruptedException e) { }
}
}
};
cleanUpThread = new Thread (cleanUp);
cleanUpThread.start();
The queue.remove() call is blocking, so the thread effectively waits until the garbage collector has freed a listener. When remove returns, you can remove the WeakReference to the listener from the listener's vector. Setting wr to null lets the garbage collector free it. If you don't set wr to null, wr holds on to the reference object until it is overwritten by the next call to queue.remove(). Until then, the reference object is not freed. This would not be too damaging, since the reference object is small, but it is poor style.
When do you stop the cleanUp thread? You must do so eventually, because otherwise you leak the memory of this thread and the model as a whole. The problem is that you cannot simply implement ThreadedWRVectorModel.finalize to stop the thread. As an anonymous inner class, the cleanUp thread has an implicit reference to the ThreadedWRVectorModel instance of which it is part. While the thread is living, ThreadedWRVectorModels cannot be finalized and garbage-collected.
To solve this problem, you introduce a terminate method that stops the cleanUp thread:
// in ThreadedWRVectorModel.java:
public void terminate() {
if (cleanUpThread != null) {
Thread moribound = cleanUpThread;
cleanUpThread = null;
moribound.interrupt();
}
} // terminate //
terminate works just fine. If no other reference to a ThreadedWRVectorModel instance exists, the instance can be garbage-collected after terminate has been called. However, this is not a perfect solution; the programmer must remember to call terminate on that model when he or she wants to discard the model. This is almost as error-prone as removing listeners explicitly!
The third way: Polling the ReferenceQueue
Instead of having a cleanUp thread, you could just implement a cleanUp method. This method would poll the reference queue. Polling the queue is not a blocking operation. If a reference is enqueued, it is returned; but if there are no enqueued references, poll returns immediately with a null reference.
The cleanUp method could poll the queue, and if there is a reference object enqueued, cleanUp can remove the reference from the listeners list. This is the way QueuedWRVectorModel is implemented:
// in QueuedWRVectorModel.java:
public void cleanUp() {
WeakReference wr = (WeakReference)queue.poll();
while (wr != null) {
listeners.removeElement (wr);
wr = (WeakReference)queue.poll();
}
} // cleanUp //
Note that, for this approach, you add listeners in the same way as you did in ThreadedWRVectorModel. That means that the weak reference to the listener is registered with the queue.
The cleanUp method could be called from the fire<anything> methods. In that case, these methods would not have to deal with removing cleared references. Also, the user of a QueuedWRVectorModel instance could call cleanUp.
Conclusion
Using the java.lang.ref package, you can interact with the garbage collector so that it frees listeners when they become only weakly reachable. This lets you automate the task of removing these listeners from a model's listeners list.
You have seen three ways of using weak references. Which one is best? WeakRefVectorModel has the advantage of removing cleared references when traversing the listeners list. However, if there are many methods traversing the list, this approach bloats the code unnecessarily.
In that case, I might prefer the overhead of a dedicated thread. It has the advantage of concentrating in one place the code that deals with cleared references. But there is a serious problem with the ThreadedWRVectorModel implementation. As shown here, it is not scalable. For each ThreadedWRVectorModel instance, you have one dedicated cleanUp thread, and there is no simple way around this thread explosion. Therefore, I would use the approach of ThreadedWRVectorModel only if I had a single global application data model.
I think the last approach, QueuedWRVectorModel is the best implementation. It concentrates the code that deals with the queue in one place. The cleanUp method can be called by any other QueuedWRVectorModel method with very little overhead. It might be slightly slower than the other two approaches, but that shouldn't be a serious problem. The main advantage of QueuedWRVectorModel is that it is perfectly scalable. Also, it is far easier to maintain, since the cleanup code is concentrated in just one method.
Nothing is ever perfect. There is a theoretical danger of running out of memory when using WeakReferences without a cleanUp thread. Say you have lots of WeakReferences to very small objects, like Integers. One could imagine a situation in which these objects are garbage-collected while the weak references to them persist, waiting to be garbage-collected themselves. These references together might use so much memory that you could run out, unless you freed them. However, this would be a rare situation.
This story, "Java Tip 79: Interact with garbage collector to avoid memory leaks" was originally published by JavaWorld.