LinkedHashMap有序原理与使用解析

珍惜时间，勤奋学习！今天给大家带来《Java LinkedHashMap有序特性详解》，正文内容主要涉及到等等，如果你正在学习文章，或者是对文章有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

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() 插入新节点后被调用，框架据此决定是否移除链表头部节点（即最久未访问的那个）。

LinkedHashMap<String, String> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
    @Override
    protected boolean removeEldestEntry(Map.Entry<String, String> eldest) {
        return size() > 100; // 超过 100 条就淘汰头节点
    }
};

• removeEldestEntry() 不会在 get() 时触发，只在 put() 后检查
• 如果只用 get() 访问，但一直不 put() 新数据，缓存不会自动收缩
• 淘汰的是链表 head 处的节点，不是随机或按 key 字典序
• 若需线程安全，得用 Collections.synchronizedMap(lruCache) 包一层

别把它当 TreeMap 用：自然排序和范围查询它都不支持

有人想用 LinkedHashMap 实现“按键字典序遍历”，这是方向性错误。它不比较 key，也不维护红黑树，所有顺序都来自操作时间戳。要自然排序或范围查询（比如找所有 key > "b" 的项），该用 TreeMap；要纯插入顺序且高性能，LinkedHashMap 才是正解。

• TreeMap 查找是 O(log n)，LinkedHashMap 是 O(1) 平均
• TreeMap 支持 subMap()、headMap() 等范围操作，LinkedHashMap 完全不提供
• 如果只是想“保持配置文件里 key 出现的顺序”，LinkedHashMap 是轻量又精准的选择
• 键为 String 时，不要指望 entrySet() 遍历出来是字母序——那是错觉

好了，本文到此结束，带大家了解了《LinkedHashMap有序原理与使用解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！