std::mutex争用导致吞吐量下降30%的主因是锁串行化瓶颈，而非CPU不足；高频小粒度操作中lock/unlock引发内核切换与缓存失效，应缩小临界区、改用atomic、分片锁及alignas(64)避免伪共享。
std::mutex 争用让吞吐量不升反降
线程数翻倍但吞吐量掉 30%，大概率不是 CPU 不够，而是 std::mutex 成了串行瓶颈。每次 lock() / unlock() 都触发内核态切换和缓存行失效，尤其在高频小粒度操作（如计数器累加、日志写入）中，开销远超计算本身。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 把临界区缩小到仅包裹真正共享的变量操作，避免把网络收发、内存分配等耗时逻辑包进去
- 用
std::atomic替代简单计数场景：例如counter.fetch_add(1, std::memory_order_relaxed)，省去锁开销 - 对批量操作，考虑“分片锁”：把一个大容器拆成 N 个子容器 + N 个独立
std::mutex，按哈希分散访问
伪共享（False Sharing）让多核变单核
多个线程修改不同变量，却因它们落在同一缓存行（通常是 64 字节），导致 CPU 缓存一致性协议频繁广播失效信号。现象是 perf 显示大量 LLC-misses，top 看 CPU 利用率高但实际工作线程 stalled 很多。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
alignas(64)强制关键变量独占缓存行，例如：struct alignas(64) WorkerStats { std::atomic<long> processed; };</long> - 避免结构体里混放热变量和冷变量；调试时可用
pahole工具检查结构体内存布局 - 不要盲目 padding 所有字段——只对被多线程高频写入的变量做对齐，否则浪费 L1 缓存空间
线程数超过物理核心数反而拖慢 IO 吞吐
在文件读写或 socket 处理中，盲目增加线程数常导致上下文切换暴涨，vmstat 1 可见 cs（context switch）列飙升，而 sy（system CPU）占比过高。此时线程不是在干活，是在排队进内核态抢资源。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- IO 密集型任务，线程数建议设为
min(4 × 物理核心数, 存储设备最大 IOPS 对应并发数)，SSD 通常 4–8 个足够 - 用
io_uring替代传统read()/write()，单线程就能处理数千并发 IO，避免线程膨胀 - 若必须多线程 IO，确保每个线程绑定独立文件描述符或 socket，并禁用
SO_REUSEPORT下的负载均衡干扰
死锁和锁顺序不一致引发隐性吞吐坍塌
吞吐量阶段性归零、strace -p PID 显示大量线程卡在 futex 系统调用，很可能是死锁或锁竞争僵持。典型模式是线程 A 持有 mutex_a 等 mutex_b，线程 B 持有 mutex_b 等 mutex_a，形成环路。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有锁按固定地址顺序获取：例如统一先 lock 地址小的 mutex，再 lock 地址大的，用
std::scoped_lock自动排序 - 上线前用
helgrind（valgrind 子工具）跑压力测试，它能检测锁获取顺序异常和潜在死锁 - 避免在持有锁期间调用可能阻塞或回调用户代码的函数（如
malloc、第三方库接口）
