LinkedHashMap 是 LRU 最简实现基础，因其启用访问顺序模式（构造时 third param=true）后，get/put 自动将节点移至尾部，再重写 removeEldestEntry() 即可自动淘汰头节点。
为什么 LinkedHashMap 是 LRU 最简实现基础
因为它的迭代顺序天然支持「访问顺序」，不用自己维护链表或时间戳。普通 HashMap 无序，TreeMap 按 key 排序，都不适合 LRU 的「最近访问优先淘汰」逻辑。
关键在构造时传入 true 作为第三个参数：new LinkedHashMap(capacity, 0.75f, true) —— 这个 true 表示启用访问顺序模式，每次 get() 或 put() 都会把对应 entry 移到链表尾部。
- 不传
true（默认false）：只按插入顺序排列，get()不会改变位置，无法支撑 LRU - 容量和负载因子建议显式指定，避免因扩容触发重哈希打乱原有顺序
- 注意：仅靠构造参数还不够，还得重写
removeEldestEntry()才能自动淘汰
如何让 LinkedHashMap 自动删除最老项
靠重写 removeEldestEntry() 方法。这个钩子在每次 put() 后被调用，返回 true 就删掉头节点（即最久未用项）。
典型写法是判断 size 是否超限：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
protected boolean removeEldestEntry(Map.Entry<k> eldest) {
return size() > MAX_SIZE;
}</k>
-
eldest参数是当前链表头部的 entry，也就是最久未访问的项 - 不要在里面做复杂操作（如日志、IO），它在
put()调用栈里，影响性能 - 如果想支持「空闲超时」或「绝对过期」，
LinkedHashMap本身做不到，得换ConcurrentHashMap + ScheduledExecutor或用Caffeine
get() 和 put() 对 LRU 顺序的影响差异
get() 触发访问顺序更新的前提是启用了访问模式（构造时第三个参数为 true）；而 put() 不仅更新值，还会把该 key 移到尾部 —— 即使是新 key，也会成为最新访问项。
- 对已存在 key 调用
put()：等效于先get()再设值，顺序更新一次 - 对不存在 key 调用
put()：插入新节点到尾部，不影响其他项顺序 - 调用
getOrDefault()或computeIfAbsent()也能触发顺序更新，但containsKey()不会 - 多线程下直接用非同步的
LinkedHashMap会出错，要么加锁，要么用Collections.synchronizedMap()（但注意迭代仍需手动同步）
容易被忽略的边界行为：null key / null value 和扩容抖动
LinkedHashMap 允许 null key 和 null value，但 LRU 场景下它们会干扰淘汰逻辑 —— 比如 null key 的 get() 仍会触发顺序更新，但它在 removeEldestEntry() 里难区分是否有效数据。
- 建议业务层禁止
nullkey，value 若必须为null，应在removeEldestEntry()中额外判空 - 扩容时整个链表重建，虽然顺序保持，但会短暂阻塞并增加 GC 压力；预估好初始
capacity，避免频繁扩容 - 如果缓存项有外部引用（比如 value 是大对象且被其他地方强引用），即使被
LinkedHashMap淘汰，也不会被回收 —— LRU 只管容器内引用
真正要稳，就得接受：LinkedHashMap 提供的是「轻量级 LRU 骨架」，不是生产级缓存。一有并发、过期、权重、监控需求，就得切到 Caffeine 或 Guava Cache。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
