默认GC在生产环境大概率不合适，因其未适配真实负载如堆外内存压力、GC停顿敏感度等；RPC网关或实时计费系统中一次2秒Full GC即可引发下游熔断。
为什么默认GC在生产环境大概率不合适
Java进程跑在服务器上，不是本地IDE里跑个HelloWorld。默认的UseParallelGC或JDK 11+的UseZGC（取决于版本）根本没考虑你的真实负载：堆外内存压力、GC停顿敏感度、对象晋升速率、老年代碎片化倾向。尤其当你的服务是RPC网关或实时计费系统时，一次Full GC卡住2秒，下游就超时熔断了。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先用
jstat -gc <pid>持续采样10分钟，重点看YGCT（年轻代GC耗时总和）、FGCT（Full GC次数）和OU（老年代已使用量趋势） - 如果
OU缓慢但持续上涨，说明对象在年轻代没被回收就晋升了，不是堆小，而是MaxTenuringThreshold或SurvivorRatio配得不合理 - 避免直接套用“大厂同款参数”，阿里用
G1GC是因为他们单机堆常设32G+，而你8G堆还硬上G1，反而触发更多混合GC
G1GC关键参数怎么调才不翻车
G1GC是目前生产环境最平衡的选择，但它不是开箱即用。核心矛盾在于：你想降低停顿（MaxGCPauseMillis），但JVM会为此频繁触发GC，导致吞吐下降；你想提高吞吐（加大InitiatingHeapOccupancyPercent），又可能引发长时间Full GC。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
-XX:MaxGCPauseMillis=200是安全起点，别设50ms——G1做不到，只会让GC更频繁 -
-XX:InitiatingHeapOccupancyPercent=45比默认45%更稳妥；若观察到并发标记总在老年代快满时才启动，可降到35，但需同步加大-XX:G1HeapRegionSize（如4M）减少region数量 - 禁用
-XX:+UseStringDeduplication除非你确认应用大量重复字符串且CPU富余——它会显著增加GC线程CPU占用 - 务必加
-XX:+PrintGCDetails -Xloggc:/path/to/gc.log，否则调参等于蒙眼开车
年轻代大小到底该不该固定
很多人迷信-Xmn固定年轻代，觉得“可控”。但G1下-Xmn会被忽略，而ParallelGC或CMS里硬设反而容易出问题：比如你设-Xmn2g，但实际每秒新对象才100MB，结果年轻代长期空转，老年代却因晋升过早而提前碎片化。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用G1时，完全放弃
-Xmn，靠-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent动态控制（推荐15–30%） - 用ParallelGC时，若堆≤4G，可设
-Xmn1g；若堆≥8G且对象生命周期短，改用-XX:NewRatio=2（年轻代:老年代=1:2）更稳 - 监控中发现
YGC间隔忽长忽短，大概率是年轻代大小与分配速率不匹配，此时看jstat输出的EU（Eden区使用量）峰值是否长期接近EC（Eden区容量）
哪些GC日志字段必须盯死
GC日志不是用来存档的，是故障前最后的预警信号。很多人只扫一眼有没有Full GC，漏掉真正危险的征兆。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 重点关注
[GC pause (G1 Evacuation Pause) (young)里的evacuation failed——这表示G1复制失败，马上会退化成Full GC - 看到
[GC concurrent-root-region-scan-end耗时超过500ms，说明根扫描阶段受应用线程干扰严重，需检查是否有大量JNI调用或synchronized块阻塞 -
[GC cleanup 123M->123M(1024M)这种“清理前后一样”说明老年代已彻底碎片化，G1无法找到连续空间分配大对象，此时-XX:G1HeapWastePercent再高也救不了，只能扩容或切ZGC
调参这事没有银弹。最常被忽略的是：GC行为会随业务流量形态突变。凌晨低峰期跑得稳，不代表大促时扛得住。上线后头三天，必须每小时拉一次jstat快照，比对OU曲线斜率变化——这才是真正在用参数对齐业务。
