开头先别急着升级机器服务慢了一般不是硬件的问题我做过几年Java服务端的性能优化最深的体会是大多数人遇到线上服务变慢第一反应是加机器、加内存、改JVM参数折腾一圈发现该慢还是慢。后来我才明白性能优化不是靠拍脑袋撞运气而是一条从观测到定位、从理论到动手的完整链路——你连问题在哪都不知道调参只是给服务器挠痒痒。这篇文章就是把我在这条链路上踩过的坑、用过的工具、总结出来的方法整理成一份可以直接照着做的实战笔记。适合正在为接口响应时间发愁的后端开发也适合刚接手Java服务、想建立性能优化方法论的同学。文章会从最容易被忽略的观测体系讲起然后逐层深入代码、JVM、数据库这几个主要瓶颈点最后用一个我实际经历过的调优案例把前面的理论串起来给你一条可以完整复现的排查路径。1. 动手优化前先搭好观测体系没有数据就没有优化性能优化最大的忌讳就是凭感觉。有人看到CPU高就怀疑是代码死循环看到内存涨就觉得是泄漏看到接口慢就认定是SQL问题结果排查半天全不是那么回事。我自己的教训是一切优化动作都必须建立在一套可量化的观测数据之上你连慢在哪里都没搞清楚就谈不上怎么优化。1.1 必须盯住的核心指标不仅是RT和QPS刚开始做性能优化的人最容易盯的就两个数接口平均响应时间RT和每秒钟处理的请求数QPS。这两个指标确实重要但只盯它们远远不够因为它们只是结果不是过程。结果变差了你需要过程指标来判断到底哪一环节出了问题。我一般会把指标分成三层来看第一层是业务层指标也就是用户能感知的RT、成功率、QPS、在线人数。这一层反映的是服务到底行不行。第二层是系统层指标CPU使用率、内存使用率、磁盘IO和网络IO。这一层反映的是机器到底扛不扛得住。注意CPU还要拆分用户态和内核态用户态高说明在跑业务代码内核态高说明系统调用频繁或者上下文切换太多。第三层是Java应用层指标也是很多人最容易忽略的GC频率和停顿时间、线程池活跃度、活跃线程数、锁等待次数、连接池使用率、请求队列堆积情况。这一层才是定位Java服务性能问题的关键入口。举个最简单的例子接口变慢了如果你只看RT和QPS你只知道慢了但如果同时看一眼GC日志发现每秒都在Young GC、每几分钟就来一次Full GC那问题方向立刻就清晰了——很大概率是堆内存配置不合理或者对象分配太频繁跟接口代码本身的执行效率关系不大。所以我会建议所有做性能优化的同学先上监控再谈优化。哪怕是最简单的方案——Prometheus配合Grafana做一个监控大盘把QPS、RT、CPU、内存、GC次数、Full GC耗时、线程池活跃度全部拉上去再配合日志系统把慢查询和异常打点拉通。这套东西不建设好后边所有结论都可能建立在误导之上。1.2 用压测建立性能基线JMH与压测平台的配合有了监控体系之后在动手优化之前还差一步压测。压测的目的不是为了测出系统最多能扛多少并发这种炫耀性的数字而是为了建立一条基线——优化前系统是什么水平优化后提升到什么水平只有有了基线你的优化动作才能被验证。压测分两个层面。一个是代码层面的微基准测试适合验证某一段具体代码的性能改进。比如你要比较字符串拼接的几种写法或者比较两种集合的遍历效率直接写main方法跑System.currentTimeMillis()是极其不靠谱的——JIT编译、逃逸分析、缓存预热都会干扰结果。这时候要用JMHJava Microbenchmark Harness它由JVM开发团队维护会帮你处理预热、统计、防止死代码消除这些问题。JMH的用法很简单核心就是在方法上打Benchmark注解Benchmark BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MICROSECONDS) Warmup(iterations 5, time 1) Measurement(iterations 5, time 1) public void testStringBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(i); } sb.toString(); }跑出来是纳秒级还是微秒级、波动大不大一看便知。这套东西特别适合用来回答某某写法到底比某某写法快多少这种问题能终结办公室里无休止的口水战。另一个层面是系统级的全链路压测验证的是整体服务能力。JMeter、wrk、开源的压测平台都行关键在于压测场景要覆盖核心链路数据要尽量接近真实。压测时要注意一个技术细节压测产生的高QPS本身会改变JVM的JIT编译状态和GC行为所以压测时间不能太短一般至少持续3到5分钟让系统稳定进入运行态之后再取样。1.3 优化前先回答三个问题瓶颈在哪、为什么、优化后怎么验证我每次接到性能优化任务都会先逼自己用三句话回答清楚当前系统的瓶颈到底在哪个环节为什么是这个环节成了瓶颈优化完成之后我要用什么指标来验证确实有效果这三个问题回答不上来我就不动手。这不是拖延而是防止做无用功。比如接口慢瓶颈可能在代码、可能在JVM、可能在数据库、也可能在网络传输不同瓶颈的优化手段天差地别搞错方向不仅浪费精力还可能把原本稳定的系统调坏。验证的手段也需要提前想清楚。优化前跑一轮压测记录RT两个维度的指标——平均响应时间和TP99即99%的请求都在该时间内完成。很多时候平均值很漂亮但TP99飘忽不定这种平均下来很好但偶尔卡一下的情况往往是GC停顿或者锁竞争造成的跟平均RT体现的问题完全不同。所以在压测中我习惯同时记录平均RT和TP99/TP999它们一个反映整体水平一个反映尾延迟两者结合才能准确描述系统体验。2. 代码层的性能陷阱从字符串拼接到大对象如果说观测体系解决的是问题在哪那么代码层优化解决的就是哪些代码在拖后腿。这一节里我要讲的几个点都是我在实际项目中真实遇到过的也是最常见的拖垮Java服务性能的代码级元凶。2.1 字符串拼接和日志打印低垂的果实往往被忽视先讲字符串拼接。平时写着方便是一回事在热点路径上跑着快不快是另一回事。在循环体里用加号拼接字符串等同于每次循环都new一个StringBuilder再处理一次扩容逻辑这种写法在几十万次调用量下差别可能不大但在压测环境下一放大差距立刻显现。我见过最夸张的一次是某订单处理接口在循环里用加号拼了一串大报文直接导致单次请求多分配了数百KB对象Young GC频率飙升。换成预分配容量的StringBuilder之后GC频率肉眼可见地降了下来。要注意的是StringBuilder的初始容量默认只有16如果你知道最终字符串的长度应该直接指定容量避免中途扩容复制StringBuilder sb new StringBuilder(256); // 按实际预估长度给容量还有一个高频陷阱是日志打印。业务代码里到处都是log.info(订单信息 order)这里面有个隐藏的大坑不管日志级别是否开启字符串拼接都会执行。在高QPS场景下这就是海量无意义的对象分配。正确做法是使用参数化日志或者先做级别判断if (logger.isDebugEnabled()) { logger.debug(订单信息{}, order); }Log4j2和Logback都支持参数化占位符传参进去只有当日志真正输出时才格式化省掉了字符串拼接的巨额开销。另外日志框架本身的性能也有讲究Log4j2的异步日志AsyncLogger在极端高并发下比同步日志高出一个数量级代价是需要额外引入disruptor依赖。日志这件事看起来不起眼线上系统被日志拖垮的案例我见过不止一次。2.2 集合选型HashMap不是万能药扩容和哈希冲突都要管Java集合的性能问题多半出在两个地方不合适的选型和不合理的初始化容量。先说选型。ArrayList和LinkedList虽然都是List但底层结构完全不同。ArrayList是数组随机访问O(1)LinkedList是双向链表插入删除在中间位置确实快但每次get都要从头遍历O(n)。很多人在不知道数据规模的情况下顺手用LinkedList结果在遍历场景下慢得离谱。我一般的原则是95%的场景用ArrayList除非你能明确说清楚为什么需要频繁在中间插入删除。再说HashMap。HashMap默认容量16负载因子0.75意味着当元素个数超过 16 * 0.75 12 时就会触发扩容扩容要重新计算所有元素的哈希值并搬移这是个相对昂贵的操作。如果你预先知道要放多少数据最好直接给定初始容量MapString, Object map new HashMap(64); int target 100; // 容量最好设置为: (int) (target / 0.75f) 1避免频繁扩容哈希冲突是另一个隐蔽的坑。HashMap在Java 8之后引入了红黑树优化当某个桶的链表长度超过8时转成红黑树把最坏情况从O(n)降到O(logn)。但红黑树本身也有代价节点对象更大、维护更复杂。如果你的自定义对象作为keyequals和hashCode实现得不好导致大量hash碰撞性能照样崩。定位这类问题比较简单生产环境用arthas的heapdump或者火焰图一看便知CPU集中在get/put方法里跑不掉。还有一点很多人会忽略当HashMap元素数量离散度不高、Map.size又特别大的时候默认容量下的扩容会非常频繁。这类场景可以考虑用专门的集合类代替比如缓存场景用Caffeine、计数场景用LongAdder配合ConcurrentHashMap。选型这件事选对了省一半事。2.3 锁竞争与线程模型别让它成为吞吐量天花板并发场景下的性能问题十个里有八个是锁竞争引起的。Java的synchronized在JDK 1.6之后做了大量优化——偏向锁、轻量级锁、自旋、锁消除大多数情况下不用担心性能。但在高并发热点路径上重量级锁竞争仍然会直接拖垮吞吐量。判断锁竞争是否严重的方法很简单在压测过程中用jstack抓线程栈如果大量线程Blocked在同一个锁对象上那就说明竞争激烈。另一个办法是观察上下文切换次数上下文切换过高往往意味着锁竞争。锁优化的手段也是有层次的从重到轻排列缩小锁粒度从锁整个方法改成锁方法内的关键代码段。读写分离读多写少的场景用ReentrantReadWriteLock或者直接上StampedLock。无锁化用AtomicInteger、LongAdder代替加锁的计数器。LongAdder在超高并发下尤其好使它把内部拆成多个cell不同线程分散累加最终汇总。减少锁持有时间不要在锁内做IO、网络请求等耗时操作。线程池隔离每个接口使用独立的线程池防止一个慢接口耗尽全部线程拖垮其他接口。这在压测和线上环境都是一个有效的隔离手段。另外一个容易被忽视的线程模型问题是ThreadLocal的使用。ThreadLocal本身很快但如果在线程池场景下不清理内存泄漏风险极高——ThreadLocal的key是WeakReference但value是强引用线程池中的线程长期存活value就无法被回收最终可能OOM。这个坑我踩过线上一个批量任务跑了几天后内存缓慢增长一查就是ThreadLocal没remove。无论从性能还是从内存安全角度用完remove都是铁律try { // 业务逻辑 } finally { threadLocal.remove(); }3. JVM内存与垃圾回收调优从GC日志反推问题代码层的优化做完之后很多服务仍然不够快。这时候十有八九问题出在JVM这一层。JVM调优是最容易踩坑的部分因为参数太多、原理太深而且网上流传的很多所谓最佳配置都是错的。我自己的经验是不要背参数要学会看GC日志从日志现象反推配置问题。3.1 看懂GC日志它是JVM健康状况的体检报告GC日志里藏着JVM几乎所有的重要信息但很多人从未仔细看过一眼。如果你用的是JDK 8启动参数里一般会带上这些-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.logJDK 9之后日志参数统一了推荐用-Xlog:gc*:file/path/to/gc.log:time,uptime,level,tags打开GC日志你会看到类似这样的内容[GC (Allocation Failure) [PSYoungGen: 6144K-1234K(7168K)] 10240K-5410K(29696K), 0.0051233 secs] [Full GC (Ergonomics) [PSYoungGen: 1234K-0K(3584K)] [ParOldGen: 20736K-18952K(30720K)] 21970K-18952K(31232K), 0.0871655 secs]这段日志信息量很大。方括号里前一个数字是GC前该区域占用后一个数字是GC后占用括号里是该区域的总容量。要注意GC是暂停业务线程的后面那个治理时间单位是秒。频繁出现的年轻代GCYoung GC和偶尔出现的老年代GCFull GC完全是两种问题。3.2 从GC日志反推问题的三个经典场景这个技能非常实用我现在看到一段GC日志基本能八成就猜出问题出在哪。有三个高频规律场景一Young GC频繁但单次耗时低。每秒甚至每几秒就一次但每次停顿只有几毫秒。这种情况不是GC本身慢而是对象分配压力太大——说白了就是Eden区不够放放不下就得频繁Minor GC来腾空间。解决办法两个方向一是扩大堆内存让Eden区变大二是检查代码有没有大量无意义的对象生成比如循环里new对象、频繁字符串拼接。场景二Full GC频繁老年代涨得快。这是比较严重的信号一般有两种可能。第一种是内存泄漏对象被错误引用无法回收。第二种是堆内存配置不够或者对象晋升阈值不合理。处理方法是先dump堆快照分析jmap -dump:formatb,fileheap.hprof pid然后用MAT或Eclipse MAT打开快照看Dominator Tree定位占据内存最大的对象来自哪段代码。我见过最典型的泄漏是静态HashMap只put不remove还有ThreadLocal没清理以及各种缓存框架使用不当。场景三Full GC停顿时间长。老年代空间巨大做标记清理确实耗时。如果业务对响应时间敏感那就需要考虑更换垃圾收集器或者调整GC策略。3.3 收集器选型与参数设置CMS、G1和ZGC怎么选垃圾收集器的选型本质上是在吞吐量、停顿时间和内存占用三者之间做权衡。没有什么收集器是绝对最优的只看你的业务场景更在意什么。我用个简表给你梳理一下主流收集器的定位收集器适用JDK核心特点适合场景Parallel ScavengeJDK8默认高吞吐关注吞吐量优先离线计算、批处理、后台任务CMSJDK8可选并发标记清除低停顿互联网应用响应时间敏感已被废弃G1JDK9默认分代分区可预测停顿大多数Java服务ZGCJDK11超低停顿最大支持TB级堆超大堆、低延迟要求极高的场景JDK 8的默认收集器是Parallel Scavenge Parallel Old它在吞吐量上表现很好适合对停顿时间不敏感的后台任务。但如果你的服务是C端接口响应时间抖动会直接带来用户体验问题就需要考虑CMS或者直接上JDK 11的G1/ZGC。G1是当前大部分线上Java服务的主流选择。它的核心设计是把堆分成一个个Region然后跟踪每个Region的回收价值优先回收垃圾最多、回收最快的Region因此能够很好地控制停顿时间。G1最关键的参数是-XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize2mMaxGCPauseMillis是你对停顿的预期G1会尽力朝这个目标调整。注意它只是一个软目标一旦堆压力太大G1也会突破这个停顿目标所以堆大小仍然要配置合理。G1对于大对象有个专门的分配机制——Humongous Allocation如果Region大小设置不合理比如Region默认是堆大小的1/2048一个几MB的数组就会直接进老年代导致老年代回收频繁。这时候可以适当调大RegionSize。ZGC适合堆特别大几十GB甚至上百GB且对延迟要求极高的场景它的停顿时间基本可以控制在10毫秒以内。但它的代价是CPU占用更高毕竟它花更多的时间和CPU在做并发标记和整理。如果你的堆只有几个GBZGC未必比G1好。对大多数Java服务我给的建议很简单JDK 8下用CMS如果还在的话JDK 11及以上用G1把堆设成机器物理内存的一半到三分之二左右MaxGCPauseMillis设成200然后通过GC日志持续观察微调RegionSize和堆大小。别一上来就追求极限参数稳定压倒一切。4. 数据库与缓存Java应用最常见的性能瓶颈环节很多Java应用跑了一段时间后性能瓶颈不在Java代码也不在JVM而在数据库。代码写得再好一条慢SQL就能把所有优化成果全部归零。这一节我把连接池、SQL、缓存这三个高频问题点挨个讲透。4.1 连接池参数HikariCP与连接泄漏的坑数据库连接池的性能影响经常被低估。以最常用的HikariCP为例它的默认参数整体合理但有两点值得注意。第一是池大小。网上流传一个经验公式maximumPoolSize ((core_count * 2) effective_spindle_count)这个公式来自PostgreSQL官方文档核心逻辑是数据库连接池不是越大越好连接太多反而会因为上下文切换和等待锁而降低吞吐量。连接池太小呢请求进来了没连接可用就会排队等待同样拖慢RT。我见过一台4核机器把连接池配到200的压测时数据库CPU被打满连接池反而成了瓶颈的放大器。合理值一般在20到50之间具体要看你的数据库规格和业务并发。第二是连接泄漏。Java服务里最常见的数据库问题不是慢SQL而是连接没释放。你的代码里只要有一个getConnection忘了close连接池就会被慢慢吃掉然后整个应用全部阻塞在等待连接上。这类问题的排查方式一是看监控中活跃连接数是否持续增长二是开启HikariCP的泄漏检测leakDetectionThreshold5000设置之后如果连接持有超过5秒还在用HikariCP就会打印告警日志直接告诉你代码里哪个位置的连接没归还。这个参数我在生产环境常年开着成本极低收益巨大。4.2 慢SQL与ORM层面的性能问题MyBatis使用中的典型坑慢SQL是最常见的数据库性能问题。MySQL默认开启的慢查询日志是个好帮手但要注意默认阈值是10秒线上你等不起10秒建议调到1秒甚至更低SET GLOBAL long_query_time 1;拿到慢SQL之后先看执行计划也就是EXPLAINEXPLAIN SELECT * FROM order WHERE user_id 12345 ORDER BY create_time DESC LIMIT 10;EXPLAIN结果里最重要的几个字段是type访问类型、key实际使用索引、rows预估扫描行数。type的值从好到差大致是system const eq_ref ref range index ALL如果看到ALL说明这条SQL是全表扫描索引没建上或者没被用上。rows字段如果远超实际结果集说明索引选择性差。ORM框架这一层也有不少坑。我遇到过的最典型的问题是MyBatis的N1查询。比如查订单列表每条订单再去查一次用户信息列表为N条就会执行1N次SQL。解决办法很简单用连表查询或者forEach批量查询替代循环里的单条查询。另一个典型的坑是批量插入的写法。很多人习惯在业务代码里循环调用mapper.insert一次一条对于大量数据来说就是灾难。正确做法是使用MyBatis的foreach批量插入insert idbatchInsert INSERT INTO order (order_no, user_id, amount) VALUES foreach collectionlist itemitem separator, (#{item.orderNo}, #{item.userId}, #{item.amount}) /foreach /insert批量插入一次拼一条大SQL虽然SQL文本很大但相比N次网络往返性能提升是数量级的。注意单条SQL不要太长一次500条左右是个比较稳妥的批量值太长MySQL的max_allowed_packet可能吃不消。4.3 缓存设计本地缓存与Redis的多级缓存策略数据库扛不住高频访问时缓存是必须的手段。但缓存设计不好反而会引入新的问题——穿透、击穿、雪崩每一个都能弄得你焦头烂额。先说我推荐的层级结构本地缓存Caffeine Redis 数据库。本地缓存放最热点、变动极少的数据访问速度是纳秒级Redis放次热点数据访问速度是毫秒级数据库是最终兜底。本地缓存的选型我推荐Caffeine它的淘汰算法是W-TinyLFU在很多场景下的命中率表现比传统的LRU更好。Caffeine的用法很简洁CacheString, User cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() // 记录命中率 .build();缓存穿透查询一个根本不存在的数据每次都打到数据库的解法一般用布隆过滤器拦截也可以对空结果也做短暂缓存。缓存击穿热点key恰好过期大量请求直接打崩数据库的解法是热点key永不过期或者加互斥锁。缓存雪崩大量key同时过期的解法是过期时间加随机值打散过期时刻。还有一个本地缓存和Redis之间的数据一致性难题。我的做法是本地缓存设置短过期时间同时监听数据库变更事件触发主动失效。这种最终一致性方案在大多数业务场景下都是可以接受的实时性要求极高的场景就不适合用本地缓存了。5. 一次真实调优案例从TP999翻倍到恢复正常的心路历程讲了这么多理论性的干货我来还原一个我自己经历的真实调优案例。这个案例虽然规模不算大但把前面提到的观测、定位、分析、优化的完整链路都串起来了非常有代表性。5.1 现象与初步判断看起来像SQL问题其实不是当时负责的是一个B端接口功能是从MySQL里查最近7天的订单数据做汇总展示。上线初期一切正常但业务量上来之后生产环境的监控开始报警接口的TP999从原来的300ms涨到了700ms并且每天下午高峰期都会持续半小时到一小时。QPS其实没有大涨平均RT也还好就是尾延迟明显恶化。团队里第一反应是查SQL因为接口逻辑按说很简单。EXPLAIN之后发现主查询确实走了索引没有全表扫描单次SQL执行只要几十毫秒在MySQL层面看不出明显问题。那时候监控上没有GC数据大家有点抓瞎怀疑是网络波动、数据库连接池不够之类的外部因素。5.2 逐步定位GC日志帮我锁定了真凶我接手之后做的第一件事就是登上测试环境的这台服务把jstat拉起来看GC情况jstat -gcutil pid 1000结果出来了S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 15.68 98.00 76.56 90.55 89.33 24512 152.33 8 12.76 165.09关键信息有两点。Eden区E使用率98%意味着Young GC刚刚触发完毕YGC次数24512次而YGCT累计152秒也就是说平均每次Young GC约6毫秒。FGCT累计12.76秒但总共才8次Full GC平均每次1.6秒。这1.6秒的Full GC停顿恰好就能解释接口的TP999翻倍甚至翻倍不止的现象——因为每次Full GC期间所有请求都在阻塞等待尾延迟自然爆炸。再看看堆空间分配情况发现一个更关键的事实老年代O使用率76%但总容量并不大说明对象晋升到老年代的速度很快。这背后的逻辑是Eden区分配压力太大对象快速晋升导致老年代在短时间内被撑满进而触发Full GC。5.3 优化方案与数据验证小参数带来的大提升问题定位清楚了解决方案就有了方向。当时做的不是改代码而是调整JVM参数和代码细节双管齐下。第一将堆内存从原来的4GB调整到8GB这台机器物理内存16GB同时把新生代比例略微调大。这样Eden区有更多空间容纳短生命周期对象Young GC频率直接从每秒好几次降到几秒一次。第二排查代码里的对象分配热点。用async-profiler出了一张火焰图CPU分析一跑很快发现汇总逻辑里对订单明细做了多次List的拷贝和循环拼接产生了大量临时对象。改掉预处理方式之后单次请求的对象分配量下降了约40%。优化后再次压测数据对比非常明显指标优化前优化后平均RT120ms90msTP999700ms180msYoung GC频率每秒3-5次每5秒1次Full GC频率每天8-10次每天0-1次这个案例其实没什么高深技巧但很好地说明了性能优化的核心思路从监控数据出发锁定问题环节再用工具定位具体原因最后用最小改动解决最大问题。如果当时靠猜去优化SQL恐怕折腾几天也找不到真正的瓶颈。6. 工具集合与常用命令解决性能问题你只需要这几把刀最后这部分我把我常用的工具和命令给你梳理成一份可以直接上手的使用清单。会写代码的人很多但会用工具定位问题的人不多。工具这东西不需要多每个方向有一把趁手的就够了。6.1 按场景分类的诊断工具清单下面这些工具我按使用场景分了类平时遇到问题直接对号入座就能快速定位。场景工具/命令典型用法看GC实时情况jstatjstat -gcutil pid 1000每秒刷新一次抓线程栈jstackjstack pid thread_dump.txt看死锁和Blocked线程堆快照分析jmap MATjmap -dump:formatb,fileheap.hprof pid然后导入MAT找内存大头在线诊断Java进程Arthasdashboard看实时状态、trace看方法耗时、watch看入参返回CPU采样火焰图async-profilerasync-profiler -d 30 -o flamegraph pid压测JMH / wrkJMH做微基准wrk做HTTP接口压测慢SQL分析MySQL slow log EXPLAIN打开慢日志阈值后结合EXPLAIN分析全链路监控SkyWalking / Zipkin串联各服务调用链路定位跨服务延迟Arthas是阿里巴巴开源的一款Java诊断工具功能极其强大不用改代码、不用重启服务就能在线上实时诊断。它最常用的几个命令我几乎天天用trace跟踪某个方法的调用耗时分布一行命令告诉你方法里哪个子调用最慢。watch观察某个方法的入参、返回值和异常线上排查问题神器。dashboard实时展示CPU、内存、GC、线程概览。async-profiler则是生成CPU火焰图的首选工具。火焰图的横轴是采样时间占比纵轴是调用栈高耸的火焰山地方就是性能热点。它用perf_event_open做硬件级采样开销极低线上也能挂。拿到火焰图一扫性能热点在哪个方法上一目了然。6.2 排查性能问题的通用四板斧流程用熟工具之后我总结了一套通用的排查流程几乎可以覆盖90%的Java服务性能问题第一步看监控大盘确认问题范围。RT涨是全体接口还是单接口CPU高是一台机器还是全部机器GC指标是否异常这一步从宏观上确定问题方向。第二步用jstack抓线程栈和jstat抓GC状态看是否有大量线程Blocked、是否有频繁GC。这两样数据几十秒就能拿到能快速排除死锁和GC两大高频嫌疑。第三步如果是CPU高用async-profiler出火焰图直奔CPU热点如果是RT高但CPU不高大概率瓶颈在IO——数据库、Redis通信、HTTP外部调用用SkyWalking链路分析具体耗时环节。第四步锁定问题后在测试环境复现用Arthas trace定位到具体方法改完代码或参数后重新压测对比优化前后的指标数据确认效果。6.3 一些我踩过坑后的经验心得最后分享几个我踩过坑之后总结出来的经验每一条都是用真金白银换来的一是优化永远从最容易验证的地方开始。顺序一般是先看监控和GC日志再查数据库慢SQL最后排查代码和JVM参数。别一上来就动代码、调参数先把数据看明白。很多时候问题只是连接池泄漏或者日志刷太猛跟业务代码无关。二是不要盲目追求极致参数。网上流传的JVM调优神帖、线程池公式满天飞但每个服务的访问模型都不一样参数只能作为起点最终要以压测结果为准。一次只改一个参数改完压测看效果方便回滚也方便总结经验。三是一定要留好压测基线。一次优化做完至少要把优化前和优化后的压测数据留存下来。后续如果再出现性能问题没有基线你就要从头再来。这不仅仅是工作习惯问题也是对自己优化成果的尊重。四是时刻记住性能优化是持续迭代的过程不是一次性的项目。代码在变、数据量在变、业务也在变今天的优化策略明天可能就是错的。保持观测习惯比掌握任何具体技巧都重要。
开头先别急着升级机器服务慢了一般不是硬件的问题我做过几年Java服务端的性能优化最深的体会是大多数人遇到线上服务变慢第一反应是加机器、加内存、改JVM参数折腾一圈发现该慢还是慢。后来我才明白性能优化不是靠拍脑袋撞运气而是一条从观测到定位、从理论到动手的完整链路——你连问题在哪都不知道调参只是给服务器挠痒痒。这篇文章就是把我在这条链路上踩过的坑、用过的工具、总结出来的方法整理成一份可以直接照着做的实战笔记。适合正在为接口响应时间发愁的后端开发也适合刚接手Java服务、想建立性能优化方法论的同学。文章会从最容易被忽略的观测体系讲起然后逐层深入代码、JVM、数据库这几个主要瓶颈点最后用一个我实际经历过的调优案例把前面的理论串起来给你一条可以完整复现的排查路径。1. 动手优化前先搭好观测体系没有数据就没有优化性能优化最大的忌讳就是凭感觉。有人看到CPU高就怀疑是代码死循环看到内存涨就觉得是泄漏看到接口慢就认定是SQL问题结果排查半天全不是那么回事。我自己的教训是一切优化动作都必须建立在一套可量化的观测数据之上你连慢在哪里都没搞清楚就谈不上怎么优化。1.1 必须盯住的核心指标不仅是RT和QPS刚开始做性能优化的人最容易盯的就两个数接口平均响应时间RT和每秒钟处理的请求数QPS。这两个指标确实重要但只盯它们远远不够因为它们只是结果不是过程。结果变差了你需要过程指标来判断到底哪一环节出了问题。我一般会把指标分成三层来看第一层是业务层指标也就是用户能感知的RT、成功率、QPS、在线人数。这一层反映的是服务到底行不行。第二层是系统层指标CPU使用率、内存使用率、磁盘IO和网络IO。这一层反映的是机器到底扛不扛得住。注意CPU还要拆分用户态和内核态用户态高说明在跑业务代码内核态高说明系统调用频繁或者上下文切换太多。第三层是Java应用层指标也是很多人最容易忽略的GC频率和停顿时间、线程池活跃度、活跃线程数、锁等待次数、连接池使用率、请求队列堆积情况。这一层才是定位Java服务性能问题的关键入口。举个最简单的例子接口变慢了如果你只看RT和QPS你只知道慢了但如果同时看一眼GC日志发现每秒都在Young GC、每几分钟就来一次Full GC那问题方向立刻就清晰了——很大概率是堆内存配置不合理或者对象分配太频繁跟接口代码本身的执行效率关系不大。所以我会建议所有做性能优化的同学先上监控再谈优化。哪怕是最简单的方案——Prometheus配合Grafana做一个监控大盘把QPS、RT、CPU、内存、GC次数、Full GC耗时、线程池活跃度全部拉上去再配合日志系统把慢查询和异常打点拉通。这套东西不建设好后边所有结论都可能建立在误导之上。1.2 用压测建立性能基线JMH与压测平台的配合有了监控体系之后在动手优化之前还差一步压测。压测的目的不是为了测出系统最多能扛多少并发这种炫耀性的数字而是为了建立一条基线——优化前系统是什么水平优化后提升到什么水平只有有了基线你的优化动作才能被验证。压测分两个层面。一个是代码层面的微基准测试适合验证某一段具体代码的性能改进。比如你要比较字符串拼接的几种写法或者比较两种集合的遍历效率直接写main方法跑System.currentTimeMillis()是极其不靠谱的——JIT编译、逃逸分析、缓存预热都会干扰结果。这时候要用JMHJava Microbenchmark Harness它由JVM开发团队维护会帮你处理预热、统计、防止死代码消除这些问题。JMH的用法很简单核心就是在方法上打Benchmark注解Benchmark BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MICROSECONDS) Warmup(iterations 5, time 1) Measurement(iterations 5, time 1) public void testStringBuilder() { StringBuilder sb new StringBuilder(); for (int i 0; i 100; i) { sb.append(i); } sb.toString(); }跑出来是纳秒级还是微秒级、波动大不大一看便知。这套东西特别适合用来回答某某写法到底比某某写法快多少这种问题能终结办公室里无休止的口水战。另一个层面是系统级的全链路压测验证的是整体服务能力。JMeter、wrk、开源的压测平台都行关键在于压测场景要覆盖核心链路数据要尽量接近真实。压测时要注意一个技术细节压测产生的高QPS本身会改变JVM的JIT编译状态和GC行为所以压测时间不能太短一般至少持续3到5分钟让系统稳定进入运行态之后再取样。1.3 优化前先回答三个问题瓶颈在哪、为什么、优化后怎么验证我每次接到性能优化任务都会先逼自己用三句话回答清楚当前系统的瓶颈到底在哪个环节为什么是这个环节成了瓶颈优化完成之后我要用什么指标来验证确实有效果这三个问题回答不上来我就不动手。这不是拖延而是防止做无用功。比如接口慢瓶颈可能在代码、可能在JVM、可能在数据库、也可能在网络传输不同瓶颈的优化手段天差地别搞错方向不仅浪费精力还可能把原本稳定的系统调坏。验证的手段也需要提前想清楚。优化前跑一轮压测记录RT两个维度的指标——平均响应时间和TP99即99%的请求都在该时间内完成。很多时候平均值很漂亮但TP99飘忽不定这种平均下来很好但偶尔卡一下的情况往往是GC停顿或者锁竞争造成的跟平均RT体现的问题完全不同。所以在压测中我习惯同时记录平均RT和TP99/TP999它们一个反映整体水平一个反映尾延迟两者结合才能准确描述系统体验。2. 代码层的性能陷阱从字符串拼接到大对象如果说观测体系解决的是问题在哪那么代码层优化解决的就是哪些代码在拖后腿。这一节里我要讲的几个点都是我在实际项目中真实遇到过的也是最常见的拖垮Java服务性能的代码级元凶。2.1 字符串拼接和日志打印低垂的果实往往被忽视先讲字符串拼接。平时写着方便是一回事在热点路径上跑着快不快是另一回事。在循环体里用加号拼接字符串等同于每次循环都new一个StringBuilder再处理一次扩容逻辑这种写法在几十万次调用量下差别可能不大但在压测环境下一放大差距立刻显现。我见过最夸张的一次是某订单处理接口在循环里用加号拼了一串大报文直接导致单次请求多分配了数百KB对象Young GC频率飙升。换成预分配容量的StringBuilder之后GC频率肉眼可见地降了下来。要注意的是StringBuilder的初始容量默认只有16如果你知道最终字符串的长度应该直接指定容量避免中途扩容复制StringBuilder sb new StringBuilder(256); // 按实际预估长度给容量还有一个高频陷阱是日志打印。业务代码里到处都是log.info(订单信息 order)这里面有个隐藏的大坑不管日志级别是否开启字符串拼接都会执行。在高QPS场景下这就是海量无意义的对象分配。正确做法是使用参数化日志或者先做级别判断if (logger.isDebugEnabled()) { logger.debug(订单信息{}, order); }Log4j2和Logback都支持参数化占位符传参进去只有当日志真正输出时才格式化省掉了字符串拼接的巨额开销。另外日志框架本身的性能也有讲究Log4j2的异步日志AsyncLogger在极端高并发下比同步日志高出一个数量级代价是需要额外引入disruptor依赖。日志这件事看起来不起眼线上系统被日志拖垮的案例我见过不止一次。2.2 集合选型HashMap不是万能药扩容和哈希冲突都要管Java集合的性能问题多半出在两个地方不合适的选型和不合理的初始化容量。先说选型。ArrayList和LinkedList虽然都是List但底层结构完全不同。ArrayList是数组随机访问O(1)LinkedList是双向链表插入删除在中间位置确实快但每次get都要从头遍历O(n)。很多人在不知道数据规模的情况下顺手用LinkedList结果在遍历场景下慢得离谱。我一般的原则是95%的场景用ArrayList除非你能明确说清楚为什么需要频繁在中间插入删除。再说HashMap。HashMap默认容量16负载因子0.75意味着当元素个数超过 16 * 0.75 12 时就会触发扩容扩容要重新计算所有元素的哈希值并搬移这是个相对昂贵的操作。如果你预先知道要放多少数据最好直接给定初始容量MapString, Object map new HashMap(64); int target 100; // 容量最好设置为: (int) (target / 0.75f) 1避免频繁扩容哈希冲突是另一个隐蔽的坑。HashMap在Java 8之后引入了红黑树优化当某个桶的链表长度超过8时转成红黑树把最坏情况从O(n)降到O(logn)。但红黑树本身也有代价节点对象更大、维护更复杂。如果你的自定义对象作为keyequals和hashCode实现得不好导致大量hash碰撞性能照样崩。定位这类问题比较简单生产环境用arthas的heapdump或者火焰图一看便知CPU集中在get/put方法里跑不掉。还有一点很多人会忽略当HashMap元素数量离散度不高、Map.size又特别大的时候默认容量下的扩容会非常频繁。这类场景可以考虑用专门的集合类代替比如缓存场景用Caffeine、计数场景用LongAdder配合ConcurrentHashMap。选型这件事选对了省一半事。2.3 锁竞争与线程模型别让它成为吞吐量天花板并发场景下的性能问题十个里有八个是锁竞争引起的。Java的synchronized在JDK 1.6之后做了大量优化——偏向锁、轻量级锁、自旋、锁消除大多数情况下不用担心性能。但在高并发热点路径上重量级锁竞争仍然会直接拖垮吞吐量。判断锁竞争是否严重的方法很简单在压测过程中用jstack抓线程栈如果大量线程Blocked在同一个锁对象上那就说明竞争激烈。另一个办法是观察上下文切换次数上下文切换过高往往意味着锁竞争。锁优化的手段也是有层次的从重到轻排列缩小锁粒度从锁整个方法改成锁方法内的关键代码段。读写分离读多写少的场景用ReentrantReadWriteLock或者直接上StampedLock。无锁化用AtomicInteger、LongAdder代替加锁的计数器。LongAdder在超高并发下尤其好使它把内部拆成多个cell不同线程分散累加最终汇总。减少锁持有时间不要在锁内做IO、网络请求等耗时操作。线程池隔离每个接口使用独立的线程池防止一个慢接口耗尽全部线程拖垮其他接口。这在压测和线上环境都是一个有效的隔离手段。另外一个容易被忽视的线程模型问题是ThreadLocal的使用。ThreadLocal本身很快但如果在线程池场景下不清理内存泄漏风险极高——ThreadLocal的key是WeakReference但value是强引用线程池中的线程长期存活value就无法被回收最终可能OOM。这个坑我踩过线上一个批量任务跑了几天后内存缓慢增长一查就是ThreadLocal没remove。无论从性能还是从内存安全角度用完remove都是铁律try { // 业务逻辑 } finally { threadLocal.remove(); }3. JVM内存与垃圾回收调优从GC日志反推问题代码层的优化做完之后很多服务仍然不够快。这时候十有八九问题出在JVM这一层。JVM调优是最容易踩坑的部分因为参数太多、原理太深而且网上流传的很多所谓最佳配置都是错的。我自己的经验是不要背参数要学会看GC日志从日志现象反推配置问题。3.1 看懂GC日志它是JVM健康状况的体检报告GC日志里藏着JVM几乎所有的重要信息但很多人从未仔细看过一眼。如果你用的是JDK 8启动参数里一般会带上这些-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.logJDK 9之后日志参数统一了推荐用-Xlog:gc*:file/path/to/gc.log:time,uptime,level,tags打开GC日志你会看到类似这样的内容[GC (Allocation Failure) [PSYoungGen: 6144K-1234K(7168K)] 10240K-5410K(29696K), 0.0051233 secs] [Full GC (Ergonomics) [PSYoungGen: 1234K-0K(3584K)] [ParOldGen: 20736K-18952K(30720K)] 21970K-18952K(31232K), 0.0871655 secs]这段日志信息量很大。方括号里前一个数字是GC前该区域占用后一个数字是GC后占用括号里是该区域的总容量。要注意GC是暂停业务线程的后面那个治理时间单位是秒。频繁出现的年轻代GCYoung GC和偶尔出现的老年代GCFull GC完全是两种问题。3.2 从GC日志反推问题的三个经典场景这个技能非常实用我现在看到一段GC日志基本能八成就猜出问题出在哪。有三个高频规律场景一Young GC频繁但单次耗时低。每秒甚至每几秒就一次但每次停顿只有几毫秒。这种情况不是GC本身慢而是对象分配压力太大——说白了就是Eden区不够放放不下就得频繁Minor GC来腾空间。解决办法两个方向一是扩大堆内存让Eden区变大二是检查代码有没有大量无意义的对象生成比如循环里new对象、频繁字符串拼接。场景二Full GC频繁老年代涨得快。这是比较严重的信号一般有两种可能。第一种是内存泄漏对象被错误引用无法回收。第二种是堆内存配置不够或者对象晋升阈值不合理。处理方法是先dump堆快照分析jmap -dump:formatb,fileheap.hprof pid然后用MAT或Eclipse MAT打开快照看Dominator Tree定位占据内存最大的对象来自哪段代码。我见过最典型的泄漏是静态HashMap只put不remove还有ThreadLocal没清理以及各种缓存框架使用不当。场景三Full GC停顿时间长。老年代空间巨大做标记清理确实耗时。如果业务对响应时间敏感那就需要考虑更换垃圾收集器或者调整GC策略。3.3 收集器选型与参数设置CMS、G1和ZGC怎么选垃圾收集器的选型本质上是在吞吐量、停顿时间和内存占用三者之间做权衡。没有什么收集器是绝对最优的只看你的业务场景更在意什么。我用个简表给你梳理一下主流收集器的定位收集器适用JDK核心特点适合场景Parallel ScavengeJDK8默认高吞吐关注吞吐量优先离线计算、批处理、后台任务CMSJDK8可选并发标记清除低停顿互联网应用响应时间敏感已被废弃G1JDK9默认分代分区可预测停顿大多数Java服务ZGCJDK11超低停顿最大支持TB级堆超大堆、低延迟要求极高的场景JDK 8的默认收集器是Parallel Scavenge Parallel Old它在吞吐量上表现很好适合对停顿时间不敏感的后台任务。但如果你的服务是C端接口响应时间抖动会直接带来用户体验问题就需要考虑CMS或者直接上JDK 11的G1/ZGC。G1是当前大部分线上Java服务的主流选择。它的核心设计是把堆分成一个个Region然后跟踪每个Region的回收价值优先回收垃圾最多、回收最快的Region因此能够很好地控制停顿时间。G1最关键的参数是-XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize2mMaxGCPauseMillis是你对停顿的预期G1会尽力朝这个目标调整。注意它只是一个软目标一旦堆压力太大G1也会突破这个停顿目标所以堆大小仍然要配置合理。G1对于大对象有个专门的分配机制——Humongous Allocation如果Region大小设置不合理比如Region默认是堆大小的1/2048一个几MB的数组就会直接进老年代导致老年代回收频繁。这时候可以适当调大RegionSize。ZGC适合堆特别大几十GB甚至上百GB且对延迟要求极高的场景它的停顿时间基本可以控制在10毫秒以内。但它的代价是CPU占用更高毕竟它花更多的时间和CPU在做并发标记和整理。如果你的堆只有几个GBZGC未必比G1好。对大多数Java服务我给的建议很简单JDK 8下用CMS如果还在的话JDK 11及以上用G1把堆设成机器物理内存的一半到三分之二左右MaxGCPauseMillis设成200然后通过GC日志持续观察微调RegionSize和堆大小。别一上来就追求极限参数稳定压倒一切。4. 数据库与缓存Java应用最常见的性能瓶颈环节很多Java应用跑了一段时间后性能瓶颈不在Java代码也不在JVM而在数据库。代码写得再好一条慢SQL就能把所有优化成果全部归零。这一节我把连接池、SQL、缓存这三个高频问题点挨个讲透。4.1 连接池参数HikariCP与连接泄漏的坑数据库连接池的性能影响经常被低估。以最常用的HikariCP为例它的默认参数整体合理但有两点值得注意。第一是池大小。网上流传一个经验公式maximumPoolSize ((core_count * 2) effective_spindle_count)这个公式来自PostgreSQL官方文档核心逻辑是数据库连接池不是越大越好连接太多反而会因为上下文切换和等待锁而降低吞吐量。连接池太小呢请求进来了没连接可用就会排队等待同样拖慢RT。我见过一台4核机器把连接池配到200的压测时数据库CPU被打满连接池反而成了瓶颈的放大器。合理值一般在20到50之间具体要看你的数据库规格和业务并发。第二是连接泄漏。Java服务里最常见的数据库问题不是慢SQL而是连接没释放。你的代码里只要有一个getConnection忘了close连接池就会被慢慢吃掉然后整个应用全部阻塞在等待连接上。这类问题的排查方式一是看监控中活跃连接数是否持续增长二是开启HikariCP的泄漏检测leakDetectionThreshold5000设置之后如果连接持有超过5秒还在用HikariCP就会打印告警日志直接告诉你代码里哪个位置的连接没归还。这个参数我在生产环境常年开着成本极低收益巨大。4.2 慢SQL与ORM层面的性能问题MyBatis使用中的典型坑慢SQL是最常见的数据库性能问题。MySQL默认开启的慢查询日志是个好帮手但要注意默认阈值是10秒线上你等不起10秒建议调到1秒甚至更低SET GLOBAL long_query_time 1;拿到慢SQL之后先看执行计划也就是EXPLAINEXPLAIN SELECT * FROM order WHERE user_id 12345 ORDER BY create_time DESC LIMIT 10;EXPLAIN结果里最重要的几个字段是type访问类型、key实际使用索引、rows预估扫描行数。type的值从好到差大致是system const eq_ref ref range index ALL如果看到ALL说明这条SQL是全表扫描索引没建上或者没被用上。rows字段如果远超实际结果集说明索引选择性差。ORM框架这一层也有不少坑。我遇到过的最典型的问题是MyBatis的N1查询。比如查订单列表每条订单再去查一次用户信息列表为N条就会执行1N次SQL。解决办法很简单用连表查询或者forEach批量查询替代循环里的单条查询。另一个典型的坑是批量插入的写法。很多人习惯在业务代码里循环调用mapper.insert一次一条对于大量数据来说就是灾难。正确做法是使用MyBatis的foreach批量插入insert idbatchInsert INSERT INTO order (order_no, user_id, amount) VALUES foreach collectionlist itemitem separator, (#{item.orderNo}, #{item.userId}, #{item.amount}) /foreach /insert批量插入一次拼一条大SQL虽然SQL文本很大但相比N次网络往返性能提升是数量级的。注意单条SQL不要太长一次500条左右是个比较稳妥的批量值太长MySQL的max_allowed_packet可能吃不消。4.3 缓存设计本地缓存与Redis的多级缓存策略数据库扛不住高频访问时缓存是必须的手段。但缓存设计不好反而会引入新的问题——穿透、击穿、雪崩每一个都能弄得你焦头烂额。先说我推荐的层级结构本地缓存Caffeine Redis 数据库。本地缓存放最热点、变动极少的数据访问速度是纳秒级Redis放次热点数据访问速度是毫秒级数据库是最终兜底。本地缓存的选型我推荐Caffeine它的淘汰算法是W-TinyLFU在很多场景下的命中率表现比传统的LRU更好。Caffeine的用法很简洁CacheString, User cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() // 记录命中率 .build();缓存穿透查询一个根本不存在的数据每次都打到数据库的解法一般用布隆过滤器拦截也可以对空结果也做短暂缓存。缓存击穿热点key恰好过期大量请求直接打崩数据库的解法是热点key永不过期或者加互斥锁。缓存雪崩大量key同时过期的解法是过期时间加随机值打散过期时刻。还有一个本地缓存和Redis之间的数据一致性难题。我的做法是本地缓存设置短过期时间同时监听数据库变更事件触发主动失效。这种最终一致性方案在大多数业务场景下都是可以接受的实时性要求极高的场景就不适合用本地缓存了。5. 一次真实调优案例从TP999翻倍到恢复正常的心路历程讲了这么多理论性的干货我来还原一个我自己经历的真实调优案例。这个案例虽然规模不算大但把前面提到的观测、定位、分析、优化的完整链路都串起来了非常有代表性。5.1 现象与初步判断看起来像SQL问题其实不是当时负责的是一个B端接口功能是从MySQL里查最近7天的订单数据做汇总展示。上线初期一切正常但业务量上来之后生产环境的监控开始报警接口的TP999从原来的300ms涨到了700ms并且每天下午高峰期都会持续半小时到一小时。QPS其实没有大涨平均RT也还好就是尾延迟明显恶化。团队里第一反应是查SQL因为接口逻辑按说很简单。EXPLAIN之后发现主查询确实走了索引没有全表扫描单次SQL执行只要几十毫秒在MySQL层面看不出明显问题。那时候监控上没有GC数据大家有点抓瞎怀疑是网络波动、数据库连接池不够之类的外部因素。5.2 逐步定位GC日志帮我锁定了真凶我接手之后做的第一件事就是登上测试环境的这台服务把jstat拉起来看GC情况jstat -gcutil pid 1000结果出来了S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 15.68 98.00 76.56 90.55 89.33 24512 152.33 8 12.76 165.09关键信息有两点。Eden区E使用率98%意味着Young GC刚刚触发完毕YGC次数24512次而YGCT累计152秒也就是说平均每次Young GC约6毫秒。FGCT累计12.76秒但总共才8次Full GC平均每次1.6秒。这1.6秒的Full GC停顿恰好就能解释接口的TP999翻倍甚至翻倍不止的现象——因为每次Full GC期间所有请求都在阻塞等待尾延迟自然爆炸。再看看堆空间分配情况发现一个更关键的事实老年代O使用率76%但总容量并不大说明对象晋升到老年代的速度很快。这背后的逻辑是Eden区分配压力太大对象快速晋升导致老年代在短时间内被撑满进而触发Full GC。5.3 优化方案与数据验证小参数带来的大提升问题定位清楚了解决方案就有了方向。当时做的不是改代码而是调整JVM参数和代码细节双管齐下。第一将堆内存从原来的4GB调整到8GB这台机器物理内存16GB同时把新生代比例略微调大。这样Eden区有更多空间容纳短生命周期对象Young GC频率直接从每秒好几次降到几秒一次。第二排查代码里的对象分配热点。用async-profiler出了一张火焰图CPU分析一跑很快发现汇总逻辑里对订单明细做了多次List的拷贝和循环拼接产生了大量临时对象。改掉预处理方式之后单次请求的对象分配量下降了约40%。优化后再次压测数据对比非常明显指标优化前优化后平均RT120ms90msTP999700ms180msYoung GC频率每秒3-5次每5秒1次Full GC频率每天8-10次每天0-1次这个案例其实没什么高深技巧但很好地说明了性能优化的核心思路从监控数据出发锁定问题环节再用工具定位具体原因最后用最小改动解决最大问题。如果当时靠猜去优化SQL恐怕折腾几天也找不到真正的瓶颈。6. 工具集合与常用命令解决性能问题你只需要这几把刀最后这部分我把我常用的工具和命令给你梳理成一份可以直接上手的使用清单。会写代码的人很多但会用工具定位问题的人不多。工具这东西不需要多每个方向有一把趁手的就够了。6.1 按场景分类的诊断工具清单下面这些工具我按使用场景分了类平时遇到问题直接对号入座就能快速定位。场景工具/命令典型用法看GC实时情况jstatjstat -gcutil pid 1000每秒刷新一次抓线程栈jstackjstack pid thread_dump.txt看死锁和Blocked线程堆快照分析jmap MATjmap -dump:formatb,fileheap.hprof pid然后导入MAT找内存大头在线诊断Java进程Arthasdashboard看实时状态、trace看方法耗时、watch看入参返回CPU采样火焰图async-profilerasync-profiler -d 30 -o flamegraph pid压测JMH / wrkJMH做微基准wrk做HTTP接口压测慢SQL分析MySQL slow log EXPLAIN打开慢日志阈值后结合EXPLAIN分析全链路监控SkyWalking / Zipkin串联各服务调用链路定位跨服务延迟Arthas是阿里巴巴开源的一款Java诊断工具功能极其强大不用改代码、不用重启服务就能在线上实时诊断。它最常用的几个命令我几乎天天用trace跟踪某个方法的调用耗时分布一行命令告诉你方法里哪个子调用最慢。watch观察某个方法的入参、返回值和异常线上排查问题神器。dashboard实时展示CPU、内存、GC、线程概览。async-profiler则是生成CPU火焰图的首选工具。火焰图的横轴是采样时间占比纵轴是调用栈高耸的火焰山地方就是性能热点。它用perf_event_open做硬件级采样开销极低线上也能挂。拿到火焰图一扫性能热点在哪个方法上一目了然。6.2 排查性能问题的通用四板斧流程用熟工具之后我总结了一套通用的排查流程几乎可以覆盖90%的Java服务性能问题第一步看监控大盘确认问题范围。RT涨是全体接口还是单接口CPU高是一台机器还是全部机器GC指标是否异常这一步从宏观上确定问题方向。第二步用jstack抓线程栈和jstat抓GC状态看是否有大量线程Blocked、是否有频繁GC。这两样数据几十秒就能拿到能快速排除死锁和GC两大高频嫌疑。第三步如果是CPU高用async-profiler出火焰图直奔CPU热点如果是RT高但CPU不高大概率瓶颈在IO——数据库、Redis通信、HTTP外部调用用SkyWalking链路分析具体耗时环节。第四步锁定问题后在测试环境复现用Arthas trace定位到具体方法改完代码或参数后重新压测对比优化前后的指标数据确认效果。6.3 一些我踩过坑后的经验心得最后分享几个我踩过坑之后总结出来的经验每一条都是用真金白银换来的一是优化永远从最容易验证的地方开始。顺序一般是先看监控和GC日志再查数据库慢SQL最后排查代码和JVM参数。别一上来就动代码、调参数先把数据看明白。很多时候问题只是连接池泄漏或者日志刷太猛跟业务代码无关。二是不要盲目追求极致参数。网上流传的JVM调优神帖、线程池公式满天飞但每个服务的访问模型都不一样参数只能作为起点最终要以压测结果为准。一次只改一个参数改完压测看效果方便回滚也方便总结经验。三是一定要留好压测基线。一次优化做完至少要把优化前和优化后的压测数据留存下来。后续如果再出现性能问题没有基线你就要从头再来。这不仅仅是工作习惯问题也是对自己优化成果的尊重。四是时刻记住性能优化是持续迭代的过程不是一次性的项目。代码在变、数据量在变、业务也在变今天的优化策略明天可能就是错的。保持观测习惯比掌握任何具体技巧都重要。
