accessorder=true是lru生效的前提，必须显式设置；仅重写removeeldestentry无效，它只控制是否删除、不决定淘汰顺序；java 8+中get/put触发顺序更新，但getordefault等不触发；removeeldestentry须严格用size()>capacity；该方法内不可耗时；linkedhashmap非线程安全，需额外同步；key必须正确实现equals/hashcode且不可变。
accessOrder=true 是 LRU 的开关，不是默认值
LinkedHashMap 默认是插入顺序（accessOrder=false），哪怕你重写了 removeEldestEntry，不打开 accessOrder，get 操作也不会把访问项移到尾部，缓存淘汰完全失效。这是最常踩的坑——代码看着像 LRU，跑起来却是 FIFO。
- 构造时必须显式传
true：new LinkedHashMap(16, 0.75f, true) - 只靠重写
removeEldestEntry不够，它只管“删不删”，不管“谁该被删”；accessOrder才决定“谁在尾部、谁最先被淘汰” - Java 8+ 中，
get和put都会触发顺序更新；但getOrDefault、computeIfAbsent等方法不会——它们绕过了 LinkedHashMap 的 access hook
removeEldestEntry 的返回逻辑必须严格匹配容量限制
这个方法不是“每 put 一次就调用一次”，而是每次 put 后触发，返回 true 才删除最老项（即头节点）。如果逻辑写成 size() > capacity + 1 或漏了等号，就会多存一项或卡住不删。
- 正确写法是：
return size() > capacity;（假设 capacity 是你期望的最大条目数） - 别在里头做 I/O、锁或耗时操作——它在
put调用栈里同步执行，拖慢所有写入 - 注意：初始空 map 的第一次
put也会进这个方法，此时size()是 1，别让它误删
并发场景下 LinkedHashMap 本身不安全
即使用了 accessOrder 和正确的 removeEldestEntry，多个线程同时 get/put 仍可能抛 ConcurrentModificationException，或导致链表断裂、丢失条目。这不是配置问题，是底层结构没加锁。
- 别用
Collections.synchronizedMap(new LinkedHashMap(...))—— 它只同步单个方法，get+put组合操作仍不原子 - 简单场景可用
ReentrantLock包一层，但吞吐会掉；高并发建议换caffeine或guava Cache - 如果坚持手写，至少把
get和put逻辑锁在同一个临界区，别分开加锁
key 的 equals/hashCode 必须可靠，否则 LRU 形同虚设
LinkedHashMap 依赖 key 的 hashCode 定位桶、equals 判等。如果 key 是自定义对象且没重写这两个方法，相同语义的 key 会被当成不同 key 存多次，缓存膨胀，removeEldestEntry 删的也不是真最老的那个。
- 检查你的 key 类是否实现了
equals和hashCode，且逻辑一致（比如都基于 id 字段） - 避免用可变字段（如
ArrayList、含 setter 的 POJO）作 key——内容变了，hash 可能变，后续get就找不到 - 字符串 key 最省心；Integer/Long 等包装类也 OK；其他一律先验
accessOrder 和 removeEldestEntry 得配对生效，缺一不可；并发和 key 健壮性这两块，最容易在线上跑一阵子才暴露问题。
