LinkedHashMap 默认按插入顺序遍历，依靠内部双向链表维护节点顺序，keySet()、entrySet()、values() 遍历顺序一致；传入第三个参数 true 则启用访问顺序模式。
LinkedHashMap 默认就按插入顺序遍历，无需额外配置
只要用 new LinkedHashMap() 或带前两个参数的构造函数（如 new LinkedHashMap(16, 0.75f)），它就会严格按 put() 的调用顺序返回元素。这不是“排序”，而是靠内部双向链表实时记录插入轨迹——每个节点多两个引用字段 before 和 after，插入时直接追加到链表尾部。
- 遍历
keySet()、entrySet()、values()三者顺序完全一致 - 重复
put("k", v)同一个 key，只更新 value，节点在链表中的位置不动 - 扩容（
resize()）会重建哈希桶，但链表节点仍按原顺序逐个 rehash 并追加，顺序不受影响 - 序列化/反序列化后顺序依然保留（前提是没自定义
writeObject()）
第三个参数 true 会彻底关闭插入顺序
一旦构造时传入 new LinkedHashMap(16, 0.75f, true)，就启用了访问顺序（access-order）模式。此时每次 get() 或对已有 key 调用 put()，对应节点都会被移到链表尾部——遍历结果反映的是“最近访问时间”，不是“首次插入时间”。
- 常见误用：复制别人代码时没注意第三个参数，导致遍历时顺序“跳变”，比如
get("a")后，"a"突然跑到最后 -
putAll(map)的顺序取决于源map的迭代顺序；若源是HashMap，那插入顺序就不可控 - 想验证是否真按插入顺序：别用
System.out.println(map)，它依赖toString()实现细节；应显式用for (Map.Entry e : map.entrySet())遍历比对
遍历安全边界：顺序只在迭代器中保证
LinkedHashMap 的有序性是通过其自身迭代器实现的，不是数据结构“自动维持”的全局状态。一旦脱离迭代器路径，顺序就不再受保障。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
map.keySet().toArray()：当前 JDK 实现通常保持顺序，但 Javadoc 不承诺，不建议依赖 -
map.entrySet().stream().forEach(...)：单线程流一般没问题；但parallelStream()可能乱序，除非加.sorted() - 多线程环境下，边遍历边
put()或remove()会触发ConcurrentModificationException -
remove(key)会从链表和哈希表中同时摘除节点，其余节点相对顺序不变；replace()不移动节点
什么时候该选 LinkedHashMap，而不是 TreeMap 或 HashMap
如果需求是“谁先来，谁在前”，LinkedHashMap 是唯一标准库内置解。TreeMap 按 key 自然序或 comparator 排序，和插入动作无关；HashMap 连“大致顺序”都不保证，扩容、JDK 版本甚至 GC 都可能让遍历结果变化。
立即学习“Java免费学习笔记（深入）”；
- 适合场景：配置项加载（需保持文件书写顺序）、日志上下文快照、接口响应字段顺序固定（如某些 JSON API 要求）、LRU 缓存（配合
accessOrder = true+removeEldestEntry()） - 性能开销：每个节点多两个引用，内存略增，但查找、插入仍是平均
O(1) - 线程安全：不支持并发修改；如需线程安全，可用
Collections.synchronizedMap(new LinkedHashMap())，但要注意迭代时仍需手动同步
真正破坏插入顺序的操作其实很少：只有显式启用 accessOrder = true、手动 clear() 后重插、或用反射绕过链表操作。其他所有常规用法，包括扩容、序列化、remove()、replace()，都不会动摇那个“先来后到”的链表结构。
