LRU与TTL内存缓存实现方法详解

本文深入探讨了如何在不依赖第三方库的前提下，高效实现一个兼具LRU（最近最少使用）淘汰与TTL（生存时间）自动过期能力的内存缓存——既避开纯Map无法感知访问顺序、缺乏过期机制的缺陷，又规避了为每个键单独设定时器导致的内存泄漏与性能陷阱；通过Dictionary+LinkedList组合管理访问序与数据存储，并采用惰性清理为主、低频轻量扫描为辅的混合过期策略，配合相对时间戳设计抵御系统时钟漂移，在保证O(1)核心操作复杂度的同时，兼顾高并发安全性、内存可控性与生产级健壮性，是构建轻量可靠本地缓存的实用指南。

为什么不能只用 Map 实现 LRU + TTL？

因为 Map 本身不支持自动过期，而手动遍历清理会破坏 O(1) 时间复杂度；同时 LRU 需要访问顺序感知，单纯靠对象属性或数组维护顺序，在高并发或频繁读写时容易错乱。常见错误是：用 setTimeout 为每个 key 单独设定时器——内存和句柄泄漏风险极高，尤其 key 量大时。

LRUMap 基础结构怎么搭才兼顾顺序与过期？

核心是把「访问时间」和「插入顺序」解耦：用 Map 存数据 + 过期时间戳，另用一个 Map（或数组）维护 key 的最近访问时间，但更轻量的做法是——每次 get 时更新时间戳，并在 set 或 get 时惰性清理过期项。实际只需两个字段：this.cache = new Map() 存 { value, expiresAt }，this.maxSize 控制容量。

• set(key, value, ttlMs)：计算 expiresAt = Date.now() + ttlMs，存入；若超容，调用 evict() 删除最久未用（即最早插入且未被 get 刷新过的）项
• get(key)：先检查 expiresAt < Date.now()，过期则 delete 并返回 undefined；否则更新该 key 的访问时间（可选：写回 expiresAt 延长有效期，按需）
• 「最久未用」靠插入顺序 + 访问标记实现：每次 get 后，delete 再 set 该 key，让其排到 Map 末尾——Map 的迭代顺序就是插入顺序，所以 this.cache.keys().next().value 就是最老的 key

如何避免 Date.now() 在高频场景下成为瓶颈？

Date.now() 调用本身不重，但若每读写都调用两次（get 检查 + set 计算），在十万级 QPS 下会有微小开销。更关键的是时钟漂移问题：比如服务刚启动、系统时间被 NTP 回拨，会导致大量缓存误判过期。稳妥做法是：所有时间比较统一用相对时间，例如记录 this.startTime = Date.now()，存 expiresInMs 而非绝对时间戳，检查时用 Date.now() - this.startTime > expiresInMs。不过要注意，如果进程运行超 24.8 天（Number.MAX_SAFE_INTEGER / 1000 / 60 / 60 / 24），相对时间差可能溢出，一般业务无需考虑。

删除策略里「惰性清理」和「主动轮询」怎么选？

惰性清理（只在 get/set 时顺手删过期项）实现简单、无额外线程开销，适合中小流量；但它无法释放已过期但长期无人访问的内存。主动轮询（如每秒 setInterval 扫描并清理）能及时回收，但需注意：扫描不能阻塞主线程，建议用 setTimeout 分批处理（每次最多删 100 个），且必须加锁防止并发修改 Map。生产环境更推荐混合策略：惰性为主，辅以低频（如每分钟一次）轻量扫描，扫描范围限制在 Math.min(100, this.cache.size / 10)。

真正容易被忽略的是：Map.prototype.delete() 不会触发 GC 立即回收，尤其是 value 是大对象（如 JSON 字符串、Buffer）时，务必确保没有外部引用残留——比如你把缓存值又传给了某个事件监听器，那它就永远不会被回收。

今天关于《LRU与TTL内存缓存实现方法详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！