Figure 6.5 This is the classic resource chart of a memory leak. The solid black line shows actual
memory use. The broken line projects reachable memory objects. The peaks and valleys are
caused by garbage collection. The slowly rising valleys are characteristic of memory leaks.
Intuitive Systems). A well-behaved application should show a usage pattern
that builds to peaks and then has distinct valleys. With similar types of activi-
ties, the valley floors should be consistent. The peaks represent normal object
allocation over time. The valleys represent memory use just after garbage
collection. If the valley floor continually creeps up between garbage-collection
cycles, that's a sign of a possible memory leak. Figure 6.5 shows the graph of a
classic memory leak. The GC s denote garbage collection at each of the peaks.
The dotted line shows a slowly increasing amount of memory not garbage
Sometimes, the symptoms of a production memory leak are clear. Of
course, a java.lang.OutOfMemoryError is a clear sign of a leak, but the excep-
tion is not always generated before a more catastrophic system error occurs .
Other symptoms may also point to a memory leak. In many cases, a leak will
cause a relatively smooth decline with progressively worsening performance.
As the system begins to swap or page more, the system performance will
degenerate rapidly until the application fails or the system crashes. Low mem-
ory can cause many different types of failures, such as an inability to connect
to a database or open a file, even though the root cause is lack of memory.
Determine that the leak should be fixed
Fixing memory leaks can be expensive. In some cases, we should push leak
fixes lower on the priority chain, and maybe not even bother to do them. If
an application's in-memory life span is relatively short, it may not make sense
to patch all memory leaks, because garbage collection may never be run. If
memory leaks and total memory usage is small, memory leaks may not be a