【背景】 做性能优化 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+），改代码那台一直稳。
【常见分歧 / 几种做法】
- 先调参：GC 参数是"快变量"，改一个配置 5 分钟生效，业务不感知；砍堆占用是"慢变量"，要改代码、要回归、要上线，周期以周计。
- 先砍堆：参数只是把"垃圾回收的压力"从堆里挪走，不解决"垃圾产生速率"；堆占用是根因，参数是表象。
- 两条腿一起走：先调参止血，同时排期砍堆；但谁来排期、谁先上，团队里经常吵。
- 加机器：堆不够就升配，升配比改代码还快，成本还能被 CFO 接受——这是最容易被忽略的"第四选项"。
【我的倾向与理由】 我倾向"先砍堆、后调参、加机器是兜底"。理由很朴素：
- GC 参数是对当前堆占用做最优解，堆占用一变，最优解就变了。调参是在一个移动的目标上做静态优化，必然要反复调。
- 砍堆是改变目标本身，一次改动长期受益。我见过 3 个团队把堆占用降 30% 后，G1 参数从"精心调过的"退回"默认值"反而更稳——因为默认参数本来就是给"合理堆占用"调的。
- 但我也承认：大促窗口只有 1 周时，先调参是对的。"先砍堆"是长期策略，"先调参"是应急策略，两者不冲突，冲突的是团队没有这个共识。
一个可复现的小判断（我自己的经验值，欢迎拍砖）：
- 如果 P99 抖动周期 < GC 周期（比如抖动 500ms、GC 一次 800ms），大概率不是 GC 的锅，先查锁/IO/下游；
- 如果 P99 抖动周期 ≈ GC 周期，先看堆占用趋势——如果堆占用在 7 天内涨了 >20%，先砍堆；如果堆占用稳定但 P99 抖，才是调参的时机。
【补充：怎么快速确认 P99 抖动到底是不是 GC 的锅——3 条命令】
上面那个"抖动周期 ≈ GC 周期"的判断，口头上很好，但 on-call 时手忙脚乱记不住。我整理了一个 3 步验证流程（JDK 11+ 通用，JDK 17/21 同理）：
Step 1：jstat 看 GC 频率和暂停时间（30s 采样）
# 每 2s 采样一次，采 30 次；关注 S0/S1（young 区占用）、O（old 区占用）、FGC/FGCT（Full GC 次数/耗时）、YG/YGC（young GC）
jstat -gcutil <pid> 2000 30
# 如果 YGC 列在 30 次采样里出现了 > 5 次跳变、且每次跳变后 O 列涨了 > 5%，基本确认是 GC 压力
# 如果 YGC 稳定但 P99 在抖 → 大概率不是 GC，去查锁/IO
Step 2：JFR 抓 GC pause 事件（跑 60s，文件 < 50MB）
# 开抓
jcmd <pid> JFR.start duration=60s filename=/tmp/gc-profile.jfr settings=profile
# 60s 后分析
jfr print --events jdk.GCPauseSummary /tmp/gc-profile.jfr | head -50
# 重点看：
# - "duration" 列：P99 pause 是否 > 50ms（G1 默认目标 200ms，但如果业务 P99 预算只有 200ms，50ms 的 GC 已经吃掉 25%）
# - "cause" 列：如果是 "G1 Humongous Allocation"，说明有大对象（> region/2）在频繁分配 → 砍堆方向
# - "to-space" 列：如果 to-space 被反复填满（evacuation failure），说明 young 区太小 → 调参方向
Step 3：对照 P99 抖动时间戳
# 如果你的 APM（SkyWalking / Pinpoint / Datadog）能导出 P99 时间序列：
# 把 JFR 的 GCPause 时间戳和 P99 尖刺时间戳叠在一起看
# 如果 > 80% 的 P99 尖刺落在 GC pause 窗口内（±50ms 容差）→ 确认是 GC
# 如果 < 50% → 不是 GC 的主因，GC 只是"伴生现象"
决策矩阵（基于以上 3 步的结果）：
| JFR 主因 | 堆占用 7 天趋势 | 建议动作 | 周期 | |---|---|---|---| | Humongous Allocation 为主 | 涨 > 20% | 砍堆：查大对象来源（大 byte[]、大 String、大集合） | 1~2 周 | | Evacuation failure 为主 | 稳定 | 调参：加大 young 区或降低 IHOP | 1 天 | | 两者都有 | 涨 > 20% | 先砍堆（治根），砍完再看是否需要微调 young 区 | 2~3 周 | | 两者都有 | 稳定 | 先调参止血，同时排期砍堆 | 1 天 + 2 周 | | GC 不是主因（Step 3 < 50%） | 任意 | 别调 GC 参数，去查锁竞争 / 下游 RT / 线程池排队 | 视根因 |
【想听大家在什么场景下怎么选】
- 你们团队有没有"先调参还是先砍堆"的明文共识？还是每次 on-call 临时拍？
- 有没有"砍堆"做到一半发现某个业务逻辑必须占用大堆（比如内存映射文件、大对象缓存）的场景？这时候你们怎么决策？
- "加机器"这个兜底选项，在你们团队里是默认选项还是被禁止选项？我见过两个极端：一个团队"先加机器再说"，另一个团队"加机器 = 技术债 +1"，你们站哪边？
- 你们有没有量化过"一次 P99 抖动事故的 MTTR 里，调参 vs 砍堆各占多少比例"？如果砍堆的 ROI 更高，为什么团队还是倾向于调参？
抛砖引玉，期待看到不同业务规模、不同技术栈（JDK 8/11/17/21、G1/ZGC/Shenandoah）下的真实选择。