LinkedHashMap迭代直接遍历双向链表而非哈希桶，性能仅取决于元素个数；插入顺序由首次put锁定，重复put不改变链表位置；accessOrder=true时通过afterNodeAccess维护LRU顺序；head/tail为transient，反序列化需重建链表以保证顺序一致。
LinkedHashMap的双向链表不是辅助结构，而是迭代主干
LinkedHashMap迭代时根本不去遍历哈希桶数组（table），而是直接从head节点开始，顺着每个Entry的after引用一路跳转，直到after == null为止。这意味着：迭代性能只和元素个数相关，和table.length无关；哪怕哈希表扩容到 64K，只要只有 5 个元素，entrySet().iterator()也只走 5 步。
这个行为由LinkedHashMap.Entry类决定——它继承自HashMap.Node，但额外持有before和after两个引用。每次插入新Entry，除了塞进哈希桶，还会被追加到双向链表尾部（tail.after = newNode; newNode.before = tail; tail = newNode;）。
put重复key时链表位置不变，这是默认行为的关键
当你调用put("a", 1)再调用put("a", 2)，底层不会新建Entry，而是复用原有节点、仅更新value字段。由于没触发newNode()，也就不会执行链表追加逻辑——所以该节点在双向链表中的位置完全不动。
- 这正是“插入顺序”语义成立的前提：顺序由首次插入时刻锁定
- 若误以为
put总会重排链表，就容易在 LRU 场景中漏掉accessOrder = true参数 - 注意
putIfAbsent、computeIfAbsent等方法同理：只在真正插入时才动链表
accessOrder = true 改变的是 afterNodeAccess 的行为，不是遍历路径
把accessOrder设为true，并不会让迭代器换一条路走；它只是让get()、put()等方法在操作已有节点后，自动调用afterNodeAccess()，把该节点从链表原位置摘下、再插到tail之后。
也就是说：
- 链表结构没变，还是那条双向链表
- 遍历起点仍是
head，终点仍是tail - 唯一变化是：最近访问的节点总在尾部，最久未访问的总在头部 —— 这才是 LRU 的基础
-
removeEldestEntry()之所以能淘汰“最老”项，就是因为它判断的是head是否该被移除
别忽略 head/tail 是 transient 字段，序列化时不保存链表状态
head和tail被声明为transient，意味着反序列化后它们为null，整个双向链表需重建。LinkedHashMap靠重写readObject()，在反序列化每个Entry时手动重新链接before/after，并恢复head/tail。
这意味着：
- 序列化前后，迭代顺序仍一致（因为重建逻辑复现了插入过程）
- 但如果你在反序列化后立刻做
get()，且accessOrder = true，链表会按新访问顺序重排 —— 和序列化前的状态可能不同 - 自定义序列化逻辑时，若漏掉链表重建，
entrySet()将返回空或乱序结果
