锁粒度优化需匹配访问模式：过粗会导致线程频繁阻塞、临界区超几十微秒；可分段加锁或改用std::shared_mutex提升读并发，但须防伪共享与假拆分。
锁粒度优化不是“越细越好”，而是让锁的保护范围刚好覆盖真正需要同步的那部分数据和操作。粗粒度锁容易成为瓶颈，细粒度锁可能引入死锁、伪共享或管理开销——关键在“匹配访问模式”。
怎么判断当前锁是不是太粗？
观察线程是否频繁在 std::mutex::lock() 或 std::shared_mutex::lock() 上阻塞；用 perf record -e sched:sched_stat_sleep 看线程是否大量时间花在等待锁上；或者加日志统计临界区平均持有时间——超过几十微秒就值得怀疑。
- 典型粗粒度陷阱：用一把
std::mutex保护整个std::unordered_map，但实际每次只查/改一个 key - 更隐蔽的问题：把多个逻辑上无关的字段塞进同一个结构体，然后对整个结构体加锁
- 调试建议：临时把锁换成
std::timed_mutex，在try_lock_for()失败时打点，快速定位争用热点
什么时候该拆成多个锁？
当多个线程操作的数据彼此独立、冲突概率低时，拆锁才有效。比如哈希表按桶分段、数组按索引区间划分、对象池按 slot 分配锁。
- 哈希表分段示例：把
std::vector<:pair std::string>></:pair>拆成 N 个子容器，每个配独立std::mutex，哈希后取bucket_index % N决定用哪把锁 - 避免“假拆分”：若所有线程总访问同一段（如 key 都集中在一个 hash range），分再多锁也白搭
- 注意内存布局：分段锁之间至少间隔 64 字节，防止不同锁变量落在同一缓存行引发伪共享（
false sharing）
读多写少场景优先换 std::shared_mutex
这不是“换锁”，而是改变同步语义——读操作不再互斥，天然提升并发吞吐。但要注意它不解决写冲突，也不适用于写频率超过 ~10% 的场景。
立即学习“C++免费学习笔记（深入）”；
- 必须用
std::shared_lock读、std::unique_lock写，混用std::lock_guard会静默退化为排他锁 -
std::shared_mutex在 Linux 上底层依赖 futex 的共享模式，比std::mutex多一次系统调用开销，所以极短临界区（ - 某些旧版 libstdc++（GCC std::shared_mutex 实现有性能缺陷，上线前务必实测
原子操作能替代锁吗？
能，但仅限于简单、无依赖的操作：计数器增减、状态标志翻转、指针交换。一旦涉及多个变量协同更新（如先读 A 再根据 A 更新 B），原子操作无法保证整体原子性，仍需锁。
-
std::atomic<int></int>的fetch_add()比std::mutex快一个数量级，延迟约 12ns vs 85ns - 别盲目用
std::memory_order_seq_cst：读写缓存一致性开销大；多数场景用relaxed或acquire/release就够 - 注意 ABA 问题：比如无锁栈中指针被重用，
compare_exchange_weak()可能误判，需配合版本号或 hazard pointer
真正难的不是选哪种锁，而是识别哪些数据真的需要锁——很多所谓“共享变量”其实可以通过线程局部存储（thread_local）、消息传递或任务划分彻底消除共享。优化锁粒度的终点，往往是把锁去掉。
