linkedhashmap 通过双向链表维护插入顺序，put() 将新节点加至链表尾，遍历结果与插入一致；accessorder=false 为默认插入顺序，true 才启用 lru；removeeldestentry() 仅在 put() 后调用，get() 不触发淘汰；非线程安全，需同步或替换方案。
LinkedHashMap 怎么保持插入顺序
它靠内部维护的双向链表实现，每次 put() 都把新节点加到链表尾。所以遍历 keySet()、entrySet() 时，顺序和插入完全一致。
- 默认构造（无参或只传
initialCapacity）下，accessOrder = false，就是插入顺序模式 - 不要误以为是靠哈希表本身有序——HashMap 是无序的，
LinkedHashMap是额外加了链表才有序 - 注意：
put()同一个 key 会更新值但不改变位置；putIfAbsent()才真正“只在不存在时插入并追加”
如何启用 LRU 访问顺序（最近最少使用）
必须显式传 accessOrder = true，否则即使重写 removeEldestEntry() 也无效。
- 构造函数要写成：
new LinkedHashMap(16, 0.75f, true) - 访问触发重排序：
get()、put()（含更新）、compute()等都会把对应节点移到链表尾 -
removeEldestEntry()是唯一能自动淘汰的钩子，但它只在每次put()后调用，get()不触发淘汰
LRU 缓存实现时最容易漏掉的三件事
很多人照着示例写完发现不淘汰、不更新顺序、或者线程不安全，问题基本出在这几个点：
- 忘了重写
removeEldestEntry()—— 即使开了accessOrder = true，不重写这个方法就永远不会删老元素 - 直接用
get()查缓存但没做空值处理，导致后续逻辑误判；建议统一走computeIfAbsent()或封装 get-or-load - 多线程场景下，
LinkedHashMap本身不是线程安全的，别在并发环境下裸用；要么加synchronized，要么换ConcurrentHashMap+ 手动维护顺序（更复杂）
为什么 size() 和迭代性能比 HashMap 略差
因为每个 entry 多存了两个引用（before 和 after），内存占用略高；迭代时要顺着链表走，不能像 HashMap 那样按桶数组顺序局部性更好。
立即学习“Java免费学习笔记（深入）”；
- 插入/查找平均仍是 O(1)，但常数项略大；对百万级数据影响可测，但一般业务感知不到
- 如果只要顺序不要 LRU，且 key 类型固定、数量稳定，可以考虑用
ArrayList<map.entry></map.entry>+HashMap组合，省内存但代码更重 - Android 上注意：低版本（API LinkedHashMap 的
removeEldestEntry()在构造时未初始化好可能返回 null，建议判空
accessOrder = true 再改回来成本不低，因为遍历行为彻底变了。 
