Your Spring Boot service in Kubernetes keeps restarting with exit code 137. How do you investigate and fix it?

What 137 means: 128 + 9, the process got SIGKILL. In Kubernetes the pod status shows OOMKilled: total process memory crossed the container’s memory limit and the kernel killed it instantly, so there’s no Java stack trace.

Why it happens: the JVM uses more than its heap. Metaspace (100–200 MB for a Spring app), the code cache, about 1 MB per platform thread stack, direct buffers for Netty and HTTP clients, and GC structures all live outside -Xmx. A config like -Xmx2g in a 2 GiB container is guaranteed to get killed once the heap fills up.

How to investigate:

1. Confirm OOMKilled in kubectl describe pod and look at the memory graph: a slow climb (leak or growing cache) or a spike (a large request, a burst of threads)?
2. Check the JVM flags actually in effect (jcmd <pid> VM.flags) and the heap size the JVM picked.
3. Enable -XX:NativeMemoryTracking=summary and compare jcmd <pid> VM.native_memory summary with the container’s memory usage to see which area grows.
4. If the heap itself grows, take a heap dump (-XX:+HeapDumpOnOutOfMemoryError, or jcmd GC.heap_dump) and look for the leak.

Fix: size the heap as a percentage, -XX:MaxRAMPercentage=75, so a quarter of the limit is left for everything else; add -XX:+ExitOnOutOfMemoryError for clean restarts; cap thread pools and off-heap caches. Only raise the limit once you know what the memory is for.