LinkedHashMap通过内部双向链表保持插入顺序：每次put()新元素时，节点既写入哈希桶又追加至链表尾部；遍历keySet()、entrySet()等均按该链表顺序返回；默认accessOrder=false时生效，设为true则转为访问顺序。
LinkedHashMap 插入顺序是怎么保持的
它靠内部维护一个双向链表，每次 put() 或 putIfAbsent() 时，新节点不仅写入哈希桶，还会被追加到链表尾部。这个链表和哈希表是同步更新的，所以遍历 keySet()、entrySet() 或 values() 都会按插入顺序返回。
注意：仅当使用默认构造函数或显式指定 accessOrder = false 时才保证插入顺序；如果传入 true，就会变成访问顺序（LRU 行为），这时候顺序会随 get() 动态调整。
哪些操作不会破坏插入顺序
put() 覆盖已有 key 时，只更新 value，不改变节点在链表中的位置 —— 顺序不变。
-
remove()删除后，对应节点从链表中摘除，后续遍历跳过它，其余顺序保持 -
clear()清空后链表重置，下次插入从头开始 -
putAll()按传入 Map 的迭代顺序逐个插入，所以源 Map 自身也得有确定顺序（比如另一个LinkedHashMap）
为什么用 LinkedHashMap 而不用 HashMap + List 手动维护
手动组合看似灵活，但容易出错：
- 并发场景下，
HashMap和List更新不同步，遍历时可能抛ConcurrentModificationException - 删除时要同时操作两个结构，漏掉一个就导致数据不一致
-
LinkedHashMap的removeEldestEntry()可直接支持 LRU 缓存逻辑，手写要额外判断和清理 - 内存占用其实更优：它把链表节点和哈希节点合并为一个对象，比两个独立结构节省引用开销
实际使用要注意的边界情况
插入顺序只对「首次 put」生效；重复 key 不会重排。如果你依赖顺序做逻辑（比如取第一个 entry 做默认值），务必确认 key 确实没被提前插入过。
另外，LinkedHashMap 不是线程安全的。多线程写入必须加锁或用 Collections.synchronizedMap(new LinkedHashMap())，但后者只保证单个操作原子性，复合操作（如“检查不存在再 put”）仍需外部同步。
序列化没问题，反序列化后顺序依然保留 —— 这点比自己拼 List 更可靠。
