Java Reference
In-Depth Information
a memory leak can be isolated through scenarios. After you've isolated a leak,
add the test to the application's regression test suite.
6.5.4
Determine the source and fix the problem
Once you've generated the narrowest possible test case, the next step is to
determine the source of the problem. Without a doubt, this is the most diffi-
cult part of the process. These strategies may help:
Use good tools
You must have effective tools to be able to track memory leaks in Java. You
need tools that let you:
Trigger garbage collection on demand.
Examine the size of the heap collectively over time.
Examine the contents of the heap, including objects on the heap.
Determine the references to an object (that prevent garbage collection).
Inspect code by hand
Many times, you can locate memory leaks by looking in the likely places. With
close attention to collections, listeners, singletons, and long life cycles in gen-
eral, you can spot many possible leaks. Further, searching tools can aid manual
inspection. Simply counting the number of adds and removes to a problematic
collection using
GREP
or an editor can help you identify an imbalance that may
lead to a leak.
Force garbage collection between repeated test cases
Most good profiling tools can force garbage collections. In this way, a code
segment can be repeatedly exercised, garbage collection run, and the heap
examined for growth. With the profiler's snapshot of the heap (graphs of
allocated space versus free space over time work well), you can make the test
case narrower.
Use object reference graphs when the search is sufficiently narrow
Most good profilers will show the references from an object on the heap.
Since you're looking for reachable objects not garbage collected, profiling is a
powerful tool when combined with garbage collection on demand. When you
find a reachable object that should have been garbage collected, you can fol-
low the reference chain to find the culprit.
