Java Reference
In-Depth Information
Out of memory errors can occur unpredictably, making it difficult to know when to get a heap
dump. There are several JVM flags that can help.
Turning on this flag (which is false by default) will cause the JVM to create a heap dump
whenever an out of memory error is thrown.
This specifies the location where the heap dump will be written; the default is
java_pid<pid>.hprof in the application's current working directory. The path can specify
either a directory (in which case the default file name is used), or the name of the actual file to
This generates a heap dump after running a full GC.
This generates a heap dump before running a full GC.
In the case where multiple heap dumps are generated (e.g., because multiple full GCs occur), a se-
quence number is appended to the heap dump filename.
Try turning on these flags if the application unpredictably throws an out of memory error due to
the heap space, and you need the heap dump at that point to analyze why the failure occurred.
Figure 7-5 shows the classic case of a Java memory leak caused by a collection class (in this
case, a HashMap ). (Collection classes are the most frequent cause of a memory leak: the ap-
plication inserts items into the collection and never frees them.) This is a comparison histo-
gram view: it displays the difference in the number of objects in two different heap dumps.
For example, there are 19,744 more Integer objects that occur in the target heap dump com-
pared to its baseline.
The best way to overcome this situation is to change the application logic such that items are
proactively discarded from the collection when they are no longer needed. Alternatively, a
collection that uses weak or soft references can automatically discard the items when nothing
else in the application is referencing them, but those collections come with a cost (as is dis-
cussed later in this chapter).
Search WWH ::

Custom Search