不能直接用 std::shared_mutex 控制多级缓存，因其将无竞争的 L1 操作拖入系统调用，导致高并发吞吐下降 30%+；应分层加锁：L1 无锁（线程隔离），L2 用 shared_mutex 仅在 miss/写回时触发，写回推荐 write-through。
为什么不能直接用 std::shared_mutex 做多级缓存的读写控制
因为多级缓存（比如 L1 本地线程缓存 + L2 全局共享缓存）的读写路径天然不对称：L1 经常被单线程高频读写，L2 才需要跨线程同步。用 std::shared_mutex 统一锁两级，会把 L1 的无竞争操作也拖进系统调用开销里，实测在高并发下吞吐可能掉 30%+。
正确做法是分层加锁：
- L1 缓存（
thread_local或std::unordered_map）完全无锁，靠线程隔离保证安全 - L2 缓存（全局
std::unordered_map）用std::shared_mutex，但只在 L1 miss 后的 load-from-L2 和写回时触发 - 写回策略建议用 write-through（写 L1 同时同步写 L2），避免 L2 脏数据和复杂 invalidation 逻辑
如何避免 std::thread 构造时捕获局部变量导致的悬垂引用
多级缓存常需要后台线程做 L2 定期清理或异步加载，但新手容易在 lambda 中直接 capture [&] 引用局部缓存对象，线程启动后原栈帧已销毁，访问就 crash。
安全写法只有两种：
立即学习“C++免费学习笔记（深入）”；
- 用
[cache_ptr = std::make_shared<l2cache>(...)]</l2cache>显式转移所有权，确保生命周期由 shared_ptr 管理 - 若必须用原始指针，改用
[cache_ptr = this]（类成员函数中）并确保this生命周期长于线程 - 绝对不要在
std::thread构造时传入std::ref(local_var)——std::thread的拷贝语义会导致引用绑定到临时副本上
std::atomic 在缓存失效标记中的误用场景
有人用 std::atomic<bool> l2_valid{true}</bool> 控制 L2 是否可用，但在多线程频繁检查时，单纯 load 可能因缓存行争用（false sharing）拖慢性能；更糟的是，如果用 store(false) 失效 L2 后没配合内存序，L1 线程可能仍读到旧值。
实际要这样处理：
- 失效标记必须用
std::atomic<bool>::store(true, std::memory_order_release)</bool>+load(std::memory_order_acquire)配对 - 若失效频率低（如配置变更），直接用
std::atomic_flag更轻量 - 别给每个 key 单独加 atomic 标记 —— 内存爆炸且无意义；按 cache 分片（shard）批量管理更现实
为什么 std::unordered_map 直接用于 L2 会在线程切换时卡顿
标准库的 std::unordered_map 重哈希（rehash）是阻塞式全表锁，一旦触发，所有读线程都会等写线程完成扩容。在缓存命中率波动时，这种卡顿不可预测且难以压测复现。
生产环境应替换为：
- 分段哈希表：手写 64 个
std::unordered_map+std::shared_mutex[64]，key hash 后取模选 shard - 或直接用
folly::ConcurrentHashMap（需引入 folly），它内部用细粒度锁 + 无锁读，实测 rehash 不影响读性能 - 若坚持用标准容器，至少预设足够大容量：
reserve(1 并禁用负载因子自动增长（通过封装 wrapper 拦截 <code>insert时的 rehash）
多级缓存的真正难点不在结构设计，而在各级之间的一致性边界——比如 L1 更新后是否立即通知 L2、通知失败怎么降级、时钟不同步时 TTL 怎么对齐。这些细节不写进代码注释，上线后必出问题。
