LinkedHashMap 默认按插入顺序维护元素，设 accessOrder=true 时转为访问顺序（LRU）；put() 和 get() 均触发节点移至链表尾，遍历顺序由双向链表保障，与哈希桶无关，扩容不破坏顺序。
LinkedHashMap 的插入顺序和访问顺序区别
LinkedHashMap 默认按插入顺序维护元素，但可以通过构造函数参数切换为访问顺序（LRU 缓存模式）。这个开关是布尔值 accessOrder，设为 true 时，每次 get() 或 put() 都会把对应节点移到链表尾部。
常见误判是以为“只要用了 LinkedHashMap 就一定保持‘写入时的顺序’”，其实如果初始化时传了 true，再频繁读取某些 key，顺序就会动态变化。
- 插入顺序（默认）：
new LinkedHashMap()或new LinkedHashMap(16, 0.75f, false) - 访问顺序（LRU）：
new LinkedHashMap(16, 0.75f, true) -
put()在访问顺序模式下也视为“访问”，会触发重排序
遍历 LinkedHashMap 时顺序是否稳定
只要不修改 map 结构（如不调用 remove()、clear()、put()），遍历结果严格保持构造时定义的顺序（插入或访问）。但要注意：迭代器本身不保证线程安全，多线程并发修改 + 遍历可能抛 ConcurrentModificationException。
另外，keySet()、values()、entrySet() 三者遍历顺序完全一致，因为底层共享同一套双向链表。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 顺序稳定性只依赖内部链表，与哈希桶位置无关
- 扩容（rehash）不会打乱链表顺序，只是重新分配节点到新桶中
- 不要在 foreach 循环中调用
remove()，应使用Iterator.remove()
为什么 HashMap 无序而 LinkedHashMap 有序
根本差异在底层数据结构：HashMap 只有哈希表（数组 + 链表/红黑树），节点散列后位置由 hashCode() 和容量决定；LinkedHashMap 多了一条双向链表，所有 Node 同时挂在哈希表和链表上，插入时既算 hash 桶位置，也追加到链表尾。
这意味着：LinkedHashMap 的“有序”不是靠排序，而是靠链表记录操作时间轴。所以它比 HashMap 略重（每个节点多两个引用字段），但时间复杂度仍是 O(1) 平均情况。
- 链表节点类是
LinkedHashMap.Entry，继承自HashMap.Node，额外含before和after - 不能通过反射或序列化绕过链表来“恢复”原始插入顺序 —— 链表就是唯一顺序来源
- 如果需要按自然顺序（如字符串字典序）排序，该用
TreeMap，不是 LinkedHashMap
remove() 和 replace() 对顺序的影响
remove(key) 会从哈希表和链表中同时摘除节点，后续遍历跳过它，其余节点相对顺序不变。replace(key, value) 不改变节点在链表中的位置，只更新 value；但 replace(key, oldValue, newValue) 成功时也不移动节点。
真正容易踩坑的是 compute()、merge() 这类方法：它们内部可能先 get() 再 put()，在访问顺序模式下会触发重排序。
-
putIfAbsent()：若 key 不存在，等价于put()→ 插入到链表尾；若存在，不改动顺序 -
computeIfPresent()：仅当 key 存在才执行，且在访问顺序模式下会移动该节点到尾部 - 想避免意外重排，就别开
accessOrder = true，除非你明确要 LRU 行为
Map<String, Integer> map = new LinkedHashMap<>(16, 0.75f, true); // 访问顺序
map.put("a", 1);
map.put("b", 2);
map.put("c", 3);
map.get("a"); // 触发重排："b" → "c" → "a"
System.out.println(map.keySet()); // [b, c, a]
LinkedHashMap 的顺序保障很实在，但也只保障它承诺的那一类顺序 —— 插入或访问，不是“任意维度的有序”。用错模式或者混淆操作语义，顺序就会出人意料。 
