Mixed GC停顿预测精度高在高频交易中是错觉，因其基于稳定假设而无法应对脉冲式对象创建与晋升，导致预测失焦、GC频次激增、CPU被挤压、吞吐量断崖下跌。
Mixed GC 的停顿预测精度对吞吐量没有正向贡献，反而在高频交易系统中是吞吐量的隐性杀手。
为什么“预测精度高”在金融交易场景里反而是错觉
G1 的停顿预测模型本质是基于历史数据的滑动平均估算，它假设对象晋升速率、Region 扫描速度、复制开销都相对稳定。但高频交易系统每毫秒都在变：盘口更新触发批量对象创建，撮合引擎突发晋升，订单状态机瞬间生成大量短生命周期对象。这些脉冲会让 G1EvacuationPause 的实际耗时剧烈抖动，而日志里仍显示 predicted: 87ms —— 预测值没崩，只是完全失焦。
常见错误现象包括：
- GC 日志频繁出现
GC pause time is 216.4ms (target: 100ms)，但业务 P99 延迟已突破 15ms 阈值 - 同一笔订单处理链路中，两次相邻
Young GC间隔仅 4ms，中间夹着一次未被预警的Mixed GC - 压测时 QPS 上不去，
jstat -gc显示YGCT和FGCT都不高，但MGCT（Mixed GC 次数）异常高
停顿预测误差如何直接吃掉吞吐量
预测不准 → G1 误判可回收 Region 数量 → 实际停顿超时 → JVM 被迫加速下一轮回收 → GC 频率被动抬升 → 应用线程 CPU 时间被持续挤压。这不是理论推演，是实测可复现的链式衰减：
- 当
-XX:MaxGCPauseMillis=20时，某做市系统实测MGCT从 12 次/分钟飙升至 89 次/分钟 - 单次
Mixed GC平均占用 2.3 个 CPU 核，高频触发后，可用核数等效下降 15%～20% - Survivor 区因频繁 Young GC 来不及“养熟”对象，晋升率上升 40%，老年代压力前移，进一步刺激 Mixed GC
- 吞吐量下降不是线性的：QPS 从 18k 跌到 12.5k（-30.6%），但 P99 延迟从 8ms 拉长到 47ms（+487%）
别调 MaxGCPauseMillis，先看并发标记阶段是否卡住
Mixed GC 不是随时能发的，它必须等并发标记周期（Initial Mark → Remark → Cleanup）完成。而这个周期在 6GB 堆 + JDK 17 下平均耗时 90～130ms，期间所有 Old Region 回收请求都被冻结。这意味着：
- 业务流量在标记阶段积压，Cleanup 一结束，G1 就会集中释放压力，触发一波高密度
Mixed GC - 你看到的“高频轻量 GC”，其实是标记延迟导致的补偿式爆发，并非模型预测灵敏
-
-XX:ConcGCThreads设太低（如默认值）会让标记更慢；设太高又抢应用线程，需按Runtime.getRuntime().availableProcessors()动态配比 - 真正该盯的指标不是
MaxGCPauseMillis，而是G1ConcurrentMark阶段的耗时分布和失败次数（Concurrent Cycle Aborted）
验证预测是否真影响吞吐，只看三组数字是否同步恶化
不要信参数，要信压测曲线。每次变更后，必须并行观测：
-
G1EvacuationPause的 P99 停顿时间是否上移（用grep "G1 Evacuation Pause" gc.log | awk '{print $NF}'抽取） -
MGCT（Mixed GC 次数）是否显著增加（jstat -gc <pid> 1000 10看趋势） - 应用层 QPS 是否同步下跌，且跌幅 > 停顿时间增幅的 2 倍（例如停顿 +12%，QPS -35% 就已危险）
真正难的不是算出预测误差有多大，而是当 Mixed GC 在订单进入撮合前 2ms 开始，你没有任何手段让它等等——G1 没有暂停接口，也没有业务感知钩子。这点在 SLA 要求 ≤15ms 的系统里，比调参重要十倍。
