LinkedHashMap访问顺序原理解析

LinkedHashMap 的访问顺序特性并非开箱即用，必须显式将 accessOrder 设为 true 才能激活 get() 或 put()（对已存在 key）触发节点移至链表尾部的“热度刷新”机制，否则默认按插入顺序运行、LRU 彻底失效；其 LRU 淘汰能力完全依赖子类重写的 removeEldestEntry() 方法返回 true 来触发删除链表头节点，且该逻辑仅在写入后执行，读取不触发淘汰；更需警惕的是，get() 查无此键时完全不扰动链表，但若误判 null 为缺失而重复 put() 会堆积冗余节点；而在并发场景下，哪怕仅多线程读取也会因内部链表修改引发结构破坏、空指针或竞态问题——这意味着一个真正可靠的 LRU 缓存远不止设个参数那么简单，从构造方式、淘汰设计到线程安全，每一步都藏着容易踩坑的关键细节。

LinkedHashMap 的 accessOrder 参数怎么设才启用访问顺序

不设 accessOrder 或设为 false（默认），LinkedHashMap 按插入顺序维护节点；只有显式传入 true 才开启访问顺序——即每次调用 get() 或 put() 已存在 key 时，对应 Entry 会被移到链表尾部。

• 构造时必须写全参： new LinkedHashMap(initialCapacity, loadFactor, true)
• 漏掉第三个参数或传 false，get() 不会改变顺序，LRU 逻辑直接失效
• 注意：JDK 8+ 中 computeIfPresent()、merge() 等方法也会触发访问重排序，但 replace(K,V) 不会（它不改变 value 时甚至不调用 afterNodeAccess()）

为什么重写 removeEldestEntry() 是 LRU 的关键开关

LinkedHashMap 本身不自动淘汰，靠子类重写 removeEldestEntry() 在每次插入后决定是否删最老项。这个方法返回 true 才真删——而“最老”在访问顺序下就是链表头节点。

• 典型写法：

  protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
      return size() > MAX_SIZE;
  }

• 别在方法里手动调用 remove(eldest.getKey())：重复删除或破坏迭代器安全
• 该方法在 put()、putAll() 后触发，但 get() 不触发——所以容量控制只响应写入，读多写少场景需额外兜底

get() 返回 null 时会不会影响 LRU 顺序

不会。如果 key 不存在，get() 返回 null，但内部不调用 afterNodeAccess()，链表结构完全不变。

• 这意味着：查不到的 key 不会“刷新热度”，也不会意外挤走其他有效项
• 但要注意空值歧义：如果业务允许 value 为 null，就不能靠 get() 返回值判断 key 是否存在，得用 containsKey()
• 若误把 null 当作缺失而反复 put()，会导致同 key 多次插入，链表尾部堆积冗余节点（虽不影响功能，但浪费内存）

并发环境下直接用 LinkedHashMap 实现 LRU 会出什么问题

会丢数据、顺序错乱、甚至 ConcurrentModificationException。因为 LinkedHashMap 非线程安全，其迭代器和链表操作都无同步保障。

• 常见错误：多个线程同时 get() + put()，导致链表指针断裂，后续遍历抛 NullPointerException
• 不能简单套 Collections.synchronizedMap()：它只锁单个方法，size() 和 removeEldestEntry() 之间存在竞态窗口
• 生产环境建议用 ConcurrentHashMap + 自研双向链表，或直接用 caffeine；非要手写，至少得把整个 get-put-removeEldestEntry 流程包进 synchronized 块

今天关于《LinkedHashMap访问顺序原理解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！