RLock本身不防击穿，真正有效的是“锁+双重检查+空值缓存”组合；直接用lock()会因未做二次校验、无兜底降级、锁粒度错误及空结果不缓存，导致大量请求穿透压垮DB。
RLock 本身不防击穿，只管加锁；真正起作用的是「锁 + 双检 + 空值缓存」组合，且锁 key 必须按业务数据动态生成。
为什么直接用 RLock.lock() 会压垮 DB
常见错误是：缓存 miss 后调用 lock()，拿到锁就查 DB、写缓存。问题在于——没拿到锁的线程不会等，而是立刻重试或直连 DB。这等于锁只串行了“第一个成功者”，其余请求照旧穿透。
-
lock()是阻塞式，线上容易积压线程，超时不可控 - 锁 key 若写死（如
"global_lock"），所有商品查询全被串行，吞吐归零 - 没做第二次缓存检查（double-check），多个线程抢到锁后仍会重复查 DB
- 空结果不写缓存，下次请求又触发整套流程，形成击穿循环
必须用 tryLock() + 轮询 + 降级
生产可用的等待策略不是死等，而是有限轮询 + 明确兜底：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调用
tryLock(100, 3000, TimeUnit.MILLISECONDS)：最多等 100ms，锁自动续期 3s - 失败后不重试加锁，改用
GET cache:key轮询，间隔 20–50ms，总等待 ≤ 500ms - 轮询超时仍未命中，才走降级逻辑（返回默认值、旧缓存、或抛业务异常）
- 轮询期间不能阻塞主线程，建议用异步回调或协程调度，避免 Tomcat 线程池耗尽
空值缓存和锁 key 的构造规则
这两个细节漏掉一个，互斥就形同虚设：
- 锁 key 必须绑定业务维度，例如商品 ID 是
123，就用"lock:goods:123"，绝不用"lock:goods" - DB 查无结果时，必须写空值：
set("goods:123", "NULL", 2, TimeUnit.MINUTES)，否则空结果永远不进缓存 - Redisson 的
RMapCache或原生命令都支持 TTL，但注意：空值 TTL 应短于正常数据（比如 2 分钟 vs 30 分钟），避免长期占位 - 锁租期（
leaseTime）要 ≥ DB 查询最坏耗时 + 写缓存开销，建议设为预估耗时的 3–5 倍，防止锁提前释放
本地缓存不是可选项，而是必加层
纯靠 Redis 锁扛不住万级 QPS，本地缓存能过滤 80% 以上重复请求：
- 先查本地缓存（如 Caffeine），命中则直接返回；未命中再走 Redis 锁流程
- 本地缓存 TTL 设为 Redis TTL 的 1/3～1/2（例如 Redis 是 30 分钟，本地设 10 分钟），提前触发 reload，削峰
- DB 查询成功后，必须同步写入本地缓存和 Redis，且本地写入要 bypass TTL 检查（用
put(key, value, expireAfterWrite)） - 本地缓存 size 一定要设上限（如
maximumSize(5000)），否则内存泄漏比 Redis 过期更难排查
最难的不是写对锁，而是判断「该等多久」「该不该返回旧值」「空值 TTL 设多长」——这些没有通用答案，得看你的 DB 查询 P99 耗时、用户容忍延迟、以及空结果的真实比例。
