LinkedHashMap 顺序行为异常主因是访问顺序模式下 containsKey() 等方法不触发重排序；removeEldestEntry() 需显式重写且仅在 put 后回调；插入/访问顺序差异始于首次 get/put；Java 21+ 兼容但序列化与并发需谨慎。
为什么 LinkedHashMap 的顺序行为不按预期？
默认情况下，LinkedHashMap 确实维护插入顺序，但一旦启用了访问顺序模式（通过构造函数第二个参数 true），它就只在调用 get()、put() 等触发“访问”的操作时才调整节点位置——而 containsKey()、getOrDefault()（Java 8+）这类方法**不会触发访问重排序**。这是最常被忽略的点。
常见错误现象：get() 后再遍历，发现元素没移到末尾；或者误以为 keySet().iterator() 一定反映最新访问次序，其实它只反映链表当前结构，而链表更新有前提条件。
- 必须用
new LinkedHashMap(initialCapacity, loadFactor, true)显式启用访问顺序 -
put()和get()会触发重排序；replace()、computeIfPresent()等也会；但containsKey()、isEmpty()、size()不会 - 迭代器返回的顺序是链表顺序，不是哈希桶顺序，所以安全，但前提是链表已被正确更新
removeEldestEntry() 是怎么控制 LRU 缓存上限的？
这个 protected 方法不是自动生效的，它只在每次 put() 或 putAll() 完成后被回调一次，返回 true 才会删除最老（链表头）的映射。关键在于：它不关心“是否被访问过”，只看当前 size 是否超限，且只对新插入/更新的 entry 生效。
典型误用：在访问顺序模式下想实现“最近最少使用”，却忘了重写该方法，或错误地在里面调用 remove() 导致并发修改异常。
- 必须继承
LinkedHashMap并重写removeEldestEntry() - 判断逻辑通常为
return size() > MAX_SIZE;，不要在里面做remove()操作 - 如果需要线程安全，不能只靠
Collections.synchronizedMap()，因为removeEldestEntry()回调和迭代不是原子的；应考虑ConcurrentHashMap+ 显式队列，或使用caffeine
插入顺序 vs 访问顺序：初始化和后续操作有何差异？
两种模式在构造后行为完全不同，但构造过程本身不区分——所有初始元素都按传入顺序追加到链表尾。差异从第一次 get() 或 put() 开始显现。
例如：用 Map.of("a",1,"b",2,"c",3) 初始化一个访问顺序的 LinkedHashMap，此时遍历仍是 a→b→c；但一旦 get("b")，链表变成 a→c→b；再 put("d",4)，变成 a→c→b→d。而插入顺序模式下，无论怎么 get()，顺序永远固定为 a→b→c→d（除非 put() 覆盖已有 key，此时也不移动）。
- 插入顺序模式（
accessOrder=false）：仅put(key, value)且 key 不存在时追加到尾；覆盖已有 key 不改变位置 - 访问顺序模式（
accessOrder=true）：每次get()或put()都把对应 entry 移到链表尾；put()新 key 也追加到尾 - 注意
putIfAbsent()：在访问顺序模式下，若 key 已存在，它不触发重排序（因为没发生实际 get/put）
Java 21+ 中 LinkedHashMap 的性能与兼容性要注意什么？
从 Java 19 开始，LinkedHashMap 内部链表节点改用更紧凑的对象表示，内存占用略降，但对外行为完全兼容。真正影响实操的是：JDK 21 默认启用 ZGC，而 LinkedHashMap 的迭代器在高并发读写场景下仍可能遇到 ConcurrentModificationException——这不是 bug，是设计使然：它不承诺 fail-fast 外的任何保证。
另一个隐性坑：序列化。LinkedHashMap 序列化时会写出链表结构，反序列化后顺序保留，但若类版本变更（比如字段增减）、或跨 JDK 版本传输（如 Java 17 序列化 → Java 21 反序列化），可能因内部字段名/顺序变化导致 InvalidClassException。
- 生产环境避免直接序列化
LinkedHashMap实例；优先用 JSON（如 Jackson）或协议缓冲区 - 如需并发读写，不要依赖
synchronized(new LinkedHashMap())，它无法保护removeEldestEntry()回调期间的竞态 - 小数据量（get() 时，访问顺序模式的链表移动带来轻微额外开销（O(1) 但常数较大）
实际用的时候，别只盯着构造参数设 true 或 false，得看清楚每一行代码调用的是哪个方法、是否真会触发链表更新——尤其是那些名字像访问、实则不更新顺序的“伪访问”方法。
