Java Reference
In-Depth Information
In the version shown in Listing 11-2, you're creating a List of objects that will exist past the
currently processing chunk. Under normal processing, most of the objects involved in a given chunk are
garbage-collected when the chunk is complete, keeping the memory footprint in check. By doing
something like what you have in this example, you would expect the memory footprint to grow out of
When you run the statement job with this bug and profile it using VisualVM, you can see that things
quickly get out of hand from a memory perspective; an OutOfMemoryException is thrown midway through
the step. Figure 11-10 shows the VisualVM Monitor tab a run of the statement job with the memory leak.
Figure 11-10. Monitoring results of the statement job with a memory leak
Notice at the very end of the memory graph in the upper-right corner of Figure 11-10 that memory
usage spikes, causing the OutOfMemoryException . But how do you know what caused the spike? If you
didn't know, the Sampler tab might be able to shed some light.
You've seen before that the Sampler tab can show what method calls are using up CPU, but it can
also tell you what objects are taking up precious memory. To see that, begin by executing your job as you
have previously. When it's running, connect to the process using VisualVM and go to the Sampler tab. To
determine the cause of a memory leak, you need to determine what changes as the memory usage
occurs. For example, in Figure 11-11, each block represents a class instance. The higher the blocks are
stacked in each column, the more instances are in memory. Each column represents a snapshot in time
within the JVM. When the program begins, the number of instances created is small (one in this case);
this number slowly rises over time, occasionally declining when garbage collection occurs. Finally it
spikes at the end to nine instances. This is the type of increase in memory usage you look for with
Search WWH ::

Custom Search