spring boot 全局异常处理无法直接捕获缓存击穿，因为缓存击穿是业务逻辑层面的并发竞争问题，而非运行时抛出的 java 异常。要解决这个问题，必须在业务代码中通过分布式锁或原子操作来保证只有一个线程去查询数据库并回填缓存，其他线程等待结果即可。
为什么全局异常处理无效
全局异常处理器（如 @ControllerAdvice）只能捕获程序执行过程中抛出的 Exception 或其子类。缓存击穿发生时，多个线程同时发现缓存为空，它们都会尝试去查数据库，这个过程本身不会抛出异常，而是会导致数据库压力瞬间增大。因此，试图在 @ExceptionHandler 中拦截“缓存击穿”是不现实的，必须从架构设计层面解决。
使用 Redisson 实现防击穿方案
推荐使用 Redisson 的 getLock() 结合 tryLock 来实现单点回源。核心思路是：当缓存未命中时，获取一个基于 Key 的分布式锁，只有拿到锁的线程才去查库并写缓存，其他线程自旋等待或返回默认值。这种方式能有效防止高并发下的重复 DB 查询。
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
@Service
public class CacheService {
private final RedissonClient redissonClient;
private final DatabaseService databaseService;
public CacheService(RedissonClient redissonClient, DatabaseService databaseService) {
this.redissonClient = redissonClient;
this.databaseService = databaseService;
}
public String getData(String key) {
// 1. 先查缓存
String cacheValue = getFromCache(key);
if (cacheValue != null) {
return cacheValue;
}
// 2. 缓存为空，获取分布式锁
RLock lock = redissonClient.getLock("lock:" + key);
try {
// 尝试加锁，等待时间设为0，立即返回是否成功
if (lock.tryLock(100, 10, TimeUnit.SECONDS)) {
try {
// 双重检查，防止在等待锁期间其他线程已回填
cacheValue = getFromCache(key);
if (cacheValue == null) {
// 3. 查数据库
cacheValue = databaseService.queryFromDB(key);
// 4. 回填缓存
putToCache(key, cacheValue);
}
} finally {
lock.unlock();
}
} else {
// 5. 没拿到锁，短暂休眠后重试或直接返回空/默认值
Thread.sleep(50);
return getData(key); // 递归重试
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException("Interrupted", e);
}
return cacheValue;
}
private String getFromCache(String key) {
// 模拟从 Redis 获取
return null;
}
private void putToCache(String key, String value) {
// 模拟写入 Redis
}
}
上述代码展示了标准的防击穿流程。预期结果是：在高并发场景下，无论有多少个请求同时到达，同一时刻只有一个线程会执行 databaseService.queryFromDB，其余线程要么等待锁释放后直接从缓存获取，要么因超时返回默认值。这避免了数据库被瞬间打满的风险。
缓存击穿的具体触发条件与验证
缓存击穿的特定条件是：Key 对应的数据在缓存中过期或被删除的瞬间，恰好有大量并发请求访问该 Key。为了验证这一点，我们可以观察上述代码中的 if (cacheValue == null) 分支。如果去掉分布式锁，仅保留简单的 synchronized 或无锁机制，在压测环境下会发现数据库连接池迅速耗尽，而加入 RLock 后，数据库负载保持平稳。这说明只有当“缓存失效”且“高并发”这两个条件同时满足时，才需要启用这种复杂的锁机制；对于低流量场景，简单的同步方法或逻辑过期策略可能更合适。
