如何使用LinkedHashMap通过accessOrder实现LRU缓存

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《如何使用LinkedHashMap通过accessOrder实现LRU缓存》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

accessOrder=true是LRU生效的前提，必须显式设置；仅重写removeEldestEntry无效，它只控制是否删除、不决定淘汰顺序；Java 8+中get/put触发顺序更新，但getOrDefault等不触发；removeEldestEntry须严格用size()>capacity；该方法内不可耗时；LinkedHashMap非线程安全，需额外同步；key必须正确实现equals/hashCode且不可变。

accessOrder=true 是 LRU 的开关，不是默认值

LinkedHashMap 默认是插入顺序（accessOrder=false），哪怕你重写了 removeEldestEntry，不打开 accessOrder，get 操作也不会把访问项移到尾部，缓存淘汰完全失效。这是最常踩的坑——代码看着像 LRU，跑起来却是 FIFO。

• 构造时必须显式传 true：new LinkedHashMap(16, 0.75f, true)
• 只靠重写 removeEldestEntry 不够，它只管“删不删”，不管“谁该被删”；accessOrder 才决定“谁在尾部、谁最先被淘汰”
• Java 8+ 中，get 和 put 都会触发顺序更新；但 getOrDefault、computeIfAbsent 等方法不会——它们绕过了 LinkedHashMap 的 access hook

removeEldestEntry 的返回逻辑必须严格匹配容量限制

这个方法不是“每 put 一次就调用一次”，而是每次 put 后触发，返回 true 才删除最老项（即头节点）。如果逻辑写成 size() > capacity + 1 或漏了等号，就会多存一项或卡住不删。

• 正确写法是：return size() > capacity;（假设 capacity 是你期望的最大条目数）
• 别在里头做 I/O、锁或耗时操作——它在 put 调用栈里同步执行，拖慢所有写入
• 注意：初始空 map 的第一次 put 也会进这个方法，此时 size() 是 1，别让它误删

并发场景下 LinkedHashMap 本身不安全

即使用了 accessOrder 和正确的 removeEldestEntry，多个线程同时 get/put 仍可能抛 ConcurrentModificationException，或导致链表断裂、丢失条目。这不是配置问题，是底层结构没加锁。

• 别用 Collections.synchronizedMap(new LinkedHashMap(...)) —— 它只同步单个方法，get + put 组合操作仍不原子
• 简单场景可用 ReentrantLock 包一层，但吞吐会掉；高并发建议换 caffeine 或 guava Cache
• 如果坚持手写，至少把 get 和 put 逻辑锁在同一个临界区，别分开加锁

key 的 equals/hashCode 必须可靠，否则 LRU 形同虚设

LinkedHashMap 依赖 key 的 hashCode 定位桶、equals 判等。如果 key 是自定义对象且没重写这两个方法，相同语义的 key 会被当成不同 key 存多次，缓存膨胀，removeEldestEntry 删的也不是真最老的那个。

• 检查你的 key 类是否实现了 equals 和 hashCode，且逻辑一致（比如都基于 id 字段）
• 避免用可变字段（如 ArrayList、含 setter 的 POJO）作 key——内容变了，hash 可能变，后续 get 就找不到
• 字符串 key 最省心；Integer/Long 等包装类也 OK；其他一律先验

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《如何使用LinkedHashMap通过accessOrder实现LRU缓存》文章吧，也可关注golang学习网公众号了解相关技术文章。