直接继承LinkedHashMap是最简可行LRU方案，因其内置accessOrder=true支持访问序、自动维护淘汰顺序，只需重写removeEldestEntry()判断size()>capacity，但需注意线程不安全及capacity校验。
为什么直接继承 LinkedHashMap 是最简可行方案
因为 LinkedHashMap 内置访问顺序（accessOrder = true）和迭代顺序一致性，天然支持 LRU 的“最近最少使用”淘汰逻辑。不用自己维护时间戳或链表，避免并发、扩容、哈希冲突等底层陷阱。
关键点在于重写 removeEldestEntry() —— 它在每次 put() 后被调用，返回 true 才触发删除最老条目。其他方式（如定时扫描、手动维护队列）容易漏删、多删或线程不安全。
-
removeEldestEntry()不是回调钩子，而是由put()/putAll()内部主动调用，无需额外触发 - 必须在构造时传入
true作为第三个参数（accessOrder），否则按插入顺序排列，不是 LRU - 该方法只对新插入项生效；如果只是
get()已存在 key，也会触发排序更新，但不调用removeEldestEntry()
removeEldestEntry() 怎么写才不丢数据、不卡死
它只负责“要不要删”，不负责“删哪个”——后者由 LinkedHashMap 自动按迭代头节点处理。常见错误是误判 size 条件，导致缓存永远不淘汰，或刚 put 就删。
正确写法是判断 size() > capacity，而不是 >= 或硬编码数值：
立即学习“Java免费学习笔记（深入）”；
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
return size() > capacity;
}
- 用
size()而非keySet().size()：前者 O(1)，后者在某些 JDK 版本里可能触发遍历 - 不要在该方法里调用
get()/put()：会引发递归调用，StackOverflowError - 不要修改传入的
eldest参数：它是只读快照，改了也没用，还可能干扰迭代器状态
并发场景下为什么不能直接用这个实现
LinkedHashMap 本身不是线程安全的，即使只重写了 removeEldestEntry()，put() 和 get() 在多线程下仍可能抛 ConcurrentModificationException，或出现 size 计算错位（比如两个线程同时触发淘汰，删掉同一条）。
- 加
synchronized方法锁太重，吞吐暴跌；推荐用Collections.synchronizedMap(new LRUCache(...))，但注意迭代操作仍需手动同步 - 更稳妥的是用
java.util.concurrent.ConcurrentHashMap+ 自研 LRU 结构，或者直接上caffeine：它内部用分段锁 + 时间轮 + 驱逐策略分离，兼顾性能与准确性 - JDK 自带的
java.util.LinkedHashMap没有提供线程安全的子类模板，别试图靠 volatile 或 CAS 修修补补
容量设为 0 或负数会发生什么
不会报错，但行为反直觉：size() > 0 对空缓存恒为 false，所以设成 0 相当于无限缓存；设成负数（如 -1）则 size() > -1 恒为 true，每次 put() 都立刻删掉最老项——只剩最后一个 entry。
- 初始化时建议校验
capacity > 0，否则默默失效 - 如果需要“无缓存”语义，直接 new 个新实例比设 capacity=0 更清晰
- 注意泛型擦除后，
LRUCache<String, Object>和LRUCache<Integer, String>是不同类型，别指望靠 capacity 控制全局内存占用
