做了很多年Java性能优化我遇到最多的提问方式就是“帮我看下JVM参数系统最近老是卡顿。”每次看到这类问题我几乎都会劝对方先别急着改参数。说实话在真实的性能问题里单靠调整JVM参数就能解决的恐怕连三分之一都不到。更多问题藏在代码逻辑、资源使用方式、数据量突变甚至一次不起眼的日志改动里。基于这个观察我一直想写一篇能把方法论、原理和案例串起来的Java性能优化指南让读到的人不用再走“先瞎调、后崩溃”的老路。这篇文章会从性能测量的正确姿势讲起再到JVM内存与GC的核心原理最后用两个真实案例复盘性能瓶颈的定位过程适合刚接触性能调优的开发者也适合希望建立系统排查思路的团队。我会尽量把每一步的“为什么”讲清楚因为知道为什么才知道怎么改。1. 性能优化的第一原则先度量再动手最后才谈调参很多性能问题的排查从一开始就走错了方向。为什么因为大家太相信自己的“直觉”了。1.1 为什么凭直觉定位的瓶颈十个有九个是错的我见过一个典型的例子某个内部系统每到月底就卡顿团队排查了几天“大家的共识”是数据库查询太慢因为报表数据在那几天暴涨。结果打开监控一看数据库的CPU和等待时间都很正常真正的问题是报表模块在JVM里做全量聚合老年代被临时对象撑满Full GC频繁到接近每秒一次。改完代码后整个报表流程从几十秒降到两秒。这个案例让我印象很深。人的本能是找一个看起来最合理的解释比如“数据量大了所以慢”但系统慢往往是因为某个局部组件最先到达了瓶颈。这个瓶颈可能在数据库可能在网络可能在锁竞争也可能就在JVM的堆里。如果不先度量所谓的“定位”只是猜测而猜测驱动的优化多半是白费功夫。所以我在做性能优化时第一步永远是回答三个问题慢在了哪个环节那个环节消耗了多少时间或资源优化之后理论上能带来多少收益回答不了这三个问题我就不建议动手改任何东西。1.2 吞吐量、延迟、资源利用率一个都不能少性能指标里最常被拿来讨论的是三个吞吐量、延迟、资源利用率。很多人只看吞吐量觉得QPS上去了就是快这是不够的。吞吐量单位时间能处理多少请求通常用TPS或QPS表示。延迟单个请求从发出到收到响应的时间通常看平均值、P95、P99。资源利用率CPU、内存、磁盘IO、网络IO的占用情况用来判断瓶颈是否在资源侧。为什么平均值会骗人举个最简单的例子90个请求耗时1毫秒9个请求耗时100毫秒剩下1个请求耗时10秒。平均耗时大约是110毫秒听着还行但P99是10秒。对真实用户来说那个10秒的请求才是体感最差的。线上服务最怕的不是平均延迟高而是长尾延迟所以P95和P99几乎是必看指标。资源利用率也不容忽视。如果CPU已经打满但吞吐还是上不去那就不是“加线程”能解决的问题反而要查是不是有忙等、死循环或者不合理的自旋。如果内存居高不下则要怀疑对象生命周期设计有问题。三个指标要放在一起看才能定位到真正的瓶颈。1.3 标准化的基线所有优化的对比锚点没有基线就没有优化。这里说的基线是一组可重复、可对比的测量数据。我自己做优化前会固定做这么几件事记录当前版本的环境信息服务版本、实例数、堆大小、垃圾收集器类型、JDK版本。打开GC日志和JFR。JDK 9以后可以用-Xlog:gc*:filegc.log这种方式输出GC日志JFR则可以通过启动参数或jcmd动态开启。用同一套压测脚本、同一个压测时长、同一个并发模型打一轮基线数据。把结果存到一个固定目录命名带上日期例如baseline-20250115。后续每一次改动代码层面的也好参数层面的也好都必须在同一套压测条件下重跑拿结果和基线对比。我见过太多团队改完参数自我感觉良好结果换了个压测工具又打回原形就是因为没有固定基线。记住一个原则没有测量的优化是玄学有测量但不对比的优化是自嗨。基线就是那条公平的起跑线。2. JVM内存与GC机制把最容易被忽略的理论补扎实很多人调优的时候不喜欢看理论觉得“参数能跑就行”。但如果没有一个准确的JVM心智模型你连日志里那几行数字代表什么都说不清更别提做判断了。2.1 对象的一生从Eden到老年代的规则JVM的堆内存通常被分为新生代和老年代。新生代里又有Eden区和两个Survivor区S0、S1对象刚创建时基本都待在Eden区。当Eden区不够用时会触发Minor GC把还活着的对象复制到Survivor区。对象在Survivor区每经过一次GC年龄加1达到阈值后就晋升到老年代。大对象例外它往往会直接进入老年代因为复制大对象太贵。理解这个流程后有两个概念必须掌握分配速率和晋升速率。分配速率单位时间内新生代分配对象的总大小。分配速率越高Minor GC越频繁。晋升速率单位时间内从新生代晋升到老年代的对象大小。晋升速率越高老年代被占满的速度越快Full GC越频繁。很多场景下系统的真实问题不是“垃圾收集器不够好”而是“垃圾产生得太快”。如果代码里每秒产生几十MB短命对象任何垃圾收集器都救不了。调优的第一步永远是降低这两个速率而不是换GC器。2.2 垃圾收集器怎么选吞吐、停顿、适用场景的取舍垃圾收集器的本质是在吞吐量、停顿时间、内存占用之间做博弈。没有“最好”的收集器只有“最合适当前场景”的收集器。收集器核心特点停顿特征典型适用场景Parallel高吞吐多线程回收STW较长后台批处理、离线计算CMS并发标记清除停顿较短但碎片多旧版本JDK的延迟敏感服务G1分区化可设停顿目标可控平均停顿低JDK 9以后的默认选择适合大多数服务ZGC / Shenandoah超低停顿停顿极短毫秒级超大堆、低延迟、高并发场景从JDK 9开始G1成为默认垃圾收集器。它把堆划分成很多Region执行GC时只回收一部分Region而不是全堆扫描所以停顿时间更可控。ZGC在JDK 15之后基本成熟停顿目标在10毫秒以内但仍然处在“用更多的CPU和内存换取更低延迟”的阶段适用面相对窄。选型建议很简单默认用G1就好除非你有非常明确的延迟指标压不过去再考虑ZGC。生产环境尽量不要玩“全家桶式”的定制收集器不好维护出了问题也不好查。2.3 一段“看起来没问题”的代码为何会引发GC风暴下面这段代码初看似乎没什么问题ListString result new ArrayList(); for (int i 0; i 100000; i) { String row formatRow(orderService.get(i)); result.add(row); }但如果orderService.get(i)每次都返回一个经过包装的对象formatRow又创建了新的字符串和中间集合那么循环十万次就会产生几十万个短期对象。在低QPS下没事QPS一旦上来Eden区很快被打满Minor GC频率飙升CPU大量消耗在GC上系统整体吞吐下降。优化思路不是去调GC参数而是减少垃圾的产生量。比如分页拉取数据、复用StringBuilder、避免在循环里做无谓的对象包装。这是一件反直觉的事很多性能问题根因根本不是JVM而是你写进JVM里的垃圾太多了。把垃圾变少GC自然就快了。3. 性能诊断工具箱从JDK自带命令到在线诊断工具的实战用法工欲善其事必先利其器。性能排查最忌讳的是“凭感觉”而工具的作用就是把感觉变成数据。以下这套组合拳基本覆盖了我日常排查的90%场景。3.1 先用免费工具把问题定位到“区”JDK自带命令行工具虽然朴素但真的很管用而且任何环境都有。jps -l列出当前Java进程的PID和启动类。jstat -gcutil pid 1000每秒打印一次各代内存使用率和GC时间。重点看这几列EEden使用率、O老年代使用率、YGCMinor GC次数、YGCTMinor GC总耗时、FGCFull GC次数、FGCTFull GC总耗时。jmap -dump:live,formatb,fileheap.hprof pid导出堆转储文件。要注意加live参数会触发一次Full GC生产环境要谨慎最好选在低峰期。jstack pid打印线程栈配合top -Hp pid找到CPU最高的线程号后再转成十六进制去线程栈里找对应线程。实际排查时我会先看jstat -gcutil。如果O区持续上升且FGC次数增长很快基本可以断定往堆转储方向排查如果CPU高但GC不频繁则把重点放在线程栈和JFR的CPU采样上。工具本身不重要重要的是从数据里读出方向。3.2 JFR不打断服务就能拿到的黑匣子JFRJava Flight Recorder是我最推荐优先使用的诊断手段。JDK 11以后JFR已经开箱即用不需要额外授权。它的开销非常低可以长期开着就像飞机上的黑匣子一样。JFR能记录的东西非常丰富CPU热点、锁竞争、堆分配、GC暂停、方法采样、文件IO、异常等。线上服务出问题时直接jcmd pid JFR.dump filenamerecording.jfr把记录拉下来用工具打开就能看到问题发生前后JVM内部的完整轨迹。我建议有条件的话线上服务长期开启JFR配置一个合理的时长和文件大小。出问题以后先看JFR再决定要不要dump堆、要不要抓线程栈。很多时候光靠JFR一条“锁竞争热点”就能直接锁定问题连堆都不用导。3.3 在线诊断工具方法级定位问题的放大镜JDK自带工具和JFR能解决“哪个区域有问题”但有时候还不够细比如“某个方法里到底哪一行慢”。这时候我会用开源诊断工具Arthas它不需要重启服务也不需要改代码直接连上就跑。几个常用命令dashboard秒级刷新当前JVM的CPU、内存、线程、GC概况相当于多了个轻量监控页。thread -n 3直接列出CPU占用最高的三个线程正在执行什么。trace 类名 方法名统计一个方法内部各子调用链路的耗时效果等同于给方法打了个计时器。我记得有一次排查“接口偶发超时”代码里层层调用不知道慢在哪。用trace一打发现90%的时间耗在一个第三方SDK的对象序列化方法里而不是业务逻辑本身。这种定位精度靠肉眼看代码是做不到的。需要提醒一点在线诊断命令在生产环境有侵入性使用前要确认权限范围trace的采样范围也要控制不要开全局trace跑几个小时。4. 案例复盘一一次内存泄漏排查从“感觉是并发”到“找到根因”理论讲再多不如走一遍真实案例。第一个案例是我印象很深的内存泄漏问题排查过程不算复杂但思考方式很典型。4.1 现象每跑一周就OOM重启就好某定时任务系统每天要处理大量批量数据。系统刚上线挺好但运行大约一周后内存使用率不断上涨最终OOM进程被迫重启。重启之后又正常然后过几天再重复一次而且间隔时间越来越短。团队初步怀疑是并发量太高导致内存不足但查了监控发现在线并发并不高堆内存却在持续爬升。这种“持续增长且重启才好”的现象基本可以判断为对象泄漏或无限缓存导致的堆占满需要往堆内部的动态变化方向查。4.2 排查链路GC日志 → jstat → heap dump → 内存分析工具我的排查顺序是打开GC日志发现老年代曲线一路向上即便Full GC之后也几乎不下降。用jstat -gcutil确认O区长期处在80%到99%之间FGC次数不断增加。在低峰期导出heap dump用MATMemory Analyzer打开看Leak Suspects和Dominator Tree也就是“谁占着最大的内存”。结果定位到一个十分不起眼的静态Map它保存了每次批量任务的处理结果。这个Map只往里写不主动清理也没有容量上限。任务跑得越多Map就越大最终把老年代活活撑满。这类问题的隐蔽性在于平时任务量少的时候完全无感一旦业务量增长Map的增长速度超过OOM阈值问题立刻爆发。而代码审查时这个Map看起来又“只是存个结果”而已很容易被忽略。4.3 修复不是换更大的堆而是改掉错误的数据结构修复方案不是把堆调大——调大堆只会让OOM来得更晚不会解决根因。我当时的处理是确认这个缓存是否真的需要长期保留。结论是不需要后续流程用完结果就丢弃。直接去掉缓存如果业务确实需要保留部分数据换成带过期时间和容量上限的缓存组件。给定时任务增加内存水位告警当老年代使用率超过阈值时报警避免再次无声无息地涨到OOM。改完之后堆内存曲线稳定下来系统连续运行几个月没有再发生过OOM。经验就是优先用堆转储来找“凶手”而不是靠代码审查猜。堆转储能直接把哪些对象在占内存、占了多少摆在你眼前尤其适合排查这种“表面上没有明显问题”的隐藏缓存。另外要澄清一个误解不是所有OOM都是内存泄漏。如果堆内存曲线整体上行但每个生命周期正常的请求也会创建大对象可能是单次分配过大或堆配置过小。区分方法就是看GC日志里内存是不是“持续且不可回收”再决定往哪个方向查。5. 案例复盘二把GC最大停顿从800ms压到15ms的完整调优过程第二个案例更贴近日常因为它的主角是GC停顿。很多线上服务的痛苦不是吞吐不够而是时不时抖一下响应时间出现刺眼的尖峰。5.1 现象P99延迟飙到2秒Full GC每10分钟一次某网关服务堆内存配置了4GB使用默认的Parallel收集器并发量不算特别高但P99延迟经常飙到2秒。打开GC日志一看Full GC大约每10分钟一次单次停顿有时候接近800毫秒。Parallel收集器的定位是高吞吐它做Full GC时会暂停所有业务线程对4GB的堆做标记-整理。这种长时间STWStop The World在网关这类对延迟敏感的服务上非常致命用户按一次按钮服务可能就卡了整整一秒。5.2 调优过程GC器切换、参数设置与代码层削减分配第一步我把收集器从Parallel切换成G1并设置-XX:MaxGCPauseMillis200。切换后Full GC次数明显变少停顿也大幅下降但同时发现Minor GC频率上升了。这说明G1正在用更频繁的Partial GC来满足停顿目标方向上没问题但还没触及根本。第二步用JFR抓分配热点结果发现某个处理方法在循环里频繁拼接很长的字符串JDK内部的数组复制导致老年代不断产生大对象。这些大对象促成了晋升老年代压力一高最终还是会触发Full GC。第三步在代码层优化把循环里的字符串拼接改成复用的StringBuilder并调整了数据的分片处理逻辑。晋升速率降下来之后老年代的压力明显减小Full GC基本变成低频事件。参数方面我只额外设置了-XX:G1HeapRegionSize16m其他交给G1自动调整。这里一定要提醒G1的参数不是越多越好。如果你为了“快速生效”复制一大段网上找来的G1调优参数很可能互相干扰反而把默认的平衡打破了。5.3 结果验证与经验沉淀优化完成后的对比数据如下指标优化前优化后Full GC频率约10分钟一次约2小时一次最大STW约800ms约15msP99延迟约2s约180ms平均吞吐波动大稳定且略有提升这个案例给了一个重要经验调优是有顺序的。先削减代码里的垃圾产生量再调整收集器类型和参数。参数的作用是“收尾”而不是“开场”。如果你把收集器换来换去但代码里的分配热点还在那只是把一个问题的表现形式换了一下。还有一个容易被忽略的点不是参数越小越好。MaxGCPauseMillis调得太小G1会为了追求低停顿而频繁回收导致吞吐下降。用了G1之后观察的维度要从“FGC次数”扩展到“YGC频率停顿时间吞吐”的三角组合判断整体是否平衡。6. 线程池与连接池参数别再用感觉当尺子线程池和连接池是并发系统里最常见的两个池子也是参数被“拍脑袋”拍得最狠的地方。有人甚至为了保险把线程池核心线程数设成几百结果不是更快而是更慢。6.1 线程池大小CPU密集和IO密集是两个公式线程池大小没有万能答案但有经验公式可以推导起点。CPU密集型任务建议线程数约等于CPU核数加1N1。因为CPU密集任务几乎不等待线程再多只会增加上下文切换。IO密集型任务建议线程数约等于N × (1 等待时间 / 计算时间)。比如8核机器任务平均等待IO 100ms计算20ms那么理论线程数就是8 × (1 100/20) 48。这个48只是起点还要考虑队列长度、拒绝策略、下游服务的承载能力。线程并不是越多越好超过临界值后上下文切换和锁竞争的成本反而会拖垮吞吐。我见过一个真实调整案例某服务把核心线程数从200下调到40结果QPS反而提高了。原因很简单之前大量线程都在抢同一把锁CPU大量消耗在阻塞和唤醒上线程变少后锁竞争降低实际业务计算的比例提高了吞吐自然上去了。6.2 数据库连接池连接数不是越多越快数据库连接池也存在类似的误区。很多人一开口就问“连接池maximumPoolSize是不是设越大越好”其实不是。数据库服务同一时间能处理的请求数是有限的。连接开得太多会让数据库内部同时排队的事务变多每个请求反而更慢。连接池的核心目标是让应用“快速拿到连接”而不是“攒一堆连接”。一个比较务实的做法是先测出单连接的数据库处理能力再结合业务峰值QPS和平均SQL耗时做估算但最终必须用压测来验证。很多中低负载系统使用连接池中间件默认的10个连接就已经完全够用了。如果连接池经常被打满优先排查是不是存在慢SQL或者连接泄漏而不是盲目调大连接数。6.3 三个藏在代码里的常见性能陷阱除了线程池和连接池代码层面还有三个高频性能陷阱值得警惕日志同步写高并发场景下每次请求都同步写日志会严重拖慢接口响应。建议在瓶颈确认后接入异步日志或者按级别降级日志输出。复杂正则表达式某些正则pattern存在灾难性回溯一个看似普通的匹配就能把CPU打满。能用简单字符串方法解决的尽量不要上复杂正则一定要用就提前预编译Pattern。自动拆箱与字符串拼接热点循环里频繁做Integer到int的转换或者用拼接字符串都会产生大量临时对象。要么改基本类型要么用StringBuilder。这个优化成本极低收益在热点路径上却非常明显。7. 让数据说真话JMH基准测试与压测中必须避开的测量偏差性能优化到最后一定会到“验证”这一步。如果验证本身有偏差前面所有的优化结论都可能站不住脚。这一章聊测试方法和误差问题。7.1 为什么手写for循环测性能会测出“假数据”很多人喜欢在main方法里写个for循环来测“哪个写法更快”这很不靠谱原因有三个预热不足JVM的JIT编译器会在方法被调用多次后介入把热点代码编译成机器码。没有充分预热你测的是“解释执行编译中”的混合状态和真实运行相差很大。死代码消除如果循环计算结果没有被使用JIT很可能直接把整个循环优化掉测出来的时间接近于零。方法内联被测方法可能被JIT内联到调用方使测量结果和实际调用场景不一致。所以不要再用一个简单的main方法去比较两段代码的性能。要用专门的微基准测试工具让评测框架帮你处理预热和优化问题。7.2 一个可以直接抄走的JMH示例JMHJava Microbenchmark Harness是Java生态里最常用的微基准测试框架。下面这个例子比较了两种字符串拼接方式的差异BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.SECONDS) State(Scope.Thread) Warmup(iterations 5, time 1) Measurement(iterations 5, time 1) Fork(1) public class StringBenchmark { Benchmark public String concatWithBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(i); } return sb.toString(); } Benchmark public String concatWithPlus() { String s ; for (int i 0; i 100; i) { s i; } return s; } }模式用了Throughput代表每秒能执行的次数预热5轮、正式测量5轮结果会用置信区间和误差范围展示比手写测试可信得多。拿到结果后再结合业务代码的实际调用频率去判断优化收益不要只看“快了百分之多少”。7.3 全链路压测的误差来源微基准解决的是“单点方法”的测量全链路压测解决的是“整体服务”的测量。但压测数据同样会骗人常见的误差来源包括压测客户端本身资源不足导致客户端成为瓶颈压测目标服务还没到极限数据就已经上不去了。压测期间日志、监控组件过度输出干扰了目标服务的真实表现测出来的数据和正常生产差异很大。分布式系统里网关负载均衡算法可能把压测流量打偏导致某台实例压力过大、其他实例很闲。容器环境里CPU限额、底层资源争抢也会造成抖动尤其要多轮压测取稳定值。我的建议是压测至少做三轮每轮之间间隔一段时间取中位数或稳定值每一轮压测记录目标机器负载、JVM GC情况、网络流量方便判断数据是否可信。没有这些伴生指标光看一个QPS数字根本不知道它是怎么来的。8. 我踩过的一些坑三个关于性能优化的错误观念讲完诊断工具、案例和测试方法我很想再聊聊那些让我吃过亏的错误观念。这些观念几乎每个做性能优化的人都会遇到越早纠正越少走弯路。第一个错误观念性能优化就是调参数。这是最常见的误解。真正带来高收益的优化大多是“去掉无用工作”和“减少对象分配”。调参数只是在代码优化之后做收尾甚至有时候调完参数代码一改参数又得重新调一遍。第二个错误观念优化代码必须先于调整结构。其实这是个伪命题。有时候调整线程池大小、切个收集器、换个缓存策略成本远低于对每一行代码做微优化。正确的做法是先定位最大瓶颈然后选择性价比最高的手段而不是按“大而全”的顺序把所有优化手段挨个来一遍。第三个错误观念测试环境验证过就稳了。测试环境的数据量、并发模型、机器配置和生产环境往往差别很大。一个在测试环境被验证“优化有效”的改动到了生产环境可能完全没效果甚至更糟。所以重要的优化上线前要有灰度验证上线后要盯紧GC、延迟、错误率和资源使用不能一改了之。到现在为止我做性能优化的习惯基本可以浓缩成这句话先问测量再问原理最后才问参数。你遇到的绝大多数性能问题都能在某个日志片段、堆转储、线程栈或者火焰图里找到答案。如果找不到大概率是你看错方向了而不是问题不存在。这套从度量到定位再到验证的方法就是我在这篇Java性能优化实战文章里最想传达的东西。
做了很多年Java性能优化我遇到最多的提问方式就是“帮我看下JVM参数系统最近老是卡顿。”每次看到这类问题我几乎都会劝对方先别急着改参数。说实话在真实的性能问题里单靠调整JVM参数就能解决的恐怕连三分之一都不到。更多问题藏在代码逻辑、资源使用方式、数据量突变甚至一次不起眼的日志改动里。基于这个观察我一直想写一篇能把方法论、原理和案例串起来的Java性能优化指南让读到的人不用再走“先瞎调、后崩溃”的老路。这篇文章会从性能测量的正确姿势讲起再到JVM内存与GC的核心原理最后用两个真实案例复盘性能瓶颈的定位过程适合刚接触性能调优的开发者也适合希望建立系统排查思路的团队。我会尽量把每一步的“为什么”讲清楚因为知道为什么才知道怎么改。1. 性能优化的第一原则先度量再动手最后才谈调参很多性能问题的排查从一开始就走错了方向。为什么因为大家太相信自己的“直觉”了。1.1 为什么凭直觉定位的瓶颈十个有九个是错的我见过一个典型的例子某个内部系统每到月底就卡顿团队排查了几天“大家的共识”是数据库查询太慢因为报表数据在那几天暴涨。结果打开监控一看数据库的CPU和等待时间都很正常真正的问题是报表模块在JVM里做全量聚合老年代被临时对象撑满Full GC频繁到接近每秒一次。改完代码后整个报表流程从几十秒降到两秒。这个案例让我印象很深。人的本能是找一个看起来最合理的解释比如“数据量大了所以慢”但系统慢往往是因为某个局部组件最先到达了瓶颈。这个瓶颈可能在数据库可能在网络可能在锁竞争也可能就在JVM的堆里。如果不先度量所谓的“定位”只是猜测而猜测驱动的优化多半是白费功夫。所以我在做性能优化时第一步永远是回答三个问题慢在了哪个环节那个环节消耗了多少时间或资源优化之后理论上能带来多少收益回答不了这三个问题我就不建议动手改任何东西。1.2 吞吐量、延迟、资源利用率一个都不能少性能指标里最常被拿来讨论的是三个吞吐量、延迟、资源利用率。很多人只看吞吐量觉得QPS上去了就是快这是不够的。吞吐量单位时间能处理多少请求通常用TPS或QPS表示。延迟单个请求从发出到收到响应的时间通常看平均值、P95、P99。资源利用率CPU、内存、磁盘IO、网络IO的占用情况用来判断瓶颈是否在资源侧。为什么平均值会骗人举个最简单的例子90个请求耗时1毫秒9个请求耗时100毫秒剩下1个请求耗时10秒。平均耗时大约是110毫秒听着还行但P99是10秒。对真实用户来说那个10秒的请求才是体感最差的。线上服务最怕的不是平均延迟高而是长尾延迟所以P95和P99几乎是必看指标。资源利用率也不容忽视。如果CPU已经打满但吞吐还是上不去那就不是“加线程”能解决的问题反而要查是不是有忙等、死循环或者不合理的自旋。如果内存居高不下则要怀疑对象生命周期设计有问题。三个指标要放在一起看才能定位到真正的瓶颈。1.3 标准化的基线所有优化的对比锚点没有基线就没有优化。这里说的基线是一组可重复、可对比的测量数据。我自己做优化前会固定做这么几件事记录当前版本的环境信息服务版本、实例数、堆大小、垃圾收集器类型、JDK版本。打开GC日志和JFR。JDK 9以后可以用-Xlog:gc*:filegc.log这种方式输出GC日志JFR则可以通过启动参数或jcmd动态开启。用同一套压测脚本、同一个压测时长、同一个并发模型打一轮基线数据。把结果存到一个固定目录命名带上日期例如baseline-20250115。后续每一次改动代码层面的也好参数层面的也好都必须在同一套压测条件下重跑拿结果和基线对比。我见过太多团队改完参数自我感觉良好结果换了个压测工具又打回原形就是因为没有固定基线。记住一个原则没有测量的优化是玄学有测量但不对比的优化是自嗨。基线就是那条公平的起跑线。2. JVM内存与GC机制把最容易被忽略的理论补扎实很多人调优的时候不喜欢看理论觉得“参数能跑就行”。但如果没有一个准确的JVM心智模型你连日志里那几行数字代表什么都说不清更别提做判断了。2.1 对象的一生从Eden到老年代的规则JVM的堆内存通常被分为新生代和老年代。新生代里又有Eden区和两个Survivor区S0、S1对象刚创建时基本都待在Eden区。当Eden区不够用时会触发Minor GC把还活着的对象复制到Survivor区。对象在Survivor区每经过一次GC年龄加1达到阈值后就晋升到老年代。大对象例外它往往会直接进入老年代因为复制大对象太贵。理解这个流程后有两个概念必须掌握分配速率和晋升速率。分配速率单位时间内新生代分配对象的总大小。分配速率越高Minor GC越频繁。晋升速率单位时间内从新生代晋升到老年代的对象大小。晋升速率越高老年代被占满的速度越快Full GC越频繁。很多场景下系统的真实问题不是“垃圾收集器不够好”而是“垃圾产生得太快”。如果代码里每秒产生几十MB短命对象任何垃圾收集器都救不了。调优的第一步永远是降低这两个速率而不是换GC器。2.2 垃圾收集器怎么选吞吐、停顿、适用场景的取舍垃圾收集器的本质是在吞吐量、停顿时间、内存占用之间做博弈。没有“最好”的收集器只有“最合适当前场景”的收集器。收集器核心特点停顿特征典型适用场景Parallel高吞吐多线程回收STW较长后台批处理、离线计算CMS并发标记清除停顿较短但碎片多旧版本JDK的延迟敏感服务G1分区化可设停顿目标可控平均停顿低JDK 9以后的默认选择适合大多数服务ZGC / Shenandoah超低停顿停顿极短毫秒级超大堆、低延迟、高并发场景从JDK 9开始G1成为默认垃圾收集器。它把堆划分成很多Region执行GC时只回收一部分Region而不是全堆扫描所以停顿时间更可控。ZGC在JDK 15之后基本成熟停顿目标在10毫秒以内但仍然处在“用更多的CPU和内存换取更低延迟”的阶段适用面相对窄。选型建议很简单默认用G1就好除非你有非常明确的延迟指标压不过去再考虑ZGC。生产环境尽量不要玩“全家桶式”的定制收集器不好维护出了问题也不好查。2.3 一段“看起来没问题”的代码为何会引发GC风暴下面这段代码初看似乎没什么问题ListString result new ArrayList(); for (int i 0; i 100000; i) { String row formatRow(orderService.get(i)); result.add(row); }但如果orderService.get(i)每次都返回一个经过包装的对象formatRow又创建了新的字符串和中间集合那么循环十万次就会产生几十万个短期对象。在低QPS下没事QPS一旦上来Eden区很快被打满Minor GC频率飙升CPU大量消耗在GC上系统整体吞吐下降。优化思路不是去调GC参数而是减少垃圾的产生量。比如分页拉取数据、复用StringBuilder、避免在循环里做无谓的对象包装。这是一件反直觉的事很多性能问题根因根本不是JVM而是你写进JVM里的垃圾太多了。把垃圾变少GC自然就快了。3. 性能诊断工具箱从JDK自带命令到在线诊断工具的实战用法工欲善其事必先利其器。性能排查最忌讳的是“凭感觉”而工具的作用就是把感觉变成数据。以下这套组合拳基本覆盖了我日常排查的90%场景。3.1 先用免费工具把问题定位到“区”JDK自带命令行工具虽然朴素但真的很管用而且任何环境都有。jps -l列出当前Java进程的PID和启动类。jstat -gcutil pid 1000每秒打印一次各代内存使用率和GC时间。重点看这几列EEden使用率、O老年代使用率、YGCMinor GC次数、YGCTMinor GC总耗时、FGCFull GC次数、FGCTFull GC总耗时。jmap -dump:live,formatb,fileheap.hprof pid导出堆转储文件。要注意加live参数会触发一次Full GC生产环境要谨慎最好选在低峰期。jstack pid打印线程栈配合top -Hp pid找到CPU最高的线程号后再转成十六进制去线程栈里找对应线程。实际排查时我会先看jstat -gcutil。如果O区持续上升且FGC次数增长很快基本可以断定往堆转储方向排查如果CPU高但GC不频繁则把重点放在线程栈和JFR的CPU采样上。工具本身不重要重要的是从数据里读出方向。3.2 JFR不打断服务就能拿到的黑匣子JFRJava Flight Recorder是我最推荐优先使用的诊断手段。JDK 11以后JFR已经开箱即用不需要额外授权。它的开销非常低可以长期开着就像飞机上的黑匣子一样。JFR能记录的东西非常丰富CPU热点、锁竞争、堆分配、GC暂停、方法采样、文件IO、异常等。线上服务出问题时直接jcmd pid JFR.dump filenamerecording.jfr把记录拉下来用工具打开就能看到问题发生前后JVM内部的完整轨迹。我建议有条件的话线上服务长期开启JFR配置一个合理的时长和文件大小。出问题以后先看JFR再决定要不要dump堆、要不要抓线程栈。很多时候光靠JFR一条“锁竞争热点”就能直接锁定问题连堆都不用导。3.3 在线诊断工具方法级定位问题的放大镜JDK自带工具和JFR能解决“哪个区域有问题”但有时候还不够细比如“某个方法里到底哪一行慢”。这时候我会用开源诊断工具Arthas它不需要重启服务也不需要改代码直接连上就跑。几个常用命令dashboard秒级刷新当前JVM的CPU、内存、线程、GC概况相当于多了个轻量监控页。thread -n 3直接列出CPU占用最高的三个线程正在执行什么。trace 类名 方法名统计一个方法内部各子调用链路的耗时效果等同于给方法打了个计时器。我记得有一次排查“接口偶发超时”代码里层层调用不知道慢在哪。用trace一打发现90%的时间耗在一个第三方SDK的对象序列化方法里而不是业务逻辑本身。这种定位精度靠肉眼看代码是做不到的。需要提醒一点在线诊断命令在生产环境有侵入性使用前要确认权限范围trace的采样范围也要控制不要开全局trace跑几个小时。4. 案例复盘一一次内存泄漏排查从“感觉是并发”到“找到根因”理论讲再多不如走一遍真实案例。第一个案例是我印象很深的内存泄漏问题排查过程不算复杂但思考方式很典型。4.1 现象每跑一周就OOM重启就好某定时任务系统每天要处理大量批量数据。系统刚上线挺好但运行大约一周后内存使用率不断上涨最终OOM进程被迫重启。重启之后又正常然后过几天再重复一次而且间隔时间越来越短。团队初步怀疑是并发量太高导致内存不足但查了监控发现在线并发并不高堆内存却在持续爬升。这种“持续增长且重启才好”的现象基本可以判断为对象泄漏或无限缓存导致的堆占满需要往堆内部的动态变化方向查。4.2 排查链路GC日志 → jstat → heap dump → 内存分析工具我的排查顺序是打开GC日志发现老年代曲线一路向上即便Full GC之后也几乎不下降。用jstat -gcutil确认O区长期处在80%到99%之间FGC次数不断增加。在低峰期导出heap dump用MATMemory Analyzer打开看Leak Suspects和Dominator Tree也就是“谁占着最大的内存”。结果定位到一个十分不起眼的静态Map它保存了每次批量任务的处理结果。这个Map只往里写不主动清理也没有容量上限。任务跑得越多Map就越大最终把老年代活活撑满。这类问题的隐蔽性在于平时任务量少的时候完全无感一旦业务量增长Map的增长速度超过OOM阈值问题立刻爆发。而代码审查时这个Map看起来又“只是存个结果”而已很容易被忽略。4.3 修复不是换更大的堆而是改掉错误的数据结构修复方案不是把堆调大——调大堆只会让OOM来得更晚不会解决根因。我当时的处理是确认这个缓存是否真的需要长期保留。结论是不需要后续流程用完结果就丢弃。直接去掉缓存如果业务确实需要保留部分数据换成带过期时间和容量上限的缓存组件。给定时任务增加内存水位告警当老年代使用率超过阈值时报警避免再次无声无息地涨到OOM。改完之后堆内存曲线稳定下来系统连续运行几个月没有再发生过OOM。经验就是优先用堆转储来找“凶手”而不是靠代码审查猜。堆转储能直接把哪些对象在占内存、占了多少摆在你眼前尤其适合排查这种“表面上没有明显问题”的隐藏缓存。另外要澄清一个误解不是所有OOM都是内存泄漏。如果堆内存曲线整体上行但每个生命周期正常的请求也会创建大对象可能是单次分配过大或堆配置过小。区分方法就是看GC日志里内存是不是“持续且不可回收”再决定往哪个方向查。5. 案例复盘二把GC最大停顿从800ms压到15ms的完整调优过程第二个案例更贴近日常因为它的主角是GC停顿。很多线上服务的痛苦不是吞吐不够而是时不时抖一下响应时间出现刺眼的尖峰。5.1 现象P99延迟飙到2秒Full GC每10分钟一次某网关服务堆内存配置了4GB使用默认的Parallel收集器并发量不算特别高但P99延迟经常飙到2秒。打开GC日志一看Full GC大约每10分钟一次单次停顿有时候接近800毫秒。Parallel收集器的定位是高吞吐它做Full GC时会暂停所有业务线程对4GB的堆做标记-整理。这种长时间STWStop The World在网关这类对延迟敏感的服务上非常致命用户按一次按钮服务可能就卡了整整一秒。5.2 调优过程GC器切换、参数设置与代码层削减分配第一步我把收集器从Parallel切换成G1并设置-XX:MaxGCPauseMillis200。切换后Full GC次数明显变少停顿也大幅下降但同时发现Minor GC频率上升了。这说明G1正在用更频繁的Partial GC来满足停顿目标方向上没问题但还没触及根本。第二步用JFR抓分配热点结果发现某个处理方法在循环里频繁拼接很长的字符串JDK内部的数组复制导致老年代不断产生大对象。这些大对象促成了晋升老年代压力一高最终还是会触发Full GC。第三步在代码层优化把循环里的字符串拼接改成复用的StringBuilder并调整了数据的分片处理逻辑。晋升速率降下来之后老年代的压力明显减小Full GC基本变成低频事件。参数方面我只额外设置了-XX:G1HeapRegionSize16m其他交给G1自动调整。这里一定要提醒G1的参数不是越多越好。如果你为了“快速生效”复制一大段网上找来的G1调优参数很可能互相干扰反而把默认的平衡打破了。5.3 结果验证与经验沉淀优化完成后的对比数据如下指标优化前优化后Full GC频率约10分钟一次约2小时一次最大STW约800ms约15msP99延迟约2s约180ms平均吞吐波动大稳定且略有提升这个案例给了一个重要经验调优是有顺序的。先削减代码里的垃圾产生量再调整收集器类型和参数。参数的作用是“收尾”而不是“开场”。如果你把收集器换来换去但代码里的分配热点还在那只是把一个问题的表现形式换了一下。还有一个容易被忽略的点不是参数越小越好。MaxGCPauseMillis调得太小G1会为了追求低停顿而频繁回收导致吞吐下降。用了G1之后观察的维度要从“FGC次数”扩展到“YGC频率停顿时间吞吐”的三角组合判断整体是否平衡。6. 线程池与连接池参数别再用感觉当尺子线程池和连接池是并发系统里最常见的两个池子也是参数被“拍脑袋”拍得最狠的地方。有人甚至为了保险把线程池核心线程数设成几百结果不是更快而是更慢。6.1 线程池大小CPU密集和IO密集是两个公式线程池大小没有万能答案但有经验公式可以推导起点。CPU密集型任务建议线程数约等于CPU核数加1N1。因为CPU密集任务几乎不等待线程再多只会增加上下文切换。IO密集型任务建议线程数约等于N × (1 等待时间 / 计算时间)。比如8核机器任务平均等待IO 100ms计算20ms那么理论线程数就是8 × (1 100/20) 48。这个48只是起点还要考虑队列长度、拒绝策略、下游服务的承载能力。线程并不是越多越好超过临界值后上下文切换和锁竞争的成本反而会拖垮吞吐。我见过一个真实调整案例某服务把核心线程数从200下调到40结果QPS反而提高了。原因很简单之前大量线程都在抢同一把锁CPU大量消耗在阻塞和唤醒上线程变少后锁竞争降低实际业务计算的比例提高了吞吐自然上去了。6.2 数据库连接池连接数不是越多越快数据库连接池也存在类似的误区。很多人一开口就问“连接池maximumPoolSize是不是设越大越好”其实不是。数据库服务同一时间能处理的请求数是有限的。连接开得太多会让数据库内部同时排队的事务变多每个请求反而更慢。连接池的核心目标是让应用“快速拿到连接”而不是“攒一堆连接”。一个比较务实的做法是先测出单连接的数据库处理能力再结合业务峰值QPS和平均SQL耗时做估算但最终必须用压测来验证。很多中低负载系统使用连接池中间件默认的10个连接就已经完全够用了。如果连接池经常被打满优先排查是不是存在慢SQL或者连接泄漏而不是盲目调大连接数。6.3 三个藏在代码里的常见性能陷阱除了线程池和连接池代码层面还有三个高频性能陷阱值得警惕日志同步写高并发场景下每次请求都同步写日志会严重拖慢接口响应。建议在瓶颈确认后接入异步日志或者按级别降级日志输出。复杂正则表达式某些正则pattern存在灾难性回溯一个看似普通的匹配就能把CPU打满。能用简单字符串方法解决的尽量不要上复杂正则一定要用就提前预编译Pattern。自动拆箱与字符串拼接热点循环里频繁做Integer到int的转换或者用拼接字符串都会产生大量临时对象。要么改基本类型要么用StringBuilder。这个优化成本极低收益在热点路径上却非常明显。7. 让数据说真话JMH基准测试与压测中必须避开的测量偏差性能优化到最后一定会到“验证”这一步。如果验证本身有偏差前面所有的优化结论都可能站不住脚。这一章聊测试方法和误差问题。7.1 为什么手写for循环测性能会测出“假数据”很多人喜欢在main方法里写个for循环来测“哪个写法更快”这很不靠谱原因有三个预热不足JVM的JIT编译器会在方法被调用多次后介入把热点代码编译成机器码。没有充分预热你测的是“解释执行编译中”的混合状态和真实运行相差很大。死代码消除如果循环计算结果没有被使用JIT很可能直接把整个循环优化掉测出来的时间接近于零。方法内联被测方法可能被JIT内联到调用方使测量结果和实际调用场景不一致。所以不要再用一个简单的main方法去比较两段代码的性能。要用专门的微基准测试工具让评测框架帮你处理预热和优化问题。7.2 一个可以直接抄走的JMH示例JMHJava Microbenchmark Harness是Java生态里最常用的微基准测试框架。下面这个例子比较了两种字符串拼接方式的差异BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.SECONDS) State(Scope.Thread) Warmup(iterations 5, time 1) Measurement(iterations 5, time 1) Fork(1) public class StringBenchmark { Benchmark public String concatWithBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(i); } return sb.toString(); } Benchmark public String concatWithPlus() { String s ; for (int i 0; i 100; i) { s i; } return s; } }模式用了Throughput代表每秒能执行的次数预热5轮、正式测量5轮结果会用置信区间和误差范围展示比手写测试可信得多。拿到结果后再结合业务代码的实际调用频率去判断优化收益不要只看“快了百分之多少”。7.3 全链路压测的误差来源微基准解决的是“单点方法”的测量全链路压测解决的是“整体服务”的测量。但压测数据同样会骗人常见的误差来源包括压测客户端本身资源不足导致客户端成为瓶颈压测目标服务还没到极限数据就已经上不去了。压测期间日志、监控组件过度输出干扰了目标服务的真实表现测出来的数据和正常生产差异很大。分布式系统里网关负载均衡算法可能把压测流量打偏导致某台实例压力过大、其他实例很闲。容器环境里CPU限额、底层资源争抢也会造成抖动尤其要多轮压测取稳定值。我的建议是压测至少做三轮每轮之间间隔一段时间取中位数或稳定值每一轮压测记录目标机器负载、JVM GC情况、网络流量方便判断数据是否可信。没有这些伴生指标光看一个QPS数字根本不知道它是怎么来的。8. 我踩过的一些坑三个关于性能优化的错误观念讲完诊断工具、案例和测试方法我很想再聊聊那些让我吃过亏的错误观念。这些观念几乎每个做性能优化的人都会遇到越早纠正越少走弯路。第一个错误观念性能优化就是调参数。这是最常见的误解。真正带来高收益的优化大多是“去掉无用工作”和“减少对象分配”。调参数只是在代码优化之后做收尾甚至有时候调完参数代码一改参数又得重新调一遍。第二个错误观念优化代码必须先于调整结构。其实这是个伪命题。有时候调整线程池大小、切个收集器、换个缓存策略成本远低于对每一行代码做微优化。正确的做法是先定位最大瓶颈然后选择性价比最高的手段而不是按“大而全”的顺序把所有优化手段挨个来一遍。第三个错误观念测试环境验证过就稳了。测试环境的数据量、并发模型、机器配置和生产环境往往差别很大。一个在测试环境被验证“优化有效”的改动到了生产环境可能完全没效果甚至更糟。所以重要的优化上线前要有灰度验证上线后要盯紧GC、延迟、错误率和资源使用不能一改了之。到现在为止我做性能优化的习惯基本可以浓缩成这句话先问测量再问原理最后才问参数。你遇到的绝大多数性能问题都能在某个日志片段、堆转储、线程栈或者火焰图里找到答案。如果找不到大概率是你看错方向了而不是问题不存在。这套从度量到定位再到验证的方法就是我在这篇Java性能优化实战文章里最想传达的东西。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
