Fix "java.lang.OutOfMemoryError: Java heap space"
Your Java server asked for more memory than it was allowed to use and gave up. More RAM is sometimes the answer and sometimes exactly the wrong one.
6 min read · Updated Oct 21, 2026 · By GuavaHost Team
In the Console tab the line looks like this:
[Server thread/ERROR]: Encountered an unexpected exception
java.lang.OutOfMemoryError: Java heap space
You may also see the panel report that the process was killed, often with exit code 137, or the server simply vanish mid-sentence with no clean shutdown.
What the heap actually is
Java does not use memory the way other programs do. When it starts, it is told a maximum amount it may use for game objects, and that pool is the heap. Everything your world holds lives in it: loaded chunks, entities, item stacks, plugin data, the lot.
The maximum comes from a startup flag:
-Xmx4096M
That is the ceiling. On your server it is set from your plan's RAM, so you do not normally edit it by hand. When the heap fills up and Java cannot free enough space to carry on, it throws OutOfMemoryError and the server dies.
The important consequence: the heap being near full is normal. Java deliberately lets it fill before cleaning up, so a RAM graph that sits at 80 or 90 per cent on a healthy Minecraft server is expected rather than alarming. Read the CPU, RAM and disk graphs in the panel explains what the shape should look like and when a number is worth worrying about.
Why it happens
In rough order of how often we see it:
- The world and player count genuinely need more than the plan has. A modded pack with eight people exploring is a different animal from vanilla survival with three.
- Too many chunks loaded. View distance and simulation distance multiply with player count, and every loaded chunk is memory.
- Entity build-up. A mob farm, a few thousand dropped items, or a decade-old world full of item frames and armour stands. Entities are the most common hidden cost.
- A memory leak in a plugin or mod. Memory climbs steadily from a clean restart and never comes back down, and the server dies on a schedule: every eight hours, every two days, always the same interval.
- Chunk generation. Exploring new terrain allocates far more than walking around explored terrain.
- A huge single operation. A world edit paste, a map render, a backup of an enormous world.
Tell a leak from honest demand
This is the distinction that decides whether buying RAM helps.
Restart the server, then watch the RAM graph over a few hours without changing anything.
| What the graph does | What it means |
|---|---|
| Rises with player count, falls when they leave | Honest demand. More RAM, or less load, will help. |
| Rises steadily even when the server is empty, never falls | A leak. More RAM only buys you a longer gap between crashes. |
| Spikes hard when someone explores, then settles | Chunk generation. Pre-generate the world. |
| Sits high and stable, server plays fine | Normal Java behaviour. Nothing to fix. |
If you have a leak, adding RAM is the wrong fix. It takes a server that crashes daily and makes it crash every other day, which is worse because it is harder to catch.
Fix 1: Reduce what the server has to hold
Cheapest and often enough on its own.
In server.properties on the Files tab:
view-distance=8
simulation-distance=6
Default view distance is 10. Dropping it to 8 cuts loaded chunks noticeably, and most players will not notice. Simulation distance controls how far entities and redstone actually tick, and lowering it usually helps more than view distance does, so change that one first.
Then deal with entities. Mob caps, hopper chains, item piles and mob farms are where modded and long-running servers quietly bleed memory, and they are fixable: Cut entity and mob lag on your server names the config keys for each.
Fix 2: Pre-generate the world
Generating new chunks is the heaviest thing a Minecraft server does, for both CPU and memory. Doing it in advance, while nobody is playing, means nobody is waiting on it later and the memory spike happens at a time you chose.
Pair it with a world border, so exploration cannot keep adding chunks forever. Decide the border first, pre-generate out to it, and the world's memory cost stops growing.
Fix 3: Find the plugin or mod
If you suspect a leak, measure rather than guess.
The practical tool is spark, which profiles a running server and can show you where memory is going as well as where ticks are going. Find what is causing lag with spark walks through it.
Failing that, bisect by hand: remove half your plugins, run for a day, see whether memory still climbs. Start with anything that keeps a lot of state, such as map viewers, logging plugins, chunk loaders, and anything you installed shortly before the crashes began.
Fix 4: Add RAM, when it is genuinely the answer
If the demand is real and you have already trimmed the obvious, the plan needs to be bigger. You can change RAM at any time from Manage plan in the server menu, and billing is prorated.
Before you do, size it rather than guessing. How much RAM does my Minecraft server need? has figures by player count and by how modded the server is, and Changing your server RAM shows the change itself.
One warning: on Java, a very large heap is not free. Garbage collection, the process that reclaims unused memory, pauses the server while it works, and those pauses grow with heap size. A server given far more memory than it needs can stutter more, not less. Size it to what the server actually uses plus headroom, not to the biggest number you can afford.
While you wait: scheduled restarts
A nightly restart is not a fix, but it is a very effective bandage. It clears accumulated memory, resets a slow leak, and costs your players a minute at an hour nobody plays. Set one up with Scheduled tasks in the server menu.
Take a backup before any of this. If the crash happens mid-save, world data can be left damaged, and restoring a backup from the Backups page is far quicker than repairing a world by hand.
Common questions
Does more RAM always fix a heap space error?
No. It fixes the case where your server genuinely needs more memory than the plan gives it, but it does nothing about a plugin that leaks memory, and it does not help a server that is drowning in entities. Watch the RAM graph from a clean restart first: if memory climbs with nobody online, more RAM only delays the crash.
Why does my RAM graph sit at 90 per cent when nothing is wrong?
Because that is how Java works. It is given a memory ceiling and uses the space it has been allowed before cleaning up, so a high, stable graph on a healthy Minecraft server is normal. Worry about the shape over time, not the number at any one moment.
My server crashes at the same time every day. What causes that?
That regularity usually points at a memory leak reaching the ceiling after a fixed amount of uptime, or at a scheduled job such as a backup or a map render that needs a large chunk of memory at once. A nightly restart will mask it while you find which plugin is responsible.
Is exit code 137 the same as a heap space error?
They are related but not identical. A heap space error means Java itself ran out of its allowed memory and said so. Exit code 137 means the process was killed from outside for exceeding its memory limit, which usually happens when something outside the heap, such as a native library, pushes total usage over the plan's RAM.
Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.
- minecraft
- java
- memory
- ram
- troubleshooting
Host a Minecraft Java server From $3.99/mo, with instant setup and DDoS protection.
Still need help? Our team is online 24/7 to answer questions.