最近我把一个老项目彻底盘活了，用时两周，把服务端的卡顿（Stop-The-World）彻底压下去了。这玩意儿，不光是代码问题，更是配置问题。咱们今天就聊聊这个“GC义父杨过游戏”，也就是怎么驯服G1收集器，让它给我干活。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
起因：服务卡顿，监控一片红
话说回来，这套系统我们跑了快一年了，一直将就着用。以前流量不大，大家都不说什么。但最近跑了个大活动，用户一下子涌进来，监控面板马上就炸了。延迟曲线那叫一个刺激，峰值直接冲到五六百毫秒。运维的同事天天找我，说这不是内存泄漏就是代码写得狗屁不通。
我立马知道，不是代码的问题，是GC（垃圾回收）在作怪。咱们用的是JVM（Java虚拟机），默认的配置跑在高并发下，那就是定时炸弹。服务一到高负载，GC就开始抽风，一抽就是几百毫秒。这几百毫秒里，所有线程都停住，用户体验直接拉胯。
第一步：确定罪魁祸首。
- 我跑了GC日志分析工具，一看报告，果然！Full GC的次数不多，但Minor GC和混合GC的STW（暂停世界）时间，加起来简直就是灾难。
- 当时的配置还是沿用老掉牙的Parallel GC，这玩意儿在高并发、大内存堆下，就是个直男癌，说停就停，根本不跟你商量。
我当时就决定了，必须换掉这个老头子收集器，请出“义父”G1（Garbage First），希望它能温柔点。
驯服义父：从G1配置开始打仗
换G1不是简单的加个参数就完事了。G1虽然号称能预测停顿时间，但如果你不给它定规矩，它照样乱来。我从切换到G1开始，就像是跟一个新上任的领导磨合，天天对着参数列表骂娘。
第二步：初次尝试，问题依旧。
我上来就直接把收集器换成了G1，然后设置了最大堆内存。跑了一晚上，第二天一看，延迟确实好了点，但还是有周期性的高延迟尖刺。我们定下的目标是99%的延迟要低于50毫秒，现在还差得远。
我意识到，不能只设置堆大小，必须介入它的工作策略。
第三步：深度调教，参数轰炸。
我开始重点关注下面这几个关键参数，对着文档一个一个尝试，每次调整完，都要跑压力测试，观察结果：
- 设置停顿时间目标（-XX:MaxGCPauseMillis=20）： 我把最大停顿时间目标设定为20毫秒。G1会尽量遵守这个目标，但这只是个目标，它不保证一定能达到。
- 调整触发百分比（-XX:InitiatingHeapOccupancyPercent）： 这是G1启动混合GC的阈值。默认是45%，这意味着堆内存用到45%就可能触发回收。这对我们这种内存变化快的服务太保守了。我硬是把它提到65%，让GC晚点介入，一次回收更多垃圾，减少回收频率。
- 调整保留老年代空间（-XX:G1ReservePercent）： 这个参数默认是10%。我发现高压下内存分配经常失败，导致紧急Full GC，吓得我赶紧把这个百分比稍微抬高了一点，留点空间给新的对象，防止分配失败。
这期间，我连续三天通宵，眼睛都熬红了。最操蛋的是有一次我以为调好了，信心满满地重启服务。结果，半夜十二点，监控警报又响了。我赶紧爬起来看，发现是由于我激进地提高了触发阈值，导致老年代瞬间爆炸，直接触发了比Parallel GC还慢的Full GC。我当时想死的心都有了。
实现：稳定压制与个人感悟
经过前面那些折腾，我明白了一个道理：GC调优没有银弹，你必须了解你的业务分配模型。我们的业务特点是短命对象多，但偶尔会有一些大对象快速进入老年代。
我锁定了几个核心配置，特别是把`-XX:G1MixedGCLiveThresholdPercent`这个参数也拉高了一点，让它回收老年代的时候更积极一些，争取把那些快死的区域都干掉。
最终跑出来的结果，延迟曲线趋于平稳，99%的延迟成功压到了40毫秒以下。服务的吞吐量也明显提升了一个档次。
为啥我对这个GC调优这么执着？
我以前的公司，就是因为对这种基础配置不上心，搞得整个系统东倒西歪。当年我们项目组在搞一个实时交易模块，延迟要求比现在苛刻得多。那时候的项目经理是个外行，非要按着他的“经验”来配置JVM，把内存分代搞得一团糟。我跟他说G1才是王道，他非不信，说CMS更结果在一次大促中，整个交易系统卡死十分钟，我们被罚得差点裤衩都没了。
那次事故后，我直接提了离职。因为那帮人根本不知道怎么做技术选型和调优，只会出了事相互推诿。我一气之下，去了现在的公司。现在看到任何一个可以优化的细节，我都要亲手把它做到极致。我不能再让这种低级错误影响我的项目，这是对过去那段糟糕经历的一种交代。
咱们搞技术的，就得把这种基础工作打牢。GC这种“义父”级别的存在，你不去调教它，它就反过来调教你。这回的“杨过游戏”，我总算是通关了。
