LinkedHashMap如何设置访问顺序

LinkedHashMap的访问顺序并非默认行为，而是必须在构造时显式传入`accessOrder = true`才能启用的关键机制——它让`get()`和`put()`操作自动将对应节点移至链表尾部，从而实现“最近访问优先”的迭代顺序，而`containsKey()`等只读方法则完全不触发重排；这一开关还彻底改变`removeEldestEntry()`的语义：开启后淘汰的是最久未被访问（而非最早插入）的条目，是构建可靠LRU缓存的核心前提；但需警惕其副作用——遍历时调用`get()`或`put()`会引发结构性修改，导致迭代器失效，因此实际使用中必须严格区分读写意图，避免逻辑陷阱。

LinkedHashMap 构造函数里 accessOrder 参数设为 true 才算开启访问顺序

默认不是访问顺序，而是插入顺序。哪怕你反复 get() 或 put()，只要没显式指定，LinkedHashMap 就按元素插入的先后排列迭代顺序。关键就在构造时那个布尔参数：accessOrder。

• new LinkedHashMap<>() 和 new LinkedHashMap<>(16, 0.75f) 都是插入顺序（accessOrder = false）
• 必须写成 new LinkedHashMap<>(16, 0.75f, true)，第三个参数 true 才启用访问顺序
• 注意：前两个参数（初始容量、负载因子）可以省略，但一旦要设 accessOrder，就必须把前两个也写全，否则编译不通过

访问顺序只对 get() 和 put() 生效，containsKey() 不触发重排序

很多人以为只要“访问”了就算，其实不是。LinkedHashMap 的访问顺序重排只发生在明确改变节点位置的操作上——也就是 get() 和 put()（含 putIfAbsent()）。而 containsKey()、getOrDefault() 这类只读方法不会移动节点。

• map.get("k") → 节点移到尾部（最新访问）
• map.put("k", "v") → 若 key 已存在，同样移到尾部；若不存在，则作为新节点追加到尾部
• map.containsKey("k") → 完全不改变链表顺序，哪怕这个 key 在头位置，查完它还在头

accessOrder = true 时 removeEldestEntry() 的判断依据是「最久未访问」而非「最早插入」

这是最容易误解的一点。当你要实现 LRU 缓存时，常配合覆写 removeEldestEntry()。如果没开访问顺序，它删的是第一个插入的；开了以后，删的就是迭代器头节点——也就是最久没被 get() 或 put() 触碰过的那个。

• 错误写法：return size() > 10; —— 会删掉最早插入但可能刚被访问过的项
• 正确逻辑依赖 accessOrder = true，再配 return size() > 10;，才能保证删的是最冷数据
• 注意：即使开了访问顺序，removeEldestEntry() 本身不自动删除，只是提供钩子；删除动作由 put() 内部触发

遍历顺序和迭代器行为在 accessOrder = true 下有隐蔽副作用

每次 get() 或 put() 都会修改链表结构，这意味着正在遍历的迭代器可能提前结束或抛 ConcurrentModificationException——不是因为多线程，而是单线程里边遍历边访问触发了结构性修改。

• 安全做法：避免在 for-each 或 iterator().forEachRemaining() 循环体内调用 get()/put()
• 如果真需要边查边更新顺序，改用 entrySet().toArray() 快照后再处理
• 另外，keySet()、values()、entrySet() 返回的集合视图都共享同一套顺序逻辑，改一个全变

accessOrder 是个开关，一开就联动整个行为模型；关了它，get() 就真的只是查，开了它，查就成了“摸一下就挪位置”的动作——这点不厘清，缓存淘汰永远不对劲。

以上就是《LinkedHashMap如何设置访问顺序》的详细内容，更多关于的资料请关注golang学习网公众号！