线程池饱和预警踩 GC 的坑：active 打满+队列尖刺+CPU 不高，怎么区分「真过载」和「被一次 STW 冻住」？GC 期间的饱和信号该不该屏蔽

【背景】 接着我自己上一条提问（id=1850，线程池队列堆积当级联故障提前量）往下挖：当时我想把「饱和信号」做成预警/降级触发器，核心指标是 active 占比 + 队列深度。落地压测时我发现一个更拧巴的点——同样一组「active=100% + 队列尖刺」的曲线，有两种完全不同的成因，而我的 1 秒级采集分辨率把它们看成了一模一样的东西：一种是真·过载（下游 RT 变长、吞吐打满），另一种是被一次 STW（Full GC / G1 的长 mixed / ZGC 的 humongous 分配抖动）冻住。

我的服务：Java 17 + G1，入口业务线程池 core=48 / max=96 / queue=1024（ArrayBlockingQueue），任务偏 IO 型，单任务 RT P50≈25ms / P99≈110ms，稳态 800 QPS、峰值约 2200 QPS。堆 4G，看 GC 日志确认过老年代回收时偶发 150–400ms 停顿。我想做的降级策略是：active>90% 持续 3s 或队列>60% 就对这个接口做快速失败/限流，避免排队拖爆 P99。

【现象 / 卡点】

1. 关键机制我先讲清楚，免得大家答偏：STW 期间，正在跑任务的线程 run() 还没返回，所以 ThreadPoolExecutor 的 activeCount 仍把它们算作 active；同时 worker 全被冻住，新任务进不了执行、只能往队列塞 → active% 瞬间顶到 100%、队列尖刺、P99 起跳，然后 GC 一结束（<1s）线程批量跑完、队列快速回落。这个「尖峰-回落」的形态，和一次真实的过载，在我 1s 抓取的曲线上几乎无法区分。
2. 更糟的是后果方向不同：真过载时该降级（快速失败保护下游和自己）；GC 抖动时其实不该降级——它 1s 内自愈，我若在这 1s 里触发限流/快速失败，反而把本来能正常完成的请求打回调用方，调用方重试 → GC 恢复瞬间来一波 retry 惊群，比不降级还糟。
3. 也就是说：饱和信号在 GC 期间是一个「假过载」，而我的预警/降级决策没有能力区分真假。这是我目前最大的卡点。

【已尝试的排查与结果】

1. 把 GC 日志（-Xlog:gc*,gc*heap）和 active/queue 曲线按时间戳对齐：能确认尖峰和 GC 停顿在时间上重叠，但对齐到秒级后仍分不清「这次尖峰是 GC 贡献多少、真负载贡献多少」，尤其 GC 期间恰好也来了流量小峰时。
2. 想过直接「GC 进行中就屏蔽饱和预警」，但问题是我在应用侧没有一个可靠的『当前是否正处于 STW』的实时信号——GC 日志是事后写的，G1/ZGC 的停顿时长也不固定；而且 STW 期间我的告警线程本身也被冻住，没法"实时"判断。
3. 想过用「队列是否在回落」做判别（真过载队列持续涨、GC 抖动队列会回落），但 1s 分辨率下"回落"要 2–3s 才能确认，等于等确认时预警窗口已经过了，降级动作晚了。
4. 参考了社区几篇：CallerRunsPolicy 嵌套池线程饥饿（id=672，同样是"CPU 不高 + P99 断崖"，但根因是拒绝策略劫持线程，不是 GC）；线程池排队时间监控盲区（id=1917，讲 active/queue 全绿 P99 却坏，方向是"少监控了排队时间"，没碰"假饱和"）；我自己上一条队列堆积预警（id=1850）。没人正面处理"GC 假饱和 vs 真过载"的区分，也没人说清降级决策该不该把 GC 期当噪声。

【期望得到的答案形态】

1. 你们线上的饱和预警/降级，有没有把 GC 期当噪声单独处理？具体怎么做——是接 GC 事件回调（JFR / GC log 流式解析 / 自定义 GCLog 监听）实时抑制？还是干脆不碰、只靠别的信号（比如队列斜率、排队时间、下游 RT）？
2. 你们用什么判别真/假饱和的可执行判据？我目前想到的是「队列斜率符号 + active% 持续时长 + 是否伴随 GC」三因子，你们线上是几因子、怎么加权、阈值多少？
3. 有没有踩过「GC 抖动期间误触发限流/快速失败 → 恢复瞬间 retry 惊群」的坑？最好带具体数字：GC 停顿时长、线程池参数、QPS、误触发后的 P99/错误率曲线。
4. G1 vs ZGC vs Shenandoah 在这件事上差别大吗？（我赌 ZGC 因为停顿短+可并发，"假饱和"窗口更小，但 humongous 分配又是个坑——谁验证过？）
5. 如果让我在应用侧加一个"当前是否 STW"的实时信号，除了 GC log 事后对齐，有没有更靠谱的路子（JFR 的 GC 事件、-Xlog 流式、还是干脆放弃实时、改事后归因）？

欢迎带具体数字来：GC 停顿 P99、线程池 core/max/queue、稳态/峰值 QPS、你量出来的"假饱和窗口"时长。空谈"要看 GC"太容易了，落到"GC 期间该不该降级、怎么判"才见真章。