Identify signs of memory leaks, such as continuous growth in memory usage, frequent complete garbage collection, OutOfMemoryError exceptions and slow application; 2. Use jmap or JVM parameters to generate heap dump files, and use tools such as Eclipse MAT, VisualVM, etc. to analyze them, focusing on the "Leak Suspects" report; 3. Common reasons include unlimited growth of static collections, unclosed resources, unlogged listeners, internal classes hold external class references, and class loader leaks. Weak references, try-with-resources, timely unbinding, static internal classes and cleaning ThreadLocal should be repaired respectively; 4. Prevent leakage through production environment monitoring, regular pressure testing, code review and static analysis tools. Memory leaks originate from improper code holding object references. They can be effectively solved through systematic investigation and standardized encoding, ultimately ensuring the stable and efficient operation of the application.

Memory leaks in Java applications can be sneaky—they don't always crash your app immediately, but over time, they cause performance degradation, OutOfMemoryError s, and sluggish behavior. Even though Java has garbage collection, memory leaks still happen due to poor coding practices or misuse of APIs. Here's how to troubleshoot and fix them effectively.

1. Recognize the Symptoms

Before diving into tools, look for signs:

• Gradual increase in memory usage over time (visible via monitoring tools like VisualVM or JConsole).
• Frequent full GC (Garbage Collection) pauses.
• java.lang.OutOfMemoryError: Java heap space in logs—even with adequate heap size.
• Application slowdowns or unresponsiveness under normal load.

If memory usage keeps climbing without plateauing after full GCs, you likely have a leak.

2. Use Profiling Tools to Capture a Heap Dump

A heap dump is a snapshot of all objects in memory—it's your best friend for diagnosis leaks.

Steps:

• Trigger a heap dump manually:

   jmap -dump:live,format=b,file=heap.hprof <pid>

  (Replace <pid> with your Java process ID from jps or ps .)

• Or enable automatic dump on OOM:

   -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps

Analyze the dump using:

• Eclipse MAT (Memory Analyzer Tool) – Great for finding "Leak Suspects."
• VisualVM or JProfiler – User-friendly GUIs for exploring object retention paths.

In MAT, run the “Leak Suspects Report”—it often points directly to problematic objects (eg, static collections holding references).

3. Common Causes & How to Fix Them

? Static Collections That Grow Indefinitely

 public class Cache {
    private static Map<String, Object> cache = new HashMap<>();
}

Problem: Static maps live as long as the classloader—never get GC'd unless explicitly cleared.

Fix:

• Use WeakHashMap for caches (keys are GC'd when no strong references).
• Or implement a cleanup strategy (eg, ScheduledExecutorService to evict old entries).

? Unclosed Resources (InputStreams, DB Connections, etc.)

 FileInputStream fis = new FileInputStream("file.txt");
// forget to close()

Problem: These hold native memory or prevent object cleanup.

Fix:

• Always use try-with-resources:

   try (FileInputStream fis = new FileInputStream("file.txt")) {
      // auto-closed
  }

? Listeners or Callbacks Not Unregistered

Swing, JavaFX, or event-driven apps often forget to remove listeners.

Fix:

• Unregister listeners in dispose() or finalize() methods (if appropriate).
• Use weak listeners if available (eg, WeakReference for callbacks).

? Inner Classes Holding Outer References

 public class Outer {
    private int[] data = new int[1000000];
    public void start() {
        new Thread(new Runnable() {
            public void run() {
                // this Runnable holds a reference to 'Outer'
                // so 'data' won't be GC'd until the thread ends
            }
        }).start();
    }
}

Fix:

• Make the inner class static if it doesn't need outer state.
• Or avoid long-lived threads referencing large outer objects.

? ClassLoader Leaks (Common in App Servers)

If you redeploy apps in Tomcat/JBoss and see leaks, it's often due to:

• Threads not stopped.
• Static fields not cleared.
• JDBC drivers not deregistered.

Fix:

• Use ThreadLocal.remove() when done.
• Clean up static caches in ServletContextListener.contextDestroyed() .

4. Monitor and Prevent Going Forward

• Add memory monitoring in production (eg, Prometheus Grafana with JMX exporter).
• Run regular load tests with profiling enabled.
• Code reviews: Look for static collections, unclosed resources, and inner classes.
• Use tools like SpotBugs or SonarQube —they flag common leak patterns.

Memory leaks in Java are fixable once you know where to look. Start with a heap dump, use tools like MAT to find the root cause, and apply fixes based on the pattern. Most leaks come from simple oversights—not magic bugs. Fix them early, and your app will run smoother and more reliable.

Basically, it's not that Java leaks—it's that your code might be holding onto things it shouldn't.

The above is the detailed content of How to Troubleshoot and Fix Memory Leaks in a Java Application. For more information, please follow other related articles on the PHP Chinese website!