Java中的LinkedHashMap的访问顺序特性_实现LRU缓存淘汰算法的基石

accessorder 必须显式设为 true 才启用访问顺序，使 get() 或 put() 已存在 key 时将对应 entry 移至链表尾部；默认 false 按插入顺序维护，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()，链表结构完全不变。

What-the-Diff

检查请求差异，自动生成更改描述

下载

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

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

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

立即学习“Java免费学习笔记（深入）”；

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