做Java性能优化这件事我干了快十年有个体会越来越深性能问题很少是单一原因造成的也几乎不可能靠“加内存”或者“调两个JVM参数”就彻底解决。它往往是代码写法、JVM配置、数据库设计、甚至操作系统层面一起“合谋”出来的。Java性能优化说白了就是在跟资源的浪费作斗争在有限的内存、CPU、IO里把每一分都用在刀刃上。这篇文章会分享一条从理论到实践的完整路径怎么建立指标基线、用什么工具做诊断、JVM内存和GC的核心原理、代码与数据库层面怎么做优化以及一个真实接口从1500ms优化到300ms以内的完整复盘。适合刚接触性能优化的初级开发者也适合已经在线上被各种卡顿、慢查询、Full GC折磨得焦头烂额的开发同学。我会尽量把每一步的“为什么”讲透而不是只丢给你一堆参数。1. 性能优化方法论与指标解读1.1 为什么“先测量、后优化、再验证”是铁律很多刚入行的同学拿到一个“系统很慢”的反馈第一反应就是改代码、调参数、换中间件。我见过最夸张的一次某团队为了优化一个接口直接把Redis引入了项目结果问题不但没解决反而多了缓存一致性的新麻烦。事后定位才发现真正的瓶颈是数据库连接池配得太小连Redis都没必要。这个案例给我们的教训就是性能优化必须先测量再动手。测量的意义在于把模糊的“慢”变成具体的数字。你至少要搞清楚这几个指标响应时间RT单个请求从发起到返回的耗时。要注意的是平均值并没有太大参考价值因为被极端值拉高的情况很常见。我们真正要关注的是P99、P95这类百分位延迟意思是99%或95%的请求都在多少毫秒以内。吞吐量一般用QPS每秒查询数或TPS每秒事务数来衡量。系统到底能扛多少并发这个数字最直接。资源占用率CPU使用率、内存占用、IO等待、网络带宽。这一步是为了搞清楚瓶颈到底卡在哪个资源上。CPU打满和磁盘IO打满优化方向是完全不同的。GC指标Young GC频率、Full GC频率、单次停顿时间、堆内存分配速率。Java应用如果这一块有问题再好的业务代码也会被拖垮。优化本身还要讲究顺序。我习惯用“三层模型”来界定问题范围代码层业务逻辑、算法、数据结构、JVM层内存分配、GC、类加载、架构系统层线程池、连接池、缓存、数据库。每一层的优化手段和成本完全不一样。我的经验是永远先做代码层排查再动JVM参数最后才考虑架构级改造。因为代码层的改动通常成本最低收益却可能最大。1.2 如何在系统上线前建立性能基线没有基线就没有对比也就谈不上优化。你连“现在到底有多慢”都不知道那“优化后有多快”就变成一个没法回答的问题。建立基线的方法很朴素选择一个和生产配置接近的环境用压测工具打流量记录一组稳定的数据。我推荐用wrk或者JMeter稍微熟练一点的话wrk更加轻量适合单接口压测JMeter适合复杂场景编排。压测过程中有几个细节很容易被忽视环境隔离压测环境一定要和生产环境完全隔离包括数据库、Redis、MQ等外部依赖。我见过有人压测时把测试环境的库和生产环境共用一个Redis结果压完发现测试流量把生产缓存全部打失效了场面相当狼狈。压测时长要够不要只压30秒至少要持续5到10分钟才能观察到JVM内存增长趋势和GC频率的变化。很多内存泄漏问题短时间压测根本看不出来。记录基线数据至少在压测脚本里把QPS、RT、P99、CPU使用率、堆内存使用率、GC日志这些数据完整记录下来作为后续所有优化的对照基准。这里多说一句性能优化是一个循序渐进的过程核心是每次改动只改变一个变量。如果你一口气改了SQL、JVM参数、连接池和代码结构结果变快了你根本不知道是哪个改动起了作用。下次出问题你又得从头排查。2. 性能分析工具链选型与使用技巧2.1 JDK自带工具jstat、jmap、jstack、jcmdJDK自带了一整套诊断工具很多老开发可能觉得它们过时了但我认为它们依然是线上问题排查的第一道防线因为这些工具在所有JDK版本里都能用不需要额外安装。jstat是查看JVM统计信息的神器尤其是GC和堆内存使用情况。我最常用的命令是jstat -gcutil pid 1000 20这个命令的意思是每秒输出一次GC相关信息连续输出20次。你会看到类似这样的输出S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 93.72 28.86 57.02 95.33 92.75 1823 12.341 4 1.352 13.693重点看YGC年轻代GC次数、YGCT年轻代GC总耗时、FGCFull GC次数和FGCTFull GC总耗时。如果FGC持续上涨那堆内存里大概率有什么东西一直没能回收必须赶紧处理。jmap用来生成堆转储快照。当怀疑内存泄漏时可以先看堆内存摘要jmap -heap pid如果确认堆里有个大对象或者异常的对象集合可以导出完整堆转储文件再拿到MATMemory Analyzer Tool里分析jmap -dump:live,formatb,fileheap.hprof pid这里要特别提个醒线上环境执行 jmap 之前一定要评估对业务的影响。尤其是 -dump 会把整个堆导出哪怕加了live参数也可能会触发一次Full GC接口就会突然变慢。如果是核心业务系统建议先降一小部分流量再执行。jstack用来输出线程快照。CPU飙高、线程死锁这类问题第一反应就是执行jstack pid thread_dump.txt拿到线程快照后重点搜索这些状态RUNNABLE、BLOCKED、WAITING看哪个线程长时间卡在某种状态。遇到死循环或者锁竞争线程栈能直接告诉你罪魁祸首在哪个类的哪一行代码。jcmd是JDK 8之后开始提供的一个综合诊断命令功能更全面比如查看系统属性、VM参数、堆信息、GC信息等。在较新的JDK上我一般优先用 jcmd 替代部分 jstack/jmap 的职责。2.2 更优雅的选择JFR、Async Profiler、ArthasJDK自带工具虽然基础好用但很多场景下还不够。这里推荐三个我日常工作包里常备的工具它们各有侧重。JFRJava Flight Recorder是JDK 11及以上版本自带的低开销采样分析工具开销通常可以控制在2%以内所以可以放心开在生产上。启动时开启java -XX:StartFlightRecordingduration10m,filenamerecording.jfr -jar yourapp.jar分析时直接用JDK自带的JMCJava Mission Control打开 .jfr 文件里面有非常详细的分配速率、GC停顿、锁竞争、IO耗时等数据。我最常用的场景就是压测的同时开启JFR跑完以后直接看“内存分配热点”哪里创建了大量对象一目了然。Async Profiler是一个采样性能分析器最擅长生成CPU火焰图。它基于异步采样的原理不需要对代码做任何侵入式的埋点。./profiler.sh -d 60 -f flamegraph.html pid运行60秒后会生成一个HTML格式的火焰图在浏览器里打开。火焰图的好处是最宽的那个“火焰”一眼就能看出来哪段代码消耗的CPU最高。我在下面要讲的实战案例里定位大字符串处理耗时靠的就是火焰图。Arthas是阿里的开源Java诊断工具在线上排查时尤其好用不需要重启应用不需要改代码。常用命令比如dashboard实时查看线程、内存、GC、CPU使用状态。watch观察方法的入参和返回值。trace查看方法内部每行代码的调用耗时。thread -n 3定位CPU占用最高的前三个线程自动输出线程栈。Arthas 还有一个特别好用的点动态反编译。当你怀疑线上代码和实际运行版本不一致时可以用jad命令反编译class文件对照一下行号和逻辑很快就知道是不是发布出问题了。3. JVM内存与GC核心优化手段3.1 理解堆内存结构和GC工作原理避免瞎调参数JVM性能优化绕不开的一个话题就是GC垃圾回收。我见过很多人一上来就问“我的JVM参数应该怎么调”这其实是个没前提的问题。调参之前你必须先理解JVM堆内存的布局和GC的基本运作方式。Java堆内存分成两大块年轻代Young Generation包括Eden区和两个Survivor区S0和S1。新建的对象基本都分配在Eden区经过几次Minor GC后仍然存活的对象会被提升到年老代。年轻代的GC叫Minor GC频率高但速度快因为大部分对象都活不过第一轮就被回收了。年老代Old Generation存放长期存活的大对象和多次GC后仍然存活的对象。当年老代满了就会触发Major GC或Full GC停顿时间长对业务影响大。GC收集器的选择也要看场景。现在JDK 8默认的Parallel GC适合追求高吞吐量的场景CMS适合低停顿场景但因为碎片和CPU开销问题JDK 9之后已经逐步淘汰G1是JDK 11及以后的主流默认选择在可控停顿时间和吞吐量之间取得了平衡ZGC和Shenandoah可以在超大堆和极低停顿场景下发挥作用但内存开销更大。读GC日志是每天的必修课。开启GC日志的方式java -Xlog:gc*:filegc.log:time,uptime,level,tags -jar yourapp.jar日志中你会看到类似这样的信息[GC pause (G1 Evacuation Pause) (young), 0.0123456 secs] [Eden: 1024.0M(1024.0M)-0.0B(1024.0M) Survivors: 2048.0K-2048.0K Heap: 1536.0M(4096.0M)-512.0M(4096.0M)]如果单次停顿时间经常超过200ms甚至500ms就必须引起重视了。线上业务如果对延迟敏感每个GC停顿都是用户可感知的卡顿。3.2 一套可复用的GC调优步骤GC调参的原则是先用代码和堆分析定位问题再调整参数验证而不是一堆参数堆上去看运气。第一步先看GC日志确认瓶颈类型Young GC太频繁说明Eden区太小或者对象分配速率过高。Full GC频繁说明年老代持续增长通常有两种情况——真正有大量存活对象或者内存泄漏再有可能是对象过早晋升。GC停顿时间过长说明堆太大或者GC收集器配置不当。第二步决定调整方向。-Xms和-Xmx建议设置为相同的值避免扩容时触发堆重新分配带来的抖动和Full GC。比如说生产环境给4G堆那就-Xms4g -Xmx4g。Eden区太小导致的频繁Young GC可以适当增大年轻代比如通过-Xmn设置年轻代大小或者调整-XX:NewRatio默认是2即年老代占堆的2/3。如果希望年轻代更宽可以调成1。G1收集器引入了一个更直观的参数-XX:MaxGCPauseMillis。比如你设置-XX:MaxGCPauseMillis100G1会尽量控制GC停顿在100ms以内它会动态调整年轻代大小来平衡吞吐量和停顿时间。第三步也是很多文章不会告诉你的一点每次调整后重新做一次和基线完全相同的压测对比所有指标。如果GC停顿降了但吞吐量掉了20%这个优化就不一定是成功的。GC参数永远是为业务目标服务的业务目标一般是“在满足RT要求的前提下最大化吞吐量”。调参过程中还有个小技巧我实测很管用用-XX:PrintGCApplicationStoppedTime把应用暂停时间单独打印出来你会看到很多你以为“GC停顿不多”的系统实际上在安全点Safe Point上卡了很久。比如某个应用开启了GC日志的高频采集导致每次RLTVM safe point同步都很慢这个坑我曾经查了一整天才定位到。4. 代码级优化与数据库性能实战4.1 最容易踩坑的代码级性能陷阱性能优化做到最后你会发现大部分问题并不是JVM参数没调好而是代码写得不够好。这里梳理几个我经手项目中反复出现的代码级问题。字符串拼接。很多人图方便在循环里直接写str value。Java在字符串拼接上有一个隐性代价每次都会创建一个新的StringBuilder对象然后做数组拷贝。循环数量一多大量短时间内释放的对象就会导致Young GC飙升。正确做法是循环外创建StringBuilder循环内append最后toString。StringBuilder sb new StringBuilder(1024); for (String item : list) { sb.append(item).append(,); } String result sb.toString();如果提前能估算拼接长度记得给new StringBuilder(1024)一个初始容量减少扩容时的数组拷贝。这一点常常被忽略。正则表达式滥用。正则表达式的编译成本比大多数人想象的高得多。一个Pattern.compile([a-z]\\d{4})如果放在方法内部每次循环执行性能损耗会非常明显。一定要把Pattern定义成静态常量或缓存起来只做matcher.matches()操作。集合初始容量。HashMap默认初始容量16超过阈值会扩容重hash这一步在大数据量场景下极其消耗CPU。如果能够估算元素数量尽量在初始化时指定容量比如new HashMap(1024)。ArrayList同理。循环内做远程调用或者数据库查询。这个问题在业务代码里最常见。一个循环里逐个查询数据库100条数据就有100次网络往返。我一直推荐的方案是循环外批量取回数据内存中建立映射关系。举一个最典型的例子订单列表接口需要关联查询用户信息如果每条订单都去查一次用户表这接口不可能快把用户ID集合收集起来一次WHERE id IN (...)批量查回来再放到Map里做关联性能能提升几个数量级。锁粒度过大。锁是Java并发里性能损耗的一大来源。有人为了解决并发问题直接在方法上加synchronized结果所有调用都变成串行了。优化的方向是缩小锁范围、使用读写锁或乐观锁、甚至用LongAdder替代AtomicLong来减少CAS竞争。我调过最夸张的一例只是把synchronized从方法级别缩小到代码块级别接口QPS直接翻了三倍。4.2 数据库慢查询与连接池优化实战数据库层面更是性能问题的高发区而且常常和Java本身的问题互相叠加。先说慢查询。MySQL的慢查询日志要开启起来。定位到慢SQL时第一件事不是去改SQL而是看执行计划EXPLAIN SELECT * FROM order_table WHERE user_id 12345 ORDER BY create_time DESC LIMIT 20;执行计划里重点看几个字段type全表扫描是ALL索引查询是range或ref、key实际用到的索引、rows预估扫描行数。如果rows是几十万上百万那这SQL怎么优化都白搭大概率是索引没建对或者没走索引。一个非常典型的问题深分页。前端慢慢往后翻页LIMIT 100000, 20这样的SQLMySQL需要先读取100020行再丢掉前10万行越往后越慢。换成游标分页或者基于上次查询的最大ID来翻页性能会好很多SELECT * FROM order_table WHERE id 100000 ORDER BY id LIMIT 20;这个改写思路我强烈建议用在所有分页查询上尤其是数据量达到几十万上百万之后效果立竿见影。连接池方面HikariCP现在是Spring Boot默认连接池它本身的性能已经非常好但配置不对还是会有问题。我推荐一套起步配置spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 max-lifetime: 1800000 idle-timeout: 600000maximum-pool-size不是越大越好。连接数一多数据库端需要维护的线程和内存也变多反而拖垮数据库。更关键的是连接池大小必须跟你的线程池大小、以及数据库的CPU核数相匹配。一个粗略的经验公式连接数 ((核心线程数 * (单请求耗时ms 连接获取耗时ms)) / 1000)。这个公式告诉我们单次查询耗时越长需要的连接数越多但如果查询很快连接数反而可以少一些。我踩过这样一个坑某服务线程池核心线程数是200连接池最大连接数却设置成了10结果压测时大量线程都在排队等连接最终吞吐量上不去CPU只用了20%。那时候怎么都没想到是连接池不够以为是服务线程池没调好白白浪费了一整天。后来想通了线程池和连接池要针对同一个压测场景去梳理排队关系整个链路才能畅通。5. 实战案例一次订单列表接口从1500ms到300ms的完整优化5.1 问题背景与压测数据前面说了那么多理论和方法这里用一个实际的案例串起来你就知道一条完整的优化路径长什么样了。当时的情况是一个电商项目的订单列表接口每次翻页都很慢用户在高峰期经常要转好一会儿圈。线上监控显示P99大约1500msP50大约是400ms。这意味着每100个请求里有1个要等1.5秒以上对用户体验是致命的。我接手后的第一步不是直接改代码而是先拉了一组测试环境的数据。压测场景设置为200个并发线程持续压测5分钟目标是把P99优化到300ms以内同时QPS不能低于压测前的1500。压测前的基线数据如下指标优化前数值P50400msP991500msQPS1502Young GC频率每秒6次Full GC频率每小时2次CPU平均使用率45%当时看到这个数据我基本可以判断RT的波动绝对不是GC停顿造成的Full GC一小时才两次不至于把P99拉到1500ms。根源大概率在业务代码或者SQL。但GC每秒6次这个频率也确实偏高值得关注。5.2 定位瓶颈火焰图、GC日志和SQL分析的联合诊断我先用Async Profiler采了60秒CPU火焰图。火焰图打开一看热点非常集中接近40%的CPU消耗在订单状态的字符串格式化和日期格式化上。代码里写了一大串SimpleDateFormat的反复创建和字符串拼接这在订单列表这种高频调用下就是一台无形的CPU杀手。接着看GC日志。每秒6次Young GC说明堆内存对象分配速率极高。用JFR查看分配热点后发现问题仍然指向那个字符串格式化方法——每次请求都会创建大量短生命周期对象。这就是我常说的“GC和代码层的关联”并不是GC参数错了而是代码本身在疯狂制造垃圾。最后看SQL层面。订单列表接口本来做了一次分页查询但对每一条订单又循环去查了一次订单明细表。更糟的是那个分页用了LIMIT 100000, 20这种深分页写法每次翻页都要扫描几十万行。N1查询加上深分页两个问题叠加数据库层面自然就慢了。5.3 优化动作与最终结果定位清楚后优化动作就很明确了代码层把循环内的SimpleDateFormat改成DateTimeFormatter线程安全并把格式化操作从循环体内移到批量处理中字符串拼接统一使用StringBuilder并预设容量。这两步直接把CPU火焰图里最宽的“火焰”消掉了一大截。SQL层把循环查明细的N1逻辑改写为一次批量查询再在内存中做分组关联深分页改成基于上次最大ID的游标分页写法。JVM参数层因为对象分配速率降下来了Young GC频率自然下降。再配合将-Xms和-Xmx统一设置为4GG1的目标停顿时间设置为100ms堆内存这块就不会再拖后腿。优化完成后重新跑了一遍完全相同的压测。结果如下指标优化前优化后提升幅度P50400ms180ms55%P991500ms280ms81%QPS15023644142%Young GC频率每秒6次每秒1次83%Full GC频率每小时2次每6小时1次明显改善这个案例有两点值得复盘。第一整个优化过程里我没有动任何架构只是把代码层面和SQL层面的“垃圾”清理干净收益就远超预期。第二JVM参数调整其实并不是这次优化的主角真正起作用的是定位到问题源头并解决它。加权内存的效果永远是放大器不是发动机。如果代码本身就在疯狂浪费资源给再多内存也只是放大浪费。6. 常见性能问题排查与避坑清单6.1 典型问题速查表为了方便日常排查我把这些年遇到的典型性能问题整理成了一张速查表。遇到问题时先对照这张表缩小范围会节省大量时间。症状可能的根因首选举措CPU 99%以上接口大面积超时死循环、正则回溯、频繁GC、线程池打满top -Hp定位线程jstack看线程栈内存持续上涨最终OOM内存泄漏、大对象列表、静态集合持有引用jmap -dump导出堆MAT分析支配树Full GC频繁吞吐量骤降年老代增长过快、对象过早晋升、连接缓存过大排查Eden分配速率、检查缓存是否有界接口偶尔卡顿RT抖动严重GC停顿、安全点同步、磁盘IO抖动开启GC日志查看停顿时间检查磁盘告警高并发下线程阻塞严重锁竞争、连接池不足、线程池队列过满jstack找BLOCKED线程检查连接池和线程池配置数据库CPU高但SQL简单索引失效、隐式类型转换、深分页EXPLAIN查看执行计划改写SQL一个请求处理特别慢远程调用超时、第三方依赖阻塞用Arthastrace定位耗时方法这张表只能帮你缩小范围真正的根因还是要靠测量工具逐一验证。我建议每个团队把这张表扩展成自己的线上排查SOP每次处理完问题补充一行“当时是怎么排查的”比任何内部培训都管用。6.2 我踩过的三个坑和复盘心得第一个坑压测环境跟生产环境配置不一致。有一次我压测环境用了8核16G的机器调优参数全部调好了一上生产就废了——生产只有4核8G。GC行为完全不同CPU核数对线程池并发度的影响也很大。所以后来我养成了一个习惯压测环境至少CPU核数和内存大小要跟生产对齐否则结论完全不成立。第二个坑一上来就调GC参数。早期做优化我总觉得JVM调参是最“高级”的事情结果参数调了一大堆收益微乎其微。后来才明白GC参数只是事后兜底的工具。代码里每秒钟创建几万个临时对象你再怎么调堆也是白搭。现在我的原则是优先扫代码其次看SQL最后才是JVM。顺序反了就是在绕远路。第三个坑只看平均RT忽略P99和GC日志。平均RT这个指标太有迷惑性了被大多数人忽视的“长尾延迟”才是体验杀手。有一次平均RT存从300ms降到了200ms我以为优化完了结果一查P99反而涨了两倍。原因是我优化了业务代码但GC停顿变得更加集中极端情况反而恶化了。所以每个优化动作之后必须同时看均值、百分位和GC日志缺一个都容易误判。最后分享一个我一直在用的复盘习惯每次性能优化都开一个独立的文档记录以下内容——问题描述、压测数据、火焰图/GC日志截图、优化动作、最终结果。坚持半年下来你会形成一张独属于自己的“性能优化地图”下次再遇到同类问题可能连工具都不用重开一眼就能锁定方向。这大概就是做性能优化最有意思的地方它不是在跟技术较劲而是在跟自己的惯性思维较劲每一次突破都意味着你对系统的理解又深了一层。