缓存击穿的本质是热点 key 过期瞬间大量请求击穿至数据库，需结合分布式锁（如 setnx+lua）与逻辑过期机制解决；锁应按 key 哈希分片、及时清理，避免串行化和内存泄漏。

缓存击穿的本质是：某个热点 key 过期瞬间，大量并发请求同时打到数据库，造成瞬时压力飙升。Java 中单纯用 Redis + get/set 无法解决，必须配合线程同步机制和合理的过期策略。

用 synchronized 锁住 key 粒度的重建逻辑

直接锁整个方法或类会导致吞吐量骤降；应缩小锁范围，按 key 计算哈希后映射到固定数量的锁对象上，避免不同 key 互相阻塞。

• 不要用 synchronized(this) 或 synchronized(Service.class)，会串行化所有请求
• 推荐用 ConcurrentHashMap 预热锁池：private static final Map<string object> lockMap = new ConcurrentHashMap();</string>
• 获取锁时： Object lock = lockMap.computeIfAbsent(key, k -> new Object()); synchronized(lock) { ... }
• 重建完成后记得 lockMap.remove(key)，防止内存泄漏（尤其 key 量大时）

用 Redis 的 SETNX + 过期时间实现分布式锁

单机 synchronized 在集群环境下失效，必须升级为分布式锁。但别手写 SETNX + DEL 组合——存在锁误删风险。

• 务必使用原子命令：SET key value NX PX 30000（value 建议用 UUID 防误删）
• 解锁不能简单 DEL，要用 Lua 脚本比对 value 再删：if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
• 业务逻辑执行超时要设置合理重试或降级，否则锁一直不释放
• 注意 Redis 主从异步复制可能导致锁丢失，生产环境建议用 Redlock 或 Redisson 的看门狗机制

加互斥锁时必须配合逻辑过期（不是 Redis TTL）

只靠锁解决“重建期间其他请求等待”问题，但没解决“重建失败后反复冲击 DB”的隐患。必须引入本地逻辑过期时间。

• 从 DB 查出数据后，封装成 CacheData<t></t>，含 data 和 expireTime 字段（比如 System.currentTimeMillis() + 2 * 60 * 1000）
• 写入 Redis 时用永久 TTL（如 SET key value EX 999999999），实际过期由代码判断 expireTime
• 若发现逻辑过期，才去抢锁重建；否则直接返回旧值（允许短暂脏读，但保 DB 安全）
• 这样即使锁失效或 DB 查询失败，也不会导致后续请求全部穿透

真正难的不是加锁动作本身，而是锁的粒度、生命周期、与业务超时的配合。一个没清理的锁对象、一次没校验的 value、一段没兜底的逻辑过期判断，都可能让缓存击穿在高并发下重现。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南