在Java并发编程里，缓存穿透是指查询一个根本不存在的数据，导致请求绕过缓存直接访问数据库。当多个线程同时查询同一个不存在的键时，如果缓存层没有做并发控制，就会出现大量重复查库，甚至因为Map的并发写入产生数据不一致。使用双重检查锁配合ConcurrentHashMap，可以在高并发场景下用较低成本实现线程安全的防护，既防止重复查库，又保证Map操作不会出错。
双重检查锁的基础原理与实现结构
双重检查锁（Double-Checked Locking）的核心目标是减少同步范围。在缓存场景中，我们首先用ConcurrentHashMap的get方法无锁读取，如果拿到结果就直接返回；如果为null，才进入synchronized块。进入同步块后再次调用get确认，这是因为在你等待锁的过程中，别的线程可能已经把值写进去了。第二次检查能避免重复执行加载逻辑，从而把锁竞争限制在“首次加载”这一瞬间。
很多初学者会把synchronized直接加在方法上，这在高并发下会让所有读请求串行化，吞吐量急剧下降。双重检查锁把同步只留给“未命中且确实要加载”的线程，绝大多数命中缓存的线程走的是无锁路径。下面是一段简化实现，展示如何用ConcurrentHashMap和synchronized配合完成基础防护：
public class SafeCache {
private final ConcurrentHashMap<String, Object> map = new ConcurrentHashMap<>();
private final Object NULL = new Object(); // 空值占位符
public Object get(String key) {
Object val = map.get(key);
if (val != null) {
return val == NULL ? null : val;
}
synchronized (this) {
val = map.get(key);
if (val != null) {
return val == NULL ? null : val;
}
Object dbVal = queryFromDb(key); // 模拟查库
if (dbVal == null) {
map.put(key, NULL);
} else {
map.put(key, dbVal);
}
return dbVal;
}
}
private Object queryFromDb(String key) {
return null; // 实际中查数据库
}
}
上面的代码里，NULL是一个特殊占位对象，用来标记“数据库里也没有”的键。这样下次再查同一个不存在的键时，第一次map.get就能拿到NULL，直接返回null，不会再进同步块。这个设计把“缓存穿透”转换成“缓存空对象”，是防护的关键一步。
ConcurrentHashMap为何适合该场景
ConcurrentHashMap在Java 8之后采用分段CAS加synchronized局部锁，读操作基本无锁。我们的双重检查锁依赖它提供的线程安全get和put，但不依赖它做全局互斥。因为get本身线程安全，所以第一重检查不需要加锁；而put在同步块内执行，也由ConcurrentHashMap保证不会因并发写入而损坏结构。相比Hashtable或Collections.synchronizedMap，它不会让读操作也排队。
如果改用普通HashMap再加外部锁，那么在锁外做get就会有并发可见性问题，可能读到半个写操作的结果。而ConcurrentHashMap的happens-before规则保证了写后读可见。下表简单对比几种Map在缓存防护中的差异：
| 实现方式 | 读性能 | 写安全 | 适用场景 |
|---|---|---|---|
| HashMap+外部锁 | 低（锁外读不安全） | 依赖锁 | 不推荐 |
| Hashtable | 低（方法级锁） | 内建 | 遗留代码 |
| ConcurrentHashMap+双重检查 | 高（无锁读） | 内建 | 高并发缓存 |
从表中可以看出，只有ConcurrentHashMap配合双重检查锁，才能做到读不加锁、写有保护。这也是为什么它在各类本地缓存组件里被广泛使用。需要注意的是，ConcurrentHashMap不保证复合操作的原子性，例如“不存在才放”如果用putIfAbsent也可以，但在我们这种需要查库并区分空占位的逻辑里，显式双重检查更直观可控。
空值占位与过期清理的工程细节
只写双重检查锁还不够，因为空值占位NULL会永久留在Map里。如果恶意构造大量不存在的键，内存会被占满。工程上通常给占位对象加时间戳，或者在另一个定时任务里清理超过一定时间的空条目。也可以在put时顺带记录写入时间，读取时发现过期就删除并放行查库。这样既挡住了瞬时穿透，也避免长期污染。
另一个细节是synchronized块的范围。如果queryFromDb很慢，锁会拖住其他也要加载的线程。可以改为用ConcurrentHashMap的computeIfAbsent，它内部已经做了类似双重检查的机制，且锁粒度更细。但computeIfAbsent里不要做耗时IO，否则会阻塞该桶。示例改用computeIfAbsent的写法如下：
public Object getV2(String key) {
Object val = map.get(key);
if (val != null) {
return val == NULL ? null : val;
}
// computeIfAbsent内部对key所在桶加锁，仅未存在时才执行
Object result = map.computeIfAbsent(key, k -> {
Object db = queryFromDb(k);
return db == null ? NULL : db;
});
return result == NULL ? null : result;
}
这段代码把同步细节交给ConcurrentHashMap，可读性更好，但在JDK版本低于8时不可用。无论哪种写法，目标一致：让不存在的键只查一次库，并用线程安全容器承接结果。实际系统中还应结合Redis等分布式缓存做多层防护，本地Map主要解决单机高并发下的重复查库与线程安全，而不是替代远程缓存。
Java并发编程双重检查锁ConcurrentHashMap修改时间：2026-08-14 17:09:33