缓存出事的时候，值班同学最常说的一句话是「缓存被打穿了」。这句话把三种完全不同的事故揉成了一个词，于是解法也跟着揉成一团：有人给穿透加互斥锁，有人给雪崩加空值缓存，最后该挡的没挡住。

这篇把三种事故拆开，用**一家便利店**从头讲到尾，再用本机 JDK 17 跑三组最小复现，把「哪一种该用哪一种写法」量出来。结论先放这里：**穿透是不存在的 key，击穿是一个存在的热点 key，雪崩是一批 key 在同一时刻过期**；三种写法各管各的，不能互相替。

---

## 先建立一个世界观

想象一家便利店：门口一排货架，后头一个大仓库。顾客要一罐牛奶，店员先看货架，有就直接拿走；没有才跑去仓库取，取回来顺手摆一瓶到货架上，下次就不用再跑。

| 技术概念 | 便利店里的角色 | 它是缓存的什么 |
|---|---|---|
| 缓存（本地 `ConcurrentHashMap` / Redis） | 门口那排货架 | 数据的副本，是全文主角 |
| 数据库 / 下游服务 | 后头的大仓库 | 回源的目标，慢而全 |
| 应用线程 | 跑腿的店员 | 谁去仓库，取决于谁先发现货架空了 |
| 缓存键 / 值 | 商品编号 / 商品 | 一次查询的最小单位 |
| 缓存未命中 | 货架上没有 | 触发回源的分支 |
| TTL / 过期时间 | 货架上的保质期标签 | 三种事故共同的触发条件 |
| 空值缓存 | 「此货暂无」的牌子 | 穿透的补丁机制 |
| 互斥重建 / singleflight | 只派一个店员去进货的进货单 | 击穿的补丁机制 |

这个类比有个前提要先说清：便利店的货架摆的是**实物**，而缓存摆的是**副本**。仓库改了配方，货架上那罐还是旧标签——这个不一致就是所有缓存方案的代价，后面「破壁」一节会逐条算清。

---

## 第一层：缓存在这个世界里是谁

**一句话定义**：缓存是把「慢而全」的仓库，换成「快而少」的门口陈列，用空间和一致性换时间。

它和**回源**的关系：回源是缓存未命中时的补偿路径，缓存的全部收益都来自「少走几次这条路」。所以判断缓存有没有出问题，不看命中率曲线好不好看，看的是**仓库被跑了多少趟**。

它和**TTL** 的关系：TTL 决定副本什么时候作废。没有「同一时刻一起作废」这件事，击穿和雪崩都不成立；反过来，只要给一批 key 设了同一个 TTL，事故就已经埋好了。

下面这段是最小的「先看货架、再跑仓库」，全文所有实验都从它变形而来：

```java
Map<String, String> shelf = new ConcurrentHashMap<>();
String v = shelf.get("sku-1");        // 先看货架
if (v == null) {
    v = loadFromWarehouse("sku-1");  // 没有才跑仓库
    shelf.put("sku-1", v);           // 回填
}
```

**类比局限之一**：现实里店员跑一趟仓库最多累一点，线上一次回源可能是一次慢 SQL、一次 RPC，放大到几千 QPS 就是数据库先倒。类比只解释「为什么少跑」，不解释「跑一趟多贵」。

---

## 第二层：这个世界怎么分工

读懂后面三种事故，只需要五个前置词：**命中**（货架有）、**未命中**（货架没有）、**回填**（从仓库取回来摆上）、**过期**（保质期到）、**淘汰**（货架满了得扔掉一些）。

再看关联知识点，每一个都写清它和缓存的关系：

1. **`ConcurrentHashMap.computeIfAbsent`** —— 它是单 JVM 内防击穿的最小互斥单元：同一个 key 的映射函数最多执行一次，其余线程拿同一个结果。
2. **布隆过滤器** —— 它是穿透在「不允许缓存空值」时的替代方案；代价是**有误判率**：说不存在的一定不存在，说存在的未必真存在。
3. **逻辑过期** —— 它是击穿在「不允许阻塞」时的解法：物理上不删 key，只标一个过期字段，先返回旧值，后台慢慢刷新。
4. **TTL 随机抖动** —— 它是雪崩最直接的解法，把集中在一个时刻的过期摊平到一段时间里。
5. **多级缓存（本地 Caffeine + Redis）** —— 它是雪崩的纵深防御，一层失效还有一层顶着。
6. **缓存一致性 / 双写** —— 它是所有缓存方案共同的代价；副本会脏，删缓存和写数据库的顺序必须设计。
7. **限流与熔断** —— 它是缓存整体失效时的最后一道兜底，保护的是仓库而不是货架。
8. **热点探测** —— 它是逻辑过期的前提：得先知道谁是爆款，才值得单独给它派进货单。
9. **`putIfAbsent`** —— 它是上一篇《接口幂等》的主角，单 JVM 内挡重复请求；在这里同样只在单 JVM 内成立。
10. **分布式锁 / Redis `SET ... NX`** —— 它是 `computeIfAbsent` 跨实例的版本，把「一个店员」升级成「全公司只派一个人」。

知识图谱收束一下，三种事故都从「未命中 + 过期」这同一个分岔口长出来：

```mermaid
graph TD
  A["缓存查询"] -->|命中| B["返回副本"]
  A -->|未命中| C["回源仓库"]
  C --> D["回填 + 设置 TTL"]
  D --> E["过期时刻"]
  E --> F1["穿透 key 不存在"]
  E --> F2["击穿 单个热点 key"]
  E --> F3["雪崩 一批 key 同时过期"]
  F1 --> G1["空值缓存 或 布隆过滤器"]
  F2 --> G2["互斥重建 或 逻辑过期"]
  F3 --> G3["TTL 抖动 加 多级缓存"]
  G1 --> H["共享缓存 与 限流兜底"]
  G2 --> H
  G3 --> H
```

---

## 第三层：忙起来会怎样

平日里一个店员跑一趟仓库看不出问题。真正的分水岭是**并发**：8 个顾客同时要一款刚下架的爆款，8 个店员都看见货架空了，是各自跑一趟，还是只派一个？

单 JVM 里这件事由 `ConcurrentHashMap` 的桶级锁决定；跨实例时没有任何本地结构能替你做这个决定。下面三组实验都在**单个 JVM** 里跑，正是为了把这个边界量清楚。

---

## 第四层：这个世界会出的事故

三种事故，按「查的 key 存不存在」和「失效的 key 有多少」一刀切开：

| 现象 | 顾客要的是什么 | 谁在跑仓库 | 本轮实测 |
|---|---|---|---|
| 穿透 | 仓库里**根本没有**的商品 | 每次查询都白跑一趟 | 10 次查询 → 10 趟；挂「暂无」牌后 → 1 趟 |
| 击穿 | **一款**刚过期的爆款 | 8 个店员同时去进货 | 朴素 `get` 后 `put` → 8 趟；`computeIfAbsent` → 1 趟 |
| 雪崩 | **一批**同时过期的商品 | 同一时刻集体回源 | 100 个 key 全落在 1 个 200ms 窗口，峰值 100；加抖动后峰值 31 |

### 事故一：穿透 —— 查一个不存在的 key

顾客连着 10 次问「有没有 sku-missing」，仓库里压根没这个编号。店员每次都老实跑一趟，货架永远是空的。**缓存根本没参与**，因为它只缓存「查到的东西」，不缓存「查不到」这件事。

补丁很朴素：在货架上挂一块「此货暂无」的牌子，也就是**缓存空值**。

```java
Map<String, String> shelf = new ConcurrentHashMap<>();
int[] trips = {0};
for (int i = 0; i < 10; i++) {
    if (shelf.get("sku-missing") == null) trips[0]++;
}
System.out.println("no null-cache  : warehouse trips = " + trips[0]);
trips[0] = 0;
for (int i = 0; i < 10; i++) {
    if (shelf.get("sku-missing") == null) {
        trips[0]++;
        shelf.put("sku-missing", "<EMPTY>");
    }
}
System.out.println("with null-cache: warehouse trips = " + trips[0]);
```

输出是 `10` 和 `1`。**因果衍生**：这块牌子马上带来新缺陷——商品真上架了，牌子还挂着，用户继续看到「暂无」。所以空值缓存必须配一个**比正常 TTL 更短**的过期时间，或者在写入路径上主动删掉它；布隆过滤器是另一条路，代价是误判和额外的维护成本。

### 事故二：击穿 —— 一个热点 key 过期

爆款下架的瞬间，8 个线程同时执行「先 `get` 再 `put`」。因为 `get` 和 `put` 之间有一段时间窗口，8 个都看见 null，8 个都去回源。本轮对照实验用 8 线程 + `CountDownLatch` 同时放行，朴素养法实测 `warehouse trips = 8`。

换成 `computeIfAbsent`，同一个 key 的映射函数只被应用一次，其余线程等在桶上拿结果：

```java
Map<String, String> shelf = new ConcurrentHashMap<>();
AtomicInteger trips = new AtomicInteger();
CountDownLatch start = new CountDownLatch(1);
ExecutorService pool = Executors.newFixedThreadPool(8);
for (int i = 0; i < 8; i++) {
    pool.submit(() -> {
        try { start.await(); } catch (InterruptedException e) { return; }
        shelf.computeIfAbsent("sku-hot", k -> { trips.incrementAndGet(); return "hot"; });
    });
}
start.countDown();
pool.shutdown();
pool.awaitTermination(5, TimeUnit.SECONDS);
System.out.println("computeIfAbsent: warehouse trips = " + trips.get());
```

输出 `1`。**因果衍生**：这里有两个容易被忽略的代价。一是同 key 的其他线程会**阻塞**在这个桶上，回源越慢堵得越久；二是映射函数执行期间持有桶锁，**函数里不能再改同一个 Map**（递归更新会抛异常甚至自锁）。要求「一个都不能阻塞」的场景，得改用逻辑过期：返回旧值，另起任务刷新。

### 事故三：雪崩 —— 一批 key 同时过期

批量预热最常写成「100 个 key，统一 TTL 1000ms」。于是 1000ms 那一刻，100 个货架位同时空掉。把过期时刻按 200ms 分桶统计：

```java
int[] uniform = new int[8], jittered = new int[8];
Random r = new Random(3057L);
for (int i = 0; i < 100; i++) {
    uniform[1000 / 200]++;
    jittered[(1000 - 400 + r.nextInt(801)) / 200]++;
}
System.out.println("uniform peak = " + Arrays.stream(uniform).max().orElse(0));
System.out.println("jittered peak = " + Arrays.stream(jittered).max().orElse(0));
```

输出 `uniform peak = 100`、`jittered peak = 31`。抖动范围取基准 TTL 的 ±40%（600~1400ms），100 个 key 摊到 5 个窗口里，实测分布 `[0, 0, 0, 22, 24, 31, 23, 0]`，峰值降了约 69%。

**这一组是确定性分桶统计，不是并发压测**：它量化的是过期时刻的分布，不是 QPS，也不含网络与数据库耗时。**因果衍生**：抖动的代价是数据新鲜度窗口被拉宽——有的副本 600ms 就换，有的要 1400ms。所以抖动适合批量写入的冷数据，热点 key 仍该走逻辑过期，别为了摊平峰值牺牲爆款的新鲜度。

三组跑完，把输出汇总一下（对照组的朴素写法来自同轮实验脚本）：

```bash
$ javac -encoding UTF-8 Penetration.java Breakdown.java Avalanche.java
$ java Penetration
no null-cache  : warehouse trips = 10
with null-cache: warehouse trips = 1
$ java Breakdown
computeIfAbsent: warehouse trips = 1
$ java Avalanche
uniform peak = 100
jittered peak = 31
naive get-then-put: warehouse trips = 8
```

---

## 换一家公司会怎么做

便利店是「每家店自己摆货架」，换成**中央仓配**（Redis 集中式缓存），组织方式完全不同：

| 维度 | 本地货架（`ConcurrentHashMap`） | 中央仓配（Redis） |
|---|---|---|
| 副本谁保管 | 每个 JVM 各一本 | 所有实例共享一本 |
| 防击穿手段 | `computeIfAbsent` 同 key 互斥 | `SET ... NX` / 分布式锁 + singleflight |
| 8 个实例同时回源 | 挡不住，最多 8 次 | 能收敛成 1 次 |
| 主要代价 | 堆内存、副本不一致、重启全丢 | 网络往返、序列化、Redis 自身高可用 |

**选型建议**：两者是叠加关系，不是二选一。本地货架挡「单实例内的瞬时重复」，中央仓配挡「跨实例的重复」；真要护住仓库，最后还得叠一层限流或熔断。这也和上一篇《接口幂等》的结论对上了——**单 JVM 里的所有技巧都过不了多实例这一关**。

---

## 世界观破壁：回到真实原理

把映射逐条翻译回去，并把类比失效的地方写全：

| 便利店里的说法 | 真实术语 | 类比在哪里失效 |
|---|---|---|
| 门口货架 | 缓存副本（本地 Map / Redis） | 货架摆的是实物，缓存摆的是副本；原件改了，副本可能还是旧的 |
| 「此货暂无」的牌子 | 空值缓存 / 布隆过滤器 | 现实里牌子会一直挂着；线上必须设短 TTL 或主动失效，否则真上架了也看不到 |
| 只派一个店员进货 | `computeIfAbsent` / singleflight | 现实里其他顾客不用等；线上同 key 线程会阻塞在桶锁上，映射函数里还不能改同一个 Map |
| 保质期标签 | TTL / 逻辑过期 | 现实里过期是物理下架；线上「逻辑过期」是仍返回旧值，只是标了待刷新 |

**版本与范围前提**：以下数字来自本机 OpenJDK 17.0.20.1（Temurin / Windows），`javac -encoding UTF-8` 后以单文件源码模式运行；缓存用 `ConcurrentHashMap` 在**单个 JVM** 内模拟。本轮**未连 Redis、未接数据库、未起多实例**，Redis `SET ... NX`、布隆过滤器、逻辑过期、分布式锁只做机制说明，没有端到端验证。三组数字用于说明机制差异，**不是生产容量数据**。

**常见坑与面试高频**（一句话答案）：

- 「穿透和击穿怎么分？」—— 看 key 存不存在：不存在的是穿透，存在但刚过期的是击穿。
- 「空值缓存会不会把内存撑爆？」—— 会，所以 TTL 要短，且要限制可缓存的 key 形态，别让随机参数直接进缓存键。
- 「`computeIfAbsent` 里能再查一次缓存吗？」—— 不能递归更新同一个 Map，会抛异常或自锁。
- 「加了抖动是不是就没事了？」—— 只摊平了峰值，没减少总量；仓库本身的容量还得靠限流兜底。

---

## 收尾

三条能带走的结论：

1. **按规模分诊**：不存在的一个 key 是穿透，过期的一个热点 key 是击穿，同一时刻过期的一批 key 是雪崩。
2. **一种写法只管一层**：空值缓存挡穿透、`computeIfAbsent` / 逻辑过期挡击穿、TTL 抖动 + 多级缓存挡雪崩；混着用会漏。
3. **单 JVM 不是终点**：本轮三组实测全部在单实例内成立，跨实例要靠共享缓存 + 分布式互斥，最后用限流兜底。

延伸阅读按这个顺序走：`HashMap` 哈希与扩容 → `ConcurrentHashMap` 桶级锁与 `computeIfAbsent` → TTL 与淘汰策略（LRU / LFU）→ 缓存一致性与双写顺序 → 布隆过滤器与误判率 → 多级缓存与热点探测 → 限流熔断与降级。

以上是本轮最小复现场景，非真实事故原始记录。完整实验脚本与输出已在本机归档，欢迎在评论区交流这三种事故在你们线上的实际形态，也欢迎指正。

缓存出事的时候，值班同学最常说的一句话是「缓存被打穿了」。这句话把三种完全不同的事故揉成了一个词，于是解法也跟着揉成一团：有人给穿透加互斥锁，有人给雪崩加空值缓存，最后该挡的没挡住。

【Java·缓存】用一家便利店讲清穿透、击穿、雪崩：从过期时刻到互斥重建的 3 组实测

三种缓存事故按「key 存不存在」和「失效数量」一刀切开。用便利店货架与仓库的单一世界观讲清算命中、回源、TTL 与回填，再用本机 JDK 17.0.20.1 跑三组最小复现：空值缓存 10→1 趟回源、computeIfAbsent 8→1 趟、TTL 抖动把 100 个 key 的过期峰值降到 31。每种写法都写清代价，并说明单 JVM 手段为何过不了多实例。

后端

数据库

编程语言

缓存穿透、击穿、雪崩是三种易混事故：穿透是查不存在的key，击穿是单个热点key过期，雪崩是一批key同时过期。本文用便利店类比拆解差异，附JDK17三组最小复现实验，实测空值缓存、computeIfAbsent、TTL抖动分别降低回源次数至1次、1次、峰值降69%，明确各解法适用边界。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【Java·缓存】用一家便利店讲清穿透、击穿、雪崩：从过期时刻到互斥重建的 3 组实测-腾讯云开发者社区-腾讯云

【Java·缓存】用一家便利店讲清穿透、击穿、雪崩：从过期时刻到互斥重建的 3 组实测

【Java·缓存】用一家便利店讲清穿透、击穿、雪崩：从过期时刻到互斥重建的 3 组实测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐