Go 实现本地 LRU 缓存库教程

本文深入剖析了在 Go 中实现高性能本地 LRU 缓存的核心原理与实战陷阱：直击 `container/list` 因缺乏 key 关联能力导致查找退化为 O(n) 的根本缺陷，强调必须结合哈希表与自定义双向链表节点实现真正的 O(1) 查找与移动；详解 Put 时避免内存泄漏的关键操作（同步删除 map 键与显式 Remove 链表节点）、线程安全的细粒度锁策略（RWMutex 原子保护 map 与 list），并理性探讨 TTL 扩展的取舍——建议惰性过期检查而非复杂定时机制，同时警示 createdAt 刷新等易被忽视的细节，助你写出健壮、高效、可维护的生产级 LRU 缓存库。

为什么不用 container/list 直接做 LRU？

因为 container/list 的节点指针（*list.Element）无法直接映射到 key，每次 Get 都得遍历链表找 value —— 时间复杂度退化成 O(n)，违背 LRU 本意。真正高效的 LRU 必须支持 O(1) 查找 + O(1) 移动节点。

所以得自己维护一个哈希表（map[interface{}] *node）+ 双向链表节点结构，且所有操作围绕“把命中节点移到头”和“淘汰尾节点”展开。

常见错误：用 map[key]value 存值、另起一个 list.List 存顺序 —— 两者完全脱节，Get 后没法把对应节点提到头部。

Put 时怎么避免内存泄漏和重复 alloc？

LRU 缓存满时，必须显式删除 map 中的旧 key，并手动调用 list.Remove() 释放链表节点引用。Go 的 GC 不会自动回收仍在链表中但已从 map 踢出的节点，因为 *list.Element 还持有它。

实操建议：

• 定义私有 node 结构体，内嵌 key, value interface{} 和 *list.Element 字段（用于反查链表节点）
• Put 前先查 map：若 key 已存在，更新 value 并 MoveToFront()；否则新建 node，插入 map 和 list 头部
• 缓存满时，取 list.Back() 对应的 node，从 map 删除其 key，再 list.Remove() 它
• 不要复用 node 实例（比如清空字段重塞），容易引发并发或逻辑错乱；直接 new 更安全

如何让缓存线程安全又不锁整个结构？

全量锁（sync.RWMutex 包裹整个 LRU struct）在高并发下会成为瓶颈。更合理的做法是：读写 map 和 list 都必须加锁，但锁粒度可以更细 —— 实际上 Go 标准库的 sync.Map 不适用于 LRU，因为它不提供顺序访问能力，所以还是得用互斥锁。

关键点：

• 用 sync.RWMutex：读多写少场景下，Get 用 RLock，Put/Delete 用 Lock
• 不要只锁 map 或只锁 list —— 二者必须原子性同步更新，否则会出现 map 有 key 但 list 没对应节点，或反之
• 如果对性能极致敏感，可考虑分片锁（shard by key hash），但本地缓存通常没必要；简单起见，一把锁足够

要不要支持带过期时间的 LRU？

纯 LRU 是容量驱逐，不关心时间。加 TTL 就变成 LRU + expiring cache，属于两个维度的策略叠加，实现会变复杂：需额外维护最小堆或定时器，或惰性检查（Get 时判断是否过期）。

实操建议：

• 如果只需要基础 LRU，别硬塞 TTL —— 代码膨胀、边界条件增多（比如过期 key 占着容量却不被访问，导致有效容量下降）
• 真需要 TTL，推荐组合模式：外层套一层 time.Now().Sub(node.createdAt) > ttl 判断，Get 返回前检查，Put 时记录 createdAt；不主动清理，靠访问触发淘汰
• 注意：此时 Len() 应返回未过期项数，而不是 map 长度 —— 否则 Cap() 判断会失准

最易被忽略的是：当 Put 一个已存在的 key 时，必须刷新它的 createdAt，否则 TTL 逻辑就失效了。

到这里，我们也就讲完了《Go 实现本地 LRU 缓存库教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！