LRU缓存必须用哈希表与双向链表组合实现：哈希表提供O(1)键值查找，双向链表维护访问时序（头为最新、尾为最久），通过哨兵节点简化操作；单独循环链表无法满足O(1)查找，且增加冗余复杂度。

直接用循环链表单独实现高性能 LRU 缓存不可取——它缺快速查找能力，无法在 O(1) 时间定位 key。真正实用的方案是：用哈希表（如 unordered_map 或 HashMap）负责键值快速存取，再配一个双向链表（非循环）维护访问时序。所谓“循环链表”在标准 LRU 实现中并无必要，反而增加边界判断复杂度，容易出错。

为什么不用循环链表？

循环链表虽能省去 null 判断，但 LRU 的核心操作是“删尾”和“插头”，需要稳定、明确的头尾标识。双向链表加哨兵节点（dummy head/tail）已足够简洁高效：
– 尾节点永远是 tail->prev，删除即 removeNode(tail->prev)
– 新节点总插在 head->next，无需遍历找“前一个”
– 循环结构对淘汰逻辑无增益，却让节点移动、调试、边界处理更易出错

关键结构协同要点

• 哈希表存 key→节点指针：确保 get 时 O(1) 定位，避免遍历链表查 key
• 双向链表节点含 key 字段：淘汰尾节点后，必须通过该 key 从哈希表中同步删除映射，否则内存泄漏
• 每次 get/put 后立即 moveToHead：不是仅插入时调整，访问即刷新时序，这是 LRU 正确性的基础
• put 前先检查是否存在：存在则更新 value + 移至头部；不存在才新建节点，再判容量是否超限

方法调用结果缓存的适配技巧

将 LRU 扩展为“方法结果缓存”，需解决参数序列化与键生成问题：
– 对入参做轻量哈希（如 std::hash 组合或 Objects.hash），生成唯一 key，不依赖 toString() 防止冲突
– 若参数含不可哈希对象（如自定义类），需显式重写 equals/hashCode（Java）或提供 hash 函数（C++/C）
– 缓存 value 不是原始返回值，而是封装后的 Result<T>，可携带时间戳、是否异常等元信息
– 避免缓存 null 或空集合，除非业务明确允许；可在 put 前过滤，减少无效占用

性能与线程安全落地建议

• 单线程场景：裸哈希表 + 双向链表足矣，零额外开销
• 多线程场景：优先用读写锁（如 shared_mutex）保护整个缓存结构，比细粒度节点锁更简单可靠
• 高并发下慎用 synchronized HashMap 或全局 lock；可考虑分段哈希（如 Java 的 ConcurrentHashMap + 分段链表）
• 命中率监控必须内置：每 get 记一次 hit/miss，暴露为只读指标，用于动态调优容量