How To Find Memory Leak In Heap Dump

A quick and dirty guide to finding Java memory leaks

almost | archive

[ 2013-June-29 14:31 ]

Last calendar week, I tracked down a Java memory leak for the get-go fourth dimension in years. I had to re-learn how to do it, so this is a note to my future self (and hopefully others). In this case, I establish it using the JDK'south debugging tools. While I know people who rave nearly some of the commercial tools, or Eclipse'south Memory Analyzer (MAT), I've never tried them. The leaks I've dealt with have been obvious plenty that the congenital-in tools got the job done. In fact, I find the JDK's tools (specially jstack, jmap and hprof) to be useful enough that I know brand certain all my production machines accept the JDK installed, non just the JRE.

To track downward a memory leak, you lot'll need a "heap dump" with a summary of the live objects in a leaky procedure. To tape a dump, starting time run jps to find the process'south PID, then run jmap -dump:live,format=b,file=(dumpfile) (pid). If you get the fault "Unable to open socket file: target process not responding or HotSpot VM not loaded", it probably means the process is running as a different user. Add together sudo -u (process user) in front of the command line, or run jmap as root with the -F flag. Finally, re-create (dumpfile) to your local motorcar and run jvisualvm --openfile (dumpfile), or use jvisualvm'due south File → Load carte du jour. Once it loads (which is slow), click the Classes tab to see something similar the post-obit:

This groups objects past class, ordered them from well-nigh to least number of instances. If you have a long running leak, it is probably one of the classes about the top of this listing. Sadly, this is the point where you need use everything yous know about the application and the internals of the objects. You need to look for "suspicious" classes: those that have "as well many" instances, or are occupying besides much retentivity. JVisualVM lets yous step through all the references to any object, so it gives you the raw tools you need to find the leak, just sometimes it is disruptive to sympathize. As an example, I'll briefly explain how I institute this leak:

In this case, we have millions of LinkedHashMap.Entry objects, which must be part of some LinkedHashMap. Tracing through some random instances didn't immediately reveal annihilation suspicious, so instead I resorted past size. HashMap.Entry[] (arrays of HashMap.Entry objects) jumped to second identify, occupying 32 MB of retention, or fifteen% of the heap. This seemed promising: for information technology to jump upwardly so much ways at that place must exist some particularly large arrays. Drilling into that course, ordered past size, revealed the following:

The left hand pane shows all instances, with largest showtime. The peak entry (selected) is an array of 131 096 elements! The top right pane shows the object's fields, with this (the object itself) selected. The bottom right pane shows all references to the assortment. This shows that it is referred to by a field called HashMap.table, which is function of the HashMap object containing the array. In plow, this is referred to by a static field DaoManager.classMap (part of OrmLite). This is the smoking gun: looking at the source of DaoManager speedily showed that this static field is a enshroud. In our case, it holds references to a huge number of database connection objects. Despite closing the connections, these objects were non removed from the enshroud. Calculation a call to DaoManager.unregisterDao solved the problem.

I would fence that OrmLite'southward default caching behaviour is very stupid, and this enshroud should at least use weak references, allowing the objects to eventually be garbage collected. On the other paw, we aren't actually using OrmLite te the way it was designed to be used. This is a debate for some other mail service, since our quick-and-dirty fix solved our problem.