SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Java New Added 10 September 2026

Java: java.lang.OutOfMemoryError: Java heap space

The heap could not satisfy an allocation after a full collection. Raising -Xmx only helps when the working set genuinely grew; if the cause is a leak, a bigger heap moves the crash later and makes the pauses worse. A heap dump taken at the moment of failure tells the two apart.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Always capture the evidence, in production too: the dump is written once
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app.hprof -jar app.jar

# What the JVM decided it could use (containers: it reads the cgroup limit)
java -XX:+PrintFlagsFinal -version | grep -Ei 'MaxHeapSize|MaxRAMPercentage'

# In a container, set a share of the limit rather than a fixed number
java -XX:MaxRAMPercentage=75 -jar app.jar

# Watch live before reaching for a profiler
jcmd <pid> GC.heap_info
jcmd <pid> GC.class_histogram | head -25

# Then open the dump and look at the dominator tree
# Eclipse MAT, or: jhat / VisualVM

# Classic causes: an unbounded cache, a growing static Map,
# a result set read fully into memory, or too large a thread pool

How to diagnose Java errors

Java errors concentrate at the class loading boundary (ClassNotFoundException, NoClassDefFoundError, UnsupportedClassVersionError) and around resource pools under load. Class loading errors are almost always classpath or version problems rather than missing code. UnsupportedClassVersionError in particular is a pure bytecode-version mismatch and tells you exactly which JDK compiled the class.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Print the actual runtime version with java -version and compare it against your build target. Major bytecode version 65 is Java 21, 61 is Java 17, 52 is Java 8.
  2. Inspect the resolved dependency tree (mvn dependency:tree, gradle dependencies) to find duplicate or conflicting versions of the same library.
  3. For pool exhaustion, log pool metrics (HikariCP exposes active, idle and pending counts). Exhaustion means connections are not being returned, which is a try-with-resources problem.
  4. Enable -verbose:class temporarily to see which jar a class is loaded from when two versions are on the classpath.
  5. Capture a heap dump on OOM with -XX:+HeapDumpOnOutOfMemoryError and analyse it rather than raising -Xmx blindly.

Tools worth reaching for

  • mvn dependency:tree
  • jcmd / jstack / jmap
  • -verbose:class
  • Eclipse MAT
  • JFR (Java Flight Recorder)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.oracle.com

Related Java errors

See all 19 Java errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.