1. 性能问题的认知框架先定位再优化别一上来就调JVM参数做Java性能优化这些年我最深的体会是大部分性能事故不是被优化解决的而是被正确归因解决的。很多同学遇到线上接口变慢第一反应是打开搜索引擎查JVM调优参数把堆内存调大、换G1收集器折腾一通后问题依旧。原因很简单——整个排查链路从一开始就偏了。性能优化应该是一条单向链路先确认现象再缩小范围再定位瓶颈最后才动手改。跳过前面的步骤直接动手等于闭着眼睛修车。这个认知框架我总结成四步几乎适用于所有Java应用的性能问题确定瓶颈类别问题出在CPU、内存、磁盘IO、网络IO、锁竞争还是数据库锁定热点区域用工具找到具体的线程、方法、对象或SQL。理解根因机制为什么这里会成为瓶颈背后是哪一层机制造成的针对性优化基于根因做最小改动并验证效果。为什么顺序这么重要因为不同类别的瓶颈解决方案可能是完全相反的。CPU密集型的瓶颈去扩内存没用内存泄漏导致的频繁Full GC去加CPU核心数也没用。有一回我接手一个订单导出接口的性能问题日志显示每次导出耗时接近15秒。前一位同学看线程池配置不高把核心线程数从10调到了50结果耗时没降反升——因为排查后发现瓶颈在数据库查询上50个线程同时压向一个慢SQL数据库直接成了更大的瓶颈。这就是典型的没定位就优化引发的次生灾害。那怎么判断瓶颈类别呢我习惯先看四个基础指标指标查询命令典型症状CPU使用率top/mpstat持续超过70%以上或频繁打满内存使用free -g/jmap -heapGC频繁、OOM、堆外内存增长磁盘IOiostat -x 1await高、util接近100%网络IOsar -n DEV 1rx/tx吞吐异常重传率高这四个指标查完基本能锁定问题的大方向。性能优化的第一原则不是优化而是测量——数据永远先于直觉。1.1 Java应用性能分析的完整排查链路结合经验我把Java应用从发现慢到找到根因的链路拆成五步每一步都有对应的工具和产出**第一步确认瓶颈是Java进程内部还是外部依赖。**用top -Hp pid看Java进程的线程级CPU消耗。如果是Java线程高问题大概率在应用内部如果是mysqld或者Redis等其他进程高问题就在外部依赖。这一步很多人忽略导致在后端应用里排查了半天最后发现是数据库慢查询引发的级联阻塞。**第二步抓线程栈看线程在干什么。**用jstack pid连续抓3到5次间隔5到10秒。看线程状态分布大量RUNNABLE说明CPU密集大量BLOCKED说明锁竞争大量WAITING说明线程池或异步任务堵住了。特别注意jstack抓取时机——最好在问题发生时连续抓多次单次快照很容易漏掉瞬时状态。**第三步看内存与GC情况。**用jstat -gcutil pid 1000每秒钟输出一次GC状态观察FGCFull GC次数和FGCTFull GC耗时是否持续增长。如果Full GC频繁且耗时长基本可以断定内存有问题需要进一步用jmap -dump导出堆快照做分析。**第四步分析堆快照。**用MAT或JProfiler打开dump文件按保留堆大小排序一眼就能看出哪些对象占用了大量内存。特别关注两个问题哪些对象数量异常庞大哪些对象被某个长生命周期对象持有导致无法回收。**第五步验证假设小步改动。**每次只改一个参数或一段代码改完压测或观察线上指标确认有效后再继续下一步。切忌一次改动多个变量——出了问题你根本不知道是哪个改动引起的。1.2 瓶颈类别的快速区分CPU、内存、IO还是锁这里有一个判断技巧纯靠现象就能做初步分流接口响应慢但CPU和内存都正常优先怀疑外部IO比如数据库查询、Redis操作、HTTP调用。用arthas trace追踪一次完整调用的时间分布立竿见影。CPU持续打满接口吞吐下降优先怀疑热点方法、死循环、正则回溯或者无意识的序列化开销。用arthas profiler或者async-profiler抓CPU火焰图。GC频繁但CPU不高优先怀疑堆配置不合理、对象分配速率过高或者内存泄漏。用jstat堆dump分析。线程大量BLOCKED或WAITING优先怀疑锁竞争、数据库连接池耗尽、线程池队列堆积。用jstack看线程栈找到锁的持有者。这套判断逻辑我用了很久准确率很高。核心思维是性能瓶颈一定落在某个具体资源上先问哪个资源被耗尽了再问为什么被耗尽。2. JVM内存模型与对象生命周期年轻代、老年代和元空间在博弈什么理解了排查链路第二件事就是理解JVM的内存机制。这不是为了背书面试题而是因为Java性能问题中内存相关的占比可能超过一半。OOM、Full GC频繁、GC停顿时间长这类问题占了线上故障的很大比例。JVM内存整体分为三大块堆内存Heap、非堆内存Non-Heap和直接内存Direct Memory。堆内存是我们平时说的Java堆细分成年轻代Eden区、两个Survivor区和老年代非堆内存包含元空间Metaspace、线程栈、JIT代码缓存等直接内存是ByteBuffer.allocateDirect分配的内存不受堆大小限制受物理内存限制。这个划分不是拍脑袋设计的。大部分Java对象朝生暮死——创建后很快就不再被引用。把所有对象丢进一个大块内存里回收每次GC都要扫描整个堆效率极低。分代设计就是基于绝大多数对象生命周期极短这个统计规律把对象按年龄分区存放对不同区域采用不同的回收策略。2.1 对象晋升机制为什么Survivor区不宜过大也不宜过小对象从创建到进入老年代走的路径大致是先在Eden区分配Minor GC时存活的对象移入Survivor区每经历一次Minor GC存活下来年龄加一直到达到-XX:MaxTenuringThreshold默认15晋升到老年代。另有动态年龄判定——如果Survivor区中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于等于该值的对象直接晋升无需等到15岁。这里有一个常见的错误调优把年轻代调得非常大认为对象不容易晋升到老年代Full GC就会减少。但年轻代过大有两个副作用每次Minor GC的扫描时间变长GC停顿随之增加晋升阈值对应的年龄是经历过的Minor GC次数年轻代越大Minor GC越少对象反而会更晚晋升老年代接收的晚熟对象数量未必减少。按业界经验年轻代大小一般占堆的1/3到1/2Survivor区大小通过-XX:SurvivorRatio8来设定Eden:Survivor8:1:1。但这不是标准答案具体要看应用的对象分配速率和存活率。如果你的服务对象分配速率极高、存活率极低可以适当扩大Eden如果对象存活率偏高扩大Survivor区减少晋升流失。2.2 从GC日志反推内存水位读懂现象背后的原因排查内存问题第一件事不是改参数而是看GC日志。线上环境务必开启GC日志成本极低收益极高。推荐的JVM启动参数组合是-Xlog:gc*:file/data/logs/gc.log:time,uptime,level,tags:filecount5,filesize20m这是JDK 8及以上的格式JDK 8用-Xloggc:/data/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps也可。然后配合jstat -gcutil实时观察。看GC日志时我重点盯着三个值Young GC频率如果几秒钟就一次说明对象分配速率太高Eden区太小被频繁打满。Full GC频率如果几分钟一次甚至更频繁说明老年代快速增长要么是对象分配速率过高导致过早晋升要么是存在内存泄漏。GC停顿时间如果Young GC几十毫秒、Full GC几秒这个停顿对高并发接口就是灾难。举一个典型的案例有一个报表服务每次生成报表需要大批量读取数据并组装对象上线后频繁Full GC每次停顿2到3秒接口大量超时。用jmap -dump导出堆快照分析后发现ArrayList实例数量巨大里面存的数据对象体积也大且被一个全局静态缓存持有无法回收。根因是生成报表时把中间结果全部缓存到静态Map里报表数据量太大直接撑爆了老年代。优化方案不是调大堆——那只是推迟爆炸时间——而是改掉缓存策略中间数据改为局部变量计算完成后立即释放必须缓存的数据用软引用SoftReference。改动后Full GC从每10分钟一次降到每6小时一次停顿时间降到了300毫秒以内。注意堆内存调大是治标不治本。绝大多数内存不够用的问题根因是代码让对象活得太久或分配得太快。先找根因再决定要不要调参。3. 垃圾回收器选型与核心参数G1和ZGC不是银弹垃圾回收器是Java性能优化的另一个焦点。每次谈到GC选型总有人默认G1一定比CMS好ZGC一定比G1好这个误区我解释过很多次。选型要看业务场景的吞吐量需求和延迟敏感度不是越新的GC越好。3.1 主流GC的适用场景对比GC回收器核心设计目标适用场景典型停顿时间Serial / Parallel吞吐量优先批处理、离线计算秒级CMS低延迟优先传统互联网后端数十到数百毫秒G1可预测停顿中大型堆、互联网后端10~200毫秒ZGC超低延迟超大堆、低延迟服务1~10毫秒Shenandoah超低延迟与ZGC竞争优势是与JDK版本解耦1~10毫秒Parallel GC的吞吐量其实在多数场景下是最高的因为它牺牲了单次停顿时间换取整体吞吐。如果你的业务对偶尔几秒的停顿不敏感比如离线统计、批量任务Parallel GC可能比G1更合适。G1的价值在于把停顿时间控制在可预期的范围内适合在线接口服务。ZGC适合堆非常大几十GB以上且必须毫秒级响应的场景。有一个值得记住的案例某支付系统的交易接口堆内存配置了8GB之前用CMS频繁促销时Full GC停顿高达2秒导致下游超时。切换到G1后通过-XX:MaxGCPauseMillis100设置目标停顿配合-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent控制年轻代比例停顿控制在了80毫秒以内。但换到另一个批处理服务后G1反而比Parallel多花了15%的运行时间——因为G1需要维护RSet等额外数据结构对弱引用的处理也复杂纯吞吐场景并不占优。3.2 参数调优的真实逻辑先明白每个参数在调什么不少同学喜欢把G1参数调来调去什么-XX:G1HeapRegionSize、-XX:InitiatingHeapOccupancyPercent改来改去结果GC表现更差了。核心问题在于没弄明白参数的作用机制。先明确-XX:MaxGCPauseMillis这个参数它只是G1软性目标不是硬性保证。G1通过调整年轻代大小来尽量满足停顿目标但如果对象分配速率极高年轻代只能缩得很小Minor GC频率疯狂上升反而导致吞吐量大幅下跌。我见过有人把停顿目标设成10毫秒结果Young GC每次都触发CPU全耗在GC上。-XX:InitiatingHeapOccupancyPercentIHOP是更关键的参数默认45表示当老年代使用率达到45%时开始并发标记周期。调低会让G1更早开始标记减少了因老年代空间不足引发Full GC的风险但标记本身有CPU开销过早触发反而拖累吞吐。调高意味着推迟标记老年代空间利用率更高但如果标记来不及完成而老年代又满了就会退化成Full GC。调优的核心方法论是从默认参数开始通过GC日志观察每次只改一个参数记录对比数据。具体到某个应用先分析对象分配速率和存活情况再决定动哪个参数。一个实用的基准步骤固定堆大小观察GC日志中的停顿时间和频率如果停顿超目标先调MaxGCPauseMillis如果GC频率过高且CPU飙升检查是否IHOP过低、年轻代过小如果对象晋升速率异常检查MaxTenuringThreshold和Survivor区大小每次调整后至少观察两小时生产流量的GC表现再做下一步。经验之谈GC参数调优有一个隐含前提——先排除代码层面的内存问题。带着内存泄漏去调GC参数就像堵漏水的水管时只加大了水压——反而喷得更厉害。4. 性能定位工具链从命令行到火焰图让数据说话工欲善其事必先利其器。性能优化的过程就是一个借助工具收集数据、验证假设的过程。我常用的工具分三梯队。4.1 第一梯队JDK自带的命令行工具这几个命令我几乎每天都会用每一个都有特定场景jps列出Java进程PID基本是所有后续命令的前置。jstat -gcutilpid1000每秒刷新GC状态看Eden/Survivor/Old区使用比例、GC次数、GC耗时。定位GC问题第一反应就是它。jstackpid抓线程快照看线程状态和栈信息。配合top -Hp可以先找到CPU最高的线程再把线程ID转十六进制在jstack里定位到对应线程。这个线程ID转十六进制的细节是很多人卡住的地方命令是printf %x 线程ID。jmap -heappid查看堆配置和当前各区域使用情况。jmap -dump 慎用线上导出大堆快照会暂停应用较长时间建议在压测环境或业务低峰期操作。jcmdJDK 8后官方推荐替代jmap的一部分功能如jcmd pid GC.heap_info比jmap -heap更安全。这一梯队是最朴素但有效的工具——不依赖任何第三方依赖生产环境开箱即用。4.2 第二梯队Arthas和async-profiler的高阶玩法Arthas是阿里开源的诊断工具线上排查问题极其方便。我用得最多的功能是trace和watch# 跟踪一个方法内部所有子调用的耗时分布 trace com.example.service.OrderService createOrder # 查看某个方法入参和返回值的详细信息 watch com.example.service.OrderService createOrder {params, returnObj} -x 3trace会输出每个子方法的耗时一眼看出耗时的大头在哪个环节——是数据库查询、Redis调用还是本地计算。这比看日志拍脑袋猜快得多。async-profiler则用来抓CPU火焰图。它的原理是用AsyncGetCallTrace接口以极低的采样开销采集Java线程的调用栈让开发者直观地看到CPU时间花在了哪个方法上。使用方式./async-profiler/profiler.sh -d 60 -o flamegraph -i 5000 pid火焰图的解读有很多细节但核心就一点看哪个函数的平顶最宽。平顶越宽说明该函数在CPU采样期间被命中的次数越多也就是这个函数消耗的CPU越多。从火焰图上我抓到过好几次让人哭笑不得的优化点——比如某个工具方法内部意外地调用了SimpleDateFormat.format做日志时间格式化一个高QPS接口里这个方法占掉了30%的CPU。4.3 第三梯队日志和监控体系是事后分析的底气线上问题不是任何时候都有机会让你现场抓数据的。多数时候问题已经发生了你只能靠采集的数据复盘。所以生产环境一定要把GC日志、慢查询日志、接口耗时日志全部打开并稳定落地。我的个人配置习惯是GC日志保留至少5个文件的滚动每个20MB覆盖最近几次Full GC周期接口层用MDC记录TraceID配合链路追踪如SkyWalking、Zipkin串起整条调用链核心服务开启HTTP请求耗时分布统计按P50/P95/P99维度观察。有了这些底数下次出性能问题第一步不是去现场抓数据而是先翻日志——很多问题在数据里已经写好了答案。5. 代码层面的热点优化高频场景逐个拆解工具定位到热点方法之后就到了动手改代码的阶段。代码层面的性能优化比很多人想象的要无聊得多——大部分优化就是三件事减少重复计算、减少对象创建、减少锁范围。5.1 字符串处理、集合选型和循环优化的具体差异先说字符串这是Java程序里最常见的对象。字符串拼接用在循环里会产生大量中间StringBuilder对象尤其在循环体内拼接每轮迭代都创建新对象。正确做法是在循环外创建StringBuilder循环内append。这一点很多人都知道但真正执行的时候还是会因为代码可读性选择直接。再一个重要的是集合选型。ArrayList和LinkedList的区别大家都知道但实际落地时经常选错。频繁在头部或中间插入删除用LinkedList但LinkedList的节点对象本身有额外内存开销且CPU缓存不友好。我倾向的默认选择是绝大多数场景ArrayList需要线程安全时用CopyOnWriteArrayList读多写少键值对用HashMap需保持插入顺序用LinkedHashMap需排序用TreeMap。还有一个容易被忽略的点是Map初始容量设置。HashMap默认初始容量16如果知道会存放很多键值对应该预先设置容量避免频繁resize。容量计算公式是期望容量 / 加载因子 1比如期望放10000个元素加载因子0.75初始容量设为10000/0.751≈13334。这个细节在高QPS接口里效果很明显因为resize是一次全量rehash大Map的rehash开销不小。循环里还有一个性能杀手在循环体内频繁调用String.split或者正则表达式匹配。每次调用Pattern.compile都会重新编译正则开销极大。正确用法是把编译好的Pattern提取成静态常量用Matcher复用。下面是一个容易被忽视的lambda性能细节——我知道网上有两种说法实际情况是这样// 这种写法每次调用都会创建一个新lambda实例 IntStream.range(0, 100000).forEach(i - process(i)); // 提取成static final的Function常量可复用同一实例 private static final IntConsumer PROCESSOR i - process(i); IntStream.range(0, 100000).forEach(PROCESSOR);lambda本身就是语法糖写起来简洁但高频路径里闭包捕获外部变量的场景会产生额外对象分配。性能敏感的高频方法里我用传统for循环或IntStream带显式实例变量的场景更多——不是为了炫技纯粹是减少不必要的对象创建。另外注意stream()和parallelStream()的使用边界。parallelStream底层是共享的ForkJoinPool默认线程数等于CPU核心数减1。多个并行流同时执行会互相争抢这个共享线程池吞吐量反而下降。我见过一个服务同时用多个parallelStream处理大数据集CPU不到30%所有任务都卡在线程池等待上。并行流的默认线程池不适合混用大量不相关的并行任务务必限制并发度。5.2 锁优化从synchronized到Lock、读写锁和无锁并发锁竞争是并发场景的经典瓶颈。优化的思路是从减少竞争到消除竞争逐层递进缩小锁粒度把锁从方法级别缩小到代码块级别或者用分段锁把一把大锁拆成多把小锁类似ConcurrentHashMap的分段设计。用读写锁替代互斥锁读多写少场景ReentrantReadWriteLock或StampedLock比synchronized吞吐量高一个量级。用并发容器替代加锁ConcurrentHashMap、CopyOnWriteArrayList在各自适用场景下远比手动加锁的HashMap/ArrayList性能好。用原子变量替代锁单纯计数、累加场景LongAdder比AtomicLong更好——它在高并发下通过分段累加减少CAS争用。这里要特别提一个经验教训不要在finally块之外手动加锁解锁要确保解锁一定执行。这不仅是正确性问题也是性能隐患——如果没有正确解锁其他线程会无限等待线上表现为接口卡死但CPU不高、线程堆积在BLOCKED状态。锁优化我建议遵循一套先评估后动刀的顺序用jstack确认线程确实大量BLOCKED在锁上分析锁的持有时间持锁时间长超过1毫秒才是问题短锁频繁竞争问题不严重根据持锁时间选择优化手段持锁时间长优先考虑无锁化或读写锁持锁时间短优先考虑缩小临界区。6. 数据库与外部IO的级联瓶颈Java应用慢常常是下游慢Java应用性能问题我粗估有超过一半的根因不在Java进程内部而在下游的数据库、Redis、HTTP服务。这就是为什么前文强调第一步要用top确认瓶颈在哪个进程——Java进程的CPU不高、内存正常但接口很慢优先怀疑IO等待。6.1 数据库慢查询的典型场景和优化手段数据库慢查询的常见场景无非这么几类缺索引、SQL写法导致索引失效、数据量太大、锁等待和死锁。排查思路首先依托慢查询日志。MySQL开启慢查询日志SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;然后EXPLAIN分析慢SQL的执行计划。看几个关键列列名关键信号typeALL表示全表扫描range/ref/eq_ref是较好的访问类型keyNULL表示未使用索引rows预估扫描行数远大于实际返回行数需要优化ExtraUsing filesort/Using temporary是排序/临时表的告警信号典型的写法类优化点避免在索引列上做函数运算比如WHERE DATE(create_time) 2024-01-01会导致索引失效应改为WHERE create_time 2024-01-01 AND create_time 2024-01-02。避免负向条件!、NOT IN、IS NOT NULL可能让索引失效具体看MySQL优化器版本和统计信息能改写的话尽量用正向条件。大查询分段处理某导出接口一次SELECT *出一万条数据服务和数据库双方都压力山大。改成游标式的分段查询每次查500条处理完再拉下一批整体耗时和峰值内存都显著下降。6.2 连接池、缓存与批量处理的组合优化数据库连接池是另一个高频瓶颈点。HikariCP是当前默认选择但参数配置有讲究maximumPoolSize不是越大越好。MySQL的默认连接数上限是1515.7后是151起应用配置的连接数远超这个值也没用还会造成数据库端线程切换开销。一般推荐CPU核心数 * 2 1这个经验值起步再根据压测结果调整。minimumIdle空闲线程保留数量。对突发流量保持少量空闲连接可以快速响应。缓存的使用是IO优化的关键手段。JVM内缓存用Caffeine功能强、体积小分布式缓存用Redis。但缓存的缓存击穿、穿透、雪崩三兄弟是必修课击穿热点key过期瞬间大量请求打穿到DB。解法是互斥锁重建缓存或逻辑过期——设置一个逻辑过期时间过期后异步重建。穿透查询一个一定不存在的key每次都打到DB。解法是缓存空值设置短过期时间或使用布隆过滤器先拦截。雪崩大量key同一时间过期。解法是过期时间加上随机值错开过期高峰。批量处理方面有一条容易踩坑的经验批量插入不要一次全量执行。比如一次插入5万条数据一次性executeBatch会让数据库端内存和事务日志压力巨大还可能触发锁等待。稳妥做法是分批次每500条一个事务提交。这个配合同步批量查询的IN分片如每次500到1000个ID整体性能提升非常明显。7. 完整案例复盘一个商品列表接口从900ms到120ms的优化过程理论知识讲了不少最后用一个完整的案例串起来。这是一个典型的先定位、再动手的优化过程希望大家能从具体操作里看到前面所有章节是如何配合使用的。7.1 现象与初步排查时间都去哪了场景一个商品列表接口服务商品搜索和分类浏览平时响应时间约300ms大促期间飙到900ms以上P99甚至超过2秒。业务方反馈页面转圈圈。我的排查链路确认瓶颈位置top查看Java进程CPU约40%不算高mysqld的CPU也约30%但iowait接近20%。怀疑数据库IO压力大。看GC状态jstat -gcutil显示Old区使用率平稳Full GC约10分钟一次每次200ms左右。GC不是主要瓶颈。看线程栈jstack抓了3次大量线程处于TIMED_WAITING细看栈信息基本都阻塞在数据库查询的socket读上。确认瓶颈在数据库查询环节。开慢查询日志发现多条耗时超过1秒的SQL全部是商品列表查询。EXPLAIN显示type列是ALL——全表扫描。根因初现商品表数据量已经超过500万行列表查询的过滤条件有两个——分类ID和上架状态但索引只有主键和分类ID单列索引。由于查询时还按价格排序ORDER BY price需要额外排序文件排序Using filesort加剧了耗时。7.2 根因验证与针对性优化优化分三步走**第一步索引优化。**建立复合索引(category_id, status, price)让索引同时覆盖过滤条件和排序字段。为什么顺序是这样因为查询条件里category_id是等值匹配、status也可能是等值条件前端经常要过滤上架状态、price是排序字段。等值匹配的列放前面排序字段放后面正好命中索引的最左前缀原则和覆盖索引能力。这个改动后同样的SQL扫描行数从500万降到了几千耗时从1秒多降到30毫秒以内。ALTER TABLE product ADD INDEX idx_category_status_price (category_id, status, price);**第二步数据访问层优化。**原代码里列表接口在循环内逐条查询商品库存和优惠信息形成N1问题。改成用一个IN查询批量拉取相关数据再用Map做内存关联。这一步把数据库往返次数从1 N降到了1 3。**第三步增加本地缓存。**商品列表的基础数据商品名、主图、价格变化频率低、读取频率高非常适合Caffeine本地缓存。缓存key设计为categoryId:pageNo:pageSize设置过期时间5分钟加上随机抖动防止雪崩。改造后大部分请求不再打到数据库。每一轮改动后我都用arthas trace验证耗时分布逐步确认优化生效。7.3 优化效果与经验沉淀改造完成后的数据对比指标优化前优化后变化P50响应时间300ms120ms下降60%P99响应时间2s380ms下降80%数据库QPS约800约200下降75%慢查询数数十次/分钟基本为0-这次案例最大的收获不是那几步改动本身而是整个过程中没有一步是拍脑袋优化。从top确认瓶颈在MySQL到慢查询日志找到具体SQL再到EXPLAIN确认索引问题再到改索引、改代码、加缓存每一步都有数据支撑。按我个人经验做Java性能优化最忌知道很多优化技巧但不知道什么时候用哪个。技巧是死的排查逻辑是活的。先定位再优化每改一步验证一步——这套方法我用了多年几乎没失手。最后提醒一句性能优化做完了不是终点把GC日志、慢查询日志、监控指标这些底数留下来下一次出问题你才能快速进入状态。
1. 性能问题的认知框架先定位再优化别一上来就调JVM参数做Java性能优化这些年我最深的体会是大部分性能事故不是被优化解决的而是被正确归因解决的。很多同学遇到线上接口变慢第一反应是打开搜索引擎查JVM调优参数把堆内存调大、换G1收集器折腾一通后问题依旧。原因很简单——整个排查链路从一开始就偏了。性能优化应该是一条单向链路先确认现象再缩小范围再定位瓶颈最后才动手改。跳过前面的步骤直接动手等于闭着眼睛修车。这个认知框架我总结成四步几乎适用于所有Java应用的性能问题确定瓶颈类别问题出在CPU、内存、磁盘IO、网络IO、锁竞争还是数据库锁定热点区域用工具找到具体的线程、方法、对象或SQL。理解根因机制为什么这里会成为瓶颈背后是哪一层机制造成的针对性优化基于根因做最小改动并验证效果。为什么顺序这么重要因为不同类别的瓶颈解决方案可能是完全相反的。CPU密集型的瓶颈去扩内存没用内存泄漏导致的频繁Full GC去加CPU核心数也没用。有一回我接手一个订单导出接口的性能问题日志显示每次导出耗时接近15秒。前一位同学看线程池配置不高把核心线程数从10调到了50结果耗时没降反升——因为排查后发现瓶颈在数据库查询上50个线程同时压向一个慢SQL数据库直接成了更大的瓶颈。这就是典型的没定位就优化引发的次生灾害。那怎么判断瓶颈类别呢我习惯先看四个基础指标指标查询命令典型症状CPU使用率top/mpstat持续超过70%以上或频繁打满内存使用free -g/jmap -heapGC频繁、OOM、堆外内存增长磁盘IOiostat -x 1await高、util接近100%网络IOsar -n DEV 1rx/tx吞吐异常重传率高这四个指标查完基本能锁定问题的大方向。性能优化的第一原则不是优化而是测量——数据永远先于直觉。1.1 Java应用性能分析的完整排查链路结合经验我把Java应用从发现慢到找到根因的链路拆成五步每一步都有对应的工具和产出**第一步确认瓶颈是Java进程内部还是外部依赖。**用top -Hp pid看Java进程的线程级CPU消耗。如果是Java线程高问题大概率在应用内部如果是mysqld或者Redis等其他进程高问题就在外部依赖。这一步很多人忽略导致在后端应用里排查了半天最后发现是数据库慢查询引发的级联阻塞。**第二步抓线程栈看线程在干什么。**用jstack pid连续抓3到5次间隔5到10秒。看线程状态分布大量RUNNABLE说明CPU密集大量BLOCKED说明锁竞争大量WAITING说明线程池或异步任务堵住了。特别注意jstack抓取时机——最好在问题发生时连续抓多次单次快照很容易漏掉瞬时状态。**第三步看内存与GC情况。**用jstat -gcutil pid 1000每秒钟输出一次GC状态观察FGCFull GC次数和FGCTFull GC耗时是否持续增长。如果Full GC频繁且耗时长基本可以断定内存有问题需要进一步用jmap -dump导出堆快照做分析。**第四步分析堆快照。**用MAT或JProfiler打开dump文件按保留堆大小排序一眼就能看出哪些对象占用了大量内存。特别关注两个问题哪些对象数量异常庞大哪些对象被某个长生命周期对象持有导致无法回收。**第五步验证假设小步改动。**每次只改一个参数或一段代码改完压测或观察线上指标确认有效后再继续下一步。切忌一次改动多个变量——出了问题你根本不知道是哪个改动引起的。1.2 瓶颈类别的快速区分CPU、内存、IO还是锁这里有一个判断技巧纯靠现象就能做初步分流接口响应慢但CPU和内存都正常优先怀疑外部IO比如数据库查询、Redis操作、HTTP调用。用arthas trace追踪一次完整调用的时间分布立竿见影。CPU持续打满接口吞吐下降优先怀疑热点方法、死循环、正则回溯或者无意识的序列化开销。用arthas profiler或者async-profiler抓CPU火焰图。GC频繁但CPU不高优先怀疑堆配置不合理、对象分配速率过高或者内存泄漏。用jstat堆dump分析。线程大量BLOCKED或WAITING优先怀疑锁竞争、数据库连接池耗尽、线程池队列堆积。用jstack看线程栈找到锁的持有者。这套判断逻辑我用了很久准确率很高。核心思维是性能瓶颈一定落在某个具体资源上先问哪个资源被耗尽了再问为什么被耗尽。2. JVM内存模型与对象生命周期年轻代、老年代和元空间在博弈什么理解了排查链路第二件事就是理解JVM的内存机制。这不是为了背书面试题而是因为Java性能问题中内存相关的占比可能超过一半。OOM、Full GC频繁、GC停顿时间长这类问题占了线上故障的很大比例。JVM内存整体分为三大块堆内存Heap、非堆内存Non-Heap和直接内存Direct Memory。堆内存是我们平时说的Java堆细分成年轻代Eden区、两个Survivor区和老年代非堆内存包含元空间Metaspace、线程栈、JIT代码缓存等直接内存是ByteBuffer.allocateDirect分配的内存不受堆大小限制受物理内存限制。这个划分不是拍脑袋设计的。大部分Java对象朝生暮死——创建后很快就不再被引用。把所有对象丢进一个大块内存里回收每次GC都要扫描整个堆效率极低。分代设计就是基于绝大多数对象生命周期极短这个统计规律把对象按年龄分区存放对不同区域采用不同的回收策略。2.1 对象晋升机制为什么Survivor区不宜过大也不宜过小对象从创建到进入老年代走的路径大致是先在Eden区分配Minor GC时存活的对象移入Survivor区每经历一次Minor GC存活下来年龄加一直到达到-XX:MaxTenuringThreshold默认15晋升到老年代。另有动态年龄判定——如果Survivor区中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于等于该值的对象直接晋升无需等到15岁。这里有一个常见的错误调优把年轻代调得非常大认为对象不容易晋升到老年代Full GC就会减少。但年轻代过大有两个副作用每次Minor GC的扫描时间变长GC停顿随之增加晋升阈值对应的年龄是经历过的Minor GC次数年轻代越大Minor GC越少对象反而会更晚晋升老年代接收的晚熟对象数量未必减少。按业界经验年轻代大小一般占堆的1/3到1/2Survivor区大小通过-XX:SurvivorRatio8来设定Eden:Survivor8:1:1。但这不是标准答案具体要看应用的对象分配速率和存活率。如果你的服务对象分配速率极高、存活率极低可以适当扩大Eden如果对象存活率偏高扩大Survivor区减少晋升流失。2.2 从GC日志反推内存水位读懂现象背后的原因排查内存问题第一件事不是改参数而是看GC日志。线上环境务必开启GC日志成本极低收益极高。推荐的JVM启动参数组合是-Xlog:gc*:file/data/logs/gc.log:time,uptime,level,tags:filecount5,filesize20m这是JDK 8及以上的格式JDK 8用-Xloggc:/data/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps也可。然后配合jstat -gcutil实时观察。看GC日志时我重点盯着三个值Young GC频率如果几秒钟就一次说明对象分配速率太高Eden区太小被频繁打满。Full GC频率如果几分钟一次甚至更频繁说明老年代快速增长要么是对象分配速率过高导致过早晋升要么是存在内存泄漏。GC停顿时间如果Young GC几十毫秒、Full GC几秒这个停顿对高并发接口就是灾难。举一个典型的案例有一个报表服务每次生成报表需要大批量读取数据并组装对象上线后频繁Full GC每次停顿2到3秒接口大量超时。用jmap -dump导出堆快照分析后发现ArrayList实例数量巨大里面存的数据对象体积也大且被一个全局静态缓存持有无法回收。根因是生成报表时把中间结果全部缓存到静态Map里报表数据量太大直接撑爆了老年代。优化方案不是调大堆——那只是推迟爆炸时间——而是改掉缓存策略中间数据改为局部变量计算完成后立即释放必须缓存的数据用软引用SoftReference。改动后Full GC从每10分钟一次降到每6小时一次停顿时间降到了300毫秒以内。注意堆内存调大是治标不治本。绝大多数内存不够用的问题根因是代码让对象活得太久或分配得太快。先找根因再决定要不要调参。3. 垃圾回收器选型与核心参数G1和ZGC不是银弹垃圾回收器是Java性能优化的另一个焦点。每次谈到GC选型总有人默认G1一定比CMS好ZGC一定比G1好这个误区我解释过很多次。选型要看业务场景的吞吐量需求和延迟敏感度不是越新的GC越好。3.1 主流GC的适用场景对比GC回收器核心设计目标适用场景典型停顿时间Serial / Parallel吞吐量优先批处理、离线计算秒级CMS低延迟优先传统互联网后端数十到数百毫秒G1可预测停顿中大型堆、互联网后端10~200毫秒ZGC超低延迟超大堆、低延迟服务1~10毫秒Shenandoah超低延迟与ZGC竞争优势是与JDK版本解耦1~10毫秒Parallel GC的吞吐量其实在多数场景下是最高的因为它牺牲了单次停顿时间换取整体吞吐。如果你的业务对偶尔几秒的停顿不敏感比如离线统计、批量任务Parallel GC可能比G1更合适。G1的价值在于把停顿时间控制在可预期的范围内适合在线接口服务。ZGC适合堆非常大几十GB以上且必须毫秒级响应的场景。有一个值得记住的案例某支付系统的交易接口堆内存配置了8GB之前用CMS频繁促销时Full GC停顿高达2秒导致下游超时。切换到G1后通过-XX:MaxGCPauseMillis100设置目标停顿配合-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent控制年轻代比例停顿控制在了80毫秒以内。但换到另一个批处理服务后G1反而比Parallel多花了15%的运行时间——因为G1需要维护RSet等额外数据结构对弱引用的处理也复杂纯吞吐场景并不占优。3.2 参数调优的真实逻辑先明白每个参数在调什么不少同学喜欢把G1参数调来调去什么-XX:G1HeapRegionSize、-XX:InitiatingHeapOccupancyPercent改来改去结果GC表现更差了。核心问题在于没弄明白参数的作用机制。先明确-XX:MaxGCPauseMillis这个参数它只是G1软性目标不是硬性保证。G1通过调整年轻代大小来尽量满足停顿目标但如果对象分配速率极高年轻代只能缩得很小Minor GC频率疯狂上升反而导致吞吐量大幅下跌。我见过有人把停顿目标设成10毫秒结果Young GC每次都触发CPU全耗在GC上。-XX:InitiatingHeapOccupancyPercentIHOP是更关键的参数默认45表示当老年代使用率达到45%时开始并发标记周期。调低会让G1更早开始标记减少了因老年代空间不足引发Full GC的风险但标记本身有CPU开销过早触发反而拖累吞吐。调高意味着推迟标记老年代空间利用率更高但如果标记来不及完成而老年代又满了就会退化成Full GC。调优的核心方法论是从默认参数开始通过GC日志观察每次只改一个参数记录对比数据。具体到某个应用先分析对象分配速率和存活情况再决定动哪个参数。一个实用的基准步骤固定堆大小观察GC日志中的停顿时间和频率如果停顿超目标先调MaxGCPauseMillis如果GC频率过高且CPU飙升检查是否IHOP过低、年轻代过小如果对象晋升速率异常检查MaxTenuringThreshold和Survivor区大小每次调整后至少观察两小时生产流量的GC表现再做下一步。经验之谈GC参数调优有一个隐含前提——先排除代码层面的内存问题。带着内存泄漏去调GC参数就像堵漏水的水管时只加大了水压——反而喷得更厉害。4. 性能定位工具链从命令行到火焰图让数据说话工欲善其事必先利其器。性能优化的过程就是一个借助工具收集数据、验证假设的过程。我常用的工具分三梯队。4.1 第一梯队JDK自带的命令行工具这几个命令我几乎每天都会用每一个都有特定场景jps列出Java进程PID基本是所有后续命令的前置。jstat -gcutilpid1000每秒刷新GC状态看Eden/Survivor/Old区使用比例、GC次数、GC耗时。定位GC问题第一反应就是它。jstackpid抓线程快照看线程状态和栈信息。配合top -Hp可以先找到CPU最高的线程再把线程ID转十六进制在jstack里定位到对应线程。这个线程ID转十六进制的细节是很多人卡住的地方命令是printf %x 线程ID。jmap -heappid查看堆配置和当前各区域使用情况。jmap -dump 慎用线上导出大堆快照会暂停应用较长时间建议在压测环境或业务低峰期操作。jcmdJDK 8后官方推荐替代jmap的一部分功能如jcmd pid GC.heap_info比jmap -heap更安全。这一梯队是最朴素但有效的工具——不依赖任何第三方依赖生产环境开箱即用。4.2 第二梯队Arthas和async-profiler的高阶玩法Arthas是阿里开源的诊断工具线上排查问题极其方便。我用得最多的功能是trace和watch# 跟踪一个方法内部所有子调用的耗时分布 trace com.example.service.OrderService createOrder # 查看某个方法入参和返回值的详细信息 watch com.example.service.OrderService createOrder {params, returnObj} -x 3trace会输出每个子方法的耗时一眼看出耗时的大头在哪个环节——是数据库查询、Redis调用还是本地计算。这比看日志拍脑袋猜快得多。async-profiler则用来抓CPU火焰图。它的原理是用AsyncGetCallTrace接口以极低的采样开销采集Java线程的调用栈让开发者直观地看到CPU时间花在了哪个方法上。使用方式./async-profiler/profiler.sh -d 60 -o flamegraph -i 5000 pid火焰图的解读有很多细节但核心就一点看哪个函数的平顶最宽。平顶越宽说明该函数在CPU采样期间被命中的次数越多也就是这个函数消耗的CPU越多。从火焰图上我抓到过好几次让人哭笑不得的优化点——比如某个工具方法内部意外地调用了SimpleDateFormat.format做日志时间格式化一个高QPS接口里这个方法占掉了30%的CPU。4.3 第三梯队日志和监控体系是事后分析的底气线上问题不是任何时候都有机会让你现场抓数据的。多数时候问题已经发生了你只能靠采集的数据复盘。所以生产环境一定要把GC日志、慢查询日志、接口耗时日志全部打开并稳定落地。我的个人配置习惯是GC日志保留至少5个文件的滚动每个20MB覆盖最近几次Full GC周期接口层用MDC记录TraceID配合链路追踪如SkyWalking、Zipkin串起整条调用链核心服务开启HTTP请求耗时分布统计按P50/P95/P99维度观察。有了这些底数下次出性能问题第一步不是去现场抓数据而是先翻日志——很多问题在数据里已经写好了答案。5. 代码层面的热点优化高频场景逐个拆解工具定位到热点方法之后就到了动手改代码的阶段。代码层面的性能优化比很多人想象的要无聊得多——大部分优化就是三件事减少重复计算、减少对象创建、减少锁范围。5.1 字符串处理、集合选型和循环优化的具体差异先说字符串这是Java程序里最常见的对象。字符串拼接用在循环里会产生大量中间StringBuilder对象尤其在循环体内拼接每轮迭代都创建新对象。正确做法是在循环外创建StringBuilder循环内append。这一点很多人都知道但真正执行的时候还是会因为代码可读性选择直接。再一个重要的是集合选型。ArrayList和LinkedList的区别大家都知道但实际落地时经常选错。频繁在头部或中间插入删除用LinkedList但LinkedList的节点对象本身有额外内存开销且CPU缓存不友好。我倾向的默认选择是绝大多数场景ArrayList需要线程安全时用CopyOnWriteArrayList读多写少键值对用HashMap需保持插入顺序用LinkedHashMap需排序用TreeMap。还有一个容易被忽略的点是Map初始容量设置。HashMap默认初始容量16如果知道会存放很多键值对应该预先设置容量避免频繁resize。容量计算公式是期望容量 / 加载因子 1比如期望放10000个元素加载因子0.75初始容量设为10000/0.751≈13334。这个细节在高QPS接口里效果很明显因为resize是一次全量rehash大Map的rehash开销不小。循环里还有一个性能杀手在循环体内频繁调用String.split或者正则表达式匹配。每次调用Pattern.compile都会重新编译正则开销极大。正确用法是把编译好的Pattern提取成静态常量用Matcher复用。下面是一个容易被忽视的lambda性能细节——我知道网上有两种说法实际情况是这样// 这种写法每次调用都会创建一个新lambda实例 IntStream.range(0, 100000).forEach(i - process(i)); // 提取成static final的Function常量可复用同一实例 private static final IntConsumer PROCESSOR i - process(i); IntStream.range(0, 100000).forEach(PROCESSOR);lambda本身就是语法糖写起来简洁但高频路径里闭包捕获外部变量的场景会产生额外对象分配。性能敏感的高频方法里我用传统for循环或IntStream带显式实例变量的场景更多——不是为了炫技纯粹是减少不必要的对象创建。另外注意stream()和parallelStream()的使用边界。parallelStream底层是共享的ForkJoinPool默认线程数等于CPU核心数减1。多个并行流同时执行会互相争抢这个共享线程池吞吐量反而下降。我见过一个服务同时用多个parallelStream处理大数据集CPU不到30%所有任务都卡在线程池等待上。并行流的默认线程池不适合混用大量不相关的并行任务务必限制并发度。5.2 锁优化从synchronized到Lock、读写锁和无锁并发锁竞争是并发场景的经典瓶颈。优化的思路是从减少竞争到消除竞争逐层递进缩小锁粒度把锁从方法级别缩小到代码块级别或者用分段锁把一把大锁拆成多把小锁类似ConcurrentHashMap的分段设计。用读写锁替代互斥锁读多写少场景ReentrantReadWriteLock或StampedLock比synchronized吞吐量高一个量级。用并发容器替代加锁ConcurrentHashMap、CopyOnWriteArrayList在各自适用场景下远比手动加锁的HashMap/ArrayList性能好。用原子变量替代锁单纯计数、累加场景LongAdder比AtomicLong更好——它在高并发下通过分段累加减少CAS争用。这里要特别提一个经验教训不要在finally块之外手动加锁解锁要确保解锁一定执行。这不仅是正确性问题也是性能隐患——如果没有正确解锁其他线程会无限等待线上表现为接口卡死但CPU不高、线程堆积在BLOCKED状态。锁优化我建议遵循一套先评估后动刀的顺序用jstack确认线程确实大量BLOCKED在锁上分析锁的持有时间持锁时间长超过1毫秒才是问题短锁频繁竞争问题不严重根据持锁时间选择优化手段持锁时间长优先考虑无锁化或读写锁持锁时间短优先考虑缩小临界区。6. 数据库与外部IO的级联瓶颈Java应用慢常常是下游慢Java应用性能问题我粗估有超过一半的根因不在Java进程内部而在下游的数据库、Redis、HTTP服务。这就是为什么前文强调第一步要用top确认瓶颈在哪个进程——Java进程的CPU不高、内存正常但接口很慢优先怀疑IO等待。6.1 数据库慢查询的典型场景和优化手段数据库慢查询的常见场景无非这么几类缺索引、SQL写法导致索引失效、数据量太大、锁等待和死锁。排查思路首先依托慢查询日志。MySQL开启慢查询日志SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;然后EXPLAIN分析慢SQL的执行计划。看几个关键列列名关键信号typeALL表示全表扫描range/ref/eq_ref是较好的访问类型keyNULL表示未使用索引rows预估扫描行数远大于实际返回行数需要优化ExtraUsing filesort/Using temporary是排序/临时表的告警信号典型的写法类优化点避免在索引列上做函数运算比如WHERE DATE(create_time) 2024-01-01会导致索引失效应改为WHERE create_time 2024-01-01 AND create_time 2024-01-02。避免负向条件!、NOT IN、IS NOT NULL可能让索引失效具体看MySQL优化器版本和统计信息能改写的话尽量用正向条件。大查询分段处理某导出接口一次SELECT *出一万条数据服务和数据库双方都压力山大。改成游标式的分段查询每次查500条处理完再拉下一批整体耗时和峰值内存都显著下降。6.2 连接池、缓存与批量处理的组合优化数据库连接池是另一个高频瓶颈点。HikariCP是当前默认选择但参数配置有讲究maximumPoolSize不是越大越好。MySQL的默认连接数上限是1515.7后是151起应用配置的连接数远超这个值也没用还会造成数据库端线程切换开销。一般推荐CPU核心数 * 2 1这个经验值起步再根据压测结果调整。minimumIdle空闲线程保留数量。对突发流量保持少量空闲连接可以快速响应。缓存的使用是IO优化的关键手段。JVM内缓存用Caffeine功能强、体积小分布式缓存用Redis。但缓存的缓存击穿、穿透、雪崩三兄弟是必修课击穿热点key过期瞬间大量请求打穿到DB。解法是互斥锁重建缓存或逻辑过期——设置一个逻辑过期时间过期后异步重建。穿透查询一个一定不存在的key每次都打到DB。解法是缓存空值设置短过期时间或使用布隆过滤器先拦截。雪崩大量key同一时间过期。解法是过期时间加上随机值错开过期高峰。批量处理方面有一条容易踩坑的经验批量插入不要一次全量执行。比如一次插入5万条数据一次性executeBatch会让数据库端内存和事务日志压力巨大还可能触发锁等待。稳妥做法是分批次每500条一个事务提交。这个配合同步批量查询的IN分片如每次500到1000个ID整体性能提升非常明显。7. 完整案例复盘一个商品列表接口从900ms到120ms的优化过程理论知识讲了不少最后用一个完整的案例串起来。这是一个典型的先定位、再动手的优化过程希望大家能从具体操作里看到前面所有章节是如何配合使用的。7.1 现象与初步排查时间都去哪了场景一个商品列表接口服务商品搜索和分类浏览平时响应时间约300ms大促期间飙到900ms以上P99甚至超过2秒。业务方反馈页面转圈圈。我的排查链路确认瓶颈位置top查看Java进程CPU约40%不算高mysqld的CPU也约30%但iowait接近20%。怀疑数据库IO压力大。看GC状态jstat -gcutil显示Old区使用率平稳Full GC约10分钟一次每次200ms左右。GC不是主要瓶颈。看线程栈jstack抓了3次大量线程处于TIMED_WAITING细看栈信息基本都阻塞在数据库查询的socket读上。确认瓶颈在数据库查询环节。开慢查询日志发现多条耗时超过1秒的SQL全部是商品列表查询。EXPLAIN显示type列是ALL——全表扫描。根因初现商品表数据量已经超过500万行列表查询的过滤条件有两个——分类ID和上架状态但索引只有主键和分类ID单列索引。由于查询时还按价格排序ORDER BY price需要额外排序文件排序Using filesort加剧了耗时。7.2 根因验证与针对性优化优化分三步走**第一步索引优化。**建立复合索引(category_id, status, price)让索引同时覆盖过滤条件和排序字段。为什么顺序是这样因为查询条件里category_id是等值匹配、status也可能是等值条件前端经常要过滤上架状态、price是排序字段。等值匹配的列放前面排序字段放后面正好命中索引的最左前缀原则和覆盖索引能力。这个改动后同样的SQL扫描行数从500万降到了几千耗时从1秒多降到30毫秒以内。ALTER TABLE product ADD INDEX idx_category_status_price (category_id, status, price);**第二步数据访问层优化。**原代码里列表接口在循环内逐条查询商品库存和优惠信息形成N1问题。改成用一个IN查询批量拉取相关数据再用Map做内存关联。这一步把数据库往返次数从1 N降到了1 3。**第三步增加本地缓存。**商品列表的基础数据商品名、主图、价格变化频率低、读取频率高非常适合Caffeine本地缓存。缓存key设计为categoryId:pageNo:pageSize设置过期时间5分钟加上随机抖动防止雪崩。改造后大部分请求不再打到数据库。每一轮改动后我都用arthas trace验证耗时分布逐步确认优化生效。7.3 优化效果与经验沉淀改造完成后的数据对比指标优化前优化后变化P50响应时间300ms120ms下降60%P99响应时间2s380ms下降80%数据库QPS约800约200下降75%慢查询数数十次/分钟基本为0-这次案例最大的收获不是那几步改动本身而是整个过程中没有一步是拍脑袋优化。从top确认瓶颈在MySQL到慢查询日志找到具体SQL再到EXPLAIN确认索引问题再到改索引、改代码、加缓存每一步都有数据支撑。按我个人经验做Java性能优化最忌知道很多优化技巧但不知道什么时候用哪个。技巧是死的排查逻辑是活的。先定位再优化每改一步验证一步——这套方法我用了多年几乎没失手。最后提醒一句性能优化做完了不是终点把GC日志、慢查询日志、监控指标这些底数留下来下一次出问题你才能快速进入状态。
