A typical large-scale application with a GUI and a database back end may use dozens of different types of listeners, all of which have to be unregistered to avoid memory leaks.

Memory Profiling

While lapsed listeners may not be a problem with short-running programs, in long-running applications, continuous memory leakage over a long period of time may lead to memory exhaustion. The Memory profiling feature of Oracle JDeveloper 10g lets you collect memory statistics on long-running programs.

The memory profile view shows allocation and garbage collection statistics for each snapshot. One quick way to look for potential memory leaks is to sort by "Diff Alloc", the difference between the number of allocated objects of each type between the current and a previous snapshot. Large numbers in the Diff Alloc column as well as the "Diff sz" column indicate objects that have been allocated but not deleted, thus pinpointing potential leaks.

To further narrow down the problem, you can also pause the memory profiling process and double-click on the class of interest to see allocation sites for objects of the type in question. When the source code is available, you can double-click on an allocation site to jump right to the source.

Heap Debugging

Knowing that potentially leaking objects have been allocated is sometimes not enough, however. To get to the source of the leak, you must ask why the garbage collector is keeping the objects.

To answer that question, we can use Oracle JDeveloper 10g's heap debugging capabilities. Once you have determined which classes are potentially leaking through memory profiling, you can obtain more detailed information by using the Heap window of JDeveloper's debugger. For LapsedListenerTest, the class that appears to be leaking from the memory profiler view is the inner class, ListenerTest$Component.

We ran the test program in debug mode, right-clicked in the Heap window, and selected Add class folder to show all instances of the class we are interested in that are available at runtime. As shown in Figure 3, there are 7 instances of that class. We first looked for reference paths for a ListenerTest$Component object located at 0X4B7B4DE4. Then we right-clicked on the first of two reference paths corresponding to a static field and selected Expand reference path, which expands the tree view to show how to reach the object in question. As expected, the ListenerTest$Component object in question is reachable from the roots through the listener table at 0X48755AEC and then one of the listeners at 0X4875C1B4.

Getting Rid of the Leaks

Once you find the memory leaks, you have a variety of ways to get rid of them. One approach is to use WeakReferences, which are not traversed by the garbage collector when determining which objects are reachable. Thus, if we make the reference from the listener list to the listener a weak one as shown below, the object of type ListenerTest$Component will eventually become unreachable and will be collected:

public static class Component {
	...
public void addListener(ComponentListener listener){      
      synchronized (listeners){      	
          		listeners.add(new WeakReference(listener));
      }
      }
}
}	

However, in a large system, keeping track of the listeners is done typically behind the scenes, so the developer's only way to get rid of the leak will be to call the remove method on all program paths that register the listener causing the object being listened on to eventually be collected.

Conclusion

Although Java's garbage collector may not solve all memory problems, and can leave leaks that can result in memory exhaustion, Oracle JDeveloper comes fully equipped with tools to address the variety of memory problems that might arise. In this article we have shown how to effectively use JDeveloper's memory profiler and heap debugger to locate memory errors.