聊到“更好的优化”我得先泼一盆冷水很多人做的优化其实是在瞎忙。接口慢了就加缓存CPU高了就调GC参数数据库卡了就升配置——不能说完全没效果但本质上是在治标而且常常把系统越改越复杂。我在一线做后台开发和性能治理这么多年踩过无数坑之后才慢慢想明白一件事真正的“更好的优化”不是某一个炫技操作而是一整套可以复用的方法论——先定目标再测量再动手最后还要回头验证。这篇文章就把这套方法论和一次完整的实战复盘掰开揉碎讲给你听。适合正在做后端接口优化、处理线上性能故障或者想要系统学习性能优化思路的开发同学。1. “更好的优化”到底优化什么先定目标再动手1.1 性能优化的真正目标函数我见过太多团队把“优化”等同于“把指标压低”。接口从 500ms 优化到 300ms 就觉得完事了再压到 100ms 就觉得了不起。但实际上任何优化动作都必须回答一个问题优化的目标函数是什么这里的“目标函数”不是数学黑话而是你做这件事想换来的最终收益。举三个真实场景你就懂了。场景一电商核心下单接口。这个接口的优化目标一定是端到端延迟的 P99和可用性因为你快 10ms 都可能影响转化率而失败率哪怕涨 0.1% 都会造成真金白银的损失。这时候哪怕牺牲一点开发效率也值得做精细化的并发控制、连接池调优、缓存预热。场景二内部数据平台的离线报表。每天凌晨跑一次跑 20 分钟还是 25 分钟业务完全无感。这时候优化的目标就不是延迟而是资源成本和稳定性。与其花三天去抠 SQL 的几十毫秒不如把目标定成“用一半的 Spark 资源跑完”这个 ROI 高得多。场景三一个只有几十人用的后台管理系统。你说它按钮响应 800ms 是不是问题是问题但优先级极低。你要是把所有热情都用在这上面老板只会觉得你闲得慌。更好的优化在这里是“别写死循环、别锁表、别让用户等 5 秒以上”做到这个级别就够了。所以看到“优化”两个字我的条件反射不是去翻代码而是去问需求方你希望换来什么是更高的吞吐、更低的延迟、更低的成本还是更稳定的运行这世界上不存在绝对“最快”的系统只有“在约束条件下最合适的系统”。这就像买房子光看面积大没有用得看地段、户型、采光、单价一综合才谈得上“更好的选择”。1.2 过早优化与合理规划的边界“过早优化是万恶之源”这句话被引用烂了但很多人理解偏了。这句话不是让你完全不优化而是反对在没有数据支撑的情况下为了“以后可能会用到”的复杂设计提前买单。我的经验是区分两层来对待第一层架构层面留对风口。比如你在设计订单表时把order_id设计成雪花 ID 而不是自增主键这是一个合理的架构决策为将来分库分表留了可能。再比如接口层的超时配置、熔断降级的预留这些属于合理的提前规划成本不高但收益很大。第二层代码层面不过度设计。比如一个表在一千条数据量级就不要一上来就搞缓存、分库分表。有人用 Redis 给一张三千行的配置表做了一层“高性能缓存”看起来很有技术感实际上除了增加数据不一致的风险没有任何收益。这种就是典型的过度优化。我自己的判断标准很简单如果这个优化动作在三五天内不做系统也不会挂那它大概率不属于“紧急优化”。反过来如果现在不做等数据量翻十倍的时候要做就得改核心链路那这个优化必须现在就做。数据库的索引设计、核心链路的日志埋点、API 的契约设计都是值得提前规划的而具体的并发模型、缓存策略、连接池大小等到流量和数据规模逼到面前再优化完全来得及。2. 没有测量就没有优化用数据代替感觉2.1 三层观测体系应用层、代码层、数据库层做优化最忌讳“凭感觉”。我见过太多同事拍着胸脯说“这个接口慢就是数据库问题”结果一查代码发现是他在循环里同步调了三五次 RPC。所以动手之前先建立观测体系。我建议从三个层面去做测量缺一层都容易误判应用层指标核心监控就是 API 的 RT、QPS、吞吐量、错误率。工具可选 Prometheus Grafana 做指标看板配合 SkyWalking、Zipkin、Jaeger 这类链路追踪系统看调用链。这一层解决的是“哪个接口慢、慢在哪个环节”。代码层剖析当你知道某个接口慢之后要看它到底在哪个函数里耗时间。Java 服务可以用 async-profiler 或者 JDK 自带 JFR 做采样生成火焰图Go 服务用 pprofPython 用 py-spy。这一层解决的是“哪一行代码是罪魁祸首”。数据库层诊断打开 MySQL 慢查询日志找到执行时间超过阈值比如 100ms的 SQL然后用 EXPLAIN 看执行计划。这一层解决的是“是不是 SQL 走了全表扫描、是不是没用索引”。这三个层面的数据必须结合起来看缺一个都可能得出错误结论。我见过一个团队查线上数据库 CPU 飙高的故障查了三天数据库慢查询结果发现罪魁祸首是应用层每台机器定时任务同时去刷一个统计报表跟数据库索引一点关系都没有。2.2 为什么平均值毫无意义请关注 P99 和 P99.9每次聊性能指标我都要强调一个观点平均值是骗人的。举个例子假设一个接口一天有一万次调用其中 9900 次都是 50ms 返回剩下 100 次因为某条 SQL 偶发慢查询要 5 秒返回。平均值算下来大概是 99.5ms看着挺快。可那 100 个用户每人等了 5 秒他们不会觉得这是个 “百毫秒级” 的接口他们只会觉得“这系统真垃圾”。所以做性能优化我只看尾延迟P99 表示 99% 的请求都小于这个值P999 表示 99.9% 的请求都小于这个值。平均值像平均工资P99 才像真正的贫富差距。一个接口的平均耗时再漂亮P99 长时间飘红就说明系统仍然存在严重的性能短板。监控面板上我通常会把 P50、P99、P999 三条曲线一起放还要加一条“最大耗时点”事件标记用来追踪是哪一个时间窗口出现了长尾。优化之前先记录这些数据优化之后重新对比用数字说话而不是用“感觉变快了”说话。2.3 火焰图怎么读别被花哨的图形吓住火焰图这个东西第一次看到的人往往会觉得眼花缭乱。其实读法非常简单横轴是采样比例或者时间纵轴是调用栈每一根“柱子”越宽代表这个函数消耗的时间占比越高。我来说一个实际场景。一个 Java 服务CPU 使用率一直下不来用async-profiler跑一下./profiler.sh -d 60 -o collapsed pid采样一分钟然后用 FlameGraph 脚本生成火焰图你大概率能在地层底层平台和上层业务代码之间看到某个方法的“宽柱子”。前阵子我就遇到一个案例火焰图里String.matches()方法占了一大块点进去才发现是一个收单程序在每次进来一个 key 的时候都用正则去校验消息格式。正则表达式每次编译匹配CPU 消耗巨大。改成预编译 Pattern 之后CPU 直接降了 30%。这就是火焰图的价值不用猜一眼就能锁定热点。所以再强调一次任何优化动作都必须在测量之后进行。你没数据就动手和蒙着眼睛拆炸弹没区别。3. 分层优化的实操手段从算法到写码3.1 算法和数据结构是上限其他都是优化这个上限很多长期做业务开发的同学有个误区觉得算法是面试题、平时用不上。但真正到了性能层面聊“更好的优化”算法和数据结构是第一优先级因为它是性能的上限而缓存、并发、索引这些手段只是在逼近这个上限。我给你举一个我手头踩过的真实改造。当时有一个批量查询接口需要根据一批订单 ID 查询对应的买家昵称。原始代码是这样for (Long buyerId : buyerIdList) { Buyer buyer buyerMapper.selectById(buyerId); // 一次数据库查询 names.add(buyer.getName()); }这段代码如果buyerIdList只有 10 个问题不明显但如果订单量到了 1 万就意味着 1 万次数据库往返每次就算 0.5ms也要 5 秒。这里优化第一步不是加缓存而是把循环查询改成批量查询ListBuyer buyers buyerMapper.selectByIds(buyerIdList); // 一次 IN 查询 MapLong, String nameMap buyers.stream().collect(Collectors.toMap(Buyer::getId, Buyer::getName));单次查询的次数从 N 次变成 1 次这个差距是数量级的缓存再多也弥补不了。很多所谓慢接口第一刀砍的其实是这种“循环里做 IO”的烂代码。再比如一个需求要判断某个 ID 是否存在于一个集合里有些人随手就写list.contains(id)当集合有十万个元素、判断要执行一万次的时候复杂度就是 O(N×M)慢得感人。改成HashSet之后每次contains都是 O(1)整体复杂度直接降到 O(NM)。这就是数据结构的价值一分钱不花纯粹靠聪明程度换来性能提升。3.2 索引、缓存、异步三大常规武器及正确用法如果说算法是再“设计”一次下面这三个手段就是再“部署”一次它们也是日常优化中最常用的三板斧。第一板斧数据库索引。SQL 慢先加索引这个大家都知道但加了索引不代表一定走索引。我总结几个最常见的“索引失效”场景都是面试必问、现场必踩的坑对索引列使用函数。比如WHERE DATE(create_time) 2024-06-11这个一旦套上函数索引就失效了会退化成全表扫描。正确做法是改成范围查询WHERE create_time 2024-06-11 00:00:00 AND create_time 2024-06-12 00:00:00。违反最左前缀匹配。表里有(shop_id, status, create_time)联合索引你如果直接查status 1对不起索引用不上。要带着最左列shop_id一起查。隐式类型转换。索引列是字符串条件值传了整数MySQL 会做类型转换索引失效。LIKE 模糊匹配以通配符开头%关键字%这种查询命中不了索引只能全表扫。这里的关键心得是每写一条 SQL都要做到心中有“执行计划”。不要觉得 EXPLAIN 是 DBA 的事。打开它看到type: ALL就要警惕看到type: ref或range才算基本靠谱。第二板斧缓存。缓存不是万能药但在读多写少的场景里它确实是最便宜的提性能手段。经典的 Cache-Aside 模式先查缓存命中直接返回没命中就查数据库再回写缓存。但要小心三个经典问题缓存穿透某个 key 根本不存在请求直接打穿缓存打到数据库。解决方法是缓存空值或者布隆过滤器挡住。缓存击穿一个热点 key 过期的一瞬间大量并发请求同时打到数据库。解决方法是加互斥锁让一个线程去重建缓存其他线程等待。缓存雪崩大量 key 同一时间过期导致数据库瞬间压力过大。解决方法就是把过期时间加上随机抖动比如 300 秒基础上加 1~30 秒随机数。这每一个问题我都见过真实事故不是理论。有一回就是配置了一个热点商品的缓存过期时间没加抖动零点一过商品刷新几万个 key 同时过期数据库连接池瞬间被打满整站卡了十分钟。第三板斧异步化。不是所有调用都必须同步等待结果。发短信、发邮件、推送消息、更新统计信息这些非核心链路完全可以丢到 MQ 里异步处理。异步化最大的价值是削峰填谷让请求先快速返回真正的处理在后台排队完成。举个我优化过的例子一个下订单接口里面同步调用了发送短信通知的 RPC这个 RPC 偶尔要 2 秒。你说一句“短信晚 2 秒收到”对用户体验毫无影响但下订单接口的 P99 却因为这条链路被拉爆。改成 MQ 异步之后接口 P99 直接掉了 400ms。异步化是最容易被人忽略、但收益又非常稳定的一种优化手段。3.3 写码层面的反模式清单如果方向和手段都对了接下来就看细节。下面这几条写码层面的问题是我在过去几年 code review 里反复看到的几乎每个都是性能杀手循环里做 IO。不管是查数据库、调 RPC 还是写日志循环里做一次就多一次网络往返规模化之后就成大坑。大对象反复拼接。在循环里用String直接拼字符串Java 里每次都会生成新对象改成StringBuilder能省一大截内存和 CPU。Python 里则用join。重复创建连接/客户端。每次请求都 new 一个 HTTP Client连接都没有复用的机会。正确做法是全局复用连接池设置合理的超时和空闲连接数。不控制对象拷贝。无意义的deepCopy、不必要的把整个 List 转来转去都是在浪费内存。深分页问题。LIMIT 100000, 20这种分页MySQL 依然要扫描前面十万行然后丢弃越翻越慢。正确做法是游标分页WHERE id 上一页最大ID ORDER BY id LIMIT 20或者基于索引的 seek 方法。这些反模式看着都挺基础但永远有人在犯。一个系统慢下来通常不是某一个原因而是几个反模式叠加在一起每层都拖一点最后就拖垮了整个接口。4. 实战案例一次接口耗时从 2.8s 降到 180ms 的完整复盘4.1 现场P99 常年飘红用户天天抱怨前阵子接手一个订单列表查询接口的优化任务。业务背景其实很简单用户进入“我的订单”页面后端返回订单列表同时要展示每个订单的评论数、物流状态、关联的营销活动信息。刚开始我拿到的数据是接口 P99 稳定在 2800msP50 也有 600ms。QPS 不算高只有 50 左右但架不住用户体验极差客服那边的工单都堆满了。排查的第一步我先看链路追踪。在调用链上可以看到整个请求时间的分布数据库环节占了 1.6 秒外部服务调用占了 0.4 秒其余是代码逻辑。明显的热点在数据库环节于是我看慢查询日志果然有一堆慢 SQL 在排队。4.2 定位根因三个问题叠加慢查询日志拿到之后我顺着代码逐层翻发现这个接口里其实藏着三个问题问题一N1 查询。主查询返回了用户最近的 20 个订单然后代码里循环遍历每一个订单去查一次这个订单的评论数。也就是说页面渲染 20 个订单数据库要查 1 次订单表 20 次评论表。每张评论表的查询本身不慢但 21 次数据库往返叠加起来光网络开销就够喝一壶的。问题二索引失效。其中一个条件过滤是查某一天创建的订单代码写的是SELECT * FROM order_table WHERE DATE(create_time) 2024-06-11 AND shop_id 123create_time上有索引但是套了一层DATE()函数索引直接被废掉。EXPLAIN 显示是全表扫。这还只是展示页一个不起眼的筛选条件结果导致每次查询都要把整张表过一遍。问题三同步调用了不需要实时的统计服务。接口里有一段逻辑是查询这个用户累计订单数量的统计数据但这个数字其实有一个小时都不变。原代码却是同步 RPC 调用跨机房往返一次固定 300 到 500ms。这三个问题单独看都不算大毛病但叠在一起就把接口拖到了秒级。4.3 修复过程与效果验证修复的思路很简单但每一步都用数据验证。修复 N1 查询把 20 次评论数查询合并成一次批量查询。用IN查出所有订单 ID然后 groupBy 一下// 优化前 for (Order order : orders) { Integer count commentMapper.countByOrderId(order.getId()); order.setCommentCount(count); } // 优化后 ListLong orderIds orders.stream().map(Order::getId).toList(); MapLong, Integer countMap commentMapper.countGroupByOrderIds(orderIds); orders.forEach(order - order.setCommentCount(countMap.getOrDefault(order.getId(), 0)));数据库往返次数直接降为 1 次。修复索引失效把日期函数包裹的条件改造成范围查询-- 优化前 WHERE DATE(create_time) 2024-06-11 AND shop_id 123 -- 优化后 WHERE create_time 2024-06-11 00:00:00 AND create_time 2024-06-12 00:00:00 AND shop_id 123再跑 EXPLAINtype从ALL变成了range扫描行数从 45 万降到了 20 行。修复同步统计服务把统计信息的获取改成缓存读取Redis 缓存 5 分钟缓存没有再去拉取统计服务并设置缓存回填StatDTO stat statCache.get(userId); if (stat null) { stat statClient.fetchStat(userId); statCache.set(userId, stat, 5 * 60); }改动上线后放量观察一周数据对比如下指标优化前优化后接口 P50600ms65ms接口 P992800ms180ms单请求数据库查询次数约 22 次3 次数据库 CPU70%20%这个结果说明大部分性能问题的收益其实藏在“常规手段做到位”里不需要什么黑科技。4.4 回归验证与稳定性提醒优化上线并不是结束。这里有一个很多人会忽略的步骤回归验证。我上线后做了三件事第一压测对比优化前后的吞吐量确认新代码在高并发下不会出现连接泄露第二持续观察一星期线上监控重点看 P999、错误率、GC 曲线有没有异常第三对缓存和异步改动做降级演练确保缓存挂了不影响主链路。我特别想提醒一点任何优化改动都要小步快跑不要一次上一个大重构。有一次我把一个核心接口的逻辑大改了一遍结果某些边界 case 没覆盖到上线半小时内就发现金额字段格式不对赶紧回滚。从那以后我给自己定了一条规矩性能优化哪怕一次能改十个点也至少要拆成三次上线每次只验证一部分效果。这样出了问题排查半径小很多。5. 常见性能故障与排查技巧速查优化做得多了你会发现线上性能故障其实就那么几类。下面这张表我攒了很多年每次从零排查的时候都会先对照一遍省下不少时间。症状常见原因排查命令/手法推荐解法接口偶发变慢P99 飙升慢 SQL、锁等待慢查询日志、EXPLAIN、SHOW PROCESSLIST优化 SQL、加索引、避免长事务CPU 居高不下正则匹配、序列化、GC 压力大top 火焰图采样预编译正则、批量处理、减少对象创建内存持续上涨内存泄漏、大对象囤积堆 dump、JFR、jmap分析 dump 找引用链修复泄漏点线程都在 BLOCKED锁竞争、数据库连接池耗尽jstack看线程栈缩小锁粒度、排查慢 SQL、调大连接池但注意上限缓存命中率极低缓存穿透、key 过期时间不合理Redis 的INFO stats、hit rate空值缓存、随机过期、布隆过滤器接口越来越慢但系统没变化深分页、数据量增长慢 SQL 日志、EXPLAIN 扫描行数游标分页、合理归档旧数据这张表不是标准答案但每一条我都踩过真实案例。拿锁等待举例有次线上接口大面积超时查 JVM 线程栈发现 90% 的线程卡在同一个对象锁上再看业务代码原来是导出 Excel 的定时任务持有了一把业务锁跑了十分钟才释放所有用户请求排队等锁。解法也很笨把定时任务移到凌晨低峰期加分布式锁防止多实例重复执行。再有一个关于排查的独家心得一次只改一个变量。很多人排查性能问题喜欢同时试好几种方案改完索引又改代码又调 JVM 参数。最后性能确实变好了但你根本不知道是哪一步起的作用下次遇到类似问题还得重新猜。正确做法是先记录现状指标改一个点验证一个点确认有效再继续下一个。6. 关于“更好的优化”我的几点笨办法前面讲了很多方法、工具和案例最后想聊聊我在实际工作中的个人体会。第一件事优化要有“体感”。不要只盯着监控面板上的曲线。有机会的话找个低峰期真实地用一个移动网络在手机上去点那个你负责的页面感受一下响应速度。数字是理性的但业务方的抱怨和人体的不耐烦是感性的。很多一眼就能看出来“这个接口绝对不适合用户”的设计都是在我自己实际操作了一次之后才真正下定决心去改的。第二件事养成记录优化日志的习惯。我每做一个优化就在一个笔记文件里记录四样东西优化前的指标数据、做了什么动作、优化后的指标数据、有没有引入新的问题。坚持一两年之后你对自己负责的系统会有一个非常宝贵的“性能时间线”这也是跟别人讲清楚“你到底做了什么”的最好凭据。第三件事优先选最简单、最朴素、最可见的方案。如果一个系统变慢先检查有没有明显的 N1、索引失效、同步非核心调用这些永远比调 GC 参数、引入新的框架、改造架构更有性价比。我做优化的优先级永远是这样先看是不是代码写烂了再看是不是数据结构和算法不够好再看能不能加索引、缓存、异步最后才轮到调 JVM、换硬件、上微服务。不是因为后面的手段没用而是前面的手段成本更低、可控性更强。最后一点做完一个优化不要急着宣告胜利。等一周看看 P999 是不是稳定看看凌晨的定时任务是不是受影响了看看发布回滚是不是顺畅。性能优化不是一个瞬间的动作而是一个连续的治理过程。好的系统不是“优化”出来的是一次又一次“重新审视需求、重新测量、重新动手”之后长出来的。愿你我都能做出真正“更好的优化”。
性能优化实战：从目标设定到2.8s降至180ms的完整方法论
聊到“更好的优化”我得先泼一盆冷水很多人做的优化其实是在瞎忙。接口慢了就加缓存CPU高了就调GC参数数据库卡了就升配置——不能说完全没效果但本质上是在治标而且常常把系统越改越复杂。我在一线做后台开发和性能治理这么多年踩过无数坑之后才慢慢想明白一件事真正的“更好的优化”不是某一个炫技操作而是一整套可以复用的方法论——先定目标再测量再动手最后还要回头验证。这篇文章就把这套方法论和一次完整的实战复盘掰开揉碎讲给你听。适合正在做后端接口优化、处理线上性能故障或者想要系统学习性能优化思路的开发同学。1. “更好的优化”到底优化什么先定目标再动手1.1 性能优化的真正目标函数我见过太多团队把“优化”等同于“把指标压低”。接口从 500ms 优化到 300ms 就觉得完事了再压到 100ms 就觉得了不起。但实际上任何优化动作都必须回答一个问题优化的目标函数是什么这里的“目标函数”不是数学黑话而是你做这件事想换来的最终收益。举三个真实场景你就懂了。场景一电商核心下单接口。这个接口的优化目标一定是端到端延迟的 P99和可用性因为你快 10ms 都可能影响转化率而失败率哪怕涨 0.1% 都会造成真金白银的损失。这时候哪怕牺牲一点开发效率也值得做精细化的并发控制、连接池调优、缓存预热。场景二内部数据平台的离线报表。每天凌晨跑一次跑 20 分钟还是 25 分钟业务完全无感。这时候优化的目标就不是延迟而是资源成本和稳定性。与其花三天去抠 SQL 的几十毫秒不如把目标定成“用一半的 Spark 资源跑完”这个 ROI 高得多。场景三一个只有几十人用的后台管理系统。你说它按钮响应 800ms 是不是问题是问题但优先级极低。你要是把所有热情都用在这上面老板只会觉得你闲得慌。更好的优化在这里是“别写死循环、别锁表、别让用户等 5 秒以上”做到这个级别就够了。所以看到“优化”两个字我的条件反射不是去翻代码而是去问需求方你希望换来什么是更高的吞吐、更低的延迟、更低的成本还是更稳定的运行这世界上不存在绝对“最快”的系统只有“在约束条件下最合适的系统”。这就像买房子光看面积大没有用得看地段、户型、采光、单价一综合才谈得上“更好的选择”。1.2 过早优化与合理规划的边界“过早优化是万恶之源”这句话被引用烂了但很多人理解偏了。这句话不是让你完全不优化而是反对在没有数据支撑的情况下为了“以后可能会用到”的复杂设计提前买单。我的经验是区分两层来对待第一层架构层面留对风口。比如你在设计订单表时把order_id设计成雪花 ID 而不是自增主键这是一个合理的架构决策为将来分库分表留了可能。再比如接口层的超时配置、熔断降级的预留这些属于合理的提前规划成本不高但收益很大。第二层代码层面不过度设计。比如一个表在一千条数据量级就不要一上来就搞缓存、分库分表。有人用 Redis 给一张三千行的配置表做了一层“高性能缓存”看起来很有技术感实际上除了增加数据不一致的风险没有任何收益。这种就是典型的过度优化。我自己的判断标准很简单如果这个优化动作在三五天内不做系统也不会挂那它大概率不属于“紧急优化”。反过来如果现在不做等数据量翻十倍的时候要做就得改核心链路那这个优化必须现在就做。数据库的索引设计、核心链路的日志埋点、API 的契约设计都是值得提前规划的而具体的并发模型、缓存策略、连接池大小等到流量和数据规模逼到面前再优化完全来得及。2. 没有测量就没有优化用数据代替感觉2.1 三层观测体系应用层、代码层、数据库层做优化最忌讳“凭感觉”。我见过太多同事拍着胸脯说“这个接口慢就是数据库问题”结果一查代码发现是他在循环里同步调了三五次 RPC。所以动手之前先建立观测体系。我建议从三个层面去做测量缺一层都容易误判应用层指标核心监控就是 API 的 RT、QPS、吞吐量、错误率。工具可选 Prometheus Grafana 做指标看板配合 SkyWalking、Zipkin、Jaeger 这类链路追踪系统看调用链。这一层解决的是“哪个接口慢、慢在哪个环节”。代码层剖析当你知道某个接口慢之后要看它到底在哪个函数里耗时间。Java 服务可以用 async-profiler 或者 JDK 自带 JFR 做采样生成火焰图Go 服务用 pprofPython 用 py-spy。这一层解决的是“哪一行代码是罪魁祸首”。数据库层诊断打开 MySQL 慢查询日志找到执行时间超过阈值比如 100ms的 SQL然后用 EXPLAIN 看执行计划。这一层解决的是“是不是 SQL 走了全表扫描、是不是没用索引”。这三个层面的数据必须结合起来看缺一个都可能得出错误结论。我见过一个团队查线上数据库 CPU 飙高的故障查了三天数据库慢查询结果发现罪魁祸首是应用层每台机器定时任务同时去刷一个统计报表跟数据库索引一点关系都没有。2.2 为什么平均值毫无意义请关注 P99 和 P99.9每次聊性能指标我都要强调一个观点平均值是骗人的。举个例子假设一个接口一天有一万次调用其中 9900 次都是 50ms 返回剩下 100 次因为某条 SQL 偶发慢查询要 5 秒返回。平均值算下来大概是 99.5ms看着挺快。可那 100 个用户每人等了 5 秒他们不会觉得这是个 “百毫秒级” 的接口他们只会觉得“这系统真垃圾”。所以做性能优化我只看尾延迟P99 表示 99% 的请求都小于这个值P999 表示 99.9% 的请求都小于这个值。平均值像平均工资P99 才像真正的贫富差距。一个接口的平均耗时再漂亮P99 长时间飘红就说明系统仍然存在严重的性能短板。监控面板上我通常会把 P50、P99、P999 三条曲线一起放还要加一条“最大耗时点”事件标记用来追踪是哪一个时间窗口出现了长尾。优化之前先记录这些数据优化之后重新对比用数字说话而不是用“感觉变快了”说话。2.3 火焰图怎么读别被花哨的图形吓住火焰图这个东西第一次看到的人往往会觉得眼花缭乱。其实读法非常简单横轴是采样比例或者时间纵轴是调用栈每一根“柱子”越宽代表这个函数消耗的时间占比越高。我来说一个实际场景。一个 Java 服务CPU 使用率一直下不来用async-profiler跑一下./profiler.sh -d 60 -o collapsed pid采样一分钟然后用 FlameGraph 脚本生成火焰图你大概率能在地层底层平台和上层业务代码之间看到某个方法的“宽柱子”。前阵子我就遇到一个案例火焰图里String.matches()方法占了一大块点进去才发现是一个收单程序在每次进来一个 key 的时候都用正则去校验消息格式。正则表达式每次编译匹配CPU 消耗巨大。改成预编译 Pattern 之后CPU 直接降了 30%。这就是火焰图的价值不用猜一眼就能锁定热点。所以再强调一次任何优化动作都必须在测量之后进行。你没数据就动手和蒙着眼睛拆炸弹没区别。3. 分层优化的实操手段从算法到写码3.1 算法和数据结构是上限其他都是优化这个上限很多长期做业务开发的同学有个误区觉得算法是面试题、平时用不上。但真正到了性能层面聊“更好的优化”算法和数据结构是第一优先级因为它是性能的上限而缓存、并发、索引这些手段只是在逼近这个上限。我给你举一个我手头踩过的真实改造。当时有一个批量查询接口需要根据一批订单 ID 查询对应的买家昵称。原始代码是这样for (Long buyerId : buyerIdList) { Buyer buyer buyerMapper.selectById(buyerId); // 一次数据库查询 names.add(buyer.getName()); }这段代码如果buyerIdList只有 10 个问题不明显但如果订单量到了 1 万就意味着 1 万次数据库往返每次就算 0.5ms也要 5 秒。这里优化第一步不是加缓存而是把循环查询改成批量查询ListBuyer buyers buyerMapper.selectByIds(buyerIdList); // 一次 IN 查询 MapLong, String nameMap buyers.stream().collect(Collectors.toMap(Buyer::getId, Buyer::getName));单次查询的次数从 N 次变成 1 次这个差距是数量级的缓存再多也弥补不了。很多所谓慢接口第一刀砍的其实是这种“循环里做 IO”的烂代码。再比如一个需求要判断某个 ID 是否存在于一个集合里有些人随手就写list.contains(id)当集合有十万个元素、判断要执行一万次的时候复杂度就是 O(N×M)慢得感人。改成HashSet之后每次contains都是 O(1)整体复杂度直接降到 O(NM)。这就是数据结构的价值一分钱不花纯粹靠聪明程度换来性能提升。3.2 索引、缓存、异步三大常规武器及正确用法如果说算法是再“设计”一次下面这三个手段就是再“部署”一次它们也是日常优化中最常用的三板斧。第一板斧数据库索引。SQL 慢先加索引这个大家都知道但加了索引不代表一定走索引。我总结几个最常见的“索引失效”场景都是面试必问、现场必踩的坑对索引列使用函数。比如WHERE DATE(create_time) 2024-06-11这个一旦套上函数索引就失效了会退化成全表扫描。正确做法是改成范围查询WHERE create_time 2024-06-11 00:00:00 AND create_time 2024-06-12 00:00:00。违反最左前缀匹配。表里有(shop_id, status, create_time)联合索引你如果直接查status 1对不起索引用不上。要带着最左列shop_id一起查。隐式类型转换。索引列是字符串条件值传了整数MySQL 会做类型转换索引失效。LIKE 模糊匹配以通配符开头%关键字%这种查询命中不了索引只能全表扫。这里的关键心得是每写一条 SQL都要做到心中有“执行计划”。不要觉得 EXPLAIN 是 DBA 的事。打开它看到type: ALL就要警惕看到type: ref或range才算基本靠谱。第二板斧缓存。缓存不是万能药但在读多写少的场景里它确实是最便宜的提性能手段。经典的 Cache-Aside 模式先查缓存命中直接返回没命中就查数据库再回写缓存。但要小心三个经典问题缓存穿透某个 key 根本不存在请求直接打穿缓存打到数据库。解决方法是缓存空值或者布隆过滤器挡住。缓存击穿一个热点 key 过期的一瞬间大量并发请求同时打到数据库。解决方法是加互斥锁让一个线程去重建缓存其他线程等待。缓存雪崩大量 key 同一时间过期导致数据库瞬间压力过大。解决方法就是把过期时间加上随机抖动比如 300 秒基础上加 1~30 秒随机数。这每一个问题我都见过真实事故不是理论。有一回就是配置了一个热点商品的缓存过期时间没加抖动零点一过商品刷新几万个 key 同时过期数据库连接池瞬间被打满整站卡了十分钟。第三板斧异步化。不是所有调用都必须同步等待结果。发短信、发邮件、推送消息、更新统计信息这些非核心链路完全可以丢到 MQ 里异步处理。异步化最大的价值是削峰填谷让请求先快速返回真正的处理在后台排队完成。举个我优化过的例子一个下订单接口里面同步调用了发送短信通知的 RPC这个 RPC 偶尔要 2 秒。你说一句“短信晚 2 秒收到”对用户体验毫无影响但下订单接口的 P99 却因为这条链路被拉爆。改成 MQ 异步之后接口 P99 直接掉了 400ms。异步化是最容易被人忽略、但收益又非常稳定的一种优化手段。3.3 写码层面的反模式清单如果方向和手段都对了接下来就看细节。下面这几条写码层面的问题是我在过去几年 code review 里反复看到的几乎每个都是性能杀手循环里做 IO。不管是查数据库、调 RPC 还是写日志循环里做一次就多一次网络往返规模化之后就成大坑。大对象反复拼接。在循环里用String直接拼字符串Java 里每次都会生成新对象改成StringBuilder能省一大截内存和 CPU。Python 里则用join。重复创建连接/客户端。每次请求都 new 一个 HTTP Client连接都没有复用的机会。正确做法是全局复用连接池设置合理的超时和空闲连接数。不控制对象拷贝。无意义的deepCopy、不必要的把整个 List 转来转去都是在浪费内存。深分页问题。LIMIT 100000, 20这种分页MySQL 依然要扫描前面十万行然后丢弃越翻越慢。正确做法是游标分页WHERE id 上一页最大ID ORDER BY id LIMIT 20或者基于索引的 seek 方法。这些反模式看着都挺基础但永远有人在犯。一个系统慢下来通常不是某一个原因而是几个反模式叠加在一起每层都拖一点最后就拖垮了整个接口。4. 实战案例一次接口耗时从 2.8s 降到 180ms 的完整复盘4.1 现场P99 常年飘红用户天天抱怨前阵子接手一个订单列表查询接口的优化任务。业务背景其实很简单用户进入“我的订单”页面后端返回订单列表同时要展示每个订单的评论数、物流状态、关联的营销活动信息。刚开始我拿到的数据是接口 P99 稳定在 2800msP50 也有 600ms。QPS 不算高只有 50 左右但架不住用户体验极差客服那边的工单都堆满了。排查的第一步我先看链路追踪。在调用链上可以看到整个请求时间的分布数据库环节占了 1.6 秒外部服务调用占了 0.4 秒其余是代码逻辑。明显的热点在数据库环节于是我看慢查询日志果然有一堆慢 SQL 在排队。4.2 定位根因三个问题叠加慢查询日志拿到之后我顺着代码逐层翻发现这个接口里其实藏着三个问题问题一N1 查询。主查询返回了用户最近的 20 个订单然后代码里循环遍历每一个订单去查一次这个订单的评论数。也就是说页面渲染 20 个订单数据库要查 1 次订单表 20 次评论表。每张评论表的查询本身不慢但 21 次数据库往返叠加起来光网络开销就够喝一壶的。问题二索引失效。其中一个条件过滤是查某一天创建的订单代码写的是SELECT * FROM order_table WHERE DATE(create_time) 2024-06-11 AND shop_id 123create_time上有索引但是套了一层DATE()函数索引直接被废掉。EXPLAIN 显示是全表扫。这还只是展示页一个不起眼的筛选条件结果导致每次查询都要把整张表过一遍。问题三同步调用了不需要实时的统计服务。接口里有一段逻辑是查询这个用户累计订单数量的统计数据但这个数字其实有一个小时都不变。原代码却是同步 RPC 调用跨机房往返一次固定 300 到 500ms。这三个问题单独看都不算大毛病但叠在一起就把接口拖到了秒级。4.3 修复过程与效果验证修复的思路很简单但每一步都用数据验证。修复 N1 查询把 20 次评论数查询合并成一次批量查询。用IN查出所有订单 ID然后 groupBy 一下// 优化前 for (Order order : orders) { Integer count commentMapper.countByOrderId(order.getId()); order.setCommentCount(count); } // 优化后 ListLong orderIds orders.stream().map(Order::getId).toList(); MapLong, Integer countMap commentMapper.countGroupByOrderIds(orderIds); orders.forEach(order - order.setCommentCount(countMap.getOrDefault(order.getId(), 0)));数据库往返次数直接降为 1 次。修复索引失效把日期函数包裹的条件改造成范围查询-- 优化前 WHERE DATE(create_time) 2024-06-11 AND shop_id 123 -- 优化后 WHERE create_time 2024-06-11 00:00:00 AND create_time 2024-06-12 00:00:00 AND shop_id 123再跑 EXPLAINtype从ALL变成了range扫描行数从 45 万降到了 20 行。修复同步统计服务把统计信息的获取改成缓存读取Redis 缓存 5 分钟缓存没有再去拉取统计服务并设置缓存回填StatDTO stat statCache.get(userId); if (stat null) { stat statClient.fetchStat(userId); statCache.set(userId, stat, 5 * 60); }改动上线后放量观察一周数据对比如下指标优化前优化后接口 P50600ms65ms接口 P992800ms180ms单请求数据库查询次数约 22 次3 次数据库 CPU70%20%这个结果说明大部分性能问题的收益其实藏在“常规手段做到位”里不需要什么黑科技。4.4 回归验证与稳定性提醒优化上线并不是结束。这里有一个很多人会忽略的步骤回归验证。我上线后做了三件事第一压测对比优化前后的吞吐量确认新代码在高并发下不会出现连接泄露第二持续观察一星期线上监控重点看 P999、错误率、GC 曲线有没有异常第三对缓存和异步改动做降级演练确保缓存挂了不影响主链路。我特别想提醒一点任何优化改动都要小步快跑不要一次上一个大重构。有一次我把一个核心接口的逻辑大改了一遍结果某些边界 case 没覆盖到上线半小时内就发现金额字段格式不对赶紧回滚。从那以后我给自己定了一条规矩性能优化哪怕一次能改十个点也至少要拆成三次上线每次只验证一部分效果。这样出了问题排查半径小很多。5. 常见性能故障与排查技巧速查优化做得多了你会发现线上性能故障其实就那么几类。下面这张表我攒了很多年每次从零排查的时候都会先对照一遍省下不少时间。症状常见原因排查命令/手法推荐解法接口偶发变慢P99 飙升慢 SQL、锁等待慢查询日志、EXPLAIN、SHOW PROCESSLIST优化 SQL、加索引、避免长事务CPU 居高不下正则匹配、序列化、GC 压力大top 火焰图采样预编译正则、批量处理、减少对象创建内存持续上涨内存泄漏、大对象囤积堆 dump、JFR、jmap分析 dump 找引用链修复泄漏点线程都在 BLOCKED锁竞争、数据库连接池耗尽jstack看线程栈缩小锁粒度、排查慢 SQL、调大连接池但注意上限缓存命中率极低缓存穿透、key 过期时间不合理Redis 的INFO stats、hit rate空值缓存、随机过期、布隆过滤器接口越来越慢但系统没变化深分页、数据量增长慢 SQL 日志、EXPLAIN 扫描行数游标分页、合理归档旧数据这张表不是标准答案但每一条我都踩过真实案例。拿锁等待举例有次线上接口大面积超时查 JVM 线程栈发现 90% 的线程卡在同一个对象锁上再看业务代码原来是导出 Excel 的定时任务持有了一把业务锁跑了十分钟才释放所有用户请求排队等锁。解法也很笨把定时任务移到凌晨低峰期加分布式锁防止多实例重复执行。再有一个关于排查的独家心得一次只改一个变量。很多人排查性能问题喜欢同时试好几种方案改完索引又改代码又调 JVM 参数。最后性能确实变好了但你根本不知道是哪一步起的作用下次遇到类似问题还得重新猜。正确做法是先记录现状指标改一个点验证一个点确认有效再继续下一个。6. 关于“更好的优化”我的几点笨办法前面讲了很多方法、工具和案例最后想聊聊我在实际工作中的个人体会。第一件事优化要有“体感”。不要只盯着监控面板上的曲线。有机会的话找个低峰期真实地用一个移动网络在手机上去点那个你负责的页面感受一下响应速度。数字是理性的但业务方的抱怨和人体的不耐烦是感性的。很多一眼就能看出来“这个接口绝对不适合用户”的设计都是在我自己实际操作了一次之后才真正下定决心去改的。第二件事养成记录优化日志的习惯。我每做一个优化就在一个笔记文件里记录四样东西优化前的指标数据、做了什么动作、优化后的指标数据、有没有引入新的问题。坚持一两年之后你对自己负责的系统会有一个非常宝贵的“性能时间线”这也是跟别人讲清楚“你到底做了什么”的最好凭据。第三件事优先选最简单、最朴素、最可见的方案。如果一个系统变慢先检查有没有明显的 N1、索引失效、同步非核心调用这些永远比调 GC 参数、引入新的框架、改造架构更有性价比。我做优化的优先级永远是这样先看是不是代码写烂了再看是不是数据结构和算法不够好再看能不能加索引、缓存、异步最后才轮到调 JVM、换硬件、上微服务。不是因为后面的手段没用而是前面的手段成本更低、可控性更强。最后一点做完一个优化不要急着宣告胜利。等一周看看 P999 是不是稳定看看凌晨的定时任务是不是受影响了看看发布回滚是不是顺畅。性能优化不是一个瞬间的动作而是一个连续的治理过程。好的系统不是“优化”出来的是一次又一次“重新审视需求、重新测量、重新动手”之后长出来的。愿你我都能做出真正“更好的优化”。
