std::shared_mutex适合读多写少场景：读线程可并发执行，写线程独占访问；但读写均衡时开销反增，宜回退std::mutex；分段加锁+shared_mutex可进一步提升桶级并发，需权衡桶数与伪共享。
std::shared_mutex 适合读多写少的场景
直接用 std::mutex 锁整个容器（比如 std::map 或缓存结构），所有线程无论读写都得排队，哪怕访问的是完全不重叠的 key，也会互相阻塞。这种“一把大锁管全部”的做法，在读操作远多于写操作时，吞吐量几乎不随线程数增加而提升。
改用 std::shared_mutex 后，多个读线程可同时调用 lock_shared() 进入临界区，写线程调用 lock() 时才会强制等待所有读锁释放。这意味着：读操作之间零阻塞，写操作仍保持独占——这才是读写分离的实质。
注意：std::shared_mutex 的开销略高于 std::mutex，若读写频率接近，反而可能因管理共享状态带来额外负担，此时回归 std::mutex 更稳。
分段加锁 + shared_mutex 实现桶级并发
单个 std::shared_mutex 虽能解耦读写，但若读写都集中在同一块数据上（比如所有线程都在查同一个配置项），仍会形成热点。这时需进一步细化粒度：把数据拆成多个逻辑段，每段配独立的 std::shared_mutex。
- 哈希表场景下，常用
hash(key) % N将 key 映射到 N 个桶，每个桶用一个std::shared_mutex保护 - 读操作只锁对应桶，不同桶的读完全并行；写操作也只锁目标桶，不影响其他桶的读写
- N 取值需权衡：太小 → 桶内竞争高；太大 → 内存占用和锁管理开销上升，且易因哈希不均导致某些桶成为瓶颈
示例中，std::vector<:shared_mutex></:shared_mutex> 配合 std::vector<:map v>></:map> 是常见组合，但要注意避免伪共享（如多个 std::shared_mutex 被映射到同一 CPU cache line）。
lock_shared 和 shared_lock 的选择陷阱
std::shared_lock 是 RAII 封装，构造时自动调用 lock_shared()，析构时自动 unlock_shared()，安全简洁；而裸调 mtx.lock_shared() 必须手动配对 mtx.unlock_shared()，一旦异常或提前 return 就容易漏解锁，引发死锁。
但要注意：std::shared_lock 构造函数默认是阻塞式获取共享锁，若想非阻塞或带超时，得用带 std::defer_lock 或 std::try_to_lock 参数的重载版本。例如：
std::shared_lock<:shared_mutex> lock(mtx, std::try_to_lock);
if (!lock.owns_lock()) { /* 处理获取失败 */ }</:shared_mutex>
另外，std::shared_lock 不支持升级为写锁（即不能从读锁“升格”成独占锁），需要写操作时必须先释放读锁、再获取独占锁，中间存在短暂窗口——这点在强一致性要求下必须评估。
别忽略写操作的副作用与顺序
读写分离只解决并发访问控制，不解决写操作本身的原子性或可见性问题。例如多个写线程更新同一变量，即使用了 std::shared_mutex::lock()，仍要确保写入过程本身是原子的（比如 data = new_value 是平凡赋值，但 data.push_back(x) 可能涉及内存分配，需确认是否线程安全）。
更隐蔽的问题是：读线程看到的“最新写入”，依赖于写操作完成后的内存同步效果。虽然 std::shared_mutex 的 unlock() 和 lock_shared() 有隐含的 memory_order 语义（类似 memory_order_acquire/release），但若写操作内部还用了其他非同步手段（如裸指针修改、std::atomic 混用），仍可能观察到不一致状态。
实际压测时，建议用 perf 或 vtune 观察 shared_mutex 的等待时间与锁争用率，而不是仅看吞吐量数字——有时候锁没争上，是因为写线程太频繁，把读线程全挡在外面了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
