1. 全链路调优的整体思路：先问自己四个“为什么”
接手这个调优任务之前，我一直有一个观点：JVM 调优最容易翻车的地方，不是参数写错，而是“不知道为什么调”。很多同学喜欢在网上找一套所谓的高并发配置，直接贴到启动脚本里，然后看着 GC 日志数字还行就觉得万事大吉。这种做法在低流量下也许看不出问题，但一旦流量冲到亿级，哪怕一个参数偏离实际场景，代价都是整条链路抖三抖。
这次接到的是一个典型的高并发交易链路优化任务，目标很明确：在压测环境复现双倍峰值流量，定位 JVM 层面的瓶颈，再通过参数调整和代码侧改造，让系统在持续高压下保持稳定。项目代号就叫“某跨平台交易系统”，技术栈以 Java 11 为主，容器化部署，接入层是自研网关，中间件涉及消息队列和内存数据库。整条链路上最脆弱的环节，恰恰不是 MySQL，也不是缓存，而是应用实例本身的堆内存管理。
在动任何参数之前，我强迫团队先回答四个问题：
第一，当前系统的瓶颈到底是不是 JVM？很多系统一压测就报超时，第一反应是调堆内存，但实际用排查工具一看，往往是锁竞争或连接池打满。第二，如果确实是 JVM 问题，具体是哪一块？是年轻代晋升过于频繁，还是老年代空间不足导致 Full GC？第三，目标吞吐量和响应时间能接受多少 GC 开销？这个标准不定义清楚，后面参数推导就没有依据。第四，线上有没有完整的监控和回滚手段？如果没有，再好看的参数也不敢落到生产环境。
这四个问题问完，项目的推进路径就清晰了。我们采用“先量化现状，再逐项优化，最后验证稳态”的方式，走了差不多三周，整个调优过程有数据支撑，而不是靠玄学拍脑袋。这一步是整个项目最关键的地基，后面的每一组参数、每一次压测，都锚定在这四个答案上。
2. 压测瓶颈定位：用火焰图和 GC 日志把“病灶”找出来
2.1 压测环境搭建的隐性坑
压测环境看起来简单，但里面的门道比大多数人想象的多。第一原则是“环境对齐”，我们专门用了一个独立的压测集群，CPU、内存、JDK 版本、容器配额必须和生产完全一致。这里特别要提醒一句：容器配额不一致的压测结果毫无参考价值，比如生产限制 4 核，压测机用 8 核跑出来的数据，直接会误导容量预估。
我们用的是某开源压测平台，从网关入口发起流量，压测机打标后经过完整链路到达应用实例。整个过程刻意绕过本地缓存，让流量真实打到下游服务，因为调优的核心目标是整条链路的 JVM 表现，而不是单点最优。流量模型也做了两档：一档是平峰模型，模拟日常 60% 负载；一档是峰值模型，模拟大促开场时瞬间拉高的流量尖峰。两种模型交替跑，方便观察 GC 行为在不同压力下的变化曲线。
2.2 火焰图采样：别让工具骗了你
定位 CPU 瓶颈，我用的是异步采样火焰图。很多新手喜欢直接抓线程 dump 看栈，但线程 dump 是瞬时快照，在峰值压力下容易漏掉真正热点。异步采样的优势在于能聚合一段时间的调用栈，把低频次但高频消耗的方法暴露出来。
实操上有个非常容易踩的坑：采样时间太短。我见过有人只采 30 秒就下结论，结果火焰图里最宽的栈是日志刷盘——这根本不是真实热点，只是采样期间恰好有一段日志突发。我的经验是至少采样 3-5 分钟，且要在压测稳定段而不是刚启动时采样，因为 JIT 编译尚未完全生效时，热点分布会严重失真。另外，采样一定要开 debug 级别，否则像内联后的方法栈会被折叠，关键信息直接丢失。
2.3 GC 日志解读：找到“吞吐量”和“延迟”的真实关系
GC 日志是 JVM 调优的核心数据源。我们统一通过-Xlog:gc*:file=/data/logs/gc.log:time,uptime,level:filecount=10,filesize=50m把 GC 日志落盘，这样既保留了历史轮转，又不会把磁盘撑爆。手动加上了-XX:+HeapDumpOnOutOfMemoryError，防止万一内存溢出时连现场都没有。
拿到第一轮压测的 GC 日志后，我们发现有两个刺眼的数字：年轻代 GC 平均耗时 80ms，但 P99 耗时到了 380ms；老年代 GC 次数不算多，但每次耗时都在 1.5 秒以上。吞吐率算下来只有 91%，也就是说有接近 9% 的 CPU 时间花在 GC 上，这对亿级流量系统来说是不可接受的。
为什么会出现这么大的毛刺？看 GC 日志细节，发现年轻代 Eden 区频繁被打满，存活对象快速晋升到老年代，导致老年代空间迅速膨胀，最后触发 Concurrent Mode Failure，也就是并发标记还没结束，老年代就撑不住要 Full GC。根因不是参数问题，而是对象分配速率太高，把堆内存的节奏彻底打乱了。
这一步我们做了个关键决策：先不调参数，先改代码。
3. 核心参数推导与线上稳态配置：每个数字都有来路
3.1 堆内存规划：为什么 16-32GB 是一个“危险区间”
关于堆内存的大小，我的建议可能跟一些人的直觉相反：不要盲目给大堆。很多团队一上来就是-Xmx32g，生怕内存不够用，结果反而踩进了“大堆陷阱”。
大堆在小流量下没问题，但一旦触发 Full GC，停顿时间会呈指数级上升。32GB 堆做一次 Full GC，停个 5-8 秒是常态。对实时性要求高的交易链路来说，这种停顿就是事故。另外，超过 32GB 意味着对象指针压缩失效，内存占用会额外增加 10%-20%，说实话性价比很低。
我们这次系统核心实例堆内存设置在 16GB，G1 收集器，目标是单实例吞吐量破 3000 TPS。选择 16GB 而不是 24GB 或 32GB，有明确的计算依据。G1 的 Region 大小默认为堆内存的 1/2048，16GB 堆对应 8MB 的 Region，这个尺寸在混合回收时表现稳定。如果堆太大会导致 Region 数量过多，RSet 维护开销随之飙升，最终反而拉低吞吐。
3.2 收集器选型与核心参数推导
收集器选型没有悬念，Java 11 的容器环境，G1 是唯一合理的选择。但 G1 参数之间相互关联，不能孤立地调某一个值。
第一个核心参数是-XX:MaxGCPauseMillis，我们设的是 100ms。这个数字不是拍脑袋定的，它来源于业务侧的响应时间指标：接口整体 P99 要求 300ms 以内，JVM 层 GC 停顿预算最多只能占 1/3。这个推导关系非常重要——所有技术参数的出发点都必须是业务容忍度，而不是“网上都说这么设”。
第二个是-XX:NewRatio或通过-XX:G1NewSizePercent控制年轻代占比。G1 下年轻代初始占比我们设为 5%，最大占比 20%。这里要解释一下：G1 的年轻代大小是动态调整的，它会根据并发标记结果自动决定是否扩容年轻代来延迟晋升。如果你固定了一个很大的年轻代，表面上 Young GC 次数少了，实际上对象晋升速率没变，老年代空间被快速蚕食，直到触发并发回收。我们试过固定 40% 年轻代占比，结果是压测 2 小时后老年代占用率飙到 89%，差点触发 Full GC。
第三个是-XX:G1HeapRegionSize，我们明确指定 8MB。默认情况下 G1 会自动计算 Region 大小，但自动计算的结果不一定合适。当大量中大对象（几百 KB 到几 MB）频繁分配时，默认 Region 尺寸会导致对象跨 Region 存储，RSet 关联复杂度飙升。手动固定为 8MB 后，大对象分配路径更规律，混合回收的效率明显提升。
第四个容易被忽略的是-XX:ConcGCThreads和-XX:ParallelGCThreads。我们容器配额 4 核，ParallelGCThreads 设置为核心数减一即 3，ConcGCThreads 设置为 1。并发标记阶段如果线程数太多，会直接抢占业务线程的 CPU，导致单次请求毛刺；太少又来不及标记，老年代回收滞后。实测下来 1 个并发标记线程在这个负载下最合适。
3.3 直接内存、元空间与线程栈的细节
除了堆内参数，堆外内存的配置也容易被忽略，但堆外内存泄漏往往比堆内更隐蔽。
元空间我们设置为-XX:MaxMetaspaceSize=512m，基础框架和自定义类加载器的总量实测在 380MB 左右，预留了 30% 余量。直接内存通过-XX:MaxDirectMemorySize=1g限制，因为 NIO 和内存数据库访问都会使用直接内存，如果不限制，遇到内存泄漏问题时连排查方向都没有。
线程栈设置为-Xss512k。很多团队保留默认的 1MB，这在网关服务上问题不大，但在业务逻辑较深的交易服务里，线程栈太大会导致单个线程内存开销过高。一个 300 线程的池子，1MB 和 512k 的差异是 150MB，累积起来很可观。我们强烈建议在高并发线程池场景下，仔细评估线程数量与栈大小的乘积。
这里顺手补充一个压测落后手才知道的细节：JIT 编译对性能影响巨大。Java 默认的编译阈值是 10000 次方法调用，但压测常常只跑 30 分钟，足够触发 C1 编译但可能还没触发 C2 编译，导致压测数据偏低。我们统一加上了-XX:TieredStopAtLevel=1做快速预热压测，单独看热点的分配情况；等参数调优基本定型后，再去掉该参数跑完整模式，用真实 JIT 编译后的数据做最终验证。
4. 实操过程与核心环节实现：从压测数据到参数落地的完整路径
4.1 第一轮压测：定位到“对象分配过快”这个根因
强调一下，我们第一轮压测跑完，并没有立刻调参，而是花了两天时间分析对象分配路径。第一步是把 GC 日志里的分配速率统计出来，用 GCeasy 分析得到每秒钟分配约 1.8GB 对象，晋升速率约 180MB/s。这个数字让我很警觉，因为服务器总内存也就 16GB 堆，按这个晋升速率，老年代十几秒就要被填满一次。
顺着火焰图和内存分配分析，定位到问题出在一个高频调用的“对账结果聚合”方法上。方法内部用Stream.collect(Collectors.toList())创建了大量临时容器对象，并且在循环体内把一次中间结果拼接成了一个新的字符串对象。这种写法在低流量下没什么感知，但在 3000 TPS 压力下，瞬间成为对象分配第一大户。
代码改法并不复杂：将循环内的字符串拼接改为StringBuilder复用，将容器对象改为预分配容量的ArrayList，把流式操作改成普通循环。改造后单方法分配速率从 680MB/s 降到 190MB/s，效果立竿见影。这里我想强调一个心态：JVM 调优并不意味着“调完参数就完事”，它往往是先代码后参数，先内存后 GC。代码层面的浪费不解决，参数调得再漂亮也是治标不治本。
4.2 参数调整与压测验证的循环节奏
改完代码后，我们进入参数调整阶段。每次只改一组参数，然后跑完整的平峰+峰值压测，对比验证后再改下一组。这个原则很重要，因为同时改多个参数，如果数据变好，你根本不知道是哪个参数的功劳；如果变坏，也不知道是哪个参数的锅。
第一组调整是年轻代占比和 GC 停顿目标，设置了-XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=20 -XX:MaxGCPauseMillis=100。压测跑完后，年轻代 GC 的平均耗时降到了 35ms，P99 降到 120ms。但老年代的问题冒出来了—因为年轻代空间变小，晋升更早更多，老年代占用率在峰值压测时达到了 73%，触发并发标记的阈值是 45%，于是并发回收开始频繁工作，整体 CPU 开销反而上升了。
第二组调整做了补偿：把-XX:InitiatingHeapOccupancyPercent从默认的 45% 降低到 35%，让并发回收更早介入，避免老年代被撑到爆。同时把-XX:ConcGCThreads从 2 调整为 1，防止并发标记阶段抢占过多 CPU。这一次压测整体表现均衡了，年轻代 GC 平均 30ms，P99 90ms，老年代并发回收期间业务 P99 没有出现明显毛刺。
第三组调整是针对大对象的。压测日志里发现部分对象直接进入了老年代，这些对象是某些大报文解析结果。我们把-XX:PretenureSizeThreshold配置为一个合适的值，再做一次压测验证。整体来看，三轮参数调整用了六天时间，最终数据比第一轮好了非常多：吞吐率从 91% 提升到 98.7%，GC 平均停顿从 80ms 降至 27ms，P99 从 380ms 降至 115ms。
4.3 启动参数全貌速查
调优完成后的关键启动参数，整理成一份可以直接复用的清单：
-Xms16g -Xmx16g -Xss512k -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=1g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1HeapRegionSize=8m -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=20 -XX:ConcGCThreads=1 -XX:ParallelGCThreads=3 -XX:InitiatingHeapOccupancyPercent=35 -XX:+HeapDumpOnOutOfMemoryError -Xlog:gc*:file=/data/logs/gc.log:time,uptime,level:filecount=10,filesize=50m要说明一下：-Xms和-Xmx设置为相同值，避免运行时动态扩容导致 CPU 额外开销。G1 本身就支持动态堆调整，但维系堆大小稳定能减少额外的 commit 操作，对容器环境更友好。如果你的机器内存足够大，也可以使用扩容模式，但绝大多数容器化部署我会建议等值设置。
5. 线上稳态落地与验证：从压测到生产的最后一公里
5.1 容器场景下的特殊调整
从压测环境到生产环境，参数基本不动，但有几个容器特有的配置必须加上。Java 10 以后默认开启了-XX:+UseContainerSupport，容器能识别到 CPU 配额，JVM 会自动调整线程数，这一步务必确认开启状态，否则 JVM 会按宿主机核数计算，导致线程池和 GC 线程数量虚高，CPU 竞争加剧。
我们生产环境的容器规格是 4 核 16GB，跟压测环境完全一致。如果生产环境计划调整规格，请务必重新跑一轮压测验证，不要拿旧的压测数据直接推算新规格下的容量。另外，透明大页建议关闭，我们是在容器平台层面统一处理的。
5.2 集成了“止血手段工具箱”的稳态设计
线上稳态不只是 JVM 参数的事，它需要配合应用层的自我保护机制。我们在调优的同时上线了三层保护：
第一层是接口层的快速失败，通过信号量限流直接拒绝超过容量的请求，防止服务线程被长时间占用。第二层是 MQ 消费端的动态拉取速率控制，通过监控消费堆积量来自动调整每次拉取的消息数量，避免消费积压时大量对象涌入堆内。第三层是老年代占用率达到 70% 时自动触发的轻量降级开关，关闭非核心链路的部分功能，给 JVM 腾出喘息空间。
这三层机制配合起来，效果很理想——线上即使发生突发流量，JVM 侧只是年轻代 GC 频次升高，老年代始终维持在安全水位，不会出现 Full GC。
5.3 容量验证与扩容推导
调优的最终目标不是“参数好看”，而是“能接下多少流量”。我们用调优后的单机能力做了扩容推导：单实例在 P99 达标的前提下能承接 3000 TPS，目标场景需要 10 万 TPS，考虑到单实例故障替换的冗余，我们按 1.3 倍冗余系数计算，需要的实例数是ceil(100000 / 3000 × 1.3) = 44 台。这个模型上线后经过了真实峰值流量的检验，没有出现容量不足导致的抖动。
这里有个细节值得说：压测时单机 3000 TPS，但线上实际流量特征是突发性更强的尖峰，和压测的均匀流量并不完全一致。所以我们把线上第一批灰度流量控制在线下压测容量的 70%，确认 P99 达标后，再逐步放开到 100%。这么做虽然保守，但避免了在流量陡增时才发现压测模型不够真实的尴尬。
5.4 灰度节奏和监控看板的设计
灰度放量分三步走。第一步是，选择流量最低的时段，将 5% 的流量切到新参数实例，观察 30 分钟，主要看 GC 日志和 P99 指标有没有异常。第二步是，将流量提升至 30%，持续观察一个业务高峰周期，重点关注年轻代 GC 频率和并发回收的耗时。第三步是，确认无问题后，切全量流量，并持续观察一周。
监控看板我们重点关注四个指标：Full GC 次数、老年代占用率变化曲线、年轻代 GC 平均和最大停顿、系统吞叶量与 GC CPU 占比。其中“老年代占用率”是最敏感的预警项，当它持续上涨且并发回收无法把水位降下来的时候，就必须立刻介入，而不是等 Full GC 已经发生了再去排查。
6. 常见问题与排查技巧实录
6.1 高并发锁竞争被误判成 GC 频繁
第一轮压测时，我们一度认为年轻代 GC 频繁是最大问题，但分析火焰图发现实际上是一个分布式锁竞争热点。方法内部大量使用了基于数据库的锁表实现，每次加锁释放都会伴随事务提交和连接归还。压测下锁等待时间累积到 800ms，线程长时间处于 BLOCKED 状态，等待中的线程持有的对象无法及时回收，间接导致年轻代对象晋升。
这个问题的发现过程让我印象深刻：单纯看 GC 日志，确实会得出“对象分配速率异常”的结论，但此刻jstat -gcutil显示堆占用其实一直稳定，只是线程等待导致的有效工作占比降下来了。排查这类问题，不能只盯 GC，要结合线程状态和火焰图一起看。定位后把锁改为基于内存数据库的原子操作，锁竞争问题彻底消除，GC 压力也随着下降了一大截。
6.2 “压测达标但线上抖动”的三种典型原因
线上出现 P99 偶尔冲高但压测完全正常的情况，我先会往三个方向排查。第一，压测流量模型和线上用户行为不同，线上有大量短连接请求，每次请求都伴随连接建立和销毁，会产生大量短生命周期对象。解决办法是使用连接池，并复用连接。第二，线上存在被压测环境遗漏的定时任务，比如整点数据聚合，触发瞬间大量对象涌入堆内。解决方式是错峰执行并限制任务并发数。第三，线上日志量远大于压测，日志框架异步化不够时，刷盘线程会抢占 CPU。排查时先用 jstack 看线程状态，再用火焰图分析占比，基本能快速定位。
6.3 发布后 CPU 飙升但是 GC 稳定，问题出在哪
有一次发布新版本后，CPU 飙到 95%，但 GC 表现完全没有异常。我们用火焰图追踪到热点集中在 JSON 序列化——新版本引入了一个更“方便”的序列化工具，内部大量使用了反射。低流量下没感知，高并发下反射调用的开销瞬间放大，而且每次序列化都会创建新的Method和Field缓存对象，给年轻代制造了额外压力。定位后替换为手写序列化方案，CPU 降回 38%，GC 也恢复到了发布前的水平。这类问题靠 JVM 参数完全解决不了，它属于代码工艺问题。
6.4 关于“加大堆内存”的典型误区
在优化过程中，有个阶段的堆内存使用率看起来很高，当时有建议直接加到 24GB，被我否决了。理由是，高流量场景下堆内存占用高并不一定代表“不够”，它可能只是 JVM 在按照预期利用空间。直接加大会导致卡表扫描范围变大，每次 Young GC 的 Root 扫描时间变长，停顿反而更差。压测实验也验证了这一点——堆加到 24GB 后，年轻代 GC 平均停顿从 27ms 涨到 45ms，吞吐率下跌了 1.2%。这就是典型的“资源的诅咒”：看起来资源更多，实际性能反而更差。
7. 最后分享一个实操习惯
整个调优项目收尾时，我们会被问最多的问题就是“这套参数能不能直接拿到其他项目用”。答案是不建议，但可以提供一个方法论：任何参数调整都要从压测数据反向推导，而不是正向抄袭。
我这里再分享一个实操习惯：每完成一轮压测，把 GC 日志、火焰图、参数变更记录这三个文件打包归档，命名规范是日期_场景_参数版本。这个习惯在迭代优化时帮了很大的忙。后期出现问题时，可以快速回退到某个历史版本，对比日志找到变化点，而不是靠记忆去猜。
另外，JVM 参数应该纳入代码仓库统一管理，走评审流程。每次参数变更都有对应 commit 记录，后续排查问题只需查 git 历史就能清楚知道哪次变更引入了什么影响。如果团队里有新手，我强烈建议先安排他独立做一轮压测分析，让他自己从日志中找出瓶颈，再让他写参数推导文档。这不只是培养新人，也是在培养团队对系统的敬畏心。JVM 调优没有一招鲜的银弹，所有的稳态，都是通过一次次“数据驱动、小步验证”积累出来的。
