Static fields holding object references can prevent garbage collection; fix by using WeakHashMap or implementing eviction. 2. Improper use of listeners and callbacks may retain objects unnecessarily; fix by unregistering listeners or using weak references and static inner classes. 3. Unclosed resources like streams or connections hold native memory; fix by using try-with-resources for automatic cleanup. 4. Non-static inner classes keep references to outer instances, blocking garbage collection; fix by making them static or using WeakReference. 5. Caches without eviction grow indefinitely; fix by using managed cache libraries like Caffeine or Ehcache with size and time limits. 6. ThreadLocal variables can leak when threads are reused; fix by always calling remove() in a finally block. 7. ClassLoader leaks occur during redeployment if old class references persist; fix by avoiding static references and stopping application-created threads. To prevent leaks, avoid long-lived static collections, use weak references appropriately, clean up ThreadLocals, prefer static inner classes, close resources with try-with-resources, and monitor memory with tools like VisualVM or JProfiler, as Java memory leaks are often subtle and emerge over time under load.

Memory leaks in Java are less common than in languages without garbage collection, but they still happen—especially in long-running applications. Since the JVM automatically reclaims unused objects, memory leaks usually stem from unintentional object retention, where objects are still reachable and thus not garbage collected, even though they’re no longer needed.

Here are the most common causes:

1. Static Fields Holding Object References

Static fields live for the lifetime of the application unless explicitly cleared. If a static collection (like a List, Map, or cache) holds references to objects, those objects won’t be garbage collected—even if they’re no longer used.

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

    public static void addToCache(String key, Object value) {
        cache.put(key, value); // Objects accumulate and never get removed
    }
}

?? Fix: Use WeakHashMap for caches when appropriate, or implement a cleanup strategy (e.g., time-based eviction).

2. Improper Use of Listeners and Callbacks

Event listeners (e.g., in GUI apps or observer patterns) are often registered but not unregistered. If the listener holds a reference to a large object (or if the listener itself is non-static inner class), it can prevent garbage collection.

button.addListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        // Anonymous inner class holds reference to enclosing instance
    }
});

?? Fix: Unregister listeners when no longer needed. Use weak references or make listeners static inner classes if they don’t need access to the outer instance.

3. Unclosed Resources (I/O, Streams, Connections)

While not always a direct memory leak, unclosed resources like InputStream, ResultSet, Socket, or Connection can hold native memory or internal buffers, leading to resource exhaustion and indirect memory pressure.

FileInputStream fis = new FileInputStream("file.txt");
// Forgot to close() — file handle and buffer stay allocated

?? Fix: Always use try-with-resources:

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

4. Inner Classes Holding Outer References

Non-static inner classes maintain a reference to their enclosing class instance. If the inner class object (e.g., a long-lived thread or timer task) outlives the outer object, it prevents the outer object from being collected.

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

    public void startTask() {
        new Thread(new Runnable() {
            public void run() {
                // This Runnable holds a reference to 'Outer' instance
                // Even if Outer is no longer needed, it can't be GC'd
            }
        }).start();
    }
}

?? Fix: Make the inner class static, or use WeakReference<Outer> if outer access is needed.

5. Caches Without Proper Eviction

Custom in-memory caches that grow indefinitely (e.g., storing user sessions or computed results) are a classic source of memory leaks.

?? Fix: Use cache libraries like Caffeine or Ehcache that support size limits, time-to-live (TTL), and weak/soft references.

6. ThreadLocal Variables

ThreadLocal variables are convenient for per-thread state, but they can leak memory—especially in environments with thread pooling (like web servers). If a thread is reused but the ThreadLocal isn’t cleared, the value stays in memory.

private static final ThreadLocal<MyObject> local = new ThreadLocal<>();

?? Fix: Always call remove() when done:

try {
    local.set(someValue);
    // ... do work
} finally {
    local.remove(); // Critical!
}

7. ClassLoader Leaks

In app servers or OSGi environments, redeploying an application without fully unloading old classes can cause ClassLoader leaks. This happens when classes loaded by the old ClassLoader are still referenced (e.g., via static fields, threads, or JNI).

?? Fix: Avoid static references to application classes. Ensure threads created by the app are stopped on undeploy.

Summary of Key Prevention Tips:

• Avoid long-lived static collections unless properly managed.
• Use weak references (WeakHashMap, WeakReference) for caches or listeners.
• Clean up ThreadLocal values.
• Prefer static inner classes to avoid accidental outer references.
• Use try-with-resources for all closable resources.
• Monitor heap usage with tools like VisualVM, Eclipse MAT, or JProfiler.

Memory leaks in Java are often subtle and only show up under load or over time—so proactive design and monitoring are key.

The above is the detailed content of What are common causes of memory leaks in Java applications?. For more information, please follow other related articles on the PHP Chinese website!