Go实现LRU缓存过期策略详解

本文深入剖析了在 Go 中实现带过期时间的 LRU 缓存时最易踩坑的核心问题，明确指出“惰性过期”（即仅在 Get 时检查时间戳、Set 时只更新有效期）才是高并发下兼顾正确性、性能与简洁性的唯一推荐方案；文章犀利批判了定时清理、全局锁、单 key goroutine 等常见误区，强调结构设计比逻辑实现更关键——避免魔改标准库、合理分离锁粒度、善用成熟库（如 hashicorp/golang-lru/v2）并辅以自定义时间字段封装，最终帮你绕开并发 panic、吞吐骤降和精度偏差等生产级陷阱，用最小成本落地稳定可靠的缓存机制。

Go 里没有内置的带过期时间的 LRU 缓存

标准库 container/list 和 map 拼出来的 LRU 只管访问顺序，不处理过期。想靠它直接实现“自动淘汰过期项”，会发现得自己维护时间戳、定时扫描、加锁判断——一写就错，而且容易漏掉并发读写竞争。

真正能用的方案只有两个：要么用成熟第三方库（比如 golang-lru 的 lru.NewARC 配合手动过期检查），要么自己封装一层带 TTL 的 wrapper。别试图魔改标准 LRU 结构体来塞时间逻辑，结构耦合太紧，后续扩展和测试成本高。

用 github.com/hashicorp/golang-lru/v2 + 自定义过期检查

这个库的 lru.Cache 支持自定义 OnEvict 回调，但不提供内置 TTL；你需要在 Get 时检查时间，在 Set 时存入时间戳。关键点不是“怎么存”，而是“什么时候判过期”：

• Get 时必须检查 value.ExpireAt 是否已过期，过期就当不存在，返回 false
• Set 时不要删老数据，让 LRU 自己按容量淘汰；只更新时间戳
• 所有时间比较用 time.Now().After(expireAt)，别用 Before 或 Sub 算秒数，易出精度偏差
• 如果缓存项是结构体，把 expireAt time.Time 字段放在结构体里，而不是额外用 map 存时间

示例片段：

type CacheItem struct {
    Data     interface{}
    ExpireAt time.Time
}
cache := lru.NewCacheany, CacheItem
cache.Set("key", CacheItem{
Data:     "value",
ExpireAt: time.Now().Add(5 * time.Minute),
})

为什么不用 time.AfterFunc 或 goroutine 定时清理

常见误区是为每个 key 启一个 time.AfterFunc，或开 goroutine 扫描全量 key 清理。这两种做法在高并发、大量 key 场景下立刻暴露问题：

• 每个 key 启一个 timer，内存和 goroutine 数线性增长，压垮调度器
• 定时扫描全量 map 是 O(n) 操作，且需全局锁，缓存读写被阻塞
• timer 精度受 runtime 调度影响，实际过期可能延迟几百毫秒甚至更久
• goroutine 中清理时若刚好有 Get 正在读，容易触发 panic：map 并发读写

正确做法是“惰性过期”（lazy expiration）：只在 Get 时检查，Set 时不干预，让 LRU 容量机制自然驱逐冷数据。过期只是“查不到”，不是“物理删除”。

注意 sync.RWMutex 的读写锁粒度

自己实现时最容易在锁上翻车：用一个全局 sync.RWMutex 包住整个 map，看起来安全，实则扼杀并发读性能。尤其在读多写少场景下，所有 Get 请求排队等读锁，吞吐骤降。

• 别对整个 cache 加锁，至少把 map 和 LRU list 分开锁，或者用 sync.Map 替代原生 map（但注意 sync.Map 不支持遍历，没法做 LRU 排序）
• 如果坚持用 map + list，推荐给 list 操作单独加锁，map 的读写用 sync.RWMutex，避免 list 遍历时锁住全部读请求
• 更稳妥的做法是用 sharded lock：把 key 哈希到多个 *sync.RWMutex 上，降低锁冲突概率

复杂点不在过期逻辑本身，而在如何让过期检查不破坏并发安全，又不拖慢读性能。很多团队最后发现，与其花两周手写，不如直接用 lru.Cache + 惰性检查，再加一层 prometheus 指标看命中率和过期率，反而更稳。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。