C++实现高效线程安全LRU缓存系统的方法

作者：袖梨 2026-06-18

不能只用一把 std::mutex 锁住整个 get() 和 put()，否则吞吐量断崖式下降；应使用 std::shared_mutex 区分读写：get() 用 shared_lock 并发，put() 用 unique_lock 排他，并注意 splice() 参数顺序、淘汰顺序、智能指针优化及迭代器有效性。

为什么不能只用一把 `std::mutex` 锁住整个 `get()` 和 `put()`

吞吐量会断崖式下降——所有读请求（get()）和写请求（put()）串行排队，哪怕并发读多于写，也完全无法利用多核。真实业务中，读占比常超 90%，锁粒度太粗直接让缓存变成瓶颈。

正确做法是区分读写场景：get() 只需查 map + 移动链表节点，全程可并发；put() 涉及插入、淘汰、更新，必须排他。C++17 的 std::shared_mutex 正为此设计：

std::shared_lock<:shared_mutex></:shared_mutex> 用于 get()：多个线程可同时持有共享锁
std::unique_lock<:shared_mutex></:shared_mutex> 用于 put()：写操作独占，自动阻塞其他读写

注意：不要在 get() 中提前释放锁再调用 splice() —— splice() 需要访问链表和 map，必须在锁内完成，否则竞态下迭代器可能已被其他线程 erase。

`std::list::splice()` 参数顺序为什么总写错

常见错误是写成 cache_list_.splice(cache_list_.begin(), it->second)，这会触发编译失败或运行时崩溃。因为 splice() 的三参数重载签名是：splice(pos, list, it)，含义是「把 it 指向的节点，插入到 pos 之前」，不是「插入到 pos 位置」。

立即学习“C++免费学习笔记（深入）”；

所以要把节点移到头部，必须写成：

cache_list_.splice(cache_list_.begin(), cache_list_, it->second);

漏掉第二个参数 cache_list_，编译器会匹配到单链表版本（forward_list），而 std::list 不支持；写成 cache_list_.splice(cache_list_.begin(), it->second) 则匹配错误重载，行为未定义。

另外：it->second 是 std::list::iterator，不是指针，不能解引用后传 —— splice() 要的就是迭代器本身。

淘汰尾部节点时，为什么必须先删 `unordered_map` 再删 `list`

顺序反了就会留下悬空迭代器：如果先 cache_list_.pop_back()，被删节点的迭代器立即失效，但 cache_map_[key] 还指着它；下次 get(key) 解引用这个迭代器，就是未定义行为（UB），轻则返回垃圾值，重则段错误。

标准做法是：

取尾部节点：auto last = cache_list_.back()
从 map 中擦除：cache_map_.erase(last.first)
再从 list 中移除：cache_list_.pop_back()

这个顺序保证 map 里永远不存指向已销毁节点的迭代器。同理，在 put() 更新已有 key 时，也不能直接赋值 cache_map_[key] = cache_list_.begin() —— 这会触发 unordered_map::operator[] 默认构造旧值再赋值，异常风险高；应改用 cache_map_.insert_or_assign(key, cache_list_.begin())（C++17）。