JVM在容器中因无法感知cfs_quota_us导致GC线程数远超CPU配额，引发上下文切换雪崩、STW延长和并发退化；需启用UseContainerSupport并显式设置ActiveProcessorCount或手动调优GC线程数。

云原生环境中，JVM 在容器内运行时若未正确感知 CPU 限制，会导致 GC 线程数量严重失配——这不是配置错误，而是 JVM 对 Linux CFS（Completely Fair Scheduler）调度器中 cfs_quota_us 机制缺乏原生适配所引发的系统性降级。

根本原因：JVM 启动时“看不见”容器 CPU 配额

JVM（尤其 JDK17 及更早版本）默认通过 /proc/cpuinfo 或 sysconf(_SC_NPROCESSORS_ONLN) 获取可用 CPU 数，而这两个接口返回的是宿主机物理核数或虚拟机 vCPU 总数，完全忽略 cgroups v1/v2 中设置的 cpu.max（cfs_quota_us/cfs_period_us）限制。例如：

• 容器配置 cpu.quota=20000, cpu.period=100000 → 实际仅允许 2 个逻辑 CPU 的计算份额
• JVM 却读到宿主机有 64 核 → 自动设 -XX:ParallelGCThreads=47、-XX:ConcGCThreads=12
• 结果：47 个并行 GC 线程在仅 2 核配额下激烈争抢，大量线程陷入 RUNNABLE→THROTTLED 状态，实际并发度远低于 1

GC 表现断层：线程多 ≠ 效率高，反而加剧 STW 和吞吐塌方

过度配置的 GC 线程在受限 CPU 下产生三重恶化：

• 上下文切换雪崩：数十个 GC 线程在 2 核上被 CFS 频繁抢占、切换，perf stat -e sched:sched_switch 可观测到每秒数万次切换
• STW 时间非线性增长：ParallelGC 的并行标记/复制阶段因线程饥饿无法饱和执行，本应毫秒级完成的任务拖长至百毫秒以上
• 并发阶段退化为串行：G1 的并发标记线程（ConcGCThreads）因调度延迟错过安全点（safepoint）窗口，被迫降级为单线程扫描，标记耗时翻倍

破局路径：从感知、约束到协同

需在 JVM 层、容器层、GC 策略层形成闭环：

• 强制显式指定：容器启动时通过 -XX:ParallelGCThreads=N -XX:ConcGCThreads=M 手动设值，N/M 应基于 cpu.quota / cpu.period 向下取整（如 2.0 → N=2, M=1）
• 启用容器感知（JDK10+）：添加 -XX:+UseContainerSupport（JDK10 引入，JDK17 默认开启），但注意它仅对 cgroup v1 memory 和部分 CPU 指标生效，仍不解析 cfs_quota_us；必须配合 -XX:ActiveProcessorCount 显式覆盖
• 选用低线程依赖 GC 器：在严苛 CPU 限制场景（如

验证与可观测关键点

仅看 GC 日志不够，需交叉验证：

• 查 JVM 实际线程数：jstack <pid> | grep "GC task thread" | wc -l</pid>
• 查容器真实配额：cat /sys/fs/cgroup/cpu,cpuacct/cpu.max（cgroup v2）或 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）
• 查调度压制：cat /sys/fs/cgroup/cpu,cpuacct/cpu.stat 中 nr_throttled 和 throttled_time 持续增长即为信号
• GC 日志中关注 [GC Worker Start (ms)] 与 [GC Worker End (ms)] 时间差是否远超理论耗时，暴露线程饥饿