Java 服务 P99 抖动：先调 GC 参数「止疼」，还是先砍堆占用「治根」？——你们线上到底按哪个顺序排

【背景】 做性能优化 3 年，复盘 P99 抖动时几乎每次都会撞上同一个分岔口：

• 某电商搜索网关（JDK 17 + G1，4C8G，堆 4G），大促前 P99 从 180ms 抖到 420ms。on-call 同学第一反应是"加个 -XX:MaxGCPauseMillis=5，再调一下 -XX:G1NewSizePercent / -XX:G1MaxNewSizePercent"，当晚就上线了，P99 回到 210ms，复盘会开完就散。
• 同一团队另一个同事，把同一段代码的 ArrayList 改成 ArrayDeque + 复用 buffer，把一次请求里 3 个临时 HashMap 改成 ThreadLocal 缓存，堆占用从 4.2G 降到 2.8G，GC 频率从 14 次/分降到 4 次/分——同样的 4C8G，P99 稳在 160ms，而且没动任何 JVM 参数。

两种做法都能"赢"。但 3 个月后再看：调参那台机器的 P99 又开始抖（堆又涨回 4G+），改代码那台一直稳。

【常见分歧 / 几种做法】

1. 先调参：GC 参数是"快变量"，改一个配置 5 分钟生效，业务不感知；砍堆占用是"慢变量"，要改代码、要回归、要上线，周期以周计。
2. 先砍堆：参数只是把"垃圾回收的压力"从堆里挪走，不解决"垃圾产生速率"；堆占用是根因，参数是表象。
3. 两条腿一起走：先调参止血，同时排期砍堆；但谁来排期、谁先上，团队里经常吵。
4. 加机器：堆不够就升配，升配比改代码还快，成本还能被 CFO 接受——这是最容易被忽略的"第四选项"。

【我的倾向与理由】 我倾向"先砍堆、后调参、加机器是兜底"。理由很朴素：

• GC 参数是对当前堆占用做最优解，堆占用一变，最优解就变了。调参是在一个移动的目标上做静态优化，必然要反复调。
• 砍堆是改变目标本身，一次改动长期受益。我见过 3 个团队把堆占用降 30% 后，G1 参数从"精心调过的"退回"默认值"反而更稳——因为默认参数本来就是给"合理堆占用"调的。
• 但我也承认：大促窗口只有 1 周时，先调参是对的。"先砍堆"是长期策略，"先调参"是应急策略，两者不冲突，冲突的是团队没有这个共识。

一个可复现的小判断（我自己的经验值，欢迎拍砖）：

• 如果 P99 抖动周期 < GC 周期（比如抖动 500ms、GC 一次 800ms），大概率不是 GC 的锅，先查锁/IO/下游；
• 如果 P99 抖动周期 ≈ GC 周期，先看堆占用趋势——如果堆占用在 7 天内涨了 >20%，先砍堆；如果堆占用稳定但 P99 抖，才是调参的时机。

【想听大家在什么场景下怎么选】

1. 你们团队有没有"先调参还是先砍堆"的明文共识？还是每次 on-call 临时拍？
2. 有没有"砍堆"做到一半发现某个业务逻辑必须占用大堆（比如内存映射文件、大对象缓存）的场景？这时候你们怎么决策？
3. "加机器"这个兜底选项，在你们团队里是默认选项还是被禁止选项？我见过两个极端：一个团队"先加机器再说"，另一个团队"加机器 = 技术债 +1"，你们站哪边？
4. 你们有没有量化过"一次 P99 抖动事故的 MTTR 里，调参 vs 砍堆各占多少比例"？如果砍堆的 ROI 更高，为什么团队还是倾向于调参？

抛砖引玉，期待看到不同业务规模、不同技术栈（JDK 8/11/17/21、G1/ZGC/Shenandoah）下的真实选择。