K8s 1.28 + cgroup v2 下 Java 17 设 CPU limit 后 GC STW 期间 P99 抖动 3 倍，如何诊断与调优？

背景 生产环境：K8s 1.28.9 + containerd 1.7.13 + cgroup v2 + 内核 5.15.0-91。节点 16C64G，跑一个 Java 17 / Spring Boot 3 的订单服务（无状态，4C8G Pod 规格），JVM 参数：-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200，未显式设置 GC 线程数。Deployment 资源：requests.cpu=2 / limits.cpu=4（即 cgroup v2 cpu.max=400000 100000）。QPS 约 3000，P99 基线 80ms 左右。

现象 每 30–60 秒出现一次 P99 尖刺，飙到 250–400ms，持续 100–300ms，然后回落。频率和 GC 周期高度吻合（约每分钟 1 次 Young GC）。

已尝试的排查与结果

1. GC log（-Xlog:gc*,gc+heap=debug:file=/logs/gc.log:time,uptime,level,tags）：每次 P99 尖刺都对应一次 Young GC，STW 在 GC log 里记的耗时是 80–150ms，看起来在 MaxGCPauseMillis 预算内，但实际用户侧感知到的延迟是 250–400ms，中间有 100–250ms 的"看不见"的延迟。
2. cgroup v2 cpu.stat：在 Pod 内 cat /sys/fs/cgroup/cpu.stat，对比 GC 前后的 nr_throttled 和 throttled_usec：每次 GC 期间 nr_throttled 增长 1–3 次，throttled_usec 增加 20000–40000（即 20–40ms 被限流）。
3. pidstat -t 1：GC 期间能看到 G1 Young RemSet 和 G1 Concurrent Refine 线程 CPU 使用率接近 100%，但总 CPU 被 cap 在 4 核。
4. JFR：jdk.GCPhase 事件里 STW 阶段 80ms，但 jdk.JavaMonitorEnter 和 jdk.ObjectAllocationNewArray 在 GC 后 200ms 内还有大量等待，说明 GC 结束后应用线程还在"追"被限流掉的工作。

我的初步假设 G1GC 的 STW 阶段（尤其是 Concurrent Mark 的 remark 和 Young GC 的 copy 阶段）需要多个 GC 线程并发跑，但 cgroup v2 cpu.max=4 把总 CPU cap 在 4 核。Java 17 默认 ParallelGCThreads 和 ConcGCThreads 是基于可见 CPU 核数（即 request=2）还是实际可用核数（即 limit=4 或节点 16C）来算的？如果 Java 看到的是节点 16C 的核数，那 GC 线程池会开 16 个左右，但 cgroup 只给 4 核额度 → GC 线程互相抢 CPU → STW 实际耗时远超 GC log 里的"逻辑耗时"。

期望得到的答案形态

1. 有人做过类似的 JVM + cgroup v2 + CPU limit 压测，能给出可复现的诊断命令（特别是如何从 cgroup v2 cpu.stat + GC log 关联出"GC 被限流"的证据链）。
2. JVM 参数层面：-XX:ParallelGCThreads 和 -XX:ConcGCThreads 应该设成多少（基于 limit 还是 request？有没有经验公式）？Java 17 的 -XX:+UseContainerSupport 在 cgroup v2 下是否真的能正确感知 limit？
3. K8s 层面：CPU limit 到底该不该设？如果设，对 Java GC 的影响有没有量化数据？如果不设，用 cpu.weight 替代，Java 侧要怎么配合？
4. 有没有人在生产里踩过"GC log 说 STW 80ms，但 P99 实际 300ms"这个坑，最后怎么解的？