摘要：# JVM调优：别等服务器挂了才想起这回事 我前两天刚处理完一个线上事故，凌晨三点被电话吵醒，一看监控——Full GC停不下来，服务响应时间直接飙到十几秒。折腾了半宿，最后发现就是个新生代大小配错了。这种场景你应该不陌生吧？很多团队都是这样，平时没人管…

JVM调优：别等服务器挂了才想起这回事

我前两天刚处理完一个线上事故，凌晨三点被电话吵醒，一看监控——Full GC停不下来，服务响应时间直接飙到十几秒。折腾了半宿，最后发现就是个新生代大小配错了。这种场景你应该不陌生吧？很多团队都是这样，平时没人管JVM，一出问题就抓瞎。

说真的，JVM调优这事儿，很多所谓的“最佳实践”在PPT里看着很猛，真到了生产环境，可能完全不是那么回事。今天我就跟你聊聊，在实际生产环境里，那些真正有用的经验。

先搞清楚你的应用是什么“脾气”

很多人在调优时犯的第一个错误，就是上来就抄参数。什么-Xmx、-XX:NewRatio一通乱配，结果效果还不如默认。

你得先知道你的应用在干什么。

我见过一个电商系统，技术团队照着某个大厂的配置模板，把新生代设得特别大。结果呢？每次大促，年轻代GC倒是少了，但老年代对象堆积如山，Full GC频繁得让人头皮发麻。

后来我们仔细分析了它的对象生命周期——发现大部分订单相关对象，其实在几分钟内就死了，根本没必要进老年代。调整了新生代比例和晋升年龄阈值后，GC停顿时间直接降了70%。

所以第一步永远是：用工具看数据。

• jstat -gcutil 看各区域使用率
• jmap -histo 看对象分布
• GC日志一定要开，而且要仔细分析

（这里插一句，有些团队开了GC日志但从来不看，那还不如不开，至少省点磁盘空间。）

参数不是越多越好，关键参数就那么几个

现在网上各种JVM参数调优文章，动辄几十个参数列出来，看着就头疼。其实在实际生产环境里，真正需要关注的参数，一只手就数得过来。

1. 堆大小设置：别太“抠门”，也别太“大方”

• -Xms和-Xmx必须设成一样大。这个我说过很多次了，但还是有团队不听。动态扩容缩容带来的内存碎片和GC停顿，在压力大的时候就是定时炸弹。
• 堆大小怎么定？看你的应用常驻内存是多少。一般建议是常驻内存的1.5-2倍，给GC留点缓冲空间。但如果你内存本来就紧张，那就得精打细算了。

2. 年轻代：别让对象“早熟”

• -XX:NewRatio控制新生代和老年代比例。如果你的应用像我刚才说的电商系统那样，大部分对象短命，那就把新生代设大点，3:1甚至2:1都行。
• -XX:MaxTenuringThreshold这个晋升阈值，默认15，但很多场景下调到5-8效果更好。让那些熬过几次GC还活着的对象早点去老年代，别在年轻代占着地方。

3. GC选择：没有最好，只有最合适

• CMS？G1？ZGC？Shenandoah？
• 说实话，现在新项目我一般都推荐G1。它没那么完美，但胜在平衡——自动分代、可预测停顿、调优相对简单。特别是对于堆内存大于4G的应用，G1的表现通常比CMS稳定。
• 但如果你用的是老系统，堆也不大（比如4G以内），ParNew+CMS可能还是更稳妥的选择。

（我知道有人要提ZGC了，确实牛，亚毫秒级停顿。但你要考虑你的应用真的需要吗？还有JDK版本、兼容性这些现实问题。）

监控比调优更重要——真的

这是我这些年最深的体会：一套好的监控体系，比任何调优技巧都值钱。

我们团队现在每个应用都标配：

1. GC日志实时分析：不是等出问题了才去看，而是实时监控GC频率、停顿时间。设置个告警，比如10分钟内发生3次Full GC，马上通知。
2. 堆内存趋势图：看老年代使用率是不是在缓慢增长——这可能意味着内存泄漏。
3. 线程堆栈定期采样：特别是CPU飙高的时候，看看是不是死锁或者某个方法卡住了。

上个月我们就靠监控提前发现了一个问题：某个服务的堆内存使用率，每天固定时间会有一个小高峰。一排查，原来是个定时任务在处理大数据量时，创建了大量临时对象。调整了处理逻辑，问题就解决了。

很多问题，你看到了，就解决了一半。

那些容易踩的坑

坑1：盲目追求“零Full GC” 有些团队把“零Full GC”当KPI，这其实挺危险的。Full GC本身不是问题，问题是频繁的、长时间的Full GC。适当的Full GC能整理内存碎片，反而是好事。

坑2：过度优化 我见过最夸张的，一个简单的Web应用，JVM参数配了三十多行。结果性能提升微乎其微，维护成本却高了不少。调优要遵循边际效应递减规律——前几个关键参数调整能解决80%的问题，后面的精细调整可能只提升5%，但复杂度却翻倍。

坑3：忽视操作系统限制 特别是容器化环境。你在Docker里设了-Xmx4g，但容器内存限制只有2g，结果就是被OOM Killer干掉。还有线程数限制、文件描述符限制……这些底层的东西，往往比JVM参数本身更重要。

实战中的“土办法”

有时候，标准方法解决不了问题，就得用点“土办法”。

比如我们遇到过一种情况：应用在每天凌晨流量低峰时，总会发生一次长时间的Full GC。分析后发现，是因为有个缓存组件在凌晨刷新，一下子加载了大量数据到堆里。

常规思路是调整缓存策略或者堆大小，但当时业务方不想改代码。怎么办？

我们搞了个“歪招”：写了个脚本，在每天缓存刷新前5分钟，主动调用System.gc()（配合-XX:+ExplicitGCInvokesConcurrent参数）。虽然不优雅，但确实解决了问题——主动在可控时间触发GC，比被动在业务高峰时GC强多了。

（当然，这只是权宜之计，后来还是重构了缓存方案。）

最后说几句大实话

JVM调优这活儿，三分靠技术，七分靠经验。你光看书、看文章没用，得真刀真枪地在生产环境折腾过几次，才能有感觉。

而且很多时候，JVM层面的优化已经到天花板了，真正的瓶颈可能在别处——数据库连接池配置不合理、缓存用错了、甚至是业务逻辑本身有问题。我见过最离谱的，团队花了两周调优JVM，最后发现是Nginx的超时时间设短了。

所以，如果你的应用现在跑得还行，别急着折腾JVM参数。先把监控做好，把日志分析流程建立起来。等真有问题的时候，你知道该怎么看、怎么分析，这就已经赢过很多人了。

行了，不废话了，该部署的部署去吧。记得，调优不是一劳永逸的事——业务在变，流量在变，你的JVM配置也得跟着变。保持观察，保持调整，这才是正道。