做JAVA优化这块前两篇我聊了不少代码层的微观细节和并发组件选型今天这篇“JAVA优化之路三”我想换个角度从一线排查的角度来聊。很多同学的优化其实是被网上的“JAVA面试题”、“八股文”带偏了一上来就调JVM参数、上并发组件结果系统反而更卡。真实的线上优化核心只有两件事先定位到确切的瓶颈再用最省成本的方式把它消掉。这篇文章我会结合自己实际处理的几个场景把常见慢SQL、GC抖动、代码层无谓开销、缓存穿透这些问题从现象到根因再到改造方案完整过一遍。1. 先想清楚优化顺序与常见误区1.1 优化金字塔模型别一上来就动JVM我见过太多人做优化第一反应就是改启动参数把堆调大、GC换掉甚至网上抄一套“大厂JVM配置”就直接怼上去。这里我强烈建议先建立一个优化金字塔模型从上往下优先级递减最顶层是架构与数据模型然后是中间件选型与集群设计接着才是应用代码实现最后才是JVM、操作系统参数这类底层调优。为什么这么排因为越靠上的层级改动带来的收益越大且成本越低架构层面的问题靠调参是永远救不回来的。举一个实际例子一个订单查询接口数据库表单表数据量过亿没有任何分区或归档策略。这时候把JVM堆从8G调到16G只是让缓存能多存一点热点数据但查询依旧慢。真正有效的做法是先做数据归档、读写分离或者把热数据放到缓存集群。不做这些光调JVM就是自欺欺人。所以第一节课我建议所有做优化的同学先按住手先画一张系统请求链路图把每一跳的耗时标出来再决定优化动作落在哪一层。1.2 别被“八股文”带偏性能优化的真实出发点“八股文”里JAVA优化的经典答案确实不少但很多是脱离场景的。比如“尽量减少对象创建”——这是对的但在请求量只有每分钟几百次的管理后台里这部分优化收益几乎可以忽略。真正要做的是先量化再动手。我习惯的做法是用监控系统拉出接口的TP99、TP999以及CPU、内存、磁盘IO、数据库慢查询数这几项核心指标。哪个指标先报警优化目标就定在哪个指标上。举个常见的反例某服务CPU经常飙到90%以上有人立刻怀疑是Full GC太频繁结果改了GC参数后没效果。用top -Hp一看是某段循环里在反复做字符串正则匹配把CPU消耗吃干净了。这就是典型的优化出发点错了——不是JVM参数的问题而是代码热点没处理。优化必须先有监控数据为依据让数据和现象说话别再凭感觉猜。2. JVM 调优与 GC 问题的排查思路2.1 堆内存模型与常见 OOM 的现场特征JVM调优这块我一直觉得不需要把堆模型背得滚瓜烂熟但几个核心区域要心里有数。新生代里的Eden区和Survivor区决定了对象创建的“短命对象”能不能被快速回收老年代则存放长期存活或大对象。OOM的类型基本能直接告诉你问题出在哪java.lang.OutOfMemoryError: Java heap space最常见多是老年代满了可能是对象泄漏也可能是堆太小GC overhead limit exceeded说明GC一直在跑但回收不到内存这基本就是对象泄漏的信号还有一种是unable to create new native thread这是操作系统线程数被打满通常和线程池滥用、连接数不释放有关。我遇到过一次比较典型的OOM场景一个报表导出功能用户每次导出几万行数据代码里用循环拼接了一个巨大的StringBuilder然后所有数据还放到一个静态的List里做缓存。并发一上来老年代直接被打满。事后看监控GC日志里Full GC从每小时一两次变成每分钟一次CPU高居不下。所以处理OOM的第一步不是调大堆而是找谁在持有这么多对象——jmap -dump导堆转储用MAT或者Eclipse MAT去分析对象引用树定位到具体业务代码的位置。2.2 GC 日志怎么看从小文件到 STW 定位很多同学不敢开GC日志怕影响性能其实GC日志的开销极小但对排查问题价值极大。线上建议加上这样一组启动参数-Xloggc:/data/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize10M日志拿到手之后重点看两类信息Young GC的频率和耗时Full GC的频率和耗时。如果Young GC每秒都有而且每次耗时都在几十毫秒以上说明新生代太小或者短命对象创建过猛如果Full GC频繁那就要怀疑老年代里被塞进了太多长生命周期对象比如缓存没设过期时间、连接池对象没关闭、批量数据一次性加载等。STWStop The World是整个GC里最需要关注的。Full GC期间所有业务线程都要暂停停顿时间一长接口超时、消息堆积这些连锁反应都会来。日志里GC pause后面的时间就是停顿时长。我在排查时习惯把GC日志里的停顿时间和监控系统里的接口耗时曲线对齐如果某个时间点GC停顿很长同时接口RT也飙升那根因基本就锁定在GC上了。2.3 常用 JVM 参数配置参考关于参数配置我强烈反对去抄别人家的“标准参数”。每台服务器的CPU核数、内存大小、业务对象特征都不一样给出一套万能配置本身就是不科学的。这里我给出一个面向常规微服务的基础模板配合一组自检说明参数项建议值说明-Xms/-Xmx服务器物理内存的一半左右避免堆大小动态伸缩两者保持一致-Xmn堆总大小的1/3到1/4新生代太大导致老年代过小停顿上升-XX:MaxMetaspaceSize256M或512M防止元空间无限膨胀导致native内存耗尽-XX:UseG1GCJDK11默认对于大堆4GG1吞吐和停顿更均衡-XX:MaxGCPauseMillis100~200只是目标停顿不是绝对值不影响实际延迟-XX:HeapDumpOnOutOfMemoryError开启OOM时自动保留现场指定-XX:HeapDumpPath参数不是越多越好-XX:PrintGCDetails这些排查型参数线上可以保留排完再关。给一台4核8G的服务器做参考-Xms4g -Xmx4g -Xmn1g -XX:UseG1GC -XX:MaxGCPauseMillis100。注意这里堆只分了4G剩下的留给堆外内存、线程栈和元空间否则堆占满物理内存系统本身就会开始swap性能更惨。每次改完参数都要做一次压测对比不然你根本不知道改动到底是正向还是反向的。3. 代码层优化最容易见效也最容易翻车的环节3.1 集合选型与容量预分配代码层的优化是从堆内存的“源头”做减法。这方面最容易见效的地方是集合。先说HashMap很多同学直接无脑new HashMap()但如果你确定要放一万条数据初始容量给16那么扩容会发生在12条之后随后每次扩容都要重新hash搬移老数据。如果一开始就能预估规模直接设置初始容量频繁扩容的开销完全规避掉。这里有个小规律容量可以设置为(预期元素个数 / 负载因子) 1也就是(10000 / 0.75) 1 ≈ 13334实际设个2的幂次倍数附近的值也行。ArrayList就更直接了底层数组不够就要扩容每次扩容拷贝旧数组数据。批量加载数据的场景里我通常先new ArrayList(expectedSize)实测下来能省掉不少内存拷贝。StringBuilder同理默认容量是16循环拼接几百次就会反复扩容。初始化时给定一个合理的预估长度比如new StringBuilder(totalLength)拼完再toString这种优化在日志输出和报表生成里效果非常明显。这些动作都不改动业务逻辑仅仅是把容器的惯性浪费去掉。3.2 不要在循环里无谓地创建对象代码层最容易翻车的一点是在循环体里创建无谓的对象。我复现过一段很典型的代码一个批量处理接口循环两万条数据每次循环里都new SimpleDateFormat、new StringBuilder、new ArrayList然后把这些小对象塞进一个List里最后统一写库。从局部看每个对象都很小但两万次循环意味着两万个临时对象进入新生代Eden区一下子就被撑满Young GC频率翻倍。而SimpleDateFormat本身是线程不安全的每次循环new确实保证了安全但也制造了大量垃圾。优化方案不复杂用DateTimeFormatter线程安全替代SimpleDateFormat并且把格式化器定义为static finalStringBuilder能复用就复用循环外建一个实例每次setLength(0)清空再拼集合容器尽量在循环外初始化按最大规模估算容量。改造后一次批量处理里Young GC次数能下降一个量级整体耗时也会有明显改善。这类改动不涉及架构风险很低但收益却在每一条请求上都积累下来。3.3 锁粒度与并发竞争的实测数据再聊并发锁的优化。这块在JAVA面试题里是高频考点但线上做决策时很多同学只会背区别不知道如何权衡。synchronized是JVM内置锁简单可靠ReentrantLock支持超时、可中断、公平/非公平等高级特性Atomic类则是无锁CAS适合非常细粒度的计数器。我建议用一个简单模型来判断临界区代码执行时间极短比如就一个自增直接用AtomicLong或LongAdder临界区代码有IO操作或耗时较长用ReentrantLock加超时避免无限等待没有特殊需求就用synchronized写法简单还不容易出错。我给一个实际的优化案例一个库存扣减接口用的是synchronized锁整个方法等于把整个方法变成串行压测下来吞吐只有每秒几百。后来把锁范围缩小到只锁那行库存记录的更新操作其余校验、拼装对象全部放到锁外。改造完直接看压测数据吞吐从600多涨到5000多延迟也大幅降低。核心逻辑就是——把锁的粒度尽量缩小别用重量级锁去保护一个只需要很短时间内完成的操作。4. 数据库与慢 SQL 优化的核心方法论4.1 慢 SQL 定位工具全家桶慢SQL优化是JAVA后端性能优化里最实在的一环也是很多同学平时感受最直观的。线上排查慢SQL我的工具链大致是这样首先开启MySQL慢查询日志设置long_query_time1让超过1秒的SQL都记录下来然后通过mysqldumpslow或直接查mysql.slow_log表先把出现频率最高的SQL抓出来接着用EXPLAIN去看执行计划确认它到底有没有走索引、扫描了多少行必要时还可以开performance_schema来统计各类SQL的等待事件和锁等待时间。有一次线上接口偶发超时我查慢日志发现是一条更新语句跑了将近3秒。可诡异的是单独执行这条SQL很快只有几十毫秒。后来才发现是大量事务持有行锁这条更新一直在等待锁释放慢日志里记录的3秒大部分时间都耗在“等待”上。这就是一个很典型的教训慢SQL日志里的时间不全是执行时间也可能是排队时间。定位慢SQL后还要同步看一下当前的锁等待和事务状态information_schema.innodb_trx、sys.innodb_lock_waits才能真正看到全貌。4.2 explain 输出列解读与索引失效场景EXPLAIN输出里我重点看四列type、key、rows、Extra。type反映了访问效率从system、const到eq_ref、ref、range、index再到ALL效率依次递减ALL就是全表扫描基本是优化靶子。key表示实际用到的索引如果为NULL说明没走到索引。rows是预估扫描行数这个数字越大SQL往往越慢。Extra里出现Using filesort或Using temporary通常意味着排序或去重没有走索引也需要关注。常见索引失效的场景我列一下对索引列做函数运算比如WHERE DATE(create_time) 2024-01-01无法走索引隐式类型转换比如索引列是varchar但传参是数字前导模糊匹配LIKE %abc由于B树的索引结构决定它无法从中间去匹配还有OR条件两端只有一边能走索引等情况。有一个改造案例一条订单统计SQLWHERE status 1 AND create_time BETWEEN 2024-01-01 AND 2024-12-31原来没建联合索引时扫描行数接近百万加了(status, create_time)联合索引后扫描行数直接降到几千查询时间从2秒降到50毫秒以内。4.3 从循环查库到批量思维的改造微服务架构里最常见的一种接口性能杀手就是在循环里逐条查数据库。我接手过一个导出功能遍历一万个订单每单查一次明细每次都是单行查询。数据库连接池只有五十个连接这一万次查询全部排队整个接口跑完要近10秒。优化方向很明确把循环内的单次查询改成批量查询用IN或者分批UNION把数据一次性取出来再在内存里做关联和聚合。这样一次往返就能拿到所有明细数据库连接占用也从一万次降到了几次。改造时有个细节必须注意IN列表长度过大时SQL可能会超长或导致索引失效一般控制在500到1000个ID一批。可以分批后放到一个List里统一处理也可以直接使用多条SQL合并结果。对于更复杂的关联数据可以先用主数据查询一次收集所有关联外键再用批量查询把子表数据取回最后在内存里用Map做关联。这种“批量思维”改完导出接口从近10秒降到0.6秒左右效果立竿见影。5. 缓存与一致性性能上去了别把数据搞坏5.1 缓存穿透、击穿、雪崩的处理手段缓存是提升性能最直接的手段但如果处理不好容易整出一堆新问题。缓存穿透指的是查询了一个必然不存在的数据缓存里没有请求直接打到数据库如果这种key很多数据库压力直接被打满。我的处理方法是在缓存里也存一个空值并设置较短的过期时间再加一层布隆过滤器做前置过滤拦截那些根本不可能存在的key。代码上实现不难关键是意识上要先把空值也缓存起来。缓存击穿是指某个热点key刚好过期一瞬间大量并发请求同时打到数据库。常见做法是用“互斥锁重建缓存”也就是让只有一个线程去查库并回填缓存其他线程先短暂等待或者拿到旧值返回。分布式环境下可以把锁放到Redis里通过SET NX实现比在本地用synchronized可靠得多。缓存雪崩则是大量key同时过期导致集体回源数据库。处理办法是过期时间加一个随机扰动值避免所有key在同一个时间点集体失效同时设置多级缓存本地缓存扛住一部分流量让数据库那一层的压力不会瞬间过高。5.2 保证数据一致性的几种常见方案缓存和数据库之间的数据一致性是JAVA后端绕不过去的问题“java怎么保证数据一致性”这个关键词我经常在面试里被问到实际线上也确实是高频痛点。最简单的是Cache Aside模式先更新数据库再删除缓存。这个模式的问题在于删除缓存失败或者并发期间有旧数据回填到缓存里导致短暂不一致。进阶一点的做法是延迟双删先删除缓存更新数据库休眠几百毫秒后再删除一次缓存尽量把并发期间可能填入的旧缓存清掉。但我要说点实际的延迟双删也不是银弹延时时间设置不好照样出问题而且在分布式场景下很难严格保证强一致。更合理的思路是接受“最终一致”配合消息队列做异步的缓存更新通知甚至直接把缓存时间设短一点来自动对账。具体落到代码上我习惯写一个CacheAsideService统一封装“更新DB后发送MQ广播删除缓存”的逻辑业务方不用关心底层细节出错概率明显降低。本质上做缓存优化要先定义好可接受的一致性级别再选匹配的方案不能一边追求强一致一边还想要最高的缓存命中率。6. 线上排查与工具实战6.1 Arthas 定位 CPU 毛刺与分析遇到CPU突然飙高、接口偶尔卡顿的问题用Arthas非常顺手。打一个小补丁部署上去看现场比盲猜代码高效得多。我举个真实过程线上某接口TP99从80ms涨到3秒但平均响应时间变化不大典型的“毛刺”问题。我先是top -Hp找到CPU占用最高的线程拿到线程ID转成16进制再用Arthas的thread命令定位到对应业务线程的名称和执行栈一眼就看到了是某个加解密方法在吃CPU。接着用Arthas的trace命令跟踪了这个方法发现每次调用都会重复加载一次证书和密钥文件而且这个方法被放在了一个高频路径里。如果把加载对象提到静态块改成一次性加载CPU开销直接下降。Arthas里还有几个常用技能watch可以查看入参和返回值适合排查数据问题jad能反编译线上类确认发布的代码确实是最新版本dashboard可以概览线程、内存、GC等整体状态。这套组合拳打下来绝大多数线上JAVA性能问题都能定位到具体代码位置。6.2 一次典型的高并发线程池过载排查线程池是JAVA并发优化里的重头戏但也经常被乱用。有一次压测一个异步处理接口在并发从500涨到1500时成功率突然大幅下降。排查发现线程池用的是newFixedThreadPool搭配无界队列任务全部堆在队列里内存被任务对象占满GC开始急剧膨胀最终导致整个进程卡住。这属于典型的线程池参数设计不合理。线程池参数如何定业界有很多公式我的经验是先把“核心线程数”和“最大线程数”区分清楚核心线程用于常规流量最大线程数应对瞬时尖峰队列必须有界否则内存安全得不到保障。比如一个IO密集型任务CPU等待时间占比高可以按核心线程数 ≈ CPU核数 * 2来设定如果是CPU密集任务设成CPU核数 1更合理。队列长度要根据可接受的任务积压时长算比如每秒新增1000个任务希望最多积压10秒那队列可以设10000。拒绝策略要选择合理的方式比如CallerRunsPolicy让无法处理的请求退回调用线程执行而不是直接丢弃。那次压测问题改完有界队列和合理拒绝策略后高并发下的成功率就从70%回稳到了99%以上。7. 优化管理上线前基准测试与压测复盘7.1 用 JMH 做微基准测试的基本写法代码层优化改完不能光凭感觉说“变快了”我建议用JMH做微基准测试把数据留成记录。这里给一个最简的最小示例BenchmarkMode(Mode.AverageTime) OutputTimeUnit(TimeUnit.MICROSECONDS) State(Scope.Thread) public class StringBuilderBenchmark { private ListString data; Setup public void init() { data IntStream.range(0, 1000) .mapToObj(i - item- i) .collect(Collectors.toList()); } Benchmark public String concatWithBuilder() { StringBuilder sb new StringBuilder(512); for (String s : data) { sb.append(s); } return sb.toString(); } Benchmark public String concatWithPlus() { String result ; for (String s : data) { result s; } return result; } }跑出来后你会直观地看到concatWithBuilder会比concatWithPlus快出一个数量级。但这类微基准测试只能用来比较代码层面的相对差异不能代表线上真实吞吐。线上性能是整体链路和资源共同决定的所以微基准测试适合做回归对比不适合做容量评估。我一般把JMH的结果归档到一个表格里下次有人提出要改这部分代码时直接拉历史数据对比防止“优化”反而变成负优化。7.2 压测和对比数据怎么留存做JAVA优化最容易出现的问题就是改完不知道效果如何之后某天又有新改动也无法快速判断是否引入性能回归。所以我特别习惯把每一次优化前后的压测数据做对比保存。压测工具可以用JMeter或wrk也可以直接用公司压测平台但一定要保证压测参数一致并发数、总请求量、数据量级、机器配置都要统一。记录的核心指标包括吞吐量TPS/QPS、响应平均耗时、TP99、TP999、CPU使用率、Full GC次数和耗时。留存数据不一定要搞很重的报表一个简单的Excel表格就够了。每行记录“日期、版本号、压测场景、压测参数、TPS、AVG、TP99、FullGC次数、改动说明”优化一次记录一次。这样做了大半年的同学会回来感谢这个习惯——线上出问题时你翻一下表格就能很快定位是哪个版本的哪次改动带来了变化省下的排查时间远远超过当时记录数据的几分钟。最后再分享一个我在实际排查中深有体会的小技巧无论做哪一层优化一定要先立一个“基线”。比如优化前先记录下CPU、内存、GC、RT、TPS这五个指标优化后跑同样场景再对比一次。没有基线的优化都是在耍流氓有了基线每一次优化到底是真改进还是瞎折腾立刻见分晓。