缓存击穿是指热点key过期瞬间大量请求穿透至数据库，仅setnx无法解决因不阻塞请求且无超时兜底；需结合loading占位符、带ex的原子锁、有限轮询等待及幂等loader。
缓存击穿到底是什么，为什么 SETNX 单靠它不够
缓存击穿是指某个热点 key 在 Redis 中过期瞬间，大量并发请求同时发现缓存缺失，全部穿透到数据库，造成瞬时 DB 压力激增。典型场景是秒杀商品详情页、热搜榜单刷新点。
SETNX（即 SET key value NX）常被拿来“抢锁”，但仅靠它防击穿有硬伤：它不阻塞后续请求，失败的线程仍会直接查库；而且没有自动续期或超时兜底，锁可能永远不释放。
- 必须搭配一个“占位符”机制：缓存失效后，首个请求写入一个短期有效的空值（如
"null"或"loading"），让其他请求快速返回，而非全量打库 - 加锁逻辑要带超时（
EX），避免死锁；推荐用 Lua 脚本原子执行SET key value NX EX seconds - 业务线程不能无限等待锁，应设置合理重试间隔（如 50ms）和最大重试次数（如 3 次）
Java 工具类怎么封装才真正可用
一个实用的防击穿工具类，核心不是“加锁”，而是“协调重建 + 快速降级”。下面这个结构在生产中验证过：
public class CacheBreakdownGuard {
private final RedisTemplate<string object> redisTemplate;
private final StringRedisTemplate stringRedisTemplate;
public CacheBreakdownGuard(RedisTemplate<string object> redisTemplate,
StringRedisTemplate stringRedisTemplate) {
this.redisTemplate = redisTemplate;
this.stringRedisTemplate = stringRedisTemplate;
}
public <t> T getOrLoad(String key, Class<t> type, Supplier<t> loader, long expireSecs) {
// 1. 先读缓存
Object cached = redisTemplate.opsForValue().get(key);
if (cached != null && !cached.equals("loading")) {
return type.cast(cached);
}
// 2. 尝试设 loading 占位符（带过期）
Boolean setSuccess = stringRedisTemplate
.opsForValue()
.setIfAbsent(key, "loading", Duration.ofSeconds(3)); // 锁最多撑 3 秒
if (Boolean.TRUE.equals(setSuccess)) {
try {
// 3. 真正加载数据
T loaded = loader.get();
if (loaded != null) {
redisTemplate.opsForValue().set(key, loaded, Duration.ofSeconds(expireSecs));
} else {
// 写空值，防止缓存穿透，但 TTL 缩短（如 2 分钟）
redisTemplate.opsForValue().set(key, "null", Duration.ofMinutes(2));
}
return loaded;
} finally {
// 4. 无论成败，删掉 loading 标记（可选：用 Lua 保证原子性）
stringRedisTemplate.delete(key);
}
} else {
// 5. 没抢到锁，等待后重试（非阻塞式轮询）
return waitForLoad(key, type, 50, 3);
}
}
private <t> T waitForLoad(String key, Class<t> type, int intervalMs, int maxRetries) {
for (int i = 0; i
<p>注意：<code>waitForLoad</code> 不是自旋，是有限次轻量轮询；<code>"loading"</code> 是字符串占位符，避免反序列化失败；空值用 <code>"null"</code> 字符串而非 <code>null</code> 对象，确保能存入 Redis。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理"><img
src="https://img.php.cn/upload/skill/000/000/081/178960683454849.jpg" alt="Redis Skill - 高性能缓存管理" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理" class="overflowclass">Redis Skill - 高性能缓存管理</a>
<p class="overflowclass">Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。</p>
</div>
<a rel="nofollow" href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<h3>为什么不用 Redisson 的 <code>RLock</code> 直接套用</h3>
<p><code>RLock</code> 是功能完整的分布式锁，但它默认设计面向“强一致性临界区”，而缓存重建不需要强互斥——只要有一个线程在建，其余线程等结果即可。用 <code>RLock</code> 反而引入额外开销和复杂度：</p>
<ul>
<li>每次获取锁都要走一次 Redis 通信，而 <code>SETNX</code> + 占位符只需一次写入判断</li>
<li>
<code>RLock</code> 的看门狗机制在缓存重建这种短任务里基本无用，还可能因网络抖动误续期</li>
<li>若 loader 执行超时或抛异常，<code>RLock</code> 释放不及时，会导致后续请求长时间等待；而上面工具类中 <code>finally delete</code> 更可控</li>
<li>Spring Cache 的 <code>@Cacheable</code> 无法直接集成 <code>RLock</code>，需手动拆解注解逻辑，破坏简洁性</li>
</ul>
<h3>上线前必须验证的三个边界点</h3>
<p>防击穿不是写了就高枕无忧，这三个点漏掉一个，压测时就容易翻车：</p>
<ul>
<li>
<code>loader</code> 函数必须是幂等的：它可能被多个线程触发（比如锁设置失败又重试，或 Lua 脚本执行失败后 fallback 到重试逻辑）</li>
<li>占位符 key 的过期时间（如上面的 3 秒）必须明显短于业务 key 的 TTL，否则会出现“旧占位符未清，新重建被拦住”的假死现象</li>
<li>当 Redis 集群发生主从切换或短暂不可用时，<code>SETNX</code> 可能返回 false 但实际没写成功，此时所有请求都会走降级路径——得确认你的数据库扛得住这波流量，或者加一层本地缓存（如 Caffeine）做二级缓冲</li>
</ul>
<p>最易被忽略的是降级响应的语义一致性：返回 <code>null</code> 还是抛异常？前端是否做了空状态兜底？这些不在 Redis 层解决，但在工具类里得留好扩展口子，比如把 <code>waitForLoad</code> 抽成 protected 方法。</p></t></t></t></t></t></string></string>
