UltraHard Scenario BasedSpring Boot#767 min readJul 11, 2026
Memory leak investigation.
practice
Hook: A Spring Boot memory leak is like a guest who keeps leaving their coat in your house every hour; the garbage collector can only clean up objects that are truly unreachable.
Question: How do you investigate a memory leak in a Spring Boot application?
Answer: A memory leak means objects are still being held in memory even though the app no longer needs them, so the JVM cannot reclaim them. In Spring Boot, the usual suspects are static collections, caches without eviction, ThreadLocal misuse, listeners, and unclosed resources. The investigation starts by confirming the symptom, then capturing a heap dump, finding the biggest retained objects, and tracing who is still referencing them.
Interview-Ready Answer: I would first confirm it is a real heap leak by watching heap usage and GC pauses under steady load. Then I would capture a heap dump with jcmd, inspect retained size in a tool like Eclipse MAT, and trace the GC roots back to the code that is keeping objects alive. In Spring Boot, I would especially check static maps, unbounded caches, ThreadLocal values, and long-lived singleton beans. Once I find the root reference, I would fix the ownership or eviction policy and verify the heap stays stable under the same traffic.
%22%20stroke%3D%22%234f46e5%22%20stroke-width%3D%221.5%22%2F%3E%3Ctext%20x%3D%22500%22%20y%3D%22308%22%20text-anchor%3D%22middle%22%20font-size%3D%2215%22%20font-weight%3D%22bold%22%20fill%3D%22%23ffffff%22%20font-family%3D%22Segoe%20UI%2C%20Arial%2C%20sans-serif%22%3EMemory%20Leak%3C%2Ftext%3E%3C%2Fsvg%3E)
What a memory leak really is
In Java, the garbage collector only frees objects that are unreachable from any GC root. A GC root is a starting point such as a live thread, a static field, or a loaded class. If your app keeps a reference to an object by mistake, that object stays reachable and grows the heap over time. That is why a leak is usually not about bytes disappearing from RAM; it is about the program accidentally keeping references alive.
How to investigate under the hood
- Confirm the pattern. Watch heap usage, GC frequency, and response latency. A leak usually shows a steady upward trend in used heap, more frequent full GCs, and eventually
OutOfMemoryErroror pod restarts. If traffic stops and memory does not fall, that is a strong clue. - Reproduce with a controlled load. Send the same request pattern for several minutes. You want a repeatable rise, not a one-off spike. A spike can simply be normal allocation pressure, where the app creates many short-lived objects but GC eventually cleans them.
- Capture a heap dump. Use
jcmd <pid> GC.heap_dump /tmp/app.hprof. A heap dump is a snapshot of live objects. It is large, often close to the live heap size, so on a 2 GB heap dump you may need several GB of workstation RAM to inspect it comfortably. - Open the dump in Eclipse MAT or VisualVM. Focus on retained size, which means how much memory would be freed if that object disappeared. Retained size is more useful than shallow size, which is only the object’s own bytes.
- Trace GC roots. If a huge list is retained by a static field, you have found the ownership bug. In Spring Boot, this often points to a singleton bean, a static cache, a listener list, or a ThreadLocal attached to a long-lived thread pool.
- Fix and verify. Replace unbounded storage with eviction, remove stale references, close resources, and rerun the same load. The heap should now rise during load and then settle instead of marching upward forever.
Tools and when to use them
| Tool | Best for | Main trade-off |
|---|---|---|
| GC logs | Fast first signal | Shows symptoms, not roots |
| JFR | Timeline and allocation bursts | More setup, less detail than a dump |
| Heap dump | Root-cause analysis | Heavy to capture and inspect |
Common Spring Boot causes
- Static collections: A
static Maporstatic Listlives for the entire classloader lifetime. - Unbounded caches: A cache without size limits or expiry slowly becomes a memory sink.
- ThreadLocal misuse:
ThreadLocalstores data per thread; if a pool thread is reused, the value can stick around forever unless removed. - Resource leaks: Unclosed streams, HTTP responses, JDBC objects, or direct buffers can hold heap or native memory.
Performance note: Finding the biggest objects in a dump is roughly linear in the number of live objects, but retained-size analysis can still take minutes on multi-GB heaps. A good rule is to fix the root reference rather than just increasing Xmx; raising heap may delay the crash but does not solve the leak.
Memory hook: Think of memory as a hotel. GC cleans empty rooms, but a leak is a guest who keeps a fake reservation alive so the room can never be reused.
Real-world production story
Imagine an e-commerce checkout service built with Spring Boot. During a weekend sale, traffic doubles and the team notices the pod memory climbing from 400 MB to 1.8 GB over a few hours. Latency jumps from 80 ms to 4 seconds, the JVM starts doing full GCs every few seconds, and Kubernetes eventually kills the pod with OOMKilled.
The root cause turns out to be a singleton bean that stores per-order response objects in a static ConcurrentHashMap for debugging. Because order IDs are unique, the map never reuses keys, so every request leaves another large object behind. The logs show growing GC pauses and the heap dump reveals that the map is retaining most of the live heap. The fix is to remove the debug store, or replace it with a bounded cache and proper expiry.
What goes wrong when people misunderstand it: teams often add more memory first. That can hide the leak for a few more hours, but the curve still grows, the app still gets slower, and the next outage is bigger and harder to diagnose.
Spring Boot
package com.example.memoryleak;
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.lang.management.MemoryUsage;
import java.time.Instant;
import java.util.Collections;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ResponseStatusException;
@SpringBootApplication
public class MemoryLeakInvestigationApplication {
public static void main(String[] args) {
SpringApplication.run(MemoryLeakInvestigationApplication.class, args);
}
}
@RestController
@RequestMapping(path = "/demo", produces = MediaType.APPLICATION_JSON_VALUE)
class LeakDemoController {
// This bean is a singleton, so its fields live for the life of the application.
// We keep the registry objects as normal fields to show that the leak is caused
// by the data structure inside them, not by creating a new controller per request.
private final LeakyRegistry leakyRegistry = new LeakyRegistry();
private final BoundedRegistry boundedRegistry = new BoundedRegistry(100);
private final MemoryMXBean memoryMxBean = ManagementFactory.getMemoryMXBean();
@PostMapping("/leak/{key}")
public Map<String, Object> leak(@PathVariable String key,
@RequestParam(defaultValue = "256") int kilobytes) {
validateInput(key, kilobytes);
// Each call allocates a fresh payload. If we store it in a static map, the object
// remains reachable and GC cannot reclaim it.
byte[] payload = new byte[kilobytes * 1024];
leakyRegistry.store(key, payload);
return stats("stored in leaky registry");
}
@PostMapping("/bounded/{key}")
public Map<String, Object> bounded(@PathVariable String key,
@RequestParam(defaultValue = "256") int kilobytes) {
validateInput(key, kilobytes);
// This path shows the safer pattern: a bounded cache with eviction.
byte[] payload = new byte[kilobytes * 1024];
boundedRegistry.store(key, payload);
return stats("stored in bounded registry");
}
@GetMapping("/stats")
public Map<String, Object> statsEndpoint() {
return stats("current snapshot");
}
@DeleteMapping("/clear")
public Map<String, Object> clear() {
leakyRegistry.clear();
boundedRegistry.clear();
// Do not rely on System.gc() as a fix in real systems; it is not deterministic.
return stats("registries cleared");
}
private void validateInput(String key, int kilobytes) {
if (key == null || key.isBlank()) {
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "key must not be blank");
}
if (kilobytes <= 0 || kilobytes > 2048) {
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "kilobytes must be between 1 and 2048");
}
}
private Map<String, Object> stats(String note) {
MemoryUsage heap = memoryMxBean.getHeapMemoryUsage();
Map<String, Object> response = new LinkedHashMap<>();
response.put("note", note);
response.put("time", Instant.now().toString());
response.put("heapUsedMb", toMb(heap.getUsed()));
response.put("heapCommittedMb", toMb(heap.getCommitted()));
response.put("heapMaxMb", toMb(heap.getMax()));
response.put("leakyEntries", leakyRegistry.size());
response.put("boundedEntries", boundedRegistry.size());
return response;
}
private long toMb(long bytes) {
if (bytes < 0) {
return -1;
}
return bytes / (1024 * 1024);
}
}
class LeakyRegistry {
// Static state is a classic leak source: it is rooted by the classloader.
// As long as the class stays loaded, this map stays alive too.
private static final Map<String, byte[]> CACHE = new ConcurrentHashMap<>();
void store(String key, byte[] payload) {
CACHE.put(key, payload);
}
int size() {
return CACHE.size();
}
void clear() {
CACHE.clear();
}
}
class BoundedRegistry {
private final int maxEntries;
private final Map<String, byte[]> cache;
BoundedRegistry(int maxEntries) {
this.maxEntries = maxEntries;
this.cache = Collections.synchronizedMap(new LinkedHashMap<String, byte[]>(16, 0.75f, true) {
@Override
protected boolean removeEldestEntry(Map.Entry<String, byte[]> eldest) {
// Evict the oldest entry so the cache cannot grow forever.
return size() > BoundedRegistry.this.maxEntries;
}
});
}
void store(String key, byte[] payload) {
cache.put(key, payload);
}
int size() {
return cache.size();
}
void clear() {
cache.clear();
}
}
Follow-up & Tricky Questions:
- How do you prove it is a real leak and not just GC pressure? Reproduce the issue with steady traffic and compare two heap dumps. If the same objects keep growing and are still reachable from GC roots, it is a leak; if memory falls back after traffic stops, it is more likely allocation pressure.
- What is the first tool you reach for? I usually start with GC logs or JFR because they are low friction and show whether the JVM is spending too much time collecting. If the pattern looks suspicious, I take a heap dump for root-cause analysis.
- Why are static fields dangerous in Spring Boot? Spring beans are often singletons, so a static collection can become a permanent root for data that should have died after the request. That is one of the easiest ways to accidentally keep memory alive for the life of the process.
- What does retained size mean? Retained size is the amount of memory that would be freed if that object were removed, including objects only reachable through it. It matters more than shallow size when you are chasing the biggest leak source.
- How do you handle ThreadLocal leaks? Always call
remove()in afinallyblock when the value is request-scoped. This matters especially with thread pools, because pooled threads are reused and can carry old data into the next request. - Tricky: Does calling
System.gc()fix a memory leak? No. It can only reclaim objects that are already unreachable, so a true leak still stays alive and the heap will grow again. - Tricky: If the heap dump is small, can the app still be leaking memory? Yes. The leak may be in native memory, direct buffers, thread stacks, or an external resource rather than on the Java heap.
- Tricky: Are all caches leaks? No. A cache is fine if it has a clear eviction policy, size limit, or TTL. It becomes a leak when nothing ever removes old entries.
Common Mistakes:
- Mistake: increasing
Xmxfirst. Correction: do that only as a temporary safety net; the real fix is to stop retaining objects forever. - Mistake: looking only at heap used. Correction: check GC pauses, retained size, and GC roots, because the number alone does not tell you why memory stays alive.
- Mistake: forgetting ThreadLocal cleanup. Correction: always clear request data in
finallywhen using thread pools. - Mistake: treating every cache as safe. Correction: make caches bounded and measurable, with eviction or expiry.
Memory Hook: ‘If you can still point to it, GC cannot free it.’ Imagine a hotel where every room has a rope tied to the lobby desk; as long as the rope stays attached, housekeeping is not allowed to clean that room.
Cheat Sheet:
- Confirm a slow upward trend, not a one-time spike.
- Use
jcmdor JFR first, then a heap dump for root cause. - Look for static maps, unbounded caches, ThreadLocal misuse, and listeners.
- Investigate retained size and GC roots, not just object count.
- Fix ownership or eviction, then rerun the same load to verify the curve flattens.
Practice Tasks:
- Hit the
/demo/leak/{key}endpoint 500 times with unique keys and watch the stats grow. - Repeat with
/demo/bounded/{key}and confirm the bounded cache stops growing past 100 entries. - Take a heap dump from a test app, open it in MAT, and find the object with the largest retained size.