accessOrder 必须显式设为 true 才启用访问顺序，使 get() 或 put() 已存在 key 时将对应 Entry 移至链表尾部；默认 false 按插入顺序维护，LRU 失效。
LinkedHashMap 的 accessOrder 参数怎么设才启用访问顺序
不设 accessOrder 或设为 false（默认），LinkedHashMap 按插入顺序维护节点；只有显式传入 true 才开启访问顺序——即每次调用 get() 或 put() 已存在 key 时，对应 Entry 会被移到链表尾部。
- 构造时必须写全参：
new LinkedHashMap(initialCapacity, loadFactor, true) - 漏掉第三个参数或传
false，get()不会改变顺序，LRU 逻辑直接失效 - 注意：JDK 8+ 中
computeIfPresent()、merge()等方法也会触发访问重排序，但replace(K,V)不会（它不改变 value 时甚至不调用afterNodeAccess()）
为什么重写 removeEldestEntry() 是 LRU 的关键开关
LinkedHashMap 本身不自动淘汰，靠子类重写 removeEldestEntry() 在每次插入后决定是否删最老项。这个方法返回 true 才真删——而“最老”在访问顺序下就是链表头节点。
- 典型写法：
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) { return size() > MAX_SIZE; } - 别在方法里手动调用
remove(eldest.getKey())：重复删除或破坏迭代器安全 - 该方法在
put()、putAll()后触发，但get()不触发——所以容量控制只响应写入，读多写少场景需额外兜底
get() 返回 null 时会不会影响 LRU 顺序
不会。如果 key 不存在，get() 返回 null，但内部不调用 afterNodeAccess()，链表结构完全不变。
- 这意味着：查不到的 key 不会“刷新热度”，也不会意外挤走其他有效项
- 但要注意空值歧义：如果业务允许 value 为
null，就不能靠get()返回值判断 key 是否存在，得用containsKey() - 若误把
null当作缺失而反复put()，会导致同 key 多次插入，链表尾部堆积冗余节点（虽不影响功能，但浪费内存）
并发环境下直接用 LinkedHashMap 实现 LRU 会出什么问题
会丢数据、顺序错乱、甚至 ConcurrentModificationException。因为 LinkedHashMap 非线程安全，其迭代器和链表操作都无同步保障。
立即学习“Java免费学习笔记（深入）”；
- 常见错误：多个线程同时
get()+put()，导致链表指针断裂，后续遍历抛NullPointerException - 不能简单套
Collections.synchronizedMap()：它只锁单个方法，size()和removeEldestEntry()之间存在竞态窗口 - 生产环境建议用
ConcurrentHashMap+ 自研双向链表，或直接用caffeine；非要手写，至少得把整个get-put-removeEldestEntry流程包进synchronized块
accessOrder 必须显式设为 true；淘汰逻辑依赖 removeEldestEntry() 的返回值，而不是它的内容；并发场景下，哪怕只读也得小心——因为 get() 在访问顺序模式下会修改内部结构。 
