Code10x
Java in a containermedium3-5 years

A Spring Boot container is given a 1 GiB memory limit with no `-Xmx` or `-XX:MaxRAMPercentage` flag set, on a current JDK. It runs fine under light load, then gets killed under a traffic spike with no exception in the application log. What happened, and what's the fix?

A current JVM reads the container's cgroup memory limit and sizes its default heap as a fraction of it, so it isn't blindly guessing — but the kernel enforces the 1 GiB limit against the whole process, not just the heap: Metaspace, thread stacks, direct buffers, the native allocator's own overhead all count too. Under light load the heap and everything around it comfortably fits; under a spike, more threads spin up (more stacks), more classes may load (more Metaspace), and the total process footprint can cross 1 GiB even though the heap itself never exceeded whatever it was sized to. The kernel's cgroup enforcement kills the process outright — OOMKilled, exit code 137 — with nothing in the Java log, because there was no Java exception; the JVM was never given the chance to log anything, it was just gone. The fix is setting -XX:MaxRAMPercentage deliberately (75% is a common starting point for a service) rather than relying on the JVM's default (25%, sized for a laptop shared with other programs) or leaving explicit room for everything that isn't heap, and adding -XX:+ExitOnOutOfMemoryError so a genuine heap exhaustion at least produces a clean, loggable exit rather than a JVM stuck answering health checks with nothing else working.

The lesson behind it →
PreviousA Spring Boot container is configured with `SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/orders`, and the database is a sibling container in the same Compose file. The application can't connect. Why not, and what should the URL say instead?Next A service is deployed with `cpu: 500m` (half a core). Its `newFixedThreadPool(Runtime.getRuntime().availableProcessors())` ends up with exactly one thread, and throughput is much worse than expected. What is `availableProcessors()` actually returning here, and why?
More on Java in a container
A service is deployed with `cpu: 500m` (half a core). Its `newFixedThreadPool(Runtime.getRuntime().availableProcessors())` ends up with exactly one thread, and throughput is much worse than expected. What is `availableProcessors()` actually returning here, and why?A service's Dockerfile ends with `CMD java -jar app.jar` (shell form, no brackets). `docker stop` on the running container takes the full 10-second grace period every time, and the JVM never runs its shutdown hooks. What's actually happening, and what fixes it?A team migrates a service onto a base image built on `eclipse-temurin:8u181-jre` — a build that predates container awareness — inside a container with a 512 MiB memory limit, on a node with 64 GiB of physical RAM. No `-Xmx` or `-XX:MaxRAMPercentage` is set. It runs fine for days, then dies with `OOMKilled`. Why does it take days rather than failing immediately, and what's actually different from the same scenario on a current JDK?A team's Dockerfile does `COPY target/app.jar app.jar` as a single layer, and every deploy — even a one-line code change — pushes and pulls the full 45 MB jar to and from the registry. What does switching to Spring Boot's layered jar actually change at the registry and node level, and why doesn't the same benefit apply to the fat jar no matter how the Dockerfile is restructured around it?