Which Java OOM Error Is Killing Your App? Dive into Heap, Metaspace & More

1. Java heap space

When the Java heap is completely filled, the garbage collector cannot reclaim memory fast enough while new objects keep being allocated, leading to java.lang.OutOfMemoryError: Java heap space.

Typical analysis steps:

Dump the heap.

Analyze the dump with tools such as MAT, YourKit, JProfiler, or IDEA Profiler.

Identify the largest objects and the classes that occupy most memory.

Review and optimise code to reduce object creation.

Increase JVM heap size, limit request or thread counts, or add more nodes.

Common library misuse

Avoid creating new instances of heavyweight objects on every request; instead keep a singleton or a pooled instance.

Apache HttpClient : create a single CloseableHttpClient at startup and reuse it.

Gson : keep a global Gson instance.

Jackson : keep a single ObjectMapper instance.

2. GC overhead limit exceeded

This error indicates that the GC is spending too much time (over 98%) reclaiming memory while freeing very little heap space, but the application is still responsive.

Typical signs:

Low request volume.

Frequent long‑duration GC pauses.

Occasional high‑latency responses.

High CPU utilization.

Investigation is similar to heap‑space OOM: analyse heap usage, reduce object allocation, and tune GC parameters.

3. Metaspace/PermGen

Metaspace stores class metadata. By default it has no hard limit, but excessive class loading can exhaust native memory, causing java.lang.OutOfMemoryError: Metaspace.

Mitigation strategies:

Set a maximum size, e.g. -XX:MaxMetaspaceSize=256m.

Track class loading with tools like Arthas or JVM flags -XX:+TraceClassLoading and -XX:+TraceClassUnloading.

Common causes of Metaspace growth include improper use of reflection, buggy Java agents that generate many dynamic classes, and excessive dynamic proxies (e.g., Spring AOP creating new proxy classes for prototype beans).

4. Code Cache

Code Cache holds JIT‑compiled hot code. When it becomes full, the JVM disables the JIT compiler, leading to slower execution. The warning looks like:

Server VM warning: CodeCache is full. Compiler has been disabled.

Adjust its size with -XX:ReservedCodeCacheSize= and avoid generating overly large classes or methods.

5. Direct Memory

Direct Memory (off‑heap) is used for high‑performance I/O, such as Netty. It is allocated via malloc and managed manually, often through sun.misc.Unsafe. Exhaustion results in java.lang.OutOfMemoryError: Direct buffer memory.

Typical limits are set with -XX:MaxDirectMemorySize=. Misuse can cause native crashes, e.g. access violations.

6. Linux OOM Killer

When the operating system runs out of memory, the Linux OOM Killer terminates the process that consumes the most memory, often the JVM itself. This usually indicates a native memory leak, frequently caused by third‑party libraries or bugs in native code such as GZIP compression utilities.

Native‑memory troubleshooting steps:

Use pmap to inspect memory mappings.

Trace system calls with strace.

Replace the default allocator (e.g., jemalloc/tcmalloc) or use profiling tools that support native analysis.

Identifying and fixing native leaks can be complex and may require root privileges and coordination with operations teams.