K8s cgroup v2 下 cpu.max 限流 2~5% 就足以让 P99 翻倍：怎么从数据上确认是限流而不是 JIT / GC / 后台任务？

背景 我负责一个核心查询服务：Spring Boot 3.2 + JDK 17.0.10（G1，-Xmx4g -XX:MaxGCPauseMillis=50）+ MySQL 8 + Redis 7，K8s 1.28.4 / containerd 1.7 / cgroup v2 / 内核 5.15，单 Pod cpu.max=200000 100000（即 limit=2 核，burst 关闭），memory limit=6G。线上 QPS 约 600~800，P50 一直稳定在 12~18ms。

现象

• 每天 10:00~11:00 与 20:00~21:00 两个尖峰窗口，P99 间歇性从 30ms 飙到 250~450ms，每 5~15 分钟出现一次，每次持续 200~800ms；
• 尖峰窗口内 P50 几乎不动（14~16ms），只有 P99 / P999 恶化——典型的「少数请求被卡住」形态；
• 监控面板里 container_cpu_usage_seconds_total 折算出的 CPU 使用率只到 limit 的 35~55%，远没到 100%，但读 cgroup v2 的 cpu.stat 能看到 nr_throttled 在涨、throttled_usec 非零，粗算 throttle 比例只有 2~5%；
• 这个 2~5% 的限流比例按直觉「应该不影响 P99」，但实际 P99 确实翻倍，让我怀疑限流不是主因，或者我算错 throttle 比例的口径。

已尝试的排查与结果

1. GC：-Xlog:gc*=file:gc.log:time,uptime,level,tags 全量日志，尖峰窗口内 0 次 Full GC，Young GC 平均 4ms、最大 9ms，Pause Young (Normal) 与 P99 尖峰时间戳没有重叠——基本排除 GC；
2. JIT：jstat -print_compilation_time <pid> 1000 在尖峰窗口抓了 3 次，Compiled 计数没有明显跳变，Failed 恒为 0，看起来也不是去优化（deopt）风暴——但我不知道怎么看 C2 编译线程是否阻塞了业务线程；
3. 连接池：HikariCP active 峰值 18/20、pending 恒为 0，connectionTimeoutCount=0；MySQL 侧 performance_schema.events_statements_history 里 P99 RT 与平时一致，排除 DB；
4. 线程：jstack 在尖峰窗口抓了 5 次（每 200ms 一次），看到一部分 Tomcat 工作线程停在 at java.base/java.lang.Object.wait(...) + ThreadPoolExecutor.getTask，一部分停在 epoll_wait，没有看到明显的锁竞争 / 死锁，但也没看到明确的「被内核 throttle」的栈帧（我猜内核层 throttle 不会体现在 Java 栈里）；
5. 后台任务：应用内只有一个 @Scheduled(fixedRate=60s) 的指标上报 + 每 5 分钟的日志轮转，量级很小，理论上不该造成 400ms 毛刺；
6. 临时把 limit 从 2 核临时调到 4 核（同节点资源够），P99 尖峰消失——这反向印证了限流相关，但 4 核时 nr_throttled 也还是非零，说明不是「限流=0」才正常。

期望得到的答案形态

1. 限流 2~5% 为什么能造成 P99 翻倍：一个可解释的机制模型（是不是「被 throttle 的那 100ms 内所有业务线程一起停」？还是「throttle 只卡到正在 runnable 的线程，但业务线程大部分时间都在 IO wait 所以影响小」？），最好带一个可量化的估算公式；
2. 可落地的确认手段：怎么把「限流 / JIT / 后台任务」三者用同一组数据区分开（例如：async-profiler 的 wall 模式 + jstat -print_compilation_time + cgroup cpu.stat 三者时间戳对齐的方法，或者更直接的 perf / bpftrace 脚本）；
3. 如果是限流，怎么调：是抬 limit、开 cpu.max.burst（cgroup v2）、还是把 CPU 密集逻辑（JSON 序列化、正则、加解密）挪到异步线程池？各自的代价是什么？
4. 验收指标：调完后用什么指标确认「限流不再是 P99 的凶手」（throttled_usec / usage_usec 的阈值？还是 P99 直方图的分位数？）。

参考：社区里 @苏清和 的《K8s 上 JVM 服务内存 limit 怎么定》和 @苏星河 的《K8s Java 17 容器被 OOMKill 但 JVM 日志显示堆未打满》都讲了 K8s + JVM 的坑，但都是内存侧；@程知远 的《Java 服务发布后前 3 分钟 P99 偏高》是 JIT 侧；这次我卡在 cgroup v2 CPU 限流的「小比例 throttle → 大 P99 抖动」 这个上游位置，想听一线经验。