How does garbage collection behave differently in a containerized environment with cgroup memory limits?

Since JDK 10 (JEP 343, container awareness, refined through JDK 17), the JVM reads cgroup limits rather than the host machine's total physical resources when computing default ergonomics - both the number of "available processors" (which drives GC thread counts) and the memory limit used for default heap sizing come from the container's cgroup, not the underlying node.

Without an explicit -Xmx, the JVM sizes the default max heap as a percentage of the detected memory limit via -XX:MaxRAMPercentage (25% by default), and GC thread pool sizes scale off the container's CPU quota/shares rather than the host's total core count - which matters because an under-provisioned GC thread pool in a CPU-throttled container can materially lengthen pause times for Parallel or G1 collections.

Misconfiguration is the most common failure mode: if cgroup limits aren't set, aren't propagated correctly by the orchestrator, or an older JVM/cgroup v1-v2 mismatch causes detection to fail, the JVM can fall back to sizing itself off the host's full memory - leading to a heap far larger than the container's actual memory limit and an OOM-killed pod. The fix is to always set -Xmx/-XX:MaxRAMPercentage explicitly and verify what the JVM actually detected with jcmd <pid> VM.info or -XX:+PrintFlagsFinal inside the container.