Container Resource Limits for JVM Apps: CPU and Memory Configuration

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Set memory limits in Kubernetes (resources.limits.memory) and use -XX:MaxRAMPercentage=75.0 so the JVM respects cgroup limits. For CPU, set resources.limits.cpu and the JVM automatically adjusts thread pool sizing via -XX:+UseContainerSupport. Set requests smaller than limits for better bin-packing; set Guaranteed QoS (requests=limits) for latency-sensitive services.

Interview Answer3 min

Docker resource limits (CPU and memory) are enforced by the Linux kernel's cgroup mechanism. The JVM sees these limits through the cgroup filesystem — if it fails to read them correctly, it sizes its heap for the host machine rather than the container.

Memory limits — heap sizing

Set the Docker memory limit with --memory=512m or in Compose with mem_limit: 512m; the JVM reads this limit via cgroup v1 or v2 and adjusts heap accordingly with -XX:+UseContainerSupport (enabled by default since JDK 10)
-XX:MaxRAMPercentage=75.0 allocates 75% of the container memory limit to heap — the remaining 25% covers Metaspace, thread stacks, direct buffers, and the JVM overhead; setting this above 85% causes OOMKill because the total process exceeds the limit before the GC has time to respond
Always set --memory and explicit JVM flags together; relying solely on UseContainerSupport without MaxRAMPercentage leaves heap at the default 25% of container RAM — a 512 MB container gets a 128 MB heap, which is too small for most Spring Boot applications

CPU limits — thread pool sizing

--cpus=0.5 gives the container half of one CPU core; --cpus=2 gives it two cores — the JVM reads the CPU quota via Runtime.getRuntime().availableProcessors() and uses this for default thread pool sizes
Spring Boot's Tomcat thread pool and ForkJoinPool both use availableProcessors() as a baseline — in a container with --cpus=0.5, the JVM sees 1 available processor, and default thread pool sizing becomes far too small for a production workload
Set explicit thread pool sizes with server.tomcat.threads.max=50 rather than relying on the JVM's available processor count — the correct pool size depends on the workload's I/O blocking factor, not the CPU quota

Resource requests vs limits in Kubernetes

Docker --memory maps to Kubernetes resources.limits.memory; always also set resources.requests.memory — requests determine scheduling placement, limits determine cgroup enforcement
A pod with only limits and no requests gets scheduled as if it has no resource requirements, potentially landing on an already-saturated node
Set requests equal to limits for a Guaranteed QoS class — the kubelet guarantees the pod will not be evicted under memory pressure; without this, a Burstable pod gets evicted before other workloads under node memory pressure

Interview-ready guide

Interview answer

Memory limits — heap sizing

Set the Docker memory limit with --memory=512m or in Compose with mem_limit: 512m; the JVM reads this limit via cgroup v1 or v2 and adjusts heap accordingly with -XX:+UseContainerSupport (enabled by default since JDK 10)
-XX:MaxRAMPercentage=75.0 allocates 75% of the container memory limit to heap — the remaining 25% covers Metaspace, thread stacks, direct buffers, and the JVM overhead; setting this above 85% causes OOMKill because the total process exceeds the limit before the GC has time to respond
Always set --memory and explicit JVM flags together; relying solely on UseContainerSupport without MaxRAMPercentage leaves heap at the default 25% of container RAM — a 512 MB container gets a 128 MB heap, which is too small for most Spring Boot applications

CPU limits — thread pool sizing

--cpus=0.5 gives the container half of one CPU core; --cpus=2 gives it two cores — the JVM reads the CPU quota via Runtime.getRuntime().availableProcessors() and uses this for default thread pool sizes
Spring Boot's Tomcat thread pool and ForkJoinPool both use availableProcessors() as a baseline — in a container with --cpus=0.5, the JVM sees 1 available processor, and default thread pool sizing becomes far too small for a production workload
Set explicit thread pool sizes with server.tomcat.threads.max=50 rather than relying on the JVM's available processor count — the correct pool size depends on the workload's I/O blocking factor, not the CPU quota

Resource requests vs limits in Kubernetes

Docker --memory maps to Kubernetes resources.limits.memory; always also set resources.requests.memory — requests determine scheduling placement, limits determine cgroup enforcement
A pod with only limits and no requests gets scheduled as if it has no resource requirements, potentially landing on an already-saturated node
Set requests equal to limits for a Guaranteed QoS class — the kubelet guarantees the pod will not be evicted under memory pressure; without this, a Burstable pod gets evicted before other workloads under node memory pressure

03 · Deep dive