CPU 打满但加机器没用：聊聊"加资源反而更慢"的几类坑，你踩过哪个

背景 热榜上"连接池怎么调""超时重试怎么配""Kafka 事务为什么卡"都聊得很透，但我做了 15 年性能优化，发现一个更底层、却很少被单独拎出来对线的分歧：很多性能问题，第一反应是"加资源"（加机器、加线程、加核），结果不但没变快，反而更慢了。 这不是玄学，是有一类明确的坑，今天想把它摊开聊聊。

我复盘过的三个真实案例（脱敏）

1. 加线程更慢：一个 Java 服务 CPU 90%+，QPS 上不去。团队把线程池从 200 拉到 1200，结果 P99 从 60ms 飙到 220ms，CPU 还是 90%。最后用火焰图 + perf 发现瓶颈是一把同步锁（缓存加载互斥），线程越多上下文切换和锁等待越重，"加线程"等于给锁竞争加料。
2. 加机器更慢：一个 IO 密集服务，单机磁盘吞吐打满。横向扩了 3 台，每台负载降了，但 P99 没降反升——因为下游是一个共享的、未分片的存储节点，总流量翻 3 倍，存储侧排队反而更长。
3. 加核更慢：一个 Go 服务 GOMAXPROCS 默认拉满，CPU 打满。改成 32 核后，一个全局的 map 加锁写操作成为热点，核越多争抢越凶，吞吐不升反降。

常见分歧 / 几种做法

• 资源派：CPU 打满就是容量不够，加机器最稳、可逆、见效快，先扩容扛住再说。
• 代码派：CPU 打满只是表象，先火焰图 + perf 找到真正的热点（锁 / 系统调用 / GC / IO 等待），改代码才是根治。
• 架构派：单机瓶颈是架构问题（共享存储、全局锁、同步阻塞），应该拆掉串行点，而不是在单点上堆资源。

我的倾向与理由 我偏向"先诊断、后加资源"，但不是说永远不扩容——而是扩容前先确认"加的是不是对的那类资源"。我的判断清单：

1. 火焰图里"用户态热点"占比高 → 改代码；
2. 大量时间耗在 futex/锁等待 → 拆锁、改无锁、分片；
3. 耗在 read/write/io_getevents → 瓶颈在 IO，加 CPU 没用，要换存储或做缓存；
4. 下游是共享未分片资源 → 加机器是放大器，先分片。 关键判据：如果加资源后 P99 不降反升，说明瓶颈是"串行点"或"共享资源"，加资源只会把排队放大。

想听大家

• 你遇到过"加资源反而更慢"的场景吗？当时是怎么定位到根因的？
• 你们团队的判断顺序是什么？先扩容还是先火焰图？
• 有没有"扩容是对的，但我一开始没意识到为什么对"的案例？（比如真正的瓶颈在下游，扩容只是把下游的排队时间摊薄了）
• 你们有没有一套"该扩容 vs 该改代码"的决策清单？