章华燕做后端这些年，被问到最多的问题大概就是：系统现在到底能扛多少并发？QPS还能不能再往上走？每次大促、秒杀、活动页上线之前，这类问题都会被反复抛出来。高并发系统性能优化这个题目，我前前后后做过不少，踩过的坑比总结出来的经验还多，所以想着把一套比较完整的思路和方法整理出来。这篇内容适合正在做服务端开发、架构设计或者性能排查的同行参考，也适合刚接触高并发的新手建立全局认知。不管你是Java、Go还是C++技术栈，底下那套瓶颈逻辑基本是相通的，差别主要在工具和实践细节上。
1. 先搞明白：高并发系统到底在优化什么
1.1 高并发不是目的，性能指标才是标尺
先说一个不少人都踩过的误区：一上来就说“我要支持百万并发”，但百万并发到底是指同时在线数、每秒请求数，还是每秒新建连接数？这三个是完全不同量级的概念。日常说的高并发，通常指单位时间内系统能处理的请求数量，也就是QPS（Queries Per Second），同时还要关注平均响应时间RT。两者之间有个简单换算关系：QPS约等于并发线程数除以平均响应时间。举个例子，如果平均RT是100毫秒，那么1000个并发线程大约能支撑1万QPS；如果RT涨到200毫秒，想支撑同样的QPS，就需要约2000个并发线程。
这也是为什么我一直主张“先优化RT，容量会跟着涨”。很多团队遇到性能问题第一反应是加机器，加完发现QPS没翻倍，原因往往就是单请求处理链路里有串行等待，加机器对串行部分毫无帮助。真正评估高并发系统，还不能只看平均RT，TP99（99%请求在多少毫秒内完成）、错误率和资源利用率同样关键。平均RT低不代表体验好，如果TP99从200毫秒漂移到2秒，系统其实已经到了过载边缘。我一般把“响应时间分位数 + 错误率 + QPS”三组指标绑定观察，缺一个都容易误判。
另外，不同业务的指标侧重点完全不同。秒杀场景核心指标是库存扣减成功率和下单延迟；Feed流场景更关注TP95下的渲染完整度和接口吞吐；游戏服务端则在平板上同时盯帧率和网络同步延迟。指标定清楚，优化才有靶子；指标都不明确，做再多调整也只能靠感觉收尾。
1.2 瓶颈通常集中在CPU、内存、IO、锁四处
高并发系统性能出问题，绝大多数逃不出CPU、内存、磁盘/网络IO和锁竞争这四个方向。把系统想成一家食堂：CPU是厨师，内存是备菜台，IO是采购和传菜通道，锁则是食堂里唯一能开的那间储藏室。客人少的时候厨师慢慢炒没问题；客人一多，备菜台堆不下、采购送菜跟不上、所有人都抢储藏室，问题就全冒出来了。
CPU瓶颈的典型特征是使用率长期在85%以上，而且还要区分是用户态高还是内核态高。用户态高通常是业务代码在大量计算，比如序列化、加解密、正则回溯；内核态高则可能是系统调用太频繁、上下文切换太多。内存瓶颈表现为GC频繁、Swap、内存占用居高不下。IO瓶颈分磁盘IO和网络IO：磁盘IO到顶时iowait会明显偏高，网络IO到顶时可能出现发送缓冲区积压、连接数升高。
锁竞争最隐蔽，表面看CPU不高，但大量线程卡在BLOCKED状态，吞吐就是上不去。你去看线程栈，会发现一堆线程都在等同一把锁。定位瓶颈时，先对照这些特征缩小范围，比盲目调参数有效得多。我见过有人CPU已经跑满还在不停调JVM堆大小，方向错了，所有努力都是白费。
1.3 优化前先建立基线和量化目标
没有压测基线就去优化，等于没量体温就乱吃药。我养成的习惯是：任何调整之前，先做一轮基础压测，记录当前环境的QPS、RT分位数、错误率、CPU、内存、网络IO数据作为基线；再根据业务目标，定一个跳一跳够得着的优化目标。例如接口现在1000 QPS、TP99 500毫秒，目标定成1500 QPS、TP99 200毫秒，这就比“把性能调到最好”可执行得多。
建立基线还有个额外价值：它能暴露出系统原本就存在的隐性缺陷。压测时我见过太多平时不暴露、一上量就崩溃的问题，例如某个底层调用没有设超时、数据库连接池大小写死、线程池队列无界。这些问题在基线压测里会提前浮出水面，给后续优化排序提供真实依据。定好基线后，每次改动只动一个变量，改完重新压测对比，这样才知道哪个动作真正起了作用，哪个动作其实是负优化。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 优化前的整体设计思路与方案比选
2.1 先分清问题是资源型还是结构型
拿到一个性能问题，先别急着改代码，而是判断它是资源型瓶颈还是结构型瓶颈。资源型瓶颈指硬件已经不够用，加CPU、加内存、加带宽就可以解决，这类问题一般出现在系统本身设计合理、但流量超过预估的场景。结构型瓶颈则指系统设计阶段就存在问题，比如核心接口链路里有串行调用、每次请求都查数据库、多个服务之间循环依赖，这种情况下加再多机器也没用，需要改架构。
判断方法也不复杂：压测时盯着资源利用率曲线看。如果CPU没满、内存没满、IO也不高，但吞吐就是上不去，大概率是结构型瓶颈，比如线程阻塞、远程调用慢、GC停顿。如果某项资源已经打到接近100%，那就先扩容或优化这项资源。一个高并发系统往往是多个瓶颈叠加，从最底层那个开始解，解完一层又会暴露下一层。
2.2 读多写少加缓存，写多延迟容忍走异步
高并发业务场景按“读多写少”和“写多读少”来分，优化手段的倾向性会非常明显。读多写少的典型是商品详情页、内容列表页，优化核心是缓存。本地缓存适合存热点数据，分布式缓存适合存全量共享数据，两者结合可以挡住绝大部分读请求。如果量再大，还可以考虑在网关层做边缘缓存，让请求根本到不了应用层。
写多且对实时性要求不高的场景，比如下单后的积分发放、操作日志记录、行为轨迹采集，核心优化手段是异步化。把同步写入请求先丢进消息队列，后端服务按自己的节奏消费，起到削峰填谷的作用。Kafka这类消息中间件几乎成了高并发写链路的标准配置，后面我会单独展开。
这里说句实在话：前端性能优化在整体链路里同样重要，只是经常被后端同学忽略。比如JSON.stringify在页面里高频处理大对象，如果序列化出现在主渲染流程，照样会拉长端侧响应时间。高并发系统不光是后端的事，端到端的体验是整条链路共同决定的。
2.3 分层优化的整体顺序
高并发系统的性能优化，如果按性价比排序，我个人的顺序是：先做代码级优化，再引入缓存，再做异步化，然后考虑数据层拆分，最后才是扩容和参数调优。代码级优化成本最低但收益有限，比如去掉重复计算、减少对象分配、优化正则、提前返回；缓存能直接把热点流量挡在数据库外面；异步化能平滑峰值；数据层拆分解决的是数据量增长后的容量问题。
这个顺序不是死的。如果系统QPS已经几万甚至更高，单纯做代码级优化就没多大意义，核心矛盾大概率在架构层面。反过来说，如果接口RT高只是因为代码里做了大量无意义的深拷贝，那也没必要一上来就上Redis、上消息队列。最忌讳的是为了用某个中间件而引入复杂度，一个能把缓存、消息队列、分库分表全部串起来的高并发系统，运维代价和故障面都很大。按收益成本比排优先级，高并发项目才能可持续推进。
3. 应用层代码优化：线程模型、池化与锁的实战要点
3.1 线程池参数不能拍脑袋，要用公式粗算
Java技术栈里，ThreadPoolExecutor参数是面试八股，也是线上调优重灾区。很多团队corePoolSize和maxPoolSize都是随便填的，队列长度用默认的无界队列，结果一遇流量尖峰，线程数没涨，请求全部堆积在队列里，RT直线上升。判断线程池大小，我习惯先分清楚任务类型。
CPU密集型任务，线程数取CPU核心数加1比较合理，再多只会增加上下文切换开销。IO密集型任务，线程数则取决于每个任务里计算时间和等待时间的比例，经验公式是：线程数 = CPU核心数 * (1 + 等待时间 / 计算时间)。假设一台8核机器，处理一个请求里有20毫秒CPU计算、80毫秒等待下游返回，那么合理线程数大约是8 * (1 + 80 / 20) = 40。这个数字不是精确解，但至少给了你一个起步参考，再结合压测微调。
还要注意队列的选择。有界队列可以触发拒绝策略，逼你考虑降级；无界队列虽然不会拒绝请求，但积压太多会让用户等到超时。线上一般配一个适当大小的有界队列，并且把拒绝策略设成自定义降级逻辑，比如直接返回繁忙提示或者走兜底数据，而不是抛异常。
3.2 连接池和对象池：昂贵资源必须复用
高并发系统的另一个关键点是“复用”。数据库连接、Redis连接、HTTP连接都是昂贵资源，如果每次请求都重新创建，TCP握手和TLS握手开销会直接把系统拖垮。更麻烦的是，高并发下频繁短连接会产生大量TIME_WAIT连接，最终耗尽本地端口，表现就是“Cannot assign requested address”。
所以业务服务必定要使用连接池。但连接池不是越大越好，这可能是新手最容易犯的错误。数据库连接池开得过大，数据库侧要维护大量连接上下文，反而降低吞吐。HikariCP官方文档给过一个参考：连接数 = ((核心数 * 2) + 有效磁盘数)，比如4核机器配10个连接左右就够。这个数字看着小，但配合快速的连接获取和归还，已经能支撑很高的QPS。关键原则是：连接是复用的通道，不是并发线程数本身。
对象池则适合创建成本高的对象，比如数据库连接、网络客户端、字节缓冲区。但注意不要全盘池化，现代JVM对短生命周期小对象分配已经非常快，池化反而增加代码复杂度和GC压力。原则是只池化那些“创建昂贵”或“必须复用”的资源，比如Netty里的ByteBuf、业务里的可重用的超大数组。
3.3 锁粒度、伪共享与GC停顿，三个隐形杀手
高并发系统调优到后期，代码逻辑通常都不是瓶颈，锁竞争和GC停顿才是。先说锁，最简单的优化是减小锁粒度：用分段锁代替全局锁、用读写锁区分读多写少、用LongAdder代替AtomicLong写多场景，甚至能用无锁就无锁。Java的ConcurrentHashMap在内部就用了分段锁和CAS，所以并发写表现远好于HashTable。
伪共享是一个特别容易踩但很难主动发现的坑。CPU缓存是以缓存行（通常64字节）为单位加载的，如果两个核心各自修改同一个缓存行里的不同变量，缓存一致性协议会让这两个核心互相通知，性能骤降。解决方法是补全填充让变量独占缓存行，Java里可以用@Contended注解。这个坑在单线程下完全暴露不出来，只有多线程压测才能看到吞吐差异。
GC停顿在Java高并发系统里往往成了最后一公里。JVM垃圾回收需要Stop The World，哪怕只有几十毫秒，对大流量系统也会造成明显的RT毛刺。选择G1还是ZGC，得看堆大小、停顿时间目标和吞吐要求。但比选GC更重要的，是减少对象分配速率。很多时候你发现GC频繁，核心原因不是堆小，而是每秒创建了大量对象。压测时开启采样，找到高频分配点，缓存复用或改用原始类型，GC压力会明显下降。
4. 缓存与数据层优化：把压力挡在最前面
4.1 缓存穿透、击穿、雪崩的应对细节
缓存是缓解高并发读压力的第一道防线，但缓存本身也有一堆问题要处理，最典型的是穿透、击穿、雪崩。
缓存穿透指查询一个不存在的数据，缓存没命中，请求直接打到数据库。恶意攻击者可以故意访问大量不存在的ID把数据库打垮。常用手段是布隆过滤器，把所有可能存在的主键提前过滤；对不存在但也可能被频繁查询的数据，缓存一个空值并设置较短过期时间，也能起到保护作用。
缓存击穿指某个热点key过期瞬间，大量并发请求同时发现缓存没有，一起涌到数据库。解决办法是互斥锁重建缓存，只放行一个请求去加载数据，其他请求等待结果后直接复用；更高级一点的做法是逻辑过期，即缓存里不设置物理过期时间，而是写入一个逻辑过期字段，后台线程发现过期后异步重建。
缓存雪崩指大量key在同一时间段集中过期，或者Redis实例不可用，导致流量全部打到数据库。规避方式包括：过期时间加随机因子，避免同一秒集体失效；核心数据做多级缓存，本地缓存挡第一层；Redis部署成高可用集群，避免单点故障。
4.2 数据库侧优化：慢SQL、索引和合并写
不管缓存做得再强，总有请求要落到数据库，数据库侧的优化决定了系统的兜底水位。最常见的问题是慢SQL。一条大表全扫描SQL，平时并发低没人察觉，高并发一来就会把数据库连接池占满。慢SQL治理三步：开慢查询日志找到全表扫描和扫描行数过多的SQL，用EXPLAIN分析执行计划，再针对where条件创建合适索引。
创建索引有几个原则要特别注意。联合索引遵循最左前缀原则，查询条件里没有最左列，索引基本失效；对区分度低的列建索引，优化器也可能弃用；索引不是越多越好，每个索引都会拖慢写入速度。高并发写入场景下，批量写比逐条写高效得多。比如下单时要生成多个子订单，单次请求内先把数据攒成列表，再一次性批量INSERT，能省掉大量网络往返和日志刷盘开销。
4.3 分库分表不是银弹，别为了分而分
数据量到一定程度，单表扛不住，很多人第一反应是分库分表。我的建议是：先确认是不是真的需要。如果只是单表数据量到了几千万，但业务上有清晰的分区键，先考虑MySQL分区表或者归档冷数据；如果数据量和写入并发都确实超出单库承载，再考虑分库分表。盲目分库会带来一系列分布式问题：跨分片事务、跨分片join、全局主键、数据迁移等。
分库分表后的主键生成，我建议用分布式ID方案，比如雪花算法。它能保证全局递增趋势，配合索引的B+树写入也友好。跨分片查询是最大痛点，设计分片键时就要想清楚哪个字段能覆盖绝大多数查询条件。比如订单表按用户ID分片，用户查询自己的订单列表完全没问题，但运营后台想按订单号查就麻烦了，这时需要额外维护一份订单号到用户ID的映射索引或者用搜索引擎。
数据层优化到后面，基本就是“热数据进缓存，冷数据进归档，中间态数据进消息队列”。优化没有一劳永逸，也不可能在不了解业务的情况下照搬一套方案。
5. Kafka在峰值流量下的消息处理实操
5.1 Kafka凭什么能支撑高并发消息场景
为什么高并发系统里，聊到消息队列时Kafka出现频率这么高？核心在于它的设计就是冲着吞吐量去的。Kafka写入数据利用了磁盘顺序追加的特性，顺序写性能比随机写高一到两个数量级；读取时又依赖page cache，热门数据其实是在内存里访问的，很多场景下根本不落磁盘。再加上零拷贝技术，数据从磁盘到网卡的过程中减少了用户态和内核态的多次拷贝，吞吐量自然高。
但是，Kafka吞吐高不等于默认配置就能用得很好。很多人上来就装个默认Kafka开始跑，结果生产端吞吐上不去、消费端频繁rebalance，最后得出结论“Kafka不行”。其实大多数时候是参数没调对。下面我列一些生产上比较实用的配置思路。
5.2 生产端、Broker端和消费端的关键参数
生产端核心参数是acks、batch.size和linger.ms。acks=0发送后不等确认，吞吐最高但有丢数据风险；acks=1表示leader写入成功即返回，吞吐和数据安全比较平衡；acks=all则要求所有副本都确认，最安全但延迟最高。金融类业务用acks=all，日志采集类业务用acks=0或1问题不大。batch.size和linger.ms是攒批的利器，适当调大batch.size、设置linger.ms为几毫秒，可以让生产者把多条消息攒成一个批次发送，吞吐提升非常明显。
Broker端重点看分区数和副本因子。分区数是Kafka并行度的上限，但也不是越多越好，每个分区在Broker上都有对应的文件句柄和内存开销。我一般按目标吞吐和消费者线程数来定分区数，公式可以粗算为：分区数 = 目标吞吐 / 单个分区可达吞吐，通常给个2到3倍的余量。副本因子越高数据越安全，但会占用额外磁盘和网络，生产环境建议至少2，核心Topic设3。
消费端的核心瓶颈在分区数和消费线程的关系上。同一个消费组里，一个分区最多被一个消费者线程消费，所以消费者线程数超过分区数是浪费的。如果消息处理太慢导致积压，正确的解法是先看消费逻辑能不能优化，再考虑增加分区和消费者；分区数不够的时候，靠加消费者机器解决不了根本问题。此外max.poll.records不要设太大，否则一次拉取太多消息，处理不过来却已经超过max.poll.interval.ms，消费者会被踢出组。
下面给一段Kafka生产者的配置示例，语言是Java：
java复制properties.put("acks", "1");
properties.put("batch.size", 32768);
properties.put("linger.ms", 5);
properties.put("buffer.memory", 64 * 1024 * 1024L);
properties.put("compression.type", "lz4");
properties.put("retries", 3);
攒批这件事，很多人有个误解：批越大越好。实际批太大反而带来内存压力和延迟上升，32KB到64KB是比较常见的起步值，配合5到10毫秒的linger.ms，在吞吐和实时性之间能取得不错的平衡。压缩建议生产端开启，lz4或zstd对CPU开销都很小，能省大量带宽。
5.3 消息积压、顺序性和重复消费的实战解法
Kafka用多了，线上最常遇到的是三个问题：消息积压、顺序错乱、重复消费。
消息积压的核心排查思路是：先看监控里消费组Lag是不是持续上涨。如果涨，第一步看消费者是否在正常拉取，是不是频繁rebalance导致消费停滞；第二步看单条消息消费耗时，如果RT明显变大，说明下游处理能力变弱，需要优化下游或扩容。扩容时注意消费者数量不能超过分区数，超过部分不干活。
顺序性问题的本质是分区键选择。Kafka只能保证单个分区内的消息有序，因此要保证同一业务实体的消息进同一个分区，比如订单状态变更消息按orderId作为key发送。只要key不变，同一订单的消息就会进入同一分区，顺序就保住了。最怕的就是发送时为了负载均衡随机指定分区，状态机消息乱序导致业务异常。
重复消费在高并发系统里几乎无法完全避免。消费端做幂等是必须的。做法包括：消息内携带全局唯一ID，消费前先查状态或插入唯一主键，重复的直接丢弃；或者将消费进度记录到业务库的事务里，保证业务操作和提交offset在同一事务中完成，做到至少一次语义下不产生重复副作用。幂等不是Kafka的功能，而是消费端的基本素质，这一点要刻在骨子里。
6. 压测、监控与排查：优化工作的裁判
6.1 压测工具与数据采集怎么选
优化做得好不好，最终要靠压测数据说话。工具方面，轻量接口压测可以用wrk，几十行配置就能打出很高的并发，适合快速验证单接口吞吐；Apache JMeter适合做复杂场景，比如多接口串联、参数化、断言，但资源占用高，不适合超大规模压力；Locust用Python写脚本，比较灵活；k6则偏向云原生和CI/CD场景。选工具没有绝对标准，关键看你压的场景是单机单接口还是全链路混合链路。
压测不能只在一台低配机器上压完就当结论，要尽量贴近生产环境。我见过最常见的压测失真案例：压测环境的线程池、连接池配置和生产环境不一致，测出来的结果根本不能指导生产容量评估。还有网关层、数据库、Redis等依赖项，如果压测环境没有完全独立，很容易出现互相干扰。全链路压测时最好引入链路追踪ID，把压测流量和真实流量隔离，这样才能在不污染线上数据的情况下验证系统容量。
6.2 从CPU到线程栈的快速定位流程
如果线上系统已经出现性能问题，我一般按这个顺序快速定位：先看全局，在服务器上执行top命令，看CPU整体占用和负载，找出占用高的进程；再看细节，按线程维度看CPU占用，Java服务用top -Hp
对于Java应用，JFR和async-profiler都是非常好用的采样工具。async-profiler能生成火焰图，直观看到CPU时间花在哪些方法上，这对定位线上热点帮助巨大。另一种常见情况是CPU不高但接口RT很高，这时候要在接口全链路加追踪，从网关到应用再到数据库，看时间到底消耗在哪个环节。如果是数据库慢查询导致，打开慢日志基本能直接定位；如果是Redis网络延迟导致，要看客户端连接池和Redis本身负载。排查过程最忌讳跳步，按链路逐层排查最省时间。
现在很多系统都做了可观测性建设，指标、日志、链路追踪三者结合。光有日志没有指标，像在黑夜里打手电；光有指标没有链路，很难定位到具体方法。一套成熟的监控体系，应该能在你还没意识到出问题时，就通过告警提醒你接口RT的TP99已经在异动。
6.3 一次秒杀系统优化案例复盘
从一个真实案例复盘来看高并发优化的完整闭环。这个系统上线初期做了一轮压测，结果是单机支撑1200 QPS，TP99达到380毫秒，表现离目标差得很远。排查时先看CPU，发现业务机器CPU在70%左右，不高；再看数据库，发现数据库CPU接近100%，慢SQL日志里全是库存表的行锁等待。结论很清晰：瓶颈在数据库的库存扣减逻辑上。
第一轮优化把库存扣减从同步SQL UPDATE改成先更新Redis中的库存预扣，再通过异步消息队列将扣减结果同步到数据库。Redis单线程模型下用Lua脚本执行扣减，能够保证原子性，单机QPS轻松过万。这轮优化后压测，接口QPS提升到6000，数据库CPU立刻降下来了。但新的问题又出现了：消息队列消费端处理能力不够，数据库写入出现积压，最终一致性时延变大。
第二轮优化围绕消费端做：批量消费、合并多条扣减消息为一次数据库批量更新，同时对消费线程数做了扩容。这两步下去，消费积压问题基本消除。两轮之后压测，单机QPS稳定在8000，TP99降到120毫秒，库存数据最终一致性的延迟控制在1秒以内。优化过程中每个改动都有对应的压测数据支撑，哪一步带来多少收益清清楚楚，这就是基线和量化目标的价值。
7. 常见问题速查与避坑心得
7.1 高频问题与排查方向速查表
结合我经历过的几次高并发系统保障，整理一张高频问题速查表，方便你遇到情况时快速对照：
| 症状 | 可能原因 | 排查入口 | 处理方向 |
|---|---|---|---|
| CPU用户态持续高 | 业务代码热点、大量序列化/加解密 | async-profiler火焰图 | 减少计算、缓存结果、升级算法 |
| CPU内核态高 | 系统调用频繁、上下文切换多 | vmstat、sar | 调大线程池、减少短任务 |
| iowait高 | 磁盘随机读写、慢SQL、日志写太多 | iostat、慢日志 | 顺序写、批量写、减少不必要日志 |
| 线程大量BLOCKED | 锁竞争激烈 | jstack查看锁等待 | 减小锁粒度、读写锁、无锁化 |
| GC频率高 | 对象分配速率过大或堆太小 | jstat、GC日志 | 优化对象分配、换GC器、调堆 |
| Redis连接数打满 | 客户端连接池过大，或服务端超时 | redis-cli info clients | 调整连接池、超时时间 |
| 消息消费Lag上涨 | 消费处理慢、分区数不够、频繁rebalance | Kafka监控Lag | 优化消费逻辑、增加分区 |
| 数据库CPU 100% | 慢SQL、锁等待、缺索引 | EXPLAIN、慢查询日志 | 建索引、批量写、读写分离 |
这张表不能代替完整的排查流程，但能在告警第一时间给你一个大致方向。方向对了，后面定位只是时间问题；方向错了，就会在错误的地方打转几个小时。
7.2 优化动作的优先级：先做收益大、成本低的事
高并发性能优化最怕“一口吃成胖子”。我通常会把待优化项列出来，按“预期收益”和“改动成本”打分，优先做高收益低成本的改动，比如加缓存、调SQL索引、改线程池参数；再看中收益中成本的动作，比如引入消息队列；最后才考虑分库分表、微服务拆分这种高成本高风险的架构级改造。
有个判断原则值得分享给你：代码级优化通常解决的是“单请求处理效率”问题，缓存和异步解决的是“整体链路结构”问题，扩容和架构拆分解决的是“容量上限”问题。不同阶段，主要矛盾会变化。日活几十万时纠结分库分表毫无必要；QPS千万级了还在逐行优化字符串拼接，也是用错了劲。想清楚自己处在哪个阶段，再决定做什么优化。
另外，任何优化都要留好回滚方案。线程池参数改小、队列改短、超时时间调低，这些看似不起眼的调整，都可能在高流量下触发连锁反应。我一般先把改动做成开关项，灰度验证通过再全量，一旦指标恶化可以立刻回滚。
7.3 我踩过的几个坑，写给你当参考
最后分享几个我踩过的坑，算是给大家避避雷。
第一，调大线程池之后RT反而上涨。当时以为IO密集型场景线程越多吞吐越高，结果线程数翻倍后上下文切换开销变大，响应时间跟着拉长。正确做法是压测时逐档增加线程数，找到吞吐增长趋缓甚至下降的临界值，而不是一味求大。
第二，给缓存设置过期时间时用了固定值。本来想避免缓存雪崩，结果是某个时间点整批key集体失效，数据库一瞬间被打满。后来改成“基础过期时间 + 随机偏移量”，效果立竿见影。
第三，分库分表后没注意跨分片查询限制。上线后才发现运营后台很多查询条件是另一列，不得已做了全分片路由，查询慢到怀疑人生。前期设计分片键时没有把主要查询场景梳理清楚，后期补的成本远高于一开始多想几分钟。
第四，压测环境和生产配置不一致导致数据失真。压测时连接池只有50，生产配了300，结果生产一上量连接数暴涨，数据库被打挂。自那以后我再也不碰“测试通过就上线”这样的流程，所有环境差异都写进发布检查单。
高并发系统性能优化没有终点，业务涨、流量涨，系统就会不断出现新瓶颈。但方法论是稳定的：明确指标、建立基线、分层优化、压测验证。把这些基本功做扎实，再复杂的系统也能一步步调出让人满意的吞吐和延迟。