直接用 std::map + std::mutex 全局锁会导致所有读写串行化，即使访问不同 key 也需排队，吞吐量受限于单核；分段锁通过哈希将 map 拆为 N 个桶，每桶独立加锁（推荐 std::shared_mutex），提升读写并行度，桶数宜选 32 或 64，索引用 hash(key) & (num_buckets-1)，桶内用 std::unordered_map，操作须在锁内完成且避免跨桶加锁。
为什么不能直接用 std::map + std::mutex 全局锁？
全局互斥锁会让所有读写操作串行化，哪怕两个线程访问的是完全不相交的 key（比如 "user_123" 和 "order_456"），也得排队。吞吐量卡在单核瓶颈上，尤其在读多写少场景下，std::mutex 成了性能拖累。
分段锁（segmented lock）的核心思路是：把 map 拆成 N 个子桶（bucket），每个桶配一把独立锁。key 经哈希后落到对应桶，线程只争抢自己需要的那个锁 —— 读写并行度大幅提升。
但注意：std::shared_mutex（C++17）比 std::mutex 更适合这里，因为它的 lock_shared() 支持多读不互斥，而 lock() 写独占。读操作多时，收益明显。
如何设计分段锁 Map 的桶索引与锁粒度？
桶数不是越多越好。太少（如 4 个）锁竞争仍高；太多（如 65536）则内存开销和哈希计算成本上升，且可能因 false sharing 导致缓存行争用。实践中，32 或 64 是较稳妥的起点，可按实际并发线程数 × 2 调整。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键实现点：
- 用
std::vector<:shared_mutex></:shared_mutex>管理 N 把锁，而非数组 —— 避免手动内存管理 - 桶索引必须用无符号哈希结果对桶数取模：
hash(key) & (num_buckets - 1)（仅当num_buckets是 2 的幂时可用位与，更快；否则用%） - 每个桶内部用
std::unordered_map而非std::map，避免 O(log n) 查找拖慢热点路径 - 不要在锁外持有迭代器或引用 —— 桶内 map 可能被其他线程重哈希（rehash），导致迭代器失效
shared\_mutex 在读写操作中的具体调用时机
std::shared_mutex 的语义必须严格匹配操作类型：读操作用 std::shared_lock，写操作用 std::unique_lock。混用会破坏线程安全，比如用 unique_lock 读，虽能跑通，但阻塞了其他读线程，白瞎了 shared_mutex 的设计。
典型操作模式：
-
get(key)：先算桶索引 →std::shared_lock<:shared_mutex></:shared_mutex>加共享锁 → 查unordered_map→ 解锁后返回值（别在锁里 return 引用！） -
put(key, value)：桶索引 →std::unique_lock<:shared_mutex></:shared_mutex>加独占锁 → 插入或覆盖 → 解锁 -
erase(key)：同put，用独占锁 - 遍历（如
size()或全量 dump）需谨慎：必须对所有桶依次加shared_lock，且注意“快照”语义 —— 中间其他线程的修改不会反映在本次遍历中
容易忽略的边界问题与修复建议
分段锁不是银弹，几个坑常被跳过：
-
rehash风险：单个桶的unordered_map在插入时可能触发 rehash，此时整个桶 map 重建，迭代器/指针全部失效。解决方法是：所有读写操作都必须在锁内完成查找+访问，绝不缓存迭代器到锁外 - 哈希冲突 ≠ 桶冲突：不同 key 哈希到同一桶是正常现象，只要桶内 map 正确处理即可；但若自定义 key 的
operator==或哈希函数有 bug，会导致查不到或重复插入 —— 务必单元测试 key 的哈希一致性 - 内存泄漏隐患：如果 value 类型含裸指针或需特殊析构，桶 map 的生命周期由容器控制，但析构发生在最后一次锁释放之后。确保 value 析构是无锁、无异常的
- 死锁风险：禁止跨桶加锁（如同时操作 bucket[3] 和 bucket[7]），否则顺序不一致易死锁。所有 API 必须单桶操作，批量接口（如
multi_get）应要求 caller 自行保证 key 分布或退化为串行处理
最麻烦的其实是 resize —— 动态扩桶需重新哈希所有已有 key，这本质上是一次全局写操作。生产环境建议初始化时设好足够桶数，避免运行时 resize。
