摘要：作为后端开发，你是不是也有过这种经历：临近大促，测试环境压测一切正常，可预发布环境一模拟高并发，服务就开始频繁卡顿，甚至直接抛出 OOM 错误？上周我就踩了这个坑 —— 负责的电商商品详情页服务，在预发布压测时 JVM 频繁 Full GC，响应时间从 50m

作为后端开发，你是不是也有过这种经历：临近大促，测试环境压测一切正常，可预发布环境一模拟高并发，服务就开始频繁卡顿，甚至直接抛出 OOM 错误？上周我就踩了这个坑 —— 负责的电商商品详情页服务，在预发布压测时 JVM 频繁 Full GC，响应时间从 50ms 飙升到 800ms，差点耽误大促上线。今天就把这个真实案例拆透，再给你分享行业专家的调优建议，最后咱们一起聊聊你遇到的 JVM 问题。

先跟你还原下当时的场景：我们团队负责的商品详情页服务，是电商平台的核心链路之一，大促期间预计 QPS 会达到平时的 5 倍。压测前，我们按照常规配置设置了 JVM 参数：-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200，测试环境压到 3 倍 QPS 时，响应时间稳定在 60ms 左右，GC 日志也没异常。

可到了预发布环境，刚把 QPS 提到 2 倍平时流量，监控面板就红了 —— 首先是服务响应时间突破 300ms，接着 GC 次数开始暴涨，原本每分钟 1-2 次的 Young GC，变成了每分钟 15 次，更要命的是，Full GC 开始频繁出现，每次持续时间超过 500ms。没过 10 分钟，服务直接抛出 “java.lang.OutOfMemoryError: Metaspace”，整个商品详情页链路中断。

当时距离大促只剩 3 天，运维同事紧急重启服务暂时恢复，但只要一压测，问题就复现。我和另外两个同事围着监控屏排查，一开始以为是预发布环境资源不足，可查看服务器内存，还有 10G 空闲；又怀疑是代码有内存泄漏，用 jmap dump 内存快照分析，也没发现大对象堆积。直到我们把 GC 日志导出，用 GCEasy 工具分析后，才发现了关键问题。

其实很多时候，我们调优 JVM 只关注 - Xms、-Xmx 这些基础参数，却忽略了和业务场景匹配的细节。就像这次案例，表面看是 “内存不够用”，实际是 3 个漏洞叠加导致的，你可以对照下自己的项目有没有类似问题。

第一个坑是Metaspace 参数缺失。我们当时只设置了堆内存大小，没配置 Metaspace 的上限（-XX:MaxMetaspaceSize），默认情况下，Metaspace 会无限占用本地内存。而商品详情页服务依赖了 20 多个第三方组件，大促前我们又新增了 3 个埋点依赖，导致类加载数量激增 —— 压测时 Metaspace 从初始的 128M 涨到了 800 多 M，超出了操作系统给 JVM 分配的本地内存上限，直接触发 OOM。

这里要跟你提个细节：很多开发以为 Metaspace 在 JDK8 后用本地内存，就不用管了，但实际上如果依赖包多、动态生成类频繁（比如用了 CGLIB 代理），一定要设置 - XX:MaxMetaspaceSize，建议根据项目依赖数量配置，一般核心服务设 256M-512M 足够，我们后来把这个参数设为 384M，Metaspace 溢出问题就解决了。

第二个问题出在G1 收集器的 RegionSize 设置上。G1 默认会根据堆内存大小自动划分 Region（比如 4G 堆会分成 2048 个 2M 的 Region），但我们的商品详情页服务在高并发下，会频繁创建大量 1.5M-2M 的商品缓存对象 —— 这些对象刚好比 RegionSize 小一点，只能放入普通 Region，而不是大对象 Region（Humongous Region）。

结果就是，这些 “准大对象” 占满普通 Region 后，会频繁触发 Young GC，而且因为对象跨 Region 引用多，GC 时的根节点扫描时间变长，原本设置的 - XX:MaxGCPauseMillis=200，实际 Young GC 耗时经常达到 300ms 以上。后来我们通过 - XX:G1HeapRegionSize=4M 手动调整 Region 大小，让这些缓存对象能进入大对象 Region，Young GC 频率直接降低了 60%，耗时也稳定在 150ms 以内。

第三个漏洞是堆内存分区比例失衡。G1 默认的新生代与老年代比例是 1:2，也就是 4G 堆中，新生代只有 1.3G 左右。但我们的服务在压测时，商品缓存对象的存活时间大概是 5 分钟，而压测持续了 20 分钟，导致大量缓存对象在新生代经历多次 GC 后，还是存活下来，被晋升到老年代。

老年代内存很快从初始的 2.6G 涨到 3.5G，触发了 G1 的 Mixed GC（混合回收），可因为老年代碎片化严重，Mixed GC 回收效率低，几次回收后老年代还是满了，最终引发 Full GC。后来我们通过 - XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50，把新生代比例提高到 40%-50%，让缓存对象能在新生代多停留一段时间，减少晋升到老年代的频率，老年代溢出问题也随之解决。

解决完问题后，我特意找了阿里中间件团队的资深架构师老周聊了聊，他有 10 年 JVM 调优经验，经手过双 11、618 等大促的调优项目。他跟我分享了 3 个 “反常识” 的调优原则，特别适合咱们互联网开发，记下来能少走很多弯路。

老周说，他遇到过很多团队，上来就给服务加一堆 JVM 参数，比如 - XX:+UseConcMarkSweepGC（CMS 收集器）、-XX:SurvivorRatio=8，结果因为参数之间不兼容，反而引发性能问题。对于 90% 的业务服务，JDK8 及以上版本的默认参数已经足够用，比如默认的 G1 收集器，在中小并发场景下，比手动配置 CMS 更稳定。

他的建议是：新项目上线前，先不用加额外 JVM 参数，只设置 - Xms 和 - Xmx（两者设为相同值，避免内存波动），运行 1-2 周后，根据监控数据（GC 频率、内存占用、响应时间）判断是否需要调优。比如如果 Young GC 每分钟超过 5 次、耗时超过 200ms，再去调整新生代大小或 RegionSize，而不是上来就 “堆参数”。

很多开发会纠结 “到底用 G1 还是 ZGC”“SurvivorRatio 设 5 还是 10”，但老周说，没有最优的参数，只有最匹配业务的参数。比如我们的商品详情页服务是 “短存活大对象多” 的场景，适合调大新生代、调整 RegionSize；但如果是支付服务，属于 “长存活小对象多” 的场景，就应该调小新生代，用 CMS 收集器减少 GC 停顿。

他举了个例子：之前有个支付团队，盲目跟风用 ZGC，结果因为支付订单对象存活时间长，ZGC 的内存屏障开销反而比 G1 大，响应时间增加了 10%，后来换回 G1，再调整老年代比例，性能才恢复。所以调优前，一定要先梳理清楚业务特点：对象大小、存活时间、并发量，再针对性调整参数。

老周反复强调，JVM 调优不是一次性工作，而是持续监控 + 动态调整的过程。他建议我们在服务上线后，一定要盯紧 3 个关键指标，一旦超标就及时干预：

他还推荐了几个实用工具：用 Prometheus+Grafana 监控 GC 指标，用 Arthas 实时查看内存占用，用 GCEasy 分析 GC 日志，这些工具能帮我们快速定位问题，不用再像以前那样 “瞎猜参数”。

讲完我的案例和专家建议，想跟你聊聊：你在项目中遇到过哪些 JVM 问题？是内存泄漏、GC 频繁，还是 OOM？当时是怎么解决的？有没有踩过 “参数越调性能越差” 的坑？

比如我之前有个同事，为了减少 GC 次数，把 - Xmx 设到 16G，结果因为堆内存太大，Full GC 一次要 5 秒，反而导致服务超时。欢迎在评论区分享你的经历，咱们一起交流调优技巧，下次遇到 JVM 问题，就能少走弯路～

来源：从程序员到架构师