线程安全的LRU缓存需分离职责：用ConcurrentHashMap管理key-value映射，用单独ReentrantLock保护双向链表结构调整（如moveToHead、removeTail），确保“查、移、插、删”原子联动，且节点字段用volatile修饰，避免NPE与容量失控。
为什么 ConcurrentHashMap + 双向链表不能直接线程安全
直接在 ConcurrentHashMap 外套一层 ReentrantLock 锁整个操作，或者只靠 ConcurrentHashMap 的分段锁，都拦不住 LRU 的“读-改-写”竞态：比如 get() 命中后要挪动节点到链表头，这个动作涉及链表指针更新和 map 中 value 的替换——两个结构要原子联动，而 ConcurrentHashMap 根本不感知你的链表。
常见错误现象：NullPointerException 在遍历链表时出现，或缓存容量失控（实际 size > maxCapacity），本质是 removeEldestEntry() 判断和节点删除没对齐，多个线程同时触发淘汰逻辑导致链表断裂。
- 必须把“查、移、插、删”这四个动作收进同一个锁作用域，且锁粒度不能太大（否则吞吐暴跌）
- 不要复用
ConcurrentHashMap的computeIfAbsent()做缓存加载——它只保证 map 操作原子，不管链表 - 链表节点的
prev/next字段必须用volatile修饰，否则一个线程改了指针，另一个线程看不到最新值
如何设计最小可行的线程安全节点与锁范围
核心是把锁从“整个 cache”下沉到“单个 key 对应的节点操作”，但又不能每个节点一把锁（死锁风险高）。稳妥做法是：用一个 ReentrantLock 控制所有链表结构调整（moveToHead()、removeTail()），再用 ConcurrentHashMap 独立管理 key-value 映射。两者职责分离，锁只管顺序，map 只管查找。
使用场景：高并发读多写少，但偶尔有 put/get 触发淘汰 —— 这时链表调整是瓶颈，不是 map 查找。
-
Node类里key、value、prev、next全部声明为final或volatile；避免构造中途被其他线程引用 - 淘汰逻辑（
removeTail()）必须在锁内完成：先从链表解绑节点，再调map.remove(key)，顺序不能反 - 不要在锁内做任何可能阻塞的操作，比如远程调用、文件 IO、或慢的
toString()
ConcurrentHashMap 的 compute 方法怎么用才不出错
computeIfAbsent() 看似方便，但它执行的 lambda 是在 map 内部加锁期间运行的，一旦你在里面操作外部链表（比如 moveToHead()），就会形成“map 锁 → 链表锁”的依赖，极易死锁。正确姿势是：只用它做纯 map 层的插入，链表调整一律放到锁保护的临界区里统一处理。
参数差异：computeIfPresent() 和 compute() 同样危险，只要 lambda 里碰链表就踩坑。
- 安全写法：先
map.get(key)尝试获取，命中则进链表锁块做moveToHead()；未命中则自己 new Node，再进锁块做addToHead()+map.put() - 绝对不要在
computeXxx()的 lambda 里调用任何含锁方法，包括你自己写的synchronized块 - 如果用了
StampedLock，注意它的乐观读模式下无法保证链表结构一致性，仍需悲观写锁兜底
容易被忽略的 reference 泄漏与 GC 问题
双向链表节点长期持有 key 和 value 强引用，而 ConcurrentHashMap 本身又持有一份，导致即使业务层已无引用，节点仍无法被回收。更隐蔽的是：如果 value 是大对象（如 byte[]、Bitmap），缓存不及时清理会快速 OOM。
性能影响：频繁 GC 会拖慢吞吐，尤其在堆内存紧张时，CMS 或 G1 可能触发 full GC。
- 考虑用
WeakReference<v></v>包装value，但注意：弱引用一碰 GC 就丢，不适合必须常驻的缓存项 - 更实用的是加
expireAfterWrite(5, TimeUnit.MINUTES)（配合ExpiringMap或自研 TTL 字段），比纯 LRU 更可控 - 务必重写
Node的finalize()（不推荐）或用Cleaner注册清理钩子，确保链表断开时释放关联资源
真正难的不是写出来，是让链表指针更新和 map 更新在任意并发节奏下都不撕裂 —— 这要求你对每行锁的起止位置、每个引用的生命周期，都看得见摸得着。
