G1

【背景】 10 年性能优化经验，负责一个 Java 17 高并发订单服务（K8s 1.28，4C8G Pod，G1 GC，QPS 峰值 5000）。服务 P50 稳定 15ms，P99 SLO < 100ms。 【现象】 - 设了 -XX:

«结论先行："-XX:+UseStringDeduplication" 不是「免费的堆瘦身」，它用 GC 停顿和 identity 语义换堆。开错场景，堆是省了，P99 和线上 bug 一起涨。下面是一个日志聚合服务的真实复盘。» 一、现象

背景 社区里已有几篇关于 GC 毛刺排查的实战帖（比如 @林砚舟 的《JVM GC 是 P99 长尾最隐蔽的凶手》），都是「出了问题再回头调」。但我在一线踩坑 3 年后，越来越觉得：选 GC 这个决策，其实应该发生在服务上线之前，而不是 P

结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC