linkedhashmap 默认按插入顺序迭代，底层通过双向链表维护节点顺序，无需额外配置；启用 accessorder=true 会改为访问顺序，导致 get() 移动节点至尾部。
LinkedHashMap 默认就按插入顺序迭代，无需额外配置
只要不启用访问顺序模式，LinkedHashMap 的迭代顺序天然与插入顺序一致。这是它和 HashMap 最核心的区别，底层靠双向链表维护插入节点的先后关系，不是靠排序或重哈希。
常见误操作是手动调用 sort() 或试图用 TreeMap 替代——完全没必要，反而引入比较逻辑和性能开销。
- 构造时传
true到第三个参数（accessOrder）才会切换成“最近访问优先”，此时顺序会动态变化 - 遍历
keySet()、values()、entrySet()都保持同一插入顺序 - 重复
put()同一个 key 不算新插入，不会改变该 entry 在链表中的位置
put() 和 putAll() 都严格遵循插入时的调用顺序
每调用一次 put(key, value)，对应节点就被追加到链表尾部；putAll(map) 则按源 map 的迭代顺序逐个插入——所以如果源 map 是 LinkedHashMap，结果顺序可预测；如果是 HashMap，则顺序不可靠。
注意：JDK 8+ 中，即使触发扩容（rehash），LinkedHashMap 仍能保持原有插入顺序，因为重散列过程会按链表顺序重新链接节点，不是简单地按 hash 桶重排。
立即学习“Java免费学习笔记（深入）”；
- 使用
putIfAbsent()时，仅当 key 不存在才插入，不影响已有顺序 -
computeIfAbsent()同理，计算出值后才插入，插入时机就是计算完成那一刻 - 避免在循环中反复
put()相同 key，看似“插入”实则只是更新，链表结构不变
遍历时顺序异常？先检查是否启用了 accessOrder
最典型的“顺序错乱”现象：刚插入完 A、B、C，但遍历时却是 B、C、A —— 这基本说明你创建时用了 new LinkedHashMap(16, 0.75f, true)，开启了访问顺序模式。此时每次 get() 都会把对应节点移到链表尾，相当于 LRU 缓存行为。
错误示例：LinkedHashMap<string integer> map = new LinkedHashMap(16, 0.75f, true); map.put("a", 1); map.put("b", 2); map.get("a"); // 此时 a 被移到尾部，迭代顺序变成 b → a</string>
- 确认构造参数第三个值是否为
true；默认是false，别显式写成true - 不要在遍历过程中调用
get()或containsKey()，可能意外触发节点移动 - 调试时可用
map.entrySet().stream().map(Map.Entry::getKey).collect(Collectors.toList())快速看当前顺序
替代方案对比：TreeMap 不等于“插入有序”，而是“自然/自定义序”
有人误以为 TreeMap 能替代 LinkedHashMap 实现插入顺序，其实它只保证按键的比较结果排序（升序或自定义），跟插入时间毫无关系。比如按字符串长度排序，"a"、"bb"、"ccc" 插入后顺序是 "a"、"bb"、"ccc"，纯属巧合；若插入 "x"、"aa"、"bbb"，顺序就变成 "x"、"aa"、"bbb" —— 看似有序，但不是插入序。
-
TreeMap插入时间复杂度是 O(log n)，LinkedHashMap是 O(1) 平摊，大数据量下差异明显 -
TreeMap要求 key 可比较（实现Comparable或传Comparator），LinkedHashMap对 key 类型无要求 - 如果真需要“插入顺序 + 副本按某字段排序”，应分开处理：用
LinkedHashMap存原始数据，需要排序时再转List后sort()
LinkedHashMap 做得既轻量又确定，别绕弯。 
