Java memory leaks mainly occur in the heap area. Common scenarios include static collection classes holding object references, not closing resources, not logged out of listeners, implicitly holding external class references, and improper use of ThreadLocal; 2. The solutions are: using weak references or limiting cache size, using try-with-resources to automatically close resources, manually logging out listeners or using weak references, declaring internal classes as static, and using remove() to clean ThreadLocal; 3. Detection methods include using jstat/jmap/jvisualvm and other JVM tools, Eclipse MAT to analyze heap dump files, and enabling GC logs to observe memory changes; 4. The best practice is to avoid long-life cycle references, timely release resources, use ThreadLocal cautiously, design reference relationships reasonably, and perform memory analysis regularly to ensure the efficiency and stability of the application.

Java memory management and avoiding memory leaks are the key to writing efficient and stable applications. Although Java has an automatic garbage collection mechanism (GC), this does not mean that developers can completely ignore memory management. Improper code design may still lead to memory leaks, which in turn will cause problems such as OutOfMemoryError and performance degradation.

The following are several key aspects to illustrate the Java memory management mechanism and how to avoid common memory leaks.

1. A brief review of Java memory structure

The Java runtime data area mainly includes the following parts:

• Heap : The storage area of object instances and arrays is the main area of garbage collection.
• Method Area : Stores class information, constants, static variables, etc. (After JDK 8, metaspace Metaspace replaced the permanent generation).
• Virtual Machine Stack (JVM Stack) : Each thread is private and stores local variables and method call stack frames.
• Local method stack : Serves local method.
• Program counter : Records the bytecode line number executed by the current thread.

Among them, heap memory is the area where memory leaks occur most frequently.

2. Common memory leak scenarios and response methods

? Static collection class holds object references

The life cycle of the static variable is the same as that of the class and is usually accompanied by the entire application. If static collections (such as static List ) are constantly adding objects without cleaning them, these objects will not be recycled.

 public class Cache {
    private static List<Object> cache = new ArrayList<>();

    public static void addToCache(Object obj) {
        cache.add(obj); // No cleaning mechanism → memory leak}
}

? Solution :

• Use WeakReference or SoftReference
• Use java.util.WeakHashMap as cache container
• Set cache size limits and clean them regularly

? Unclosed resources (I/O, database connection, etc.)

If the file flow, network connection, database connection and other resources are not explicitly closed, it will not only occupy memory, but also consume system resources.

 FileInputStream fis = new FileInputStream("file.txt");
ObjectInputStream ois = new ObjectInputStream(fis);
// Forgot close() → File handle and memory not released

? Solution : Use the try-with-resources syntax to automatically close the resources that implement AutoCloseable :

 try (FileInputStream fis = new FileInputStream("file.txt");
     ObjectInputStream ois = new ObjectInputStream(fis)) {
    //Use resources} // Automatically close

? Listeners and callbacks are not logged out

In a GUI program or event-driven system, if the listener is registered but not cancelled at the appropriate time, the object cannot be recycled.

 eventSource.addListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) { ... }
});

Anonymous internal class holds references to external classes, and if the event source exists for a long time, the listener cannot be recycled.

? Solution :

• Using weak reference listeners
• Manually log out the listener before object is destroyed
• Consider using lifecycle management in observer mode

? Internal classes hold external class references (especially static internal class misuse)

Non-static inner classes implicitly hold references to external classes. If the life cycle of the inner class object is longer than that of the outer class, it will cause the outer class instance to be unable to be recycled.

 public class Outer {
    private int[] largeData = new int[1000000];

    class Inner {
        void doSomething() {
            // Access Outer.this.largeData
        }
    }
}

If the Inner object is held for a long time (such as being placed in a static collection), Outer instance cannot be released.

? Solution :

• Declare the inner class as static to avoid implicit references
• Manually manage reference relationships
• Pay attention to the life cycle of thread classes (such as TimerTask , Runnable )

? Improper use of ThreadLocal

ThreadLocal provides independent copy of variables for each thread, but if the thread is a long-term thread in the thread pool (such as the Tomcat thread), the values in ThreadLocal may exist for a long time.

 private static ThreadLocal<Object> userContext = new ThreadLocal<>();

If remove() is not called after set() , the object will always exist in the thread's ThreadLocalMap , causing a memory leak.

? Solution :

• Call remove() after using ThreadLocal
• Clean up in finally block:

 try {
    userContext.set(user);
    // Business logic} finally {
    userContext.remove(); // Required}

3. How to detect and troubleshoot memory leaks

? Use the JVM built-in tools

• jstat : Monitor GC and heap memory changes
• jmap : generate heap dump file (heap dump)
• jhat or jvisualvm : analyze heap dump
• jconsole / jvisualvm : Real-time monitoring of memory, threads, and class loading

? Use professional tools

• Eclipse MAT (Memory Analyzer Tool) : Analyze dump files and find out the root cause of memory leaks
• YourKit / JProfiler : Commercial-grade performance analysis tool with strong visualization
• VisualVM (free): Integrated monitoring, analysis, dump viewing

? Observe GC logs

Turn on the GC log and observe whether Full GC is frequently and the memory cannot be released:

 -XX: PrintGC -XX: PrintGCDetails -Xloggc:gc.log

If memory is found to continue to grow in the elderly, there will be very little recovery after GC, which is very likely to be a memory leak.

4. Best Practice Recommendations

To avoid memory leaks, the following encoding habits are recommended:

• Avoid unnecessary long-life cycle references , especially static collections
• Close resources in a timely manner , and give priority to try-with-resources
• Use ThreadLocal with caution and be sure to call remove()
• Avoid holding references to short-lived objects in long-lived objects
• Use WeakHashMap as cache to automatically clean up recycled keys
• Avoid uncontrollably referencing external classes in internal classes
• Regular stress tests and memory analysis

Basically that's it. Java's GC helps you do a lot, but "automatic" does not mean "no management required". Only by understanding the object life cycle, reference relationships and JVM mechanism can we write truly robust applications. Not complicated, but easy to ignore.

The above is the detailed content of Java Memory Management and Avoiding Memory Leaks. For more information, please follow other related articles on the PHP Chinese website!