How to Diagnose Java Memory Leaks Using jstat, jmap, and BTrace

This article documents a typical Java memory usage issue and walks through step‑by‑step analysis for newcomers.

Initial Symptom

The business system processing MQ messages slowed down, accumulating over 2 million messages; jstat showed frequent Full GC and eventually an OOM.

Further Analysis

Identifying which objects consume most memory, the author avoids full heap dumps and instead uses jmap -histo:live [pid], revealing that Hashtable entries exceed 50 million, occupying about 1.5 GB.

Locating the Code

Having pinpointed Hashtable as the culprit, the next step is to find the code inserting data. Using BTrace to trace Hashtable.put calls, a script TracingHashTable.java is written and executed with:

bin/btrace -cp build 4947 TracingHashTable.java

The stack traces show that after receiving a message, the code that queries the database via iBatis and MySQL JDBC driver puts many properties into the Hashtable, leading to the memory pressure.

With this investigation the problematic code segment is identified, ready for white‑box refactoring and optimization.