这是一个非常经典且重要的并发缓存设计模式。在缓存更新的逻辑中，在加锁前和加锁后都去读取缓存，这通常被称为 “双重检查”（Double-Check），它的目的是为了解决高并发场景下的一些核心问题。
1、 核心思想与流程
这个模式最常见的应用场景是 “缓存重建”：当缓存失效（不存在）时，我们需要从数据库中加载数据并写入缓存。
如果没有锁，在超高并发下，会有大量请求同时发现缓存失效，然后同时去访问数据库，导致 “缓存击穿” 。加锁就是为了防止这种情况。
标准流程如下：
1. 第一重检查（锁外）
- 请求到达，首先查询缓存。
- 如果缓存存在：直接返回数据，流程结束。这是最快速的路径，避免了任何锁开销。
- 如果缓存不存在：进入下一步。
2. 加锁
- 在尝试重建缓存之前，先获取一个分布式锁（如果是单机服务，可以用本地锁如 `synchronized` 或 `ReentrantLock`）。
- 目的：确保同一时间只有一个线程/请求能够执行重建缓存的逻辑。
3. 第二重检查（锁内）
- 在获得锁之后，再次查询缓存。
- 为什么？ 因为在当前请求等待锁的期间，可能**已经有另一个先拿到锁的线程完成了缓存重建**。
- 如果缓存存在：说明数据已经被其他线程写入了。那么当前线程直接释放锁，然后使用缓存中的数据即可，无需再访问数据库。
- **如果缓存仍然不存在**：说明当前线程是第一个（也是唯一一个）需要去重建缓存的线程。进入下一步。
4. 执行业务逻辑 & 重建缓存
- 从数据库查询数据。
- 将数据写入缓存。
- 释放锁。
为什么需要两次读取缓存？
我们可以通过一个生动的并发场景来理解：假设在某一时刻，缓存 `key=A` 失效，同时有 **1000 个并发请求** 涌入。
示例代码:
public String getData(String key) {// 第一重检查：锁外检查（快路径）String data = cache.get(key);if (data != null) {return data;}// 缓存不存在，尝试获取锁String lockKey = "lock:" + key;boolean locked = distributedLock.tryLock(lockKey);if (!locked) {// 没拿到锁，可以稍后重试，或者直接去查数据库（不推荐），这里我们简单等待一下再递归调用Thread.sleep(100);return getData(key);}try {// 第二重检查：锁内检查（双重检查）data = cache.get(key);if (data != null) {return data;}// 缓存确实为空，执行重建逻辑data = database.query(key);cache.set(key, data, ttl);return data;} finally {distributedLock.unlock(lockKey);}
}
总而言之，**加锁前读缓存是为了效率，加锁后读缓存是为了正确性和进一步的效率优化**。这是一个在高并发环境下兼顾性能与数据一致性的经典设计。