老项目性能优化实战：从定位瓶颈到缓存、SQL与线程池调优

要说项目优化要点，最核心的其实不是什么高深技术，而是先把问题找对。前阵子我接手了一个跑了三年的内部业务系统，高峰期接口P95响应时间直接飙到3秒多，时不时还收到内存溢出的告警。最让人崩溃的是，团队里每个人都在说“这项目太老了，得重构”，但问到具体哪里慢、为什么慢，没有人能说清楚。

这篇文章就围绕一次实际的项目优化过程，把从定位瓶颈、到动手优化、再到验证效果的完整思路写出来。整个过程不依赖大规模重构，也不需要引入一堆新奇框架，适合正在被线上性能问题困扰的后端、运维和全栈工程师参考。哪怕你手上是一个老项目，只要照这套方法一步步来，也能逐步把它拉回正常水位。

1. 先别急着改代码：项目优化要点的总体思路

遇到性能问题，大多数人第一反应是“某个接口写得不行”，于是打开代码找几个可疑的段落开始改。这个做法最大的问题是：你在改动之前，根本不知道时间到底花在了哪里。项目优化要解决的核心其实只有两件事，一是怎么把问题找准，二是怎么让每一次改动都可控。

1.1 从现象倒推根因，优化才不会被带偏

线上系统慢，表象是接口响应慢，但底层原因可能五花八门。有可能是SQL没走索引，也有可能是下游接口超时，还有可能是线程池排队、GC停顿、CPU竞争、大对象序列化，甚至只是某台机器的磁盘IO出了问题。

我在实际排查中就遇到过这种情况：表面上是一个订单导出接口很慢，业务方反馈“点一次要等半分钟”。刚开始看代码，发现里面有一个for循环，循环里每次调一次外部服务，第一反应是觉得外部服务拖慢了速度。结果加上调用链追踪之后发现，真正耗时的地方根本不在外部请求，而是每次循环里重新查了一次配置表，配置表数据量涨到几十万行之后，这条“附带”的SQL反而成了最大的瓶颈。

这就是典型的“现象倒推根因”场景。正确的做法是形成一个“现象—假设—验证”的闭环：先记录现象，比如响应时间、错误数、CPU曲线；然后提出几个可能的假设；再通过日志、监控、链路追踪去验证；最后锁定了根因再做改动。而不是看到一个可疑代码就上手改，那样很容易把项目改得越来越乱。

1.2 定一个明确的目标，量化每一步收益

优化最忌讳的目标叫“让系统变快一点”，因为“快一点”没法衡量，也没法验证。真正可执行的目标应该是一个数字。比如我们的目标定成：核心接口P95响应时间从2500毫秒降到800毫秒以内，高峰期CPU使用率峰值不超过75%，Full GC次数从每小时8次降到接近0。

定完目标之后，我习惯用一张表来记录每一步的收益。表里很简单，就是三列：优化项、改动前数据、改动后数据。这张表在优化结束后非常有用，它既是给团队看的交付物，也是给自己复盘用的依据。没有数字支撑的优化报告是没有说服力的，有了这张表，你才知道哪一步真正产生了价值，哪一步属于瞎折腾。

顺便说一下，很多人会忽略一个细节：在做优化之前，一定要先确认当前系统的“基线数据”是稳定的。如果本来线上就在频繁发版、业务数据就在猛涨，那你测出来的数据可能根本不准。我一般会先观察一两周的监控曲线，确认基线稳定之后，才开始动手。

2. 定位瓶颈：性能数据不会说谎

优化工作里最花时间的往往不是改代码，而是找瓶颈。线上环境和本地不一样，你不能随便加日志然后重新部署，所以优先顺序很重要。我的经验是：先看监控大盘和APM，再看慢SQL和GC日志，最后才上火焰图。每一层工具解决一个层面的问题，跳过任何一步都可能让你绕远路。

2.1 用APM和日志先把“故障现场”还原出来

APM工具的价值在于它能给你一条完整的调用链。比如SkyWalking或者Pinpoint，部署好之后，可以看到一个请求从进入网关、调用服务A、再调服务B、最后查询数据库，每一步各花了多少时间。有了这个，你就可以快速判断耗时到底是集中在哪一段。

如果团队成本有限，不想引入完整APM体系，也有一个轻量办法：在网关层统一记录每个请求的处理时间和上游耗时，再让每个服务在入口打印一条“入参、耗时、结果”的标准日志。这样即使没有完整的链路追踪，也能通过请求ID把一段日志串起来，找到耗时大户。

看日志的时候要特别注意关联性。我遇到过很多次，接口本身执行得很快，但整体响应就是慢，后来发现是网关到服务之间有一个连接池配置过小，流量一上来就排队。这种情况如果只看单服务日志，根本看不出问题。所以拿到一条慢请求之后，尽量把从最外层到最内层的所有日志都翻一遍，把“时间黑洞”定位到某一个具体的服务或数据库操作上。

2.2 慢SQL、GC日志和火焰图，三板斧找到真凶

慢SQL日志几乎是所有后端优化里最值得优先看的数据。很多数据库默认关闭了慢查询日志，或者阈值设得太高，导致你根本发现不了问题。我一般会把慢查询阈值设成200毫秒或500毫秒，持续收集几天，然后再来分析。分析时重点看执行计划，检查有没有全表扫描、有没有filesort、索引有没有真正生效。

GC日志是另一个信息富矿。Young GC如果非常频繁，说明短生命周期对象太多，分配压力大；Full GC频繁，那就要怀疑堆是不是太小、缓存是不是驻留大量对象，或者是代码里有长期持有大引用的地方。看到Full GC次数明显异常时，我一般还会配合堆转储来看，直接定位到具体是哪类对象占着内存不释放。

火焰图适合定位CPU密集型的热点代码。用Async-profiler之类的工具在压测或高峰期抓几分钟数据，就能看到某个函数消耗了多少CPU。你可能会惊讶地发现，平时觉得“复杂的业务逻辑”根本不是热点，真正吃CPU的是一个简单的字符串拼接或者序列化工具。下面这张表是我做瓶颈分析时常用到的排查对照，可以帮你快速缩小范围：

这套三板斧用下来，绝大多数项目的性能瓶颈都能定位到“可执行的层面”。如果这三样看完了还是找不到原因，那就要考虑是不是基础设施层面出了问题，比如宿主机CPU争抢、网络抖动、或者磁盘IO异常。老项目尤其容易出现这类“隐性故障”，因为环境复杂，谁都不会第一时间怀疑到基础设施。

3. 核心优化动作：缓存、并发与代码热点的实战调整

真正开始动手的时候，顺序很重要。我的经验是：先做不需要动架构的改动，也就是缓存、SQL、连接池、线程池这些。这类改动风险低、见效快，几天内就能看到数据变化。不要一上来就拆服务、换框架，那是最后逼不得已才做的事情。

3.1 缓存设计：不是所有数据都值得缓存

缓存是优化里最常用的手段，但也是最容易被滥用的手段。我曾经看到有团队把所有查询结果都塞进缓存，结果数据更新之后缓存和数据库不一致，又得专门写一堆缓存清理逻辑。实际上，缓存只适合两类数据：一类是读多写少的，另一类是实时性要求不高的。

举个例子，当时系统里有一个商品标签配置接口，每次请求都要查一次MySQL，可这份配置一周都可能不更新一次。这个场景加一个本地缓存，TTL设成60秒，就足够解决问题了，接口耗时从30毫秒降到了1毫秒左右。这种改动几乎零风险，而且效果立竿见影。

当然，用缓存也要考虑几个经典问题：缓存穿透、缓存击穿和缓存雪崩。简单说，穿透是查一个根本不存在的数据，请求直接打到数据库；击穿是热点key失效瞬间大量请求打到数据库；雪崩是大面积key同时失效。工程上的通用做法并不复杂，穿透可以用空值缓存或者布隆过滤器挡一下，击穿可以用互斥锁重建缓存，雪崩则给过期时间加一个随机值，避免大量key在同一时刻过期。

我的建议是，不要一上来就上特别复杂的缓存框架。先搞清楚你的数据形态，“本地缓存+分布式缓存”的组合足够覆盖绝大多数业务场景。分布式缓存用来放热点数据，本地缓存用来放那些对一致性不敏感、但调用极其频繁的配置项。

3.2 数据库侧优化：索引、SQL重写与连接池参数

数据库优化是最容易拿到“收益数据”的部分。当时项目里有一条订单列表查询SQL，按用户ID和时间范围查订单，每次请求耗时220毫秒左右，不算特别慢，但因为这个接口被高频调用，累积起来对数据库压力很大。分析执行计划之后发现，表里只有user_id上的普通索引，而查询里还带了create_time范围条件，导致MySQL要先根据user_id捞出一堆数据，再做filesort排序，最后才分页返回。

优化思路其实很简单：建一个组合索引(user_id, create_time)，让MySQL可以直接按索引顺序扫描，省掉排序这一步。同时把select *改成只取需要的字段，减少数据传输量。改动上线后，同样的SQL耗时降到了5毫秒左右。这个案例也说明了一个道理：SQL慢，很多时候不是数据量太大，而是索引建得不对。

连接池参数也值得检查。常见的问题是maxActive配得过大或者过小。过小会导致请求排队，过大会让数据库连接数爆炸，反而把数据库拖垮。连接池的核心参数要结合压测来调，包括initialSize、maxActive、maxWait、minEvictableIdleTimeMillis这几个。我的经验是，先给一个相对保守的配置，然后通过压测逐步往上加，同时观察数据库这边的连接数曲线，找到一个双方都稳定的平衡点。

3.3 线程池与JVM参数：把资源用在刀刃上

线程池是并发问题的重灾区。之前接手的一个服务，核心线程数配了200，最大线程数也是200，队列用的还是无界队列。高峰期任务全部堆在队列里，接口响应时间一路飙升，CPU也被打满。后来重新梳理了业务类型，把核心线程数调小，同时给队列设了上限，超过上限后按拒绝策略处理，接口的排队时间才明显降下来。

线程池的核心参数其实只有在特定的流量模型下才有最优解。一般来说，CPU密集型任务的线程数可以按“CPU核数+1”来估算，IO密集型任务则可以稍微多配一些，但要靠压测来验证。队列长度要有限制，不能无脑用无界队列，否则流量一涌进来，积压的任务会拖垮整个服务。

JVM参数的调整更需要谨慎。当时我们遇到Full GC频繁的问题，第一反应是堆太小，于是把-Xmx直接调大。结果Full GC反而更慢了，因为堆变大之后，单次GC的耗时也变长了。后来才发现真正的问题是一段代码把大量配置对象长期持有在内存里，属于内存管理不当，而不是堆不够用。所以改JVM参数之前，一定要先弄清楚GC压力的来源。如果对象确实该回收，调堆大小只是治标不治本。

顺便说几个我常用的JVM调整原则：第一，-Xms和-Xmx设成同一个值，避免运行时动态扩容；第二，结合服务器物理内存来设置堆大小，给操作系统和外部进程留出余量；第三，开启GC日志，并且把GC日志单独存放，方便后期排查问题。

4. 优化不只在代码里：发布流程与配置治理

项目优化要点如果只盯着性能和代码，那只能算完成了一半。真正让优化能持续下去，还必须把发布流程和配置管理这块理顺，否则一次不靠谱的发版就能让前面所有的优化白费。

4.1 用CI/CD把发版从“高危操作”变成“日常动作”

很多老项目的痛点是一模一样的：发布靠人肉，打jar包、上传服务器、手动杀进程、再nohup启动。整个过程既慢又容易出错，一旦遇到回滚，基本就是翻出上一个包再折腾一遍。这种发布方式带来的直接后果是，大家不敢频繁发版，所有改动堆在一起，最后发一次大版本，风险又进一步放大。

我做的第一件事是把构建流程挪到流水线里：代码提交后自动触发构建，构建产物带上版本号；构建通过后自动部署到测试环境；部署到生产环境则通过一个按钮来操作。CI/CD工具本身不用纠结，GitLab CI或者Jenkins都可以，关键是先把“构建、部署、回滚”这三条链路通起来。

部署策略上，我强烈建议至少做到分批发布。所谓分批发布，就是先部署一台机器，验证没有问题之后，再滚动部署到其余机器。如果一个服务只部署在一个实例上，那不管优化做得再好，发布时终究还是有中断的风险。把单实例扩成多实例，同时让网关或负载均衡支持摘除节点，这样发布一台、验证一台、再继续下一台，整个过程的爆炸半径会小很多。

回滚设计也不能忽略。每次发布的镜像或制品都保留上一版本，并且把回滚操作做成脚本或流水线任务。我见过不只一次，线上出了事，大家还在手忙脚乱地翻历史包。一旦把回滚做成“一键”，你发布的时候底气会足很多，不用担心出事没人能收拾。

4.2 配置中心化与灰度发布，降低上线风险

代码里写配置是另一种隐患。最常见的就是数据库地址、第三方接口地址、超时时间直接写在application.yml里，改一次配置就要重新发一次包。而且每个环境配置还不一样，测试环境调好的东西，一上生产就出问题。更麻烦的是，有些开关类配置，比如“当前是否开启某个功能”，本来应该是线上随时能切换的，结果却是跟着代码走，想关都关不掉。

配置中心化要解决的就是这个问题。把配置从代码里拆出来，放到配置中心统一管理，修改之后实时生效，不用发版。这样数据库地址、超时时间、功能开关这些都能在控制台上改，而且最好有审计记录，谁在什么时间改了什么配置，都留得清清楚楚。我当时接手项目的第一周，就先把所有业务开关类配置抽了出来，后面遇到线上问题需要临时降级，就直接改配置，不用再紧急发版。

灰度发布是降低上线风险的另一个关键手段。它的思路很简单：新版本先放到小范围流量上验证，确认没问题之后再逐步扩大。具体可以按用户维度灰度，比如只放给内部测试账号；也可以按流量比例灰度，比如先放5%的流量进去。放量之后观察核心指标，稳定了再继续往上涨。灰度发布不是大型公司的专利，现在很多网关和服务框架都支持按比例转发流量，配置起来并不复杂。

5. 优化效果的验证与可持续保障

优化到底有没有用，不能靠“感觉快了一点”来评价，需要通过压测和监控数据来确认。与此同时，还要把这一轮的经验沉淀到机制里，防止过一段时间性能又悄悄回退。

5.1 压测与回归指标：用数据确认收益

压测的意义不是“跑一下看看能扛多少并发”，而是验证优化前后的效果差异。我一般会先用JMeter或者wrk跑一轮优化前的基线，记录TPS、响应时间P99、错误率和CPU占用率。然后等优化后版本部署到压测环境，用同样的流量模型再跑一遍。注意是同一套压测脚本、同样的并发量、同样长度的压测时间，这样出来的数据才具有可比性。

压测的场景也要贴近真实流量模型。如果线上主要是读多写少的场景，压测脚本里就要体现这个比例；如果接口有登录态依赖，脚本里也要带上。只看单接口的吞吐量，而不看混合场景，很容易得出过于乐观的结论。

我们当时压测的一组数据可以作为参考：

看到这组数据的时候，团队的信心一下子就上来了。之前所有人都在说“要重构”，重构的周期至少两三个月，但我们只是做了一轮缓存、SQL和线程池的调整，在一个星期内就把核心指标拉到了一个健康水位。

5.2 监控告警与定期复盘，防止性能回退

优化上线之后，必须紧盯着监控数据看，尤其是前半小时。重点看响应时间曲线、错误率、GC次数、CPU和内存使用情况。我见过不少项目，优化上线当天没问题，过了一个星期性能又回去了，原因可能是新功能引入了一条慢SQL，也可能是某次发布偷偷改掉了线程池配置。

所以监控告警要提前设好。比如核心接口P95响应时间超过500毫秒持续5分钟就告警，Full GC次数在10分钟内超过3次就告警，错误率超过1%就告警。告警阈值根据自己的业务特点来定，没有必要追求极低的阈值导致误报疲劳。关键在于，你要让问题在影响用户之前就被发现，而不是等用户投诉了你才知道。

最后，把这一轮的优化经验沉淀到文档里也非常重要。优化过程中的结论、改动的SQL、调整的参数、压测数据，都要记录下来。项目里的人总是流动的，今天你知道这条SQL为什么慢，三个月后新同事接手，如果文档里没有留下线索，他又要重新排查一遍。把这些内容整理成一份性能优化的记录，后续再做类似优化的时候，可以直接参考底稿。

说到最后，我个人在实际操作中最大的体会是：项目优化不是一次性的运动，而是一个定位问题、小步改动、量化验证的循环。很多团队一遇到性能问题就喊着要重构，但重构的周期太长，风险太高。相比起来，先改一条慢SQL、配一个合理缓存、把线程池参数调准，这些小的改动累积起来，往往比一次推倒重来更有效。

如果你手上正好也有一个老项目，我建议从今天开始，先把线上的慢查询日志和GC日志打开，再找一两个最核心的接口做一次链路分析。数据会告诉你问题在哪。优化不需要一步登天，把每一步收益都记录下来，项目会在一个又一个可控的决策中慢慢变稳。