锁竞争严重时吞吐量断崖下跌，需减少线程等待与共享内存争抢：优先用std::shared_mutex替代mutex（读多写少场景），单变量操作改用std::atomic，拆分粗粒度锁为分片锁或thread_local，避免伪共享与死锁，根本在于减少共享状态。
锁竞争严重时，程序吞吐量会断崖式下跌，不是“加更多线程”能解决的——关键得让线程少等、少抢、少碰同一块内存。
std::mutex 用多了？先换 std::shared_mutex 看读写比
如果读操作远多于写（比如缓存查询、配置读取），一把 std::mutex 把所有读线程都堵成队列，纯属浪费。换成 std::shared_mutex 后，多个读线程可同时进入，只在写时互斥。
- 改法简单：把
mutable std::mutex mtx换成mutable std::shared_mutex mtx - 读操作用
std::shared_lock<:shared_mutex></:shared_mutex>，写操作用std::unique_lock<:shared_mutex></:shared_mutex> - 注意：C++17 起才原生支持，别在旧编译器上硬套；Clang/GCC 7+、MSVC 2017+ 可用
- 性能提升不是理论值——实测读多写少场景下平均延迟从 85ns 降到 42ns
简单计数或状态标志？直接上 std::atomic
像全局计数器、开关标志、指针替换这类单变量操作，std::mutex 是大炮打蚊子。硬件级原子指令没锁开销，也不阻塞线程。
- 把
int counter+std::lock_guard换成std::atomic<int> counter{0}</int> - 常用操作：
counter.fetch_add(1, std::memory_order_relaxed)（无同步需求时）、counter.load(std::memory_order_acquire)（需确保之前写已生效） - 别乱用
std::memory_order_seq_cst——它强制全局顺序，性能最差；多数场景relaxed或acquire/release就够 - 不适用复杂逻辑：比如“先读再判再写”，原子操作无法替代锁，强行拆分会引入 ABA 问题
锁粒度太粗？拆分资源或加 thread_local
一个 std::mutex 保护整个哈希表，十个线程更新不同 key 也得排队——这是典型粒度过粗。
- 分片加锁：把大容器拆成 N 个子容器，每组配独立
std::mutex，key 哈希后路由到对应分片 - 读写分离 + 局部缓存：读操作先查线程本地副本，仅在过期或缺失时加锁访问共享源
- 用
thread_local隔离非共享状态：比如每个线程维护自己的临时缓冲区、计数器、解析上下文，避免反复争抢全局资源 - 警惕伪共享：两个
thread_local变量若被分配到同一缓存行（64 字节），仍可能因 CPU 缓存一致性协议互相拖慢；可用alignas(64)强制对齐
死锁风险高？优先用 std::scoped_lock 和 std::try_lock
多个锁嵌套时，获取顺序稍有不一致就卡死。手动管理 std::lock_guard 容易翻车，尤其跨函数调用。
- 同时锁多个互斥量，必须用
std::scoped_lock<:mutex std::mutex></:mutex>——它自动按地址排序加锁，杜绝死锁 - 不确定能否快速拿到锁时，改用
std::unique_lock+try_lock()，失败就退避或重试，不干等 - 避免在锁内调用可能再拿锁的第三方函数（如日志库、STL 容器操作），否则调用链可能隐式形成循环等待
- 调试时开启
-D_GLIBCXX_DEBUG（GCC）或使用 ThreadSanitizer，能捕获大部分锁顺序错误
真正难优化的从来不是锁本身，而是共享状态的设计——越想靠锁“兜底”，越容易陷入争抢泥潭；把数据流理清楚，让线程尽量各干各的，才是根治之道。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
