What does "java.lang.OutOfMemoryError: Java heap space" mean?

The server ran out of memory. Java was asked for more memory than the heap it was given, so it stopped. Give it more RAM (raise the RAM setting), or lower the view-distance in server.properties.

How do I fix "java.lang.OutOfMemoryError: Java heap space"?

1. Read the System Details block: Every crash report has one. "Memory:" shows free, total and max. If max is well below what the machine has, the heap is simply too small for the pack. If max is close to the machine total, the server is oversubscribed and the fix is elsewhere. 2. Raise -Xmx, but leave room: Java needs memory outside the heap for class metadata, compiled code, thread stacks and network buffers. On a modded server that is 1.5 to 2.5 GB. Never set -Xmx to the whole machine; on a hosted plan leave at least a fifth of the allocation unassigned. 3. Cut what stays loaded: view-distance and simulation-distance in server.properties decide how many chunks sit in memory per player. Dropping view-distance from 12 to 8 roughly halves the loaded area. Chunk pre-generation and spawn-protection do not help here. 4. Check for the AllTheLeaks report: If the log has a "Memory Leaks detected" block, a mod is holding on to objects it should have dropped. The block names it. Remove or update that mod before buying more RAM. 5. Restart and watch: After the change, watch the memory graph for an hour of normal play. A saw-tooth that returns to the same floor after each collection is healthy. A floor that climbs every cycle is a leak, and the pack author needs the log.

Roastd / Minecraft

critical

The server ran out of memory

What it looks like in your log

java.lang.OutOfMemoryError: Java heap space

What causes it

Java was asked for more memory than the heap it was given, so it stopped.

How to fix it

Give it more RAM (raise the RAM setting), or lower the view-distance in server.properties.

Why it happens

The heap is the memory Java hands the server for everything it keeps in play: loaded chunks, entities, tile entities, item stacks, plugin and mod state. -Xmx caps it. When the server needs one more object and the garbage collector cannot free anything, Java throws this and the server thread dies with it.

It is almost never a leak on a healthy server. It is a heap sized for the wrong workload: a modpack that wants 8 GB running on 4, a view distance that keeps twice as many chunks loaded as the RAM covers, or a plugin that caches whole worlds. The crash lands on whichever allocation happened to be last, which is why the stack trace names something innocent.

Fix it step by step

1Read the System Details blockEvery crash report has one. "Memory:" shows free, total and max. If max is well below what the machine has, the heap is simply too small for the pack. If max is close to the machine total, the server is oversubscribed and the fix is elsewhere.
2Raise -Xmx, but leave roomJava needs memory outside the heap for class metadata, compiled code, thread stacks and network buffers. On a modded server that is 1.5 to 2.5 GB. Never set -Xmx to the whole machine; on a hosted plan leave at least a fifth of the allocation unassigned.
3Cut what stays loadedview-distance and simulation-distance in server.properties decide how many chunks sit in memory per player. Dropping view-distance from 12 to 8 roughly halves the loaded area. Chunk pre-generation and spawn-protection do not help here.
4Check for the AllTheLeaks reportIf the log has a "Memory Leaks detected" block, a mod is holding on to objects it should have dropped. The block names it. Remove or update that mod before buying more RAM.
5Restart and watchAfter the change, watch the memory graph for an hour of normal play. A saw-tooth that returns to the same floor after each collection is healthy. A floor that climbs every cycle is a leak, and the pack author needs the log.

If that didn't work

If the server dies with exit code 137 and no OutOfMemoryError line, that is the operating system killing the process, not Java. The heap fit, the process as a whole did not. The fix is the opposite: lower -Xmx so the total stays under the limit.

If the error names Metaspace or "unable to create native thread", more -Xmx will not help. Those are separate pools with their own pages.

Not sure this is your problem? Paste your log and Roastd will tell you which of these it actually matched, and what else it found.

Check your own log