LinkedHashMap 默认按插入顺序遍历,设 accessOrder=true 后改为访问顺序(LRU),每次 get 或 put 都会将节点移至链表尾,头节点为最久未访问项;需重写 removeEldestEntry() 实现自动淘汰。

LinkedHashMap 默认按插入顺序,但 accessOrder=true 会彻底改变遍历行为
很多人以为只要用了 LinkedHashMap,遍历就“一定”是写入顺序——这是最常见的误判。关键开关是构造时传的第三个参数:accessOrder。默认为 false(插入顺序),设为 true 后,每次 get() 或对已有 key 调用 put(),都会把对应节点移到链表尾部,头节点变成“最久未访问”的那个。
- 插入顺序(默认):
new LinkedHashMap()或new LinkedHashMap(16, 0.75f, false) - 访问顺序(LRU 模式):
new LinkedHashMap(16, 0.75f, true) -
put("x", 1)在访问顺序模式下也算一次“访问”,会触发重排序 - 即使只读不写,频繁
get()也会让顺序动态漂移,不是静态快照
遍历时的顺序稳定性,只依赖链表,和哈希桶完全无关
LinkedHashMap 的“有序”不是靠排序算法,也不是靠 hash 值大小,而是靠内部那条双向链表——每个 Entry 都有 before 和 after 引用,构成一条时间轴。扩容(rehash)时,节点在哈希表里的位置可能变,但链表中相对顺序丝毫不受影响。
-
keySet()、values()、entrySet()三者遍历顺序严格一致,因为共享同一链表 - 只要不调用
remove()、clear()、put(),遍历结果就绝对稳定 - 不能通过反射或序列化绕过链表去“恢复原始插入顺序”——链表就是唯一权威
- 多线程并发修改 + 遍历会触发
ConcurrentModificationException,它不是线程安全的
实现 LRU 缓存,光设 accessOrder=true 还不够
启用访问顺序只是第一步。真正自动淘汰“最老”元素,必须重写 removeEldestEntry() 方法,并让它返回 true。这个钩子会在每次 put() 插入新节点后被调用,框架据此决定是否移除链表头部节点(即最久未访问的那个)。
LinkedHashMaplruCache = new LinkedHashMap<>(16, 0.75f, true) { @Override protected boolean removeEldestEntry(Map.Entry eldest) { return size() > 100; // 超过 100 条就淘汰头节点 } };
-
removeEldestEntry()不会在get()时触发,只在put()后检查 - 如果只用
get()访问,但一直不put()新数据,缓存不会自动收缩 - 淘汰的是链表 head 处的节点,不是随机或按 key 字典序
- 若需线程安全,得用
Collections.synchronizedMap(lruCache)包一层
别把它当 TreeMap 用:自然排序和范围查询它都不支持
有人想用 LinkedHashMap 实现“按键字典序遍历”,这是方向性错误。它不比较 key,也不维护红黑树,所有顺序都来自操作时间戳。要自然排序或范围查询(比如找所有 key > "b" 的项),该用 TreeMap;要纯插入顺序且高性能,LinkedHashMap 才是正解。
立即学习“Java免费学习笔记(深入)”;
-
TreeMap查找是O(log n),LinkedHashMap是O(1)平均 -
TreeMap支持subMap()、headMap()等范围操作,LinkedHashMap完全不提供 - 如果只是想“保持配置文件里 key 出现的顺序”,
LinkedHashMap是轻量又精准的选择 - 键为
String时,不要指望entrySet()遍历出来是字母序——那是错觉
accessOrder=true,顺序就活起来了,而你得清楚它怎么活、何时活、活了之后怎么控。










