LinkedHashMap 默认按插入顺序遍历，设 accessOrder=true 后改为访问顺序（LRU），每次 get 或 put 都会将节点移至链表尾，头节点为最久未访问项；需重写 removeEldestEntry() 实现自动淘汰。
LinkedHashMap 默认按插入顺序，但 accessOrder=true 会彻底改变遍历行为
很多人以为只要用了 LinkedHashMap，遍历就“一定”是写入顺序——这是最常见的误判。关键开关是构造时传的第三个参数：accessOrder。默认为 false（插入顺序），设为 true 后，每次 get() 或对已有 key 调用 put()，都会把对应节点移到链表尾部，头节点变成“最久未访问”的那个。
- 插入顺序（默认）：
new LinkedHashMap()或new LinkedHashMap(16, 0.75f, false) - 访问顺序（LRU 模式）：
new LinkedHashMap(16, 0.75f, true) -
put("x", 1)在访问顺序模式下也算一次“访问”，会触发重排序 - 即使只读不写，频繁
get()也会让顺序动态漂移，不是静态快照
遍历时的顺序稳定性，只依赖链表，和哈希桶完全无关
LinkedHashMap 的“有序”不是靠排序算法，也不是靠 hash 值大小，而是靠内部那条双向链表——每个 Entry 都有 before 和 after 引用，构成一条时间轴。扩容（rehash）时，节点在哈希表里的位置可能变，但链表中相对顺序丝毫不受影响。
-
keySet()、values()、entrySet()三者遍历顺序严格一致，因为共享同一链表 - 只要不调用
remove()、clear()、put()，遍历结果就绝对稳定 - 不能通过反射或序列化绕过链表去“恢复原始插入顺序”——链表就是唯一权威
- 多线程并发修改 + 遍历会触发
ConcurrentModificationException，它不是线程安全的
实现 LRU 缓存，光设 accessOrder=true 还不够
启用访问顺序只是第一步。真正自动淘汰“最老”元素，必须重写 removeEldestEntry() 方法，并让它返回 true。这个钩子会在每次 put() 插入新节点后被调用，框架据此决定是否移除链表头部节点（即最久未访问的那个）。
LinkedHashMap<String, String> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
@Override
protected boolean removeEldestEntry(Map.Entry<String, String> eldest) {
return size() > 100; // 超过 100 条就淘汰头节点
}
};
-
removeEldestEntry()不会在get()时触发，只在put()后检查 - 如果只用
get()访问，但一直不put()新数据，缓存不会自动收缩 - 淘汰的是链表 head 处的节点，不是随机或按 key 字典序
- 若需线程安全，得用
Collections.synchronizedMap(lruCache)包一层
别把它当 TreeMap 用：自然排序和范围查询它都不支持
有人想用 LinkedHashMap 实现“按键字典序遍历”，这是方向性错误。它不比较 key，也不维护红黑树，所有顺序都来自操作时间戳。要自然排序或范围查询（比如找所有 key > "b" 的项），该用 TreeMap；要纯插入顺序且高性能，LinkedHashMap 才是正解。
立即学习“Java免费学习笔记（深入）”；
-
TreeMap查找是O(log n)，LinkedHashMap是O(1)平均 -
TreeMap支持subMap()、headMap()等范围操作，LinkedHashMap完全不提供 - 如果只是想“保持配置文件里 key 出现的顺序”，
LinkedHashMap是轻量又精准的选择 - 键为
String时，不要指望entrySet()遍历出来是字母序——那是错觉
accessOrder=true，顺序就活起来了，而你得清楚它怎么活、何时活、活了之后怎么控。 
