应细化锁粒度以提升并发吞吐：用std::shared_mutex优化读多写少场景；哈希表按桶分锁并均匀哈希；队列头尾分离加锁且用std::scoped_lock防死锁；原子操作替代锁仅适用于简单操作，并注意伪共享。
锁粒度太大直接卡死并发吞吐，不是加线程就能解决的——得把“一把大锁”拆成多把小锁，让线程各管各的数据段。
std::shared_mutex 适合读多写少的缓存场景
如果你的共享数据主要是被读取（比如配置缓存、热点字典），std::shared_mutex 比 std::mutex 更合适。它允许任意数量的线程同时持 std::shared_lock，只在写入时用 std::unique_lock 排他。
- 错误用法：
std::mutex包裹整个get()和put()，哪怕只是查一个 key 也要排队 - 正确做法：读操作用
std::shared_lock<std::shared_mutex>，写操作用std::unique_lock<std::shared_mutex> - 注意点：如果写操作频繁（比如每秒几百次），
std::shared_mutex可能因写饥饿导致读线程迟迟得不到响应
哈希表分桶加锁要均匀切分，避免热点桶
对 std::unordered_map 这类结构，不能整个容器一把锁，而是按桶（bucket）或哈希值取模后分段加锁。
- 典型实现：用
std::vector<std::mutex>维护 N 个锁，key 的锁索引为hash(key) % N - 关键约束：N 要足够大（常见 64 或 128），且 hash 函数要均匀，否则某些锁会被反复争抢
- 陷阱：别用
key % N直接当索引——整数 key 往往低比特重复性高，容易集中到少数桶 - 性能影响：锁数量翻倍，内存占用略增，但平均等待时间可能从毫秒级降到纳秒级
队列头尾分离锁必须严格隔离访问路径
并发队列（如生产者-消费者模型）中，入队和出队常发生在不同端，可分别用独立 std::mutex 保护头指针和尾指针。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 适用前提：底层是链表或循环缓冲区，且头/尾操作不互相依赖（例如不检查空/满状态）
- 风险点：若需判断队列是否为空（既读头又读尾），就必须同时获取两个锁，此时必须用
std::scoped_lock防死锁 - 示例：
std::scoped_lock lock{head_mutex, tail_mutex};—— 它自动按地址顺序加锁，避免顺序不一致 - 别省事写两个
std::lock_guard分别套，那是死锁高发区
atomic 替代锁只适用于极简操作
不是所有共享变量都需要锁。对单个整数计数器、开关标志、指针原子更新，std::atomic 是更轻量的选择。
- 典型场景：
std::atomic_int ref_count{0}、std::atomic_bool shutdown_requested{false} - 限制：不能用于复合操作（比如“先读再加再写”），除非用
fetch_add等原子 RMW 指令 - 易错点：默认
memory_order_seq_cst开销略高；高频场景可降级为memory_order_relaxed或memory_order_acquire/release，但需理解同步语义 - 伪共享警告：多个
std::atomic变量若落在同一缓存行（64 字节），仍会相互干扰，要用alignas(64)隔开
细化锁粒度不是越多越好，核心是观察真实争用热点——用 perf record -e sched:sched_stat_sleep 看线程在哪等锁，再决定拆哪、怎么拆。盲目分段反而增加 cache miss 和锁管理开销。
