Redis双重检查锁防击穿原理解析

本文深入剖析了Redis缓存击穿场景下双重检查锁的核心原理与落地要点：它通过锁外第一次检查快速过滤命中请求、锁内第二次检查精准拦截“锁等待期”已被他人写入缓存的竞态，从而避免高并发下数据库重复查询导致QPS暴增；同时强调必须配套空值缓存防穿透、Lua脚本原子删锁保安全，并指出synchronized等本地锁在分布式环境完全失效，生产环境应首选Redisson等成熟分布式锁方案——漏掉任一环节，都可能让击穿演变为穿透或锁混乱，危及系统稳定性。

为什么单次查缓存不够，非得“双重检查”？

因为锁不是瞬间拿到的。你第一次查 Redis 没值，去抢 SETNX 锁，这中间可能有几十毫秒——足够另一个线程抢到锁、查库、写缓存、释放锁。等你终于拿到锁，再傻乎乎去查库，就纯属浪费资源，还拖慢响应。

双重检查的本质，是把「是否需要查库」这个判断，从锁外挪到锁内再确认一次。它不解决加锁开销，但能拦住绝大多数重复查库请求。

• 第一次检查（锁外）：快速过滤掉 90%+ 的命中请求，避免无谓加锁
• 第二次检查（锁内）：防御“锁等待期”已被别人建好缓存的竞态，防止重复 IO
• 漏掉第二次检查 → 高并发下数据库 QPS 瞬间翻倍，尤其在热点 key 过期后那几秒

synchronized 在 Redis 击穿场景中能用吗？

能，但仅限单机部署且流量可控的小服务。一旦上集群或压测过万 QPS，synchronized 就完全失效——它锁不住其他机器上的线程。

真实生产环境必须用分布式锁，比如 Redis 的 SETNX + 过期时间，或者封装好的 Redisson.getLock()。别图省事用本地锁应付上线。

• synchronized(this) 只对当前 JVM 实例有效，跨进程/跨机器等于没锁
• 用 SETNX 时必须配 EX 参数，否则锁不释放会导致死锁
• 推荐直接用 Redisson：它自动处理锁续期、原子删锁（Lua 脚本）、中断响应，比手写安全得多

拿到锁后查 Redis 还是 null，接下来该怎么做？

这时才真正进入「重建缓存」路径。但注意：查库失败 ≠ 放弃，空结果也得缓存，否则就变成缓存穿透。

• 数据库查到数据 → 写入 Redis，设合理 TTL（别用永不过期，除非你能保证后台异步刷新）
• 数据库查不到（比如 id = -1）→ 写入一个空值（如 "null" 或自定义占位对象），同样设 TTL（比如 2 分钟），防穿透
• 千万别直接 return null：前端下次来还是打库，攻击者扫一遍负数 ID 就能把 DB 拖垮

删锁为什么必须用 Lua 脚本？

因为「判断是不是我加的锁」和「删除这个锁」这两步，必须原子执行。如果先 GET 再 DEL，中间可能被别的线程抢先加锁、覆盖，导致误删别人正在用的锁。

Redis 官方明确要求：分布式锁的释放操作，必须通过一个 Lua 脚本完成校验与删除。

• 错误写法：if redis.get("lock:key") == myLockValue then redis.del("lock:key") → 不是原子操作
• 正确写法：用一段 Lua 脚本，redis.call("GET", KEYS[1]) == ARGV[1] 成立才 DEL
• Redisson 默认就走这路子，自己手写记得严格校验锁 value（不能只比 key）

最容易被忽略的点，其实是第二次检查之后的「空值缓存」和「删锁原子性」——前者防穿透，后者保安全，两个漏一个，击穿就可能演变成穿透或锁混乱。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis双重检查锁防击穿原理解析》文章吧，也可关注golang学习网公众号了解相关技术文章。