Java’s garbage collector automatically reclaims objects that are no longer reachable. This removes much of the manual memory-management burden found in lower-level languages.
However, garbage collection cannot reclaim objects that are still reachable—even when the application no longer needs them. This is how memory leaks can occur in Java applications.
What a Memory Leak Looks Like
An application may gradually consume more memory as it runs. Eventually, garbage collection becomes more frequent, response times deteriorate, or the process runs out of heap space.
The cause is not always a single enormous object. It may be a collection that grows indefinitely or a long-lived object that accidentally retains references to temporary data.
Common Sources of Memory Leaks
Several patterns deserve attention:
- Static collections that continuously accumulate entries.
- Caches without size limits or expiration policies.
- Listeners that are registered but never removed.
- Thread-local values retained by reused worker threads.
- Background tasks that keep references to completed work.
- Unbounded queues that receive data faster than consumers process it.
These objects may be technically reachable, so the garbage collector correctly leaves them alone.
Be Careful with Long-Lived Collections
Consider a cache implemented using a static map:
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
public class UserCache {
private static final Map<String, User> CACHE =
new ConcurrentHashMap<>();
public static void put(String id, User user) {
CACHE.put(id, user);
}
}This cache has no eviction policy. If unique entries continue to arrive, the map can grow for the lifetime of the process.
A concurrent map makes concurrent access safer, but it does not solve unbounded memory growth.
Use a cache with explicit size limits, expiration, or another lifecycle policy when appropriate.
Diagnose Before Changing Code
When memory use rises, collect evidence before guessing.
Useful tools include:
- JVM memory metrics.
- Garbage-collection logs.
- Heap dumps.
- Java Flight Recorder.
- Profilers that show allocation rates and retained objects.
A heap dump can help identify which objects consume memory and which references keep them reachable.
Compare heap behavior after similar workloads. A temporary rise during processing is not necessarily a leak if memory returns to a stable level afterward.
Understand Allocation and Retention
High allocation rates and memory leaks are different problems.
An application may allocate many short-lived objects, creating garbage-collection pressure without retaining excessive memory. Another application may allocate relatively little but keep a growing set of objects reachable indefinitely.
The remedy depends on which problem the evidence reveals.
For allocation pressure, reducing unnecessary object creation may help. For retention problems, identify and correct the references or lifecycle rules that prevent objects from becoming collectible.
Review Listener and Thread Lifecycles
When registering listeners or callbacks, identify who owns their lifecycle and when they should be removed.
Similarly, thread-local values require care in thread pools because worker threads may be reused for unrelated requests. Clean up values when their purpose ends.
Lifecycle management should be explicit wherever objects outlive individual requests or tasks.
Conclusion
Garbage collection prevents many memory-management errors, but it cannot identify objects that are reachable and no longer useful. Unbounded collections, listeners, caches, and retained thread-local values are common sources of memory leaks.
Use JVM diagnostics to distinguish allocation pressure from retention, then fix the underlying ownership or lifecycle problem rather than relying on larger heaps alone.
