Code10x
Java in a containermedium3-5 years

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 container's CPU limit isn't a count of cores, it's a quota — 500 millicores means 50 milliseconds of CPU time per 100-millisecond period, spread across however many physical cores the process happens to run on. A container-aware JVM reads that quota and reports it through Runtime.availableProcessors(), and a fractional quota below one whole core still rounds up to 1 — it never reports 0, since a process needs at least one logical processor to exist at all — so availableProcessors() returns exactly 1 here, and a thread pool sized from it gets exactly one thread. The fix isn't really about the thread pool at all: give the JVM at least one whole CPU if genuine parallelism (a parallelStream(), multiple worker threads doing CPU-bound work) matters, or size I/O-bound pools from the downstream's own capacity rather than from core count, since an I/O pool sized to 1 caps concurrent requests at one regardless of how much the JVM is actually waiting rather than computing.

The lesson behind it →
PreviousA 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?Next A Compose file has `depends_on: [postgres]` with no `condition:`, and the API container crashes on startup roughly one time in five with a connection-refused error, but never on a rerun a moment later. What's the race, and what actually fixes 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'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?