2026-11-01

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：三者都是 List 接口实现，本质差异在底层结构——ArrayList/Vector 基于动态数组、LinkedList 基于双向链表，由此决定读写增删性能与线程安全边界。
> 关键词：动态数组扩容 1.5x · 双向链表指针 · synchronized
> 边界：链表 O(1) 增删的前提是已持有节点引用，否则定位仍 O(n)；线程安全读多写少优先 CopyOnWriteArrayList。

### L2 · 核心讲解

**核心考点定位**：考察 Java 集合框架三种 List 实现的底层结构差异，以及从底层结构推导出的读写增删性能与线程安全边界；面试官想看到"从底层实现推能力"，而不是背结论。

**机制链（≥3 环）**：
1. ArrayList 基于动态数组 → 元素存于连续内存 `Object[] elementData` → 按下标 O(1) 随机访问；但中间插入/删除需搬运后续元素 → O(n)。
2. 数组容量固定 → 元素数达到容量需扩容 `grow()`（默认 1.5 倍）→ 新建数组 + `System.arraycopy` 整体迁移 → 扩容成本随规模上升。
3. LinkedList 基于双向链表 → 每个节点含 `prev/next` 指针 → 增删只改指针 O(1)；但定位任意节点仍需从首/尾遍历 → O(n)。
4. Vector 用 `synchronized` 修饰方法 → 线程安全，但整方法加锁 → 并发读写串行化、吞吐低 → JDK 已标记过时，读多写少用 `CopyOnWriteArrayList` 替代。

**证据锚点**：
- `Object[] elementData`：ArrayList 底层数组
- `grow()` / `newCapacity`：扩容逻辑（1.5 倍）
- `System.arraycopy`：扩容/搬运时复制数组
- `Node<E>`（`item/prev/next`）：LinkedList 节点
- `addFirst`/`addLast`：头尾 O(1) 增删
- `synchronized`：Vector 方法级锁
- `CopyOnWriteArrayList`：读多写少的线程安全替代
- `modCount`：fail-fast 迭代检测

**对比与权衡**：

| 维度 | ArrayList | LinkedList | Vector |
|---|---|---|---|
| 底层结构 | 动态数组 | 双向链表 | 动态数组 |
| 随机访问 | O(1) | O(n) 遍历 | O(1) |
| 中间增删 | O(n) 搬运 | O(n) 定位 + O(1) 指针 | O(n) 搬运 |
| 头尾增删 | 尾部均摊 O(1) | O(1) | 尾部均摊 O(1) |
| 线程安全 | 否 | 否 | 方法级 synchronized |
| 扩容 | 1.5 倍 | 无 | 2 倍 |

**常见误区**：
1. 错误："LinkedList 增删一定比 ArrayList 快" → 正确：只有"已定位到节点"时 O(1)，任意位置增删仍需 O(n) 遍历定位 → 为什么：链表的 O(1) 增删前提是持有节点引用，否则先要遍历到目标。
2. 错误："Vector 已废弃就绝不使用" → 正确：过时但未删除，线程安全读多写少时优先 `CopyOnWriteArrayList` → 为什么：Vector 的整方法 `synchronized` 全局锁，写并发吞吐低。
3. 错误："ArrayList 扩容是 2 倍" → 正确：ArrayList 默认 1.5 倍（Vector 才是 2 倍）→ 为什么：1.5 倍在"扩容频率"与"内存浪费/拷贝成本"间折中。
4. 错误："ArrayList 和 Vector 性能一样" → 正确：Vector 每次增删都加锁，且有同步开销，单线程下比 ArrayList 慢 → 为什么：锁竞争与内存屏障开销。

**适用边界**：
- **适合**：读多写少、按下标访问 → ArrayList；频繁头尾增删、迭代中删除 → LinkedList。
- **不适合**：LinkedList 在"随机访问 + 中间插入"混合场景通常更慢；Vector 在现代并发场景几乎不用。
- **替代方案**：线程安全读多写少 → `CopyOnWriteArrayList`；线程安全写多 → `Collections.synchronizedList` 或并发容器。

### 延伸追问（≥3）

1. **ArrayList 为什么扩容 1.5 倍而不是 2 倍？**
- 要点：1.5 倍在"扩容次数"与"拷贝成本/内存浪费"间折中；2 倍（Vector）内存增长更快但拷贝更少
- 追问落点：与 `HashMap` 0.75 负载因子的设计取舍类比

2. **LinkedList 头尾增删如何做到 O(1)？**
- 要点：`addFirst`/`addLast` 直接改头尾哨兵节点指针，无需遍历
- 追问落点：为什么"任意位置增删"仍 O(n)

3. **fail-fast 是什么？**
- 要点：迭代期间结构变更使 `modCount` 变化，触发 `ConcurrentModificationException`
- 追问落点：与 `CopyOnWriteArrayList` 的 fail-safe 迭代器区别

4. **CopyOnWriteArrayList 有什么代价？**
- 要点：写时复制整个底层数组，写开销 O(n)，适合读多写少
- 追问落点：写多场景为何不用它

### 面试者参考回答

**【结论】** 三者都是 List 接口实现，本质差异在底层结构：ArrayList/Vector 基于动态数组、LinkedList 基于双向链表，由此决定读写增删性能与线程安全。

**【三点】**
第一，随机访问：ArrayList/Vector 按下标 O(1)，LinkedList 需 O(n) 遍历；所以"按位置查"用数组实现。
第二，增删：链表只改指针，数组要搬运后续元素；但链表增删前要先 O(n) 定位，所以"头尾频繁增删"才占优。
第三，线程安全与扩容：Vector 方法 synchronized、扩容 2 倍，已过时；ArrayList 扩容 1.5 倍且非线程安全；读多写少需要线程安全时用 CopyOnWriteArrayList。

**【边界】** 链表 O(1) 增删的前提是已持有节点引用，否则定位仍 O(n)；线程安全按"读多写少"选 CopyOnWriteArrayList，写多时其整数组复制成本高，反而不划算。

> 最后更新：2026-11-01 · 基于第 2 次作答

### L1 · 30 秒速记
> 结论：Offset 是消息在**分区内**的唯一位置标识，从 0 开始单调递增、不可复用；消费者组把它持久化到 `__consumer_offsets`，用来记录"消费到哪了"。
> 关键词：分区内单调递增 · 消费者组提交 · (topic, partition, offset)
> 边界：Offset 非全局唯一，需三元组唯一定位；`auto.offset.reset` 只在首次订阅且无历史 offset 时生效。

### L2 · 核心讲解

**核心考点定位**：考察 Offset 的"位点语义"（分区内单调、不可复用）与"位点存储"（消费者组持久化到 `__consumer_offsets`）两个层面；面试官想看到从"是什么"到"存哪、怎么提交"的完整链条。

**机制链（≥3 环）**：
1. 消息写入分区 → broker 分配**分区内单调递增**的 offset（从 0 开始）→ 作为该分区内消息的位置标识。
2. 消费者读取消息后 → 消费者组记录**已消费位点**（提交 offset）→ 重启后从该位点继续消费，实现断点续读。
3. offset 提交持久化 → Kafka 0.9 前存 ZooKeeper，0.9+ 存内置 Topic `__consumer_offsets`（50 分区，key=group+topic+partition）→ 用 Kafka 自身存位点，性能好且可查询。
4. 提交策略不同 → `enable.auto.commit` 自动提交可能重复消费；手动 `commitSync` 业务成功后提交 → 保证 at-least-once。

**证据锚点**：
- `__consumer_offsets`：位点存储的内置 Topic（0.9+）
- `Log Start Offset`：分区最早可读位点
- `Log End Offset (LEO)`：分区末尾下一位
- `enable.auto.commit`：自动提交开关
- `commitSync` / `commitAsync`：手动提交方式
- `auto.offset.reset`：earliest / latest / none
- `kafka-consumer-groups.sh`：查看组与 lag
- 50 个分区：`__consumer_offsets` 分区数
- `(topic, partition, offset)`：唯一标识三元组

**对比与权衡**：

| 提交策略 | 一致性 | 性能 | 风险 |
|---|---|---|---|
| 自动提交（5s） | 弱 | 高 | 重复消费 |
| `commitSync` | 强 | 低 | 阻塞等待 |
| `commitAsync` | 中 | 高 | 提交可能丢失 |
| 手动 + `commitSync` | 强 | 中 | 需业务完成后提交 |

**常见误区**：
1. 错误："Offset 是全局消息 ID" → 正确：Offset 是**分区内**位置，全局唯一需 `(topic, partition, offset)` 三元组 → 为什么：Kafka 没有全局唯一消息 ID。
2. 错误："Offset 由消费者实例自己维护" → 正确：Offset 由**消费者组**管理并持久化到 `__consumer_offsets` → 为什么：组内重平衡、实例重启要靠组级位点恢复。
3. 错误："offset 可复用/会回收" → 正确：offset 单调递增**不可复用**，即使消息被 retention 删除 → 为什么：保证位点单调、避免复用导致重复读。
4. 错误："auto.offset.reset 随时生效" → 正确：只在**首次订阅且无历史 offset** 时生效，之后从提交 offset 开始 → 为什么：已有提交位点时忽略该配置。

**适用边界**：
- **适合**：需要断点续读、组内消费位点管理（`__consumer_offsets`）。
- **不适合**：需要精确一次消费时，offset 提交 + 幂等还不够，需事务/幂等。
- **替代方案**：Exactly-Once 用幂等 + 事务；重放用 `seek`/`--from-earliest`；滞后排查用 lag 监控。

### 延伸追问（≥3）

1. **消费者组挂了重启从哪消费？**
- 要点：从 `__consumer_offsets` 读最近 commit；异步提交可能重复消费
- 追问落点：at-least-once vs exactly-once 的取舍

2. **怎么判断消费者组是否堆积？**
- 要点：lag = `LEO` - 已提交 offset；`kafka-consumer-groups.sh --describe`
- 追问落点：lag 突增的定位（慢消费者/分区不均/下游瓶颈）

3. **Offset 会跳号吗？**
- 要点：compaction 删旧保留最新，offset 不复用、可跳号
- 追问落点：与 RocketMQ 消费位点（队列 offset + 位点队列）的对比

4. **如何实现 Exactly-Once？**
- 要点：幂等 + 事务（`read_committed`），或业务侧幂等表
- 追问落点：与 at-least-once 的吞吐/复杂度权衡

### 面试者参考回答

**【结论】** Offset 是消息在分区内的唯一位置标识，从 0 开始单调递增、不可复用；消费者组把它持久化到 `__consumer_offsets` 记录消费进度。

**【三点】**
第一，位点语义：offset 在**分区内**从 0 单调递增，唯一定位一条消息需 `(topic, partition, offset)` 三元组，Kafka 没有全局消息 ID。
第二，位点存储：0.9 前存 ZooKeeper，0.9+ 存内置 Topic `__consumer_offsets`（50 分区，key=group+topic+partition），重启后从提交位点续读。
第三，提交策略：自动提交简单但可能重复消费；手动 `commitSync` 在业务成功后提交，保证至少一次；`auto.offset.reset` 仅首次订阅无历史位点时生效。

**【边界】** offset 单调但可跳号（compaction/删除）；`__consumer_offsets` 本身是 Kafka topic；精确一次需幂等 + 事务，不能只靠提交位点。

> 最后更新：2026-11-01 · 基于第 2 次作答

### L1 · 30 秒速记
> 结论：Seata 四种模式按"侵入性/一致性/性能"取舍——AT 低侵入自动回滚、TCC 业务补偿锁细、Saga 长链路状态机、XA 数据库两阶段强一致但阻塞。
> 关键词：AT undo_log · TCC try/confirm/cancel · Saga 状态机 · XA 2PC
> 边界：模式选择看业务对一致性/侵入性的容忍度，大多数链路用 AT 或最终一致方案足够。

### L2 · 核心讲解

**核心考点定位**：不只考"有哪 4 种"，而是考"每种模式的机制 + 适配场景 + 选型依据"；面试官想看到选型矩阵，而非只背名字。

**机制链（≥3 环）**：
1. AT → 代理 DataSource，一阶段写 before/after image + `undo_log` + 申请全局锁 → 二阶段成功异步删 undo_log、失败反向 SQL 回滚 → 业务低侵入。
2. TCC → 业务实现 Try（冻结）/Confirm（提交）/Cancel（补偿）→ 锁粒度细、无全局锁 → 适合核心账务、跨库、需资源预留。
3. Saga → 长事务拆成多个本地事务 + 每步补偿 → 状态机编排 → 适合长链路、可接受最终一致。
4. XA → 基于数据库 XA/JTA 两阶段提交 → 强一致但全程持锁、阻塞 → 单库多表或传统 JTA 场景。

**证据锚点**：
- `undo_log`：AT 反向回滚日志
- `@GlobalTransactional`：AT 全局事务入口
- `Try/Confirm/Cancel`：TCC 三方法
- `状态机`：Saga 编排
- `JTA`：XA 两阶段标准
- `2PC`：两阶段提交
- `before image` / `after image`：AT 前后镜像
- 全局锁：AT 二阶段期间的锁
- 补偿：业务侧回滚逻辑

**对比与权衡**：

| 模式 | 一致性 | 侵入性 | 性能 | 是否阻塞 |
|---|---|---|---|---|
| XA | 强 | 低 | 低 | 全程持锁 |
| AT | 最终一致 | 低 | 中 | 全局锁 |
| TCC | 最终一致 | 高 | 高 | 无全局锁 |
| Saga | 最终一致 | 中 | 高 | 无 |

**常见误区**：
1. 错误："AT 是强一致" → 正确：AT 是**最终一致**（一阶段本地提交，二阶段补偿）→ 为什么：中间态可能被读到，靠全局锁降低但非强一致。
2. 错误："XA 只能在同一个数据库内用" → 正确：XA 靠 TM 跨库协调（2PC 正是为此设计），但**全程持锁、阻塞** → 为什么：锁粒度全局、吞吐低。
3. 错误："Saga 补偿一定成功" → 正确：补偿需**幂等 + 可重试 + 状态可查**，失败进人工/对账 → 为什么：补偿本身也可能失败。
4. 错误："TCC 与 AT 侵入性一样" → 正确：TCC 需业务实现 Try/Confirm/Cancel，侵入远高于 AT → 为什么：AT 靠代理 + undo_log 自动回滚。

**适用边界**：
- **适合**：常规微服务链路（订单/库存）→ AT；核心账务、跨库、细粒度资源 → TCC；长链路多步 → Saga。
- **不适合**：需强一致且能承受阻塞 → XA（牺牲性能）；最终一致可容忍时不必上强一致。
- **替代方案**：本地消息表、事务消息（RocketMQ）、最大努力通知。

### 延伸追问（≥3）

1. **AT 与 TCC 怎么选？**
- 要点：AT 低侵入有全局锁；TCC 侵入高但锁细可控
- 追问落点：核心账务为何倾向 TCC（资源预留、可干预）

2. **Saga 补偿一定成功吗？**
- 要点：不保证，需幂等 + 重试 + 状态可查
- 追问落点：补偿失败进人工对账/告警

3. **XA 为何生产上越来越少用？**
- 要点：全程持锁阻塞、性能差、对数据库和中间件要求高
- 追问落点：与 AT/本地消息表的替代

4. **还有哪些分布式事务方案？**
- 要点：本地消息表、事务消息（RocketMQ）、最大努力通知
- 追问落点：与 Seata 各模式的取舍

### 面试者参考回答

**【结论】** Seata 有 AT、TCC、Saga、XA 四种模式，本质是在"侵入性、一致性、性能"之间做取舍。

**【三点】**
第一，AT 默认首选：代理数据源 + `undo_log` 自动回滚，业务几乎不改，适合订单、库存等常规微服务，代价是全局锁。
第二，TCC 与 Saga：TCC 业务写 Try/Confirm/Cancel，侵入最大但资源控制最细，适合核心账务/跨库；Saga 是长链路状态机编排，每步配补偿，适合多步、可接受最终一致。
第三，XA 是数据库原生两阶段：强一致但全程持锁、阻塞、性能差，只在单库多表或传统 JTA 场景考虑，生产上已很少用。

**【边界】** 模式选择看业务对一致性和侵入性的容忍度，不是越强越好；大多数互联网链路用 AT 或最终一致方案就够了；要资源可干预、能人工介入补偿，才值得上 TCC 的侵入成本。

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：JMM 是 Java 的**抽象内存模型**，解决多线程的可见性与有序性（happens-before）；JVM 是 Java 的**具体运行时**，负责内存区域划分与自动内存管理（GC）。
> 关键词：主内存/工作内存 · happens-before · 内存分区
> 边界：JMM 是"规范"（语言层规则），JVM 是"实现"（运行时落地）；JMM 不保证复合操作原子性。

### L2 · 核心讲解

**核心考点定位**：考察是否区分"JMM（并发正确性模型）"与"JVM（运行时内存管理）"两个不同维度；面试官想看到 JMM 的可见性/有序性/happens-before 机制，而非把 volatile/synchronized 当成 JMM 本身。

**机制链（≥3 环）**：
1. 多线程读写共享变量 → 每个线程有独立**工作内存**（线程本地缓存）→ 主内存的最新值可能不可见 → JMM 用"主内存/工作内存"模型定义可见性。
2. 编译器与 CPU 允许**指令重排** → 单线程语义不变但多线程可见序可能出错 → JMM 用 happens-before 规则约束重排。
3. `volatile` 写 → 强制刷新到主内存并禁止相关重排 → 其他线程读 `volatile` 看到最新值 → 解决可见性与有序性。
4. `synchronized`/锁 → 获取锁清空工作内存、释放锁写回主内存 → 建立 happens-before → 既互斥又保证锁内共享变量可见。

**证据锚点**：
- `volatile`：可见性 + 禁止重排
- `synchronized`：互斥 + happens-before 内存语义
- `happens-before`：JMM 核心规则
- 主内存 / 工作内存：JMM 的抽象层级
- `-Xms` / `-Xmx`：堆初始/最大容量
- `-Xss`：虚拟机栈容量
- `-XX:MetaspaceSize`：方法区/元空间
- `-XX:MaxDirectMemorySize`：直接内存上限
- `Minor GC` / `Full GC`：分代回收
- 程序计数器：线程私有，记录字节码执行位置
- 虚拟机栈：线程私有，栈帧（局部变量/操作数栈）
- 本地方法栈：native 方法栈帧

**对比与权衡**：

| 维度 | JMM | JVM |
|---|---|---|
| 定位 | 语言级抽象内存模型（规范） | 运行时环境（具体实现） |
| 解决 | 可见性 / 有序性 / 原子性（并发正确） | 内存布局、自动分配与回收 |
| 核心机制 | happens-before、volatile、锁 | 内存分区、GC、类加载 |
| 抽象对象 | 主内存 / 工作内存 | 堆 / 栈 / 方法区 / PC / 本地方法栈 |

**常见误区**：
1. 错误："volatile 就是 JMM" → 正确：volatile 是 JMM 提供保证的关键字之一，JMM 是更底层的模型 → 为什么：混淆了"机制"与"模型"，JMM 是规则体系。
2. 错误："JMM 保证所有变量原子性" → 正确：JMM 只保证可见性/有序性，原子性靠锁或 `Atomic*` 类；`i++` 非原子 → 为什么：复合读改写需要 CAS/锁。
3. 错误："JVM 只管理堆内存" → 正确：JVM 管理堆、虚拟机栈、本地方法栈、方法区/元空间、程序计数器 → 为什么：栈溢出、元空间溢出同样是 JVM 内存问题。
4. 错误："synchronized 只保证互斥" → 正确：synchronized 同时建立 happens-before，保证锁内共享变量可见 → 为什么：锁不仅有互斥，还有内存语义。

**适用边界**：
- **适合**：需要解释并发正确性（可见性/有序性）→ JMM；需要解释内存布局与 GC → JVM。
- **不适合**：JMM 不解决原子性（复合操作需锁/CAS）；JVM 内存分区溢出类型不同（堆/元空间/栈/直接内存）。
- **替代方案**：原子性用 `AtomicInteger`/锁；有序性单点用 `volatile`；复杂并发用 `java.util.concurrent`。

### 延伸追问（≥3）

1. **happens-before 有哪些规则？**
- 要点：程序次序、监视器锁、volatile、线程 start/join、传递性
- 追问落点：为什么锁释放后能看到锁前的写入（写回主内存 + 清空工作内存）

2. **可见性问题怎么触发？**
- 要点：工作内存缓存未及时与主内存同步，读旧值
- 追问落点：volatile 的"写后刷新、读前失效"如何解决

3. **JVM 哪些区域会 OOM？**
- 要点：堆 / 方法区 / 虚拟机栈 / 直接内存各自的溢出类型与报错
- 追问落点：各区域溢出的排查命令（`jstat`/`jmap`/`-XX:+HeapDumpOnOutOfMemoryError`）

4. **volatile 为什么不保证原子性？**
- 要点：volatile 只保证可见/有序，不提供复合操作的原子
- 追问落点：`i++` 用 `AtomicInteger`/锁的正确做法

### 面试者参考回答

**【结论】** JMM 是 Java 并发正确性的抽象内存模型，解决多线程的可见性与有序性；JVM 是 Java 运行时，负责内存分区与自动内存管理。

**【三点】**
第一，JMM 解决"看不见"：用主内存/工作内存模型定义可见性，happens-before 规则约束重排；volatile 写刷新主内存、读失效工作内存。
第二，锁的内存语义：获取锁清空工作内存，释放锁写回主内存，因此 synchronized 既互斥又保证可见性。
第三，JVM 是"落地"：管理堆（对象）、虚拟机栈（栈帧）、方法区/元空间（类信息）、程序计数器；GC 自动回收，`-Xmx/-Xms` 调容量。

**【边界】** JMM 不保证复合操作原子性（`i++` 要锁或 CAS）；JVM 各内存区溢出类型不同，需分区域排查；不要把"机制（volatile/锁）"与"模型（JMM）"混为一谈。

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：`a == b` 为 **true**——`"a"+"b"` 是**编译期常量折叠**，`b` 与 `"ab"` 指向**同一字符串常量池条目**；`==` 比较的是引用。
> 关键词：编译期常量折叠 · 字符串常量池 · intern
> 边界：若任一操作数是**运行期变量**（非 final/非编译期常量），则走运行期拼接，`==` 为 false。

### L2 · 核心讲解

**核心考点定位**：考察字符串"编译期常量 vs 运行期对象"的**引用身份比较**；面试官想看到"`==` 比较引用 + 常量折叠何时发生 + 常量池 intern"，而非只背"`==` 比地址"。

**机制链（≥3 环）**：
1. `String a = "ab"` → 字面量在**编译期**放入字符串常量池 → `a` 指向常量池中的 `"ab"` 实例。
2. `String b = "a" + "b"` → 两个操作数都是**编译期常量**（字面量）→ **编译期常量折叠**为 `"ab"` → `b` 同样指向常量池中同一个 `"ab"` 条目 → `a == b` 为 true。
3. 若 `String c = new String("ab")` → `new` 强制在堆上新分配对象 → `c` 的引用与常量池条目不同 → `c == a` 为 false，但 `c.equals(a)` 为 true。
4. 若 `String s1 = "a"; String b2 = s1 + "b";` → `s1` 是运行期变量 → 编译期无法折叠 → 运行期走 `StringBuilder.append` 生成堆上新 String → `b2 == a` 为 false。

**证据锚点**：
- `"ab"`：字面量，编译期入池
- `"a" + "b"`：编译期常量折叠
- `new String("ab")`：强制堆上新对象
- `StringBuilder.append`：运行期拼接实现
- `intern()`：运行期字符串池化
- `String#equals`：内容比较（String 重写）
- `final`：编译期常量的必要条件之一
- 字符串常量池：JDK7 后位于堆中
- `==`：引用比较
- 编译期常量：字面量 / final 常量表达式

**对比与权衡**：

| 表达式 | 编译期折叠 | 是否常量池 | `a == b` |
|---|---|---|---|
| `"ab"` | — | 是 | 基准 |
| `"a" + "b"` | 是 | 是 | true |
| `s1 + "b"`（s1 变量） | 否 | 否（堆） | false |
| `new String("ab")` | 否 | 否（堆） | false |
| `"a" + "b"`（final 变量） | 是 | 是 | true |

**常见误区**：
1. 错误：""a"+"b" 会 new 新字符串，所以 `==` false" → 正确：字面量拼接是**编译期常量折叠**，指向常量池同一条目 → true → 为什么：折叠在编译阶段完成，不产生运行期对象。
2. 错误："只要有一个变量参与拼接就是编译期常量" → 正确：必须是 **final + 编译期常量**（字面量/常量表达式）才折叠；非 final 变量 → 运行期拼接 → false → 为什么：运行期变量值编译期未知，无法折叠。
3. 错误："`==` 和 `equals` 都能比较字符串内容" → 正确：`==` 比较引用，`equals` 比较内容 → 为什么：String 重写了 `equals` 为内容比较，`==` 仍是引用比较。
4. 错误："`intern()` 没有意义" → 正确：`intern()` 把运行期字符串放入常量池并返回池内引用，可池化复用 → 为什么：用于运行期动态字符串的复用，但需注意常量池内存。

**适用边界**：
- **适合**：字面量/final 编译期常量拼接 → 常量折叠，可 `==` 判断；需要内容判断 → `equals`。
- **不适合**：运行期变量拼接 → 折叠失效，`==` 不可靠；需池化运行期字符串 → `intern`（注意池内存）。
- **替代方案**：内容比较统一用 `equals`/`Objects.equals`；循环拼接用显式 `StringBuilder`。

### 延伸追问（≥3）

1. **常量折叠的条件是什么？**
- 要点：两个操作数都是编译期常量（字面量 / `final` 常量表达式）
- 追问落点：`static final` 与普通 `final` 在折叠上的区别

2. **`intern()` 做了什么？**
- 要点：查池中有无，有则返回池内引用，无则入池并返回
- 追问落点：JDK6 常量池在永久代 vs JDK7 后移入堆的影响

3. **`StringBuilder` 与 `+` 的关系？**
- 要点：编译期 `+` 拼接被转为 `StringBuilder.append` 链
- 追问落点：循环内拼接为何建议显式 `StringBuilder` 避免反复创建

4. **为什么判字符串用 `equals` 不用 `==`？**
- 要点：`==` 比较引用，`equals` 比较内容；`Objects.equals` 空安全
- 追问落点：`String` 的 `equals` 实现（先 `==` 快路径再逐字符）

### 面试者参考回答

**【结论】** `a == b` 为 true——`"a"+"b"` 是编译期常量折叠，与 `"ab"` 指向同一个字符串常量池条目；`==` 比较的是引用。

**【三点】**
第一，字面量入池：`"ab"` 编译期进入字符串常量池，`a` 指向该条目。
第二，常量折叠：`"a"+"b"` 两个操作数都是字面量，编译期折叠成 `"ab"`，`b` 也指向同一池条目，所以 `==` 为 true。
第三，何时为 false：一旦换成运行期变量拼接（`s1 + "b"`）或 `new String("ab")`，就生成堆上新对象，`==` 为 false、`equals` 为 true。

**【边界】** `==` 只比较引用，比内容必须 `equals`；常量折叠仅限字面量/final 编译期常量，运行期拼接不折叠；需要复用运行期字符串用 `intern()`。

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：Redisson 用 Redis 的 **Hash 结构 + Lua 脚本**实现可重入分布式锁；`getLock(key)` 拿锁对象，`lock()`（看门狗自动续期）或 `tryLock(waitTime, leaseTime)` 拿锁，`unlock()` 校验持有者后释放。
> 关键词：Lua 原子 · Hash 可重入 · 看门狗续期
> 边界：锁需设过期防宕机死锁；看门狗只在**未指定 leaseTime** 时启用；单节点有单点故障需 RedLock。

### L2 · 核心讲解

**核心考点定位**：考察 Redisson 分布式锁的**底层机制**（Lua 原子性、可重入、看门狗续期、解锁校验持有者），而非仅背 API；面试官想看到"为什么这样写才安全"。

**机制链（≥3 环）**：
1. `getLock(key)` → 返回 `RLock` 对象，绑定 Redis key（内部为 Hash）→ 加锁/解锁都走 **Lua 脚本**保证原子。
2. `lock()` → Lua 脚本 `SETNX` + `PEXPIRE`，拿不到则**订阅解锁通知**阻塞等待 → 拿到锁后启动**看门狗**定时续期（默认 30s，每 1/3 续期）。
3. 可重入 → Hash 的 **field=线程 id、value=重入计数** → 同一线程重入计数加一；释放减一，减到 0 才真正删除 key。
4. `unlock()` → Lua **校验持有者**（field=当前线程 id）再删除 → 防误删他人锁；删除后发布解锁通知唤醒等待线程。

**证据锚点**：
- `RedissonClient.getLock(key)`：获取锁对象
- `RLock.lock()`：阻塞拿锁（看门狗续期）
- `tryLock(waitTime, leaseTime)`：带等待/租约拿锁
- `PEXPIRE`：设置锁过期毫秒
- `SETNX`：不存在才设置
- `Lua` 脚本：原子执行判断+加锁/解锁
- Hash `field=threadId`：可重入计数键
- `unlock()`：校验持有者后释放
- `lockWatchdogTimeout`：看门狗默认 30s
- `leaseTime`：显式租约（设了则停看门狗）
- 发布/订阅：解锁通知唤醒等待者
- RedLock：多节点多数派容错

**对比与权衡**：

| 方式 | 原子性 | 可重入 | 自动续期 | 释放安全 |
|---|---|---|---|---|
| `SETNX`+`EXPIRE` 两步 | 需 Lua 合成 | 否 | 否 | 需校验 |
| Redisson `RLock` | Lua 原子 | 是（Hash 计数） | 看门狗 | 校验持有者 |
| 单条 `SET` 命令 | 原子 | 否 | 否 | 易误删 |

**常见误区**：
1. 错误："SETNX 后单独 EXPIRE 就安全" → 正确：`SETNX` 与 `EXPIRE` 需合成一条原子命令或用 Lua，否则设置过期前进程崩溃会死锁 → 为什么：两步非原子，中间宕机导致锁永不过期。
2. 错误："unlock 直接 DEL key 就行" → 正确：必须校验 value=线程 id 再删，否则可能误删他人锁 → 为什么：锁超时后他人拿到锁，旧持有者 DEL 会误删新锁。
3. 错误："看门狗一直续期，锁永不释放" → 正确：看门狗只在持锁线程存活时续期，`unlock` 或线程死亡即停 → 为什么：续期与持锁生命周期绑定。
4. 错误："leaseTime 越短越好" → 正确：过短业务未完成锁被释放；不设则看门狗续期，设了则到期强制释放 → 为什么：过期时间要与业务执行时长匹配。

**适用边界**：
- **适合**：需要可重入、防误删、自动续期的分布式互斥（秒杀、防重复提交）。
- **不适合**：单 Redis 节点单点故障场景；强一致要求超出单节点能力。
- **替代方案**：RedLock 多节点容错；`SET key val NX PX` 原生简单锁（无续期/可重入）。

### 延伸追问（≥3）

1. **为什么用 Lua 脚本？**
- 要点：保证"判断 + 加锁/解锁"原子，避免竞态
- 追问落点：与 `SETNX`+`EXPIRE` 两步的非原子竞态对比

2. **看门狗如何续期？**
- 要点：默认 30s（`lockWatchdogTimeout`），每 1/3（约 10s）续期
- 追问落点：续期失败 / 线程死亡的边界，是否可能释放他人锁

3. **可重入怎么实现？**
- 要点：Hash field=线程 id、value=重入计数，释放减到 0 才删
- 追问落点：与 `ReentrantLock` 的可重入语义类比

4. **锁超时误删如何防？**
- 要点：解锁 Lua 校验持有者再删除
- 追问落点：RedLock 多节点多数派如何降低误删/脑裂风险

### 面试者参考回答

**【结论】** Redisson 用 Redis 的 Hash + Lua 脚本实现可重入分布式锁；`getLock(key)` 拿锁，`lock()` 看门狗自动续期，`unlock()` 校验持有者后释放。

**【三点】**
第一，原子加锁：Lua 脚本 `SETNX` + `PEXPIRE` 原子执行；可重入用 Hash 的 field=线程 id、value=重入计数。
第二，自动续期：`lock()` 不设 leaseTime 时启动看门狗，默认 30s 每 1/3 续期，避免业务未完成锁过期。
第三，安全释放：`unlock()` 用 Lua 校验 value=当前线程 id 再删除，防误删他人锁；释放后发布通知唤醒等待线程。

**【边界】** 锁依赖 Redis 可用，需降级策略；单节点有单点故障用 RedLock；设置 leaseTime 则看门狗停用，需与业务执行时长匹配。

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：缓存一致性本质是"数据更新后缓存未同步"的中间态，方案按一致性强度递进——**TTL 兜底最终一致 → Cache Aside 删缓存 → 延迟双删 → binlog 订阅删除 → 读后回填**。
> 关键词：Cache Aside · 延迟双删 · binlog 订阅
> 边界：强一致需写库后失效并控制并发读写顺序；"删缓存"比"更新缓存"更稳。

### L2 · 核心讲解

**核心考点定位**：考察缓存一致性问题的**根因**（更新顺序 + 并发读写竞态）与多级方案取舍；面试官想看到"先分析不一致怎么产生，再给方案"，而非只背"先更库再删缓存"。

**机制链（≥3 环）**：
1. 写库 + 缓存更新 → 两个独立动作**非原子** → 任一顺序都可能产生不一致中间态 → 本质是"写库与写缓存的竞态"。
2. Cache Aside：写库成功后**删缓存** → 下次读未命中再回填 → 比更新缓存少写放大，且避免覆盖新值。
3. 删缓存后、回填前被并发读写入旧值 → 用**延迟双删**：删缓存 → 等写库完成后再隔一个延迟（如 `500ms`）删一次 → 旧值回填在第二次删除时被清掉。
4. 复杂/强依赖场景 → **订阅 binlog**（Canal）监听 DB 变更 → 解析后触发缓存删除/更新 → 解耦、可靠、可重试。

**证据锚点**：
- `Cache Aside`：读未命中回填、写后删缓存
- `TTL`：兜底最终一致
- 延迟双删：删 → 等窗口 → 再删
- `500ms`：常见延迟窗口量级
- `binlog`：DB 变更日志
- `Canal`：MySQL binlog 订阅组件
- 读后回填：写时同步更新缓存（接近强一致）
- `cache-aside` / `read-through` / `write-through` / `write-back`：四种缓存模式
- 缓存击穿 / 穿透 / 雪崩：读侧可用性问题
- `Redis`：缓存存储
- `MYSQL`：数据源（主从延迟影响一致性窗口）

**对比与权衡**：

| 方案 | 一致性 | 复杂度 | 实时性 | 适用 |
|---|---|---|---|---|
| TTL 兜底 | 最终一致 | 低 | 有延迟 | 可容忍不一致 |
| Cache Aside 删缓存 | 最终一致 | 低 | 高 | 常规 |
| 延迟双删 | 最终一致（更强） | 中 | 高 | 高并发写 |
| binlog 订阅 | 最终一致（可靠） | 高 | 高 | 复杂/强依赖 |
| 读后回填 | 接近强一致 | 中 | 高 | 写少读多 |

**常见误区**：
1. 错误："更新缓存比删除缓存好" → 正确：写后删缓存更稳，避免并发写覆盖新值 → 为什么：更新缓存要保证顺序，删除让下次读重建。
2. 错误："先删缓存再更库" → 正确：先更库再删缓存（或延迟双删），先删后更库会让并发读回填旧值 → 为什么：删后更库前被读回填旧值，且旧值可能长期存在。
3. 错误："加 TTL 就绝对一致" → 正确：TTL 只保证最终一致，TTL 窗口内仍不一致 → 为什么：过期前读到的是旧值。
4. 错误："延迟双删的延迟随便设" → 正确：延迟要大于写库耗时 + 读回填耗时，否则第二次删除覆盖不了回填 → 为什么：窗口估算错误导致旧值残留。

**适用边界**：
- **适合**：可容忍最终一致的读多写少场景；高并发写用延迟双删；强依赖用 binlog 订阅。
- **不适合**：强一致业务（支付/库存）缓存很难做到，需串行化读写 + 兜底。
- **替代方案**：读后回填（写时同步更新）；binlog 订阅有解析延迟与运维成本，需权衡；写多读多时用消息队列异步失效并做幂等补偿。

### 延伸追问（≥3）

1. **为什么"先更库再删缓存"仍可能不一致？**
- 要点：删缓存与更库之间有读回填窗口，用延迟双删兜底
- 追问落点：延迟窗口怎么估算（写库耗时 + 读回填耗时）

2. **延迟双删的第二次删除失败怎么办？**
- 要点：异步重试 + 补偿，或用 binlog 兜底
- 追问落点：与消息队列/事件溯源的对比

3. **binlog 订阅（Canal）方案的成本？**
- 要点：解析延迟、部署运维、重复消费需幂等
- 追问落点：与 TTL/删除方案的粒度差异

4. **缓存击穿/穿透/雪崩与一致性什么关系？**
- 要点：是"读侧"可用性问题，与"写侧"一致性是不同维度
- 追问落点：热点 key 过期瞬间的击穿治理

### 面试者参考回答

**【结论】** 缓存一致性本质是写库与写缓存的竞态，方案按一致性强度递进：TTL 兜底 → Cache Aside 删缓存 → 延迟双删 → binlog 订阅；写侧用"删缓存"比"更新缓存"更稳。

**【三点】**
第一，根因与兜底：写库与缓存更新非原子，先接受最终一致，TTL 保证最终收敛。
第二，删除策略：写库后删缓存（Cache Aside），下次读重建；高并发下用延迟双删（删 → 等写库+读回填窗口 → 再删）覆盖旧值回填。
第三，可靠一致：复杂场景订阅 binlog（Canal）监听变更触发删除，解耦可重试；要求强一致则读后回填 + 控制读写顺序。

**【边界】** 强一致缓存需串行化读写，代价高；TTL/删除只给最终一致；binlog 有解析延迟与运维成本，需权衡后选型；延迟双删的延迟窗口要覆盖"写库 + 读回填"耗时，估算偏小会导致旧值残留。

> 最后更新：2026-11-01 · 基于第 2 次作答

### L1 · 30 秒速记
> 结论：OOM 本质是 JVM 认为无法通过 GC 解决内存不足，抛 `java.lang.OutOfMemoryError`；按空间分 8 类（堆/元空间/直接内存/GC overhead/线程/数组/压缩类空间/协程）。
> 关键词：Java heap space · Metaspace · Direct buffer memory · HeapDumpOnOutOfMemoryError
> 边界：OOM 不必然立即退出；排查三件套 = 堆 dump + GC 日志 + 原生内存追踪。

### L2 · 核心讲解

**核心考点定位**：考察 OOM 的**分类完整性** + **每类触发场景** + **监控/解决手段**；面试官想看到"类型 → 根因 → 手段"矩阵，而非只报一个"堆溢出"。

**机制链（≥3 环）**：
1. 堆满且 GC 无法回收 → 抛 `Java heap space` → 典型根因：静态集合无界增长、缓存无 TTL、大对象一次性加载、监听器未反注册、ThreadLocal 未 remove。
2. GC 时间 >98% 但回收 <2% → 抛 `GC overhead limit exceeded` → 是堆溢出的前兆，多因内存泄漏后期。
3. 类元数据占满方法区 → `Metaspace` → 根因：CGLIB/ByteBuddy 动态代理、Groovy/JS 脚本反复编译、热部署反复创建 ClassLoader。
4. 直接内存超 `-XX:MaxDirectMemorySize` → `Direct buffer memory` → 根因：Netty `ByteBuf` 未 `release`、`FileChannel.map` 未 `unmap`。
5. 线程创建失败 → `unable to create new native thread` → 根因：Thread 未复用、线程池无上限、ThreadLocal 泄漏导致线程膨胀。

**证据锚点**：
- `Java heap space`：堆溢出（最常见）
- `Metaspace`：元空间溢出（JDK 8+）
- `Direct buffer memory`：直接内存溢出
- `GC overhead limit exceeded`：GC >98% 回收 <2%
- `unable to create new native thread`：线程过多
- `-XX:+HeapDumpOnOutOfMemoryError`：OOM 自动 dump（救命参数）
- `-XX:HeapDumpPath`：dump 路径
- `-XX:MaxDirectMemorySize`：直接内存上限
- `-XX:MaxMetaspaceSize`：元空间上限
- `jstat -gcutil <pid> 1000`：GC 频率与堆使用
- `jcmd <pid> VM.native_memory summary`：NMT 原生内存
- `jmap -histo:live <pid>`：对象直方图
- `MAT`：Dominator Tree / Leak Suspects
- `ByteBuf.refCnt`：Netty 引用计数检查

**对比与权衡**：

| 类型 | 根因 | 短期处置 | 长期解决 |
|---|---|---|---|
| Java heap space | 泄漏 / 大对象 | 扩堆 + 重启 | 修泄漏、缓存加 TTL |
| Metaspace | ClassLoader 泄漏 | 调大 `MaxMetaspaceSize` | 排 ClassLoader 泄漏 |
| Direct buffer memory | ByteBuf 未释放 | 重启 | 显式 `release`、Cleaner |
| GC overhead | 泄漏后期 | 换 GC 器 | 修泄漏 |
| unable to create thread | 线程过多 | 扩容 | 线程池化、ThreadLocal 管理 |

**常见误区**：
1. 错误："OOM 只有堆溢出" → 正确：OOM 分 8 类，堆/元空间/直接内存/GC overhead/线程/数组/压缩类空间/协程 → 为什么：各空间独立满溢。
2. 错误："OOM 后 JVM 立即退出" → 正确：OOM 抛 `Error`，JVM 不一定立即退出（除非 `-XX:+ExitOnOutOfMemoryError`）→ 为什么：默认先尝试 GC 后再分配，失败才抛。
3. 错误："直接内存算在堆里" → 正确：直接内存（`DirectByteBuffer`）不在堆，受 `-XX:MaxDirectMemorySize` 限制，堆可能没满 → 为什么：NIO/Netty 泄漏时堆正常但进程挂。
4. 错误："加 `-Xmx` 就能解决所有 OOM" → 正确：`-Xmx` 只解决堆；Metaspace/直接内存/线程各自有独立参数 → 为什么：不同空间独立治理。

**适用边界**：
- **适合**：需 `-XX:+HeapDumpOnOutOfMemoryError` 保证 dump；区分泄漏（FullGC 后堆使用率不降）vs 抖动（短暂峰值）。
- **不适合**：`-Xmx` 只治堆；DirectBuffer/线程需各自参数与治理。
- **替代方案**：`kill -15` 而非 `-9` 保 dump；JDK 9+ 用 Cleaner 处理 DirectByteBuffer；Java 21+ Loom 协程 OOM 为新类型。

### 延伸追问（≥3）

1. **Java heap space 与 GC overhead 什么关系？**
- 要点：GC overhead 是堆溢出的前兆——GC 努力回收但效果差
- 追问落点：为何先出现 GC overhead 再堆溢出

2. **怎么判断内存泄漏还是正常使用？**
- 要点：多次 FullGC 后堆使用率仍不降 = 泄漏；MAT Dominator Tree 找最大存活持有者
- 追问落点：Shortest Path to GC Roots 看是否被不该引用的强引用持有

3. **Metaspace 泄漏如何定位？**
- 要点：`jcmd <pid> GC.class_histogram` 看 ClassLoader 数量；查热部署/脚本引擎/反射动态代理
- 追问落点：`VM.classloader_stats` 事件与 JFR 分析

4. **DirectByteBuffer 泄漏怎么查？**
- 要点：JDK 9+ Cleaner 自动回收、JFR `jdk.DirectByteBuffer` 事件、`VM.native_memory`
- 追问落点：Netty 用 `ByteBuf.refCnt()` / `ReferenceCountUtil.safeRelease`

5. **生产 OOM 应急 SOP？**
- 要点：kill 前保证 dump、`kill -15`、MAT 分析、扩堆临时、根因优先修泄漏
- 追问落点：`-XX:+ExitOnOutOfMemoryError` 容器自动重启的取舍

### 面试者参考回答

**【结论】** OOM 本质是 JVM 认为无法通过 GC 解决内存不足，抛 `java.lang.OutOfMemoryError`；按空间分 8 类，排查三件套是堆 dump + GC 日志 + 原生内存追踪。

**【三点】**
第一，分类与根因：堆溢出=泄漏/大对象；Metaspace=ClassLoader 泄漏（动态代理/脚本/热部署）；Direct buffer=ByteBuf 未释放；GC overhead=泄漏后期；线程过多=线程池无上限。
第二，监控与救命参数：`-XX:+HeapDumpOnOutOfMemoryError` 自动 dump；`jstat -gcutil` 看 GC、`jcmd VM.native_memory` 看原生内存、`jmap -histo:live` 看对象；MAT 看 Dominator Tree/Leak Suspects。
第三，解决矩阵：堆=扩堆+修泄漏；Metaspace=调 `MaxMetaspaceSize`+排 ClassLoader；DirectBuffer=显式 release+Cleaner；线程=线程池化+ThreadLocal 管理。

**【边界】** OOM 不必然立即退出，`kill -15` 保 dump；区分泄漏（FullGC 后不降）vs 抖动（短暂峰值）；不同空间独立治理，`-Xmx` 只治堆，直接内存/元空间各有参数。

> 最后更新：2026-11-01 · 基于第 2 次作答

### L1 · 30 秒速记
> 结论：RR 防幻读**双机制**——**快照读**（普通 SELECT）靠 MVCC（首次读建 ReadView 复用），**当前读**（SELECT FOR UPDATE/UPDATE/DELETE）靠 Next-Key Lock（Record Lock + Gap Lock）；InnoDB 并不 100% 防幻读。
> 关键词：MVCC ReadView · Next-Key Lock · 快照读/当前读
> 边界：混用快照读与当前读可见"看似幻读"；RC 只加 Record Lock 不防间隙插入。

### L2 · 核心讲解

**核心考点定位**：考察能否讲清 RR 下"快照读靠 MVCC、当前读靠 Next-Key Lock"双机制，并识别"InnoDB 不 100% 防幻读"的边界；面试官想看到两条路径 + 边界反例。

**机制链（≥3 环）**：
1. 幻读定义：两次相同查询**行数不同**（看到新插入/消失的行）；≠ 脏读 ≠ 不可重复读。
2. 快照读（普通 SELECT）→ 首次一致性读创建 ReadView（`m_ids`/`min_trx_id`/`max_trx_id`/`creator_trx_id`）→ RR 复用该 ReadView → 其他事务 INSERT/UPDATE/DELETE 均不可见 → 快照读路径无幻读。
3. 当前读（SELECT FOR UPDATE/UPDATE/DELETE）→ 加 Next-Key Lock（Record Lock + Gap Lock）→ 锁索引记录 + 记录间间隙 → 其他事务无法在间隙内插入。
4. 锁范围陷阱/混用 → 快照读看不到新插入、当前读看到已提交插入 → 事务内混用可见"看似幻读" → 官方承认非 100%。
5. RC vs RR → RC 每次快照读新建 ReadView、只加 Record Lock（不防间隙插入）；RR 首次读复用 ReadView、加 Next-Key Lock → 隔离级别决定防幻读强度。

**证据锚点**：
- `ReadView`：快照读的可见性快照
- `m_ids`：活跃事务列表
- `min_trx_id` / `max_trx_id`：可见性边界
- `creator_trx_id`：本事务 id
- `Next-Key Lock`：Record + Gap 组合
- `Record Lock`：锁索引记录
- `Gap Lock`：锁索引间隙（不含记录）
- `Insert Intention Lock`：insert 前的特殊 gap
- `SELECT ... FOR UPDATE`：当前读加锁
- `trx_id` / `roll_pointer`：隐藏列
- `undo log`：版本链
- `SERIALIZABLE`：完全防幻读（全读加 S 锁）
- `RC`：每次新建 ReadView、只加 Record Lock
- `RR`：首次读复用 ReadView、加 Next-Key Lock

**对比与权衡**：

| 维度 | 快照读 | 当前读 |
|---|---|---|
| 语句 | 普通 SELECT | SELECT FOR UPDATE / UPDATE / DELETE |
| 防幻读机制 | MVCC ReadView | Next-Key Lock |
| ReadView | RR 首次读后复用 | 无（读最新已提交） |
| 可见性 | 首次读时刻快照 | 最新已提交 |
| 防幻读 | 完全无幻读 | 大部分防（有边界） |

**常见误区**：
1. 错误："RR 完全防幻读" → 正确：官方不保证 100%，混用快照/当前读有边界 → 为什么：当前读读最新已提交，能看到间隙内新插入。
2. 错误："MVCC 是 RR 唯一手段" → 正确：MVCC 只是快照读手段，当前读靠 Next-Key Lock → 为什么：两条路径，机制不同。
3. 错误："RR 靠行锁防幻读" → 正确：靠的是 Next-Key Lock（含间隙锁），行锁只锁记录 → 为什么：间隙锁才挡插入。
4. 错误："RC 也能防幻读" → 正确：RC 只加 Record Lock 不加 Gap Lock，间隙可插入 → 为什么：RC 不防幻读。
5. 错误："快照读与当前读防幻读效果一样" → 正确：快照读（MVCC）完全无幻读，当前读（Next-Key Lock）大部分防、有边界 → 为什么：当前读读最新已提交，能跨过快照看到已提交插入。

**适用边界**：
- **适合**：读多写少、需防幻读 → RR；写多、有间隙锁性能顾虑 → RC。
- **不适合**：要 100% 防幻读 → SERIALIZABLE（全读加 S 锁、串行化，业务难接受）。
- **替代方案**：Spring 默认 RC、MySQL 默认 RR；按业务权衡，接受 RR"大部分防"折中；高频插入场景注意 Gap Lock 阻塞范围；对账/统计类只读事务用 RR 快照读最省锁。

### 延伸追问（≥3）

1. **RC 与 RR 在锁行为上的差异？**
- 要点：ReadView 创建时机（RC 每次新建、RR 首次复用）；RC 只加 Record Lock、RR 加 Next-Key Lock
- 追问落点：生产选 RC 还是 RR 的依据

2. **RR 下"看到自己提交后又看到别的行"是什么情况？**
- 要点：事务内混用快照读与当前读；当前读读最新已提交
- 追问落点：为何不是 MVCC 的锅

3. **如何验证 RR 是否真防幻读？**
- 要点：会话 A `FOR UPDATE` 锁间隙、会话 B INSERT 被阻塞；A 再当前读才看到
- 追问落点：改成快照读则始终看不到

4. **何时选 RC 还是 RR？**
- 要点：读多写少防幻读选 RR；写多、间隙锁性能顾虑选 RC
- 追问落点：SERIALIZABLE 全读加 S 锁的代价

### 面试者参考回答

**【结论】** InnoDB 在 RR 下用双机制防幻读：快照读（普通 SELECT）靠 MVCC，当前读（SELECT FOR UPDATE/UPDATE/DELETE）靠 Next-Key Lock；但不 100% 防。

**【三点】**
第一，快照读靠 MVCC：普通 SELECT 首次读创建 ReadView（m_ids/min/max/creator_trx_id），RR 首次读后复用，读到首次读时刻快照，其他事务的增删改都不可见，快照读路径无幻读。
第二，当前读靠 Next-Key Lock：SELECT FOR UPDATE/UPDATE/DELETE 加 Next-Key Lock（Record Lock + Gap Lock），锁记录+间隙，其他事务无法在间隙内插入；RC 只加 Record Lock 不防间隙插入。
第三，边界与选型：混用快照读与当前读时，当前读看到间隙内已提交插入，看似幻读；官方不保证 100%。RC 每次新建 ReadView 只加 Record Lock（不防），RR 大部分防（有边界），SERIALIZABLE 完全防但全读加 S 锁代价高。

**【边界】** 工程上接受 RR"大部分防"折中；要 100% 只能 SERIALIZABLE（串行化，业务难接受）；生产 Spring 默认 RC、MySQL 默认 RR，按读多写少/间隙锁性能权衡。

> 最后更新：2026-11-01 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：用**观察者模式**——天气数据作为 Subject，通知服务与行程推荐服务作为 Observer，天气变化时统一通知所有订阅者；推荐算法再用**策略模式**按用户/场景选择。
> 关键词：Observer 解耦 · Subject/Observer · Strategy 选策略
> 边界：观察者适合"一对多、事件驱动"；若仅单一固定反应或需强顺序强一致，观察者可能过度设计。

### L2 · 核心讲解

**核心考点定位**：考察"事件驱动的一对多通知"选型与"算法可替换"的组合能力；面试官想看到解耦收益与失败路径，而非只背模式名。

**机制链（≥3 环）**：
1. 天气数据变化（Subject）→ 调用 `notifyObservers()` 遍历注册的 Observer → 各 Observer 的 `update()` 被触发 → 通知与推荐解耦。
2. 观察者在运行期**动态注册/注销** → 新增通知渠道（短信/推送/行程推荐）**不改**天气数据类 → 符合开闭原则。
3. 推荐行程算法多变 → 用**策略模式**：推荐算法抽象为策略接口，运行期按用户偏好/天气场景切换 → 避免 if-else 分支爆炸。
4. 观察者回调失败 → 需**异常隔离**（逐 Observer try-catch）+ 重试/降级 → 防止单个观察者失败影响整条通知链路。
5. 通知链路变长/跨服务 → 从观察者演进到**事件总线/消息队列** → 异步削峰、可靠投递、失败可重试 → 代价是引入中间件与最终一致。

**证据锚点**：
- `Observer`：观察者接口（`update()`）
- `Subject`：被观察者（注册表）
- `notifyObservers`：统一通知入口
- `registerObserver` / `unregisterObserver`：运行期订阅管理
- `Strategy`：算法族抽象接口
- `Context`：持策略引用、运行时切换
- 推模型 / 拉模型：数据传递方式
- 开闭原则：对扩展开放、对修改关闭
- 事件驱动：变化触发、被动响应
- 发布/订阅：解耦的事件模型
- 回调异常隔离：逐 Observer try-catch
- 重试 / 降级：失败兜底
- `Kafka` / 消息队列：跨服务异步解耦
- 死信队列：重试失败的最终兜底
- `@EventListener`：Spring 事件监听（观察者落地）
- `ApplicationEventPublisher`：Spring 事件发布入口

**对比与权衡**：

| 方案 | 耦合 | 扩展性 | 失败隔离 | 适用 |
|---|---|---|---|---|
| 直接 if-else 通知 | 高 | 差 | 无 | 少渠道、固定 |
| 观察者模式 | 低 | 好（动态增删） | 需逐 Observer 隔离 | 一对多事件 |
| 事件总线 / 发布订阅 | 低 | 好（异步） | 好（消息队列） | 跨服务、异步 |
| 策略模式（推荐算法） | 低 | 好 | 无 | 算法可替换 |

**常见误区**：
1. 错误："观察者就是回调函数" → 正确：观察者是**订阅集合**，回调只是实现细节；核心是"一对多、运行期动态订阅" → 为什么：回调是单点，观察者是多点注册。
2. 错误："观察者能保证通知顺序" → 正确：观察者默认不保证顺序（尤其异步），需强顺序要显式串行化 → 为什么：遍历顺序 + 异步回调打破顺序。
3. 错误："观察者回调失败要整条中断" → 正确：应**逐 Observer 隔离异常** + 重试/降级，防单点拖垮通知 → 为什么：一个观察者抛异常会中断后续通知。
4. 错误："策略模式用于任何分支" → 正确：策略适合"算法族可替换"，分支少/固定用 if-else 更简单 → 为什么：过度抽象增加类数量与理解成本。
5. 错误："观察者里塞策略就完事" → 正确：观察者解决"通知谁"、策略解决"怎么推荐"，两者职责不同，应组合而非混用 → 为什么：混用会让被观察者反向依赖具体推荐算法，破坏解耦。
6. 错误："观察者只适合单机" → 正确：进程内观察者单机；跨服务可用事件总线/消息队列实现分布式观察者语义 → 为什么：网络分区、可靠投递需要中间件承载。

**适用边界**：
- **适合**：事件源一对多、订阅者动态增删（通知/推荐/监控）。
- **不适合**：仅单一固定反应；需强一致/强顺序（需显式串行化或事件总线）。
- **替代方案**：事件总线（异步、跨服务）；消息队列（可靠投递、重试、死信兜底）；模板方法（骨架固定、步骤可变）；Spring 的 `ApplicationEventPublisher`/`@EventListener` 是观察者模式的框架化落地，跨服务再升级到消息队列。

### 延伸追问（≥3）

1. **观察者与事件总线区别？**
- 要点：观察者进程内同步、事件总线可异步/跨服务
- 追问落点：何时上消息队列（可靠性、异步削峰）

2. **推模型与拉模型？**
- 要点：推=Subject 传数据，拉=Observer 自行拉取
- 追问落点：各自解耦程度与空数据传递

3. **观察者回调异常怎么隔离？**
- 要点：逐 Observer try-catch + 重试/降级
- 追问落点：与消息队列重试/死信队列的对比

4. **策略模式与模板方法区别？**
- 要点：策略=算法整体可替换（组合）；模板=骨架固定、步骤可变（继承）
- 追问落点：何时用组合而非继承

### 面试者参考回答

**【结论】** 用观察者模式：天气数据作为被观察者，通知服务与推荐行程作为观察者，天气变化时统一通知；推荐算法再用策略模式按用户/场景选择。

**【三点】**
第一，观察者解耦：天气数据类不依赖具体通知渠道，新增渠道只需注册观察者，符合开闭原则。
第二，策略选算法：推荐行程算法抽象为策略接口，运行期按用户偏好/天气场景切换，避免 if-else 分支爆炸。
第三，失败隔离：逐观察者 try-catch + 重试/降级，防止单个通知失败拖垮整条链路；通知渠道在运行期动态增删，新增不改天气数据类。

**【边界】** 观察者适合"一对多、动态订阅"；若仅单一固定反应或需强顺序强一致，观察者可能过度设计，可改用事件总线/显式串行化；策略模式不要为少量固定分支过度抽象；链路跨服务、需可靠投递时升级到消息队列，代价是引入中间件与最终一致。