Code10x
Java in a containersenior8+ years

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?

Before container awareness, the JVM sized its default heap by reading /proc/meminfo — the host's total physical memory — because that was the only notion of "the machine" a userspace process had, and it was a correct assumption everywhere except inside a container with a tighter cgroup limit than the host actually has. On a 64 GiB host, a pre-aware JVM's default heap comes out on the order of 16 GiB (roughly a quarter of what it read), entirely independent of the container's real 512 MiB ceiling. It doesn't fail immediately because the heap grows lazily as the application actually allocates objects, not all at once at startup — the process runs normally for as long as its real memory usage stays under 512 MiB, which can be days of ordinary traffic before enough has accumulated to cross the cgroup's actual limit. The moment it does, the kernel's cgroup enforcement kills the process outright with no Java exception and nothing in the application log, because the JVM was never told a tighter limit than the host's existed in the first place. This became the default fix around Java 10, backported to 8u191 — worth hedging the exact point-release precision on, since that detail is easy to misstate — after which the JVM reads the cgroup's actual limit and sizes against it instead.

The lesson behind it →
PreviousA service's image ends with `USER app` (uid 10001). In development it's run with `-v $(pwd)/data:/app/data`, where `./data` was created by a plain `mkdir` as the developer's own user (uid 1000). The container gets `Permission denied` writing to `/app/data`. Why, precisely, and does switching to a named volume change anything?Next 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?
More on Java in a container
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 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'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?