LinkedHashMap访问顺序原理解析

golang学习网今天将给大家带来《LinkedHashMap访问顺序机制详解》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

LinkedHashMap默认按插入顺序遍历，启用访问顺序后每次访问将对应节点移至链表尾部，天然支持LRU缓存；底层基于哈希表+双向链表，重写removeEldestEntry可实现容量限制淘汰。

保持插入或访问顺序

LinkedHashMap 默认按元素插入顺序遍历，比如先 put("a",1)，再 put("b",2)，遍历时一定先 a 后 b。这个顺序不会因 get 或重复 put 同一个 key 而改变——除非显式启用访问顺序模式。

开启访问顺序（构造时传 true）后，每次调用 get、put（含更新值）、replace 等访问操作，对应 Entry 都会被移到双向链表末尾。这意味着链表尾部始终是最近被访问的元素，头部是最久未访问的——这正是 LRU 缓存的核心逻辑基础。

底层靠哈希表 + 双向链表协同工作

它继承 HashMap，复用其哈希表结构（数组+链表/红黑树）实现 O(1) 平均查找；同时每个节点额外携带 before 和 after 指针，构成双向链表。

插入新元素时：既写入哈希表，也追加到链表尾部；
访问已有元素且启用了 accessOrder：在哈希表中定位后，立即调整该节点在链表中的位置，将其 unlink 再 append 到尾部；
删除元素时：同步从哈希表和链表中移除对应节点，保证两者一致性。

支持定制淘汰策略：重写 removeEldestEntry

当新元素插入触发扩容前，LinkedHashMap 会自动调用 removeEldestEntry 方法，传入当前最老的 Entry（即链表头节点）。默认返回 false，不淘汰。

• 若想实现固定容量的 LRU 缓存，只需重写该方法，返回 size() > maxSize
• 该方法只在 put 过程中触发，get 不触发淘汰
• 淘汰的是链表头部元素，天然符合“最久未使用”语义

线程不安全但可扩展性强

它本身不是线程安全的，多线程环境下需外部同步（如用 Collections.synchronizedMap 包装），或配合读写锁使用。

它实现了 Cloneable 和 Serializable，支持深拷贝与序列化；迭代器采用快速失败机制（fail-fast），遍历时若结构被并发修改会抛 ConcurrentModificationException。

相比 HashMap，内存开销略高（每个节点多两个指针），但遍历性能更优——因为直接沿链表走，无需遍历整个哈希桶数组。

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