hardScenarioConceptMidSeniorStaff
A service dies with OutOfMemoryError in production. Walk me through diagnosing it.
Read the message text first, because it names which region ran out. Then use the GC log to see whether the live set after each full collection is trending upward, which means a leak, or flat and close to the ceiling, which means the heap is simply too small. A heap dump tells you what is retaining the memory.
6 min readUpdated 2026-08-15
Answer
Short answer
Diagnose Java OutOfMemoryError by reading the exact message first, because heap, Metaspace, direct buffer and native thread failures point to different resources. Then use GC logs, heap dumps and container or OS evidence to decide whether the live set is leaking, the limit is too small, or memory is being exhausted outside the Java heap.
Was this answer helpful?
Likely follow-ups
- How would you tell a Java OutOfMemoryError apart from the container being killed by the kernel?
- What does a Metaspace OutOfMemoryError usually mean, and why do repeated redeploys trigger it?
- Why can shrinking the heap fix "unable to create new native thread"?
- How does the default maximum heap get chosen when you run in a container with no -Xmx?
Related questions
- Your GC log shows a stop-the-world pause far longer than the collection work inside it. Where did the rest of the time go?hardAlso on jvm and garbage-collection5 min
- You put @functools.lru_cache on a method to speed it up, and the service's memory keeps growing. Why, and which fix do you choose?mediumAlso on memory-leak and garbage-collection4 min
- How do you optimise Java Virtual Machine (JVM) garbage collection to eliminate tail latency spikes in a game server?hardAlso on jvm and garbage-collection3 min
- Your application cannot reach a service that should be up. Walk me through diagnosing it from the shell.mediumAlso on troubleshooting6 min