Why Linux kills your Java process, and how to stop it

1. Confirm it

sudo journalctl -k | grep -i -E "out of memory|killed process"
sudo dmesg -T | grep -i -E "out of memory|oom-kill|killed process"
systemctl status myapp --no-pager      # shows "Main process exited, code=killed, status=9/KILL"

A line like Out of memory: Killed process 1234 (java) total-vm:3500000kB, anon-rss:900000kB is the proof. The anon-rss value is how much real memory the process had. If you see this and your application has no OutOfMemoryError in its log, the server was too small for everything running on it. If the kill appears together with an application error, read Fix OutOfMemoryError first.

2. Add up the memory

The heap is only part of a Java process. It also needs metaspace, thread stacks, the code cache, direct buffers and GC structures, typically 300 to 600 MB on top of -Xmx. Then the database, Nginx and the OS need theirs.

free -m
ps aux --sort=-rss | head -8
sudo smem -rtk 2>/dev/null | head

If Java has -Xmx1g on a 1 GB server, the kill is certain. Use the JVM heap calculator for the right numbers, or read how much RAM a Java app needs.

3. Fixes, in the order to try them

1. Lower the heap. Reduce -Xmx, and keep -Xms equal to it. Cap -XX:MaxMetaspaceSize and reduce -Xss or the thread pool size if you have hundreds of threads.
2. Move other memory users. Run the database somewhere else, stop services you do not need, and cut the database buffer sizes (MySQL innodb_buffer_pool_size, PostgreSQL shared_buffers).
3. Add swap as a safety net. A small swap file gives the kernel room during a spike. It does not make a too-small server fast. See Add swap for a Java server.
4. Use a bigger server. If steady use is above the physical RAM, nothing else will hold.

4. Make the failure predictable

Set a memory limit on the service so that only it is affected, and tell the kernel which process is less important:

sudo systemctl edit myapp
# add:
[Service]
MemoryMax=1400M        # about heap + overhead, below physical RAM
OOMScoreAdjust=-200    # makes this service less likely to be picked
Restart=on-failure
RestartSec=5

With MemoryMax only the service is killed when it goes over, and Restart=on-failure brings it back. Protecting the database the same way (with a more negative OOMScoreAdjust) is wise, because a killed database is worse than a restarted web application. Use these settings to limit the damage, not to avoid fixing the sizing.

5. Watch for it

A simple monitoring alert on available memory and swap use warns you before the next kill.

Last updated October 29, 2026.