2026-10-30

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

### L1 · 30 秒速记

> 结论：Redis 的 5 种核心类型是 String/Hash/List/Set/Zset，面试要"表面用途 + 底层结构"两层答。
> 关键词：SDS · quicklist · skiplist · 整数数组 · ziplist
> 边界：衍生类型 Geo/Bitmap/HyperLogLog 是在 String 之上封装，不是独立底层结构。

### L2 · 核心讲解

**核心考点定位**：Redis 类型题，面试官真正想听的是"这个类型为什么快 + 底层怎么存"，而不是单纯背用途清单。

**机制链（≥3 环）**：
1. 表面分类 → 每种类型有独立 API，用途区分：String 最通用、Hash 存对象、List 队列、Set 去重、Zset 排行。
2. 底层结构 → Redis 为省内存做了**多编码优化**：Hash/List/Set 小数据时用 ziplist/intset 紧凑结构，超阈值升级 hashtable/quicklist。
3. 为什么快 → 内存存储 + O(1) 哈希 + 紧凑编码减少内存碎片，单线程避免锁竞争。

**证据锚点**：
- `SDS`：String 的底层，C 字符串的 O(N) 求长升级为 O(1)，且二进制安全。
- `quicklist`：List 底层 = 双向链表 + ziplist 节点，兼顾两端 O(1) 操作与内存紧凑。
- `skiplist`：Zset 底层之一，跳表实现有序，查询/插入 O(log N)，与哈希表配合存成员→分值。
- `intset`：Set 全整数且量小时用整数数组，查找二分。

**对比与权衡**：

| 类型 | 底层（小→大） | 典型场景 | 关键 API |
|---|---|---|---|
| String | SDS | 缓存、计数器、分布式锁 | SET/GET/INCR |
| Hash | ziplist → hashtable | 对象字段存储 | HGETALL/HSET |
| List | quicklist | 队列/栈、消息流 | LPUSH/RPOP/LRANGE |
| Set | intset → hashtable | 去重、交集/并集 | SADD/SINTER |
| Zset | ziplist → skiplist+dict | 排行榜、Top N | ZADD/ZRANGEBYSCORE |

**常见误区**：
1. 错误：只背 5 种类型名 → 正确：每种类型讲"用途 + 底层结构 + 典型命令" → 为什么：面试官要的是深度。
2. 错误：把 Zset 说成"有序链表" → 正确：skiplist + 哈希表 → 为什么：跳表才是 O(log N) 关键。
3. 错误：认为 Redis 单线程所以所有操作都 O(1) → 正确：ZRANGE 是 O(log N+M)，大 key 会阻塞 → 为什么：单线程下任何慢命令都卡全局。

**适用边界**：如果追问"百万级排行榜"，需进一步讲 skiplist 的 span 字段如何 O(log N) 定位排名，而非简单列举。

### 延伸追问（≥3）

1. **Zset 为什么用跳表而不是红黑树？**
- 要点：跳表实现简单、范围查询友好（ZRANGE 需按序输出）、支持 O(log N) 插入。
- 追问落点：跳表的随机层数与内存代价。
2. **Hash 什么时候从 ziplist 升级为 hashtable？**
- 要点：字段数 >512 或单字段长度 >64 字节时升级，省内存让位给性能。
- 追问落点：编码转换的具体阈值（hash-max-ziplist-entries）。
3. **List 的 quicklist 相比普通链表好在哪？**
- 要点：双向链表 + ziplist 节点，内存紧凑且两端操作 O(1)，中间随机访问仍 O(N)。
- 追问落点：list-max-ziplist-size 控制节点大小。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，Redis 的核心是 5 种基本类型——String、Hash、List、Set、Zset，面试时我习惯"用途 + 底层结构"两层来讲。

**【三点】** 第一，String 是 SDS 实现，能存字符串和数字，支持 SETNX、INCR，常用于缓存、计数器、分布式锁；底层用简单动态字符串，比 C 字符串多了长度字段，求长是 O(1) 且二进制安全。第二，Hash 存对象字段，小数据用 ziplist 紧凑存储，字段多或值大了升级为哈希表；它比 String 序列化整个对象好在能按字段单独读写，适合缓存一个对象的多个属性。第三，List 是 quicklist——双向链表串起多个 ziplist 节点，两端 push/pop 是 O(1)，能当队列和栈；Set 全整数且量小时用 intset 整数数组，去重加交集并集，适合"共同好友"这种场景；Zset 用跳表加哈希表，跳表按分值有序、O(log N) 插入查询，哈希表存成员到分值的映射，所以排行榜、Top N 都靠它，而且跳表实现简单、范围查询天然友好，这是它而不是红黑树的原因。另外衍生类型，比如 Geo 存经纬度、Bitmap 做位图、HyperLogLog 做基数统计，都是在 String 之上封装。

**【边界】** 当然，这些底层编码不是固定的——Hash、List、Set 在数据量小的时候会用 ziplist、intset 这种紧凑结构省内存，一旦超过阈值（比如哈希字段数超 512）就升级为哈希表或 quicklist，所以问"类型"要连着"编码转换"一起答，才显得真正懂 Redis。

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

### L1 · 30 秒速记

> 结论：单例核心是"全局唯一 + 懒加载权衡"，推荐静态内部类 Holder 或枚举。
> 关键词：饿汉 · 懒汉 · 双检锁 · Holder · 枚举
> 边界：Spring 的单例是容器管理的 scope，不是手写单例，别混淆。

### L2 · 核心讲解

**核心考点定位**：单例题面试官看三件事——①几种写法的线程安全性 ②双重校验锁为什么需要 volatile ③反射/序列化如何破坏单例及防御。

**机制链（≥3 环）**：
1. 饿汉式 → 类加载即实例化，线程安全但可能浪费（类加载早于首次使用）。
2. 懒汉式 → 首次访问才创建；同步方法版加锁重、双检锁用 volatile 禁止指令重排。
3. 最优解 → 静态内部类 Holder：类加载时**不实例化**，首次 getInstance 触发初始化，天然线程安全无锁。

**证据锚点**：
- `volatile`：双检锁中禁止 `new` 的"分配→初始化→引用赋值"重排序，防止拿到未初始化对象。
- `双重检查`：外层判 null 避免进入锁，内层判 null 防止重复创建。
- `枚举`：JVM 保证枚举单实例，天然防御反射和序列化，这是 Effective Java 推荐的简洁方案。
- `getInstance`：所有写法统一对外暴露静态方法获取唯一实例，构造器一律 private。
- `类加载`：静态内部类 Holder 由 JVM 类加载机制保证初始化线程安全，无锁懒加载。
- `readResolve`：普通单例重写此方法可防御序列化反序列化产生第二个实例。

**对比与权衡**：

| 写法 | 懒加载 | 线程安全 | 防御反射/序列化 | 评价 |
|---|---|---|---|---|
| 饿汉 | ❌ | ✅ | ❌ | 简单，但可能浪费 |
| 懒汉 synchronized | ✅ | ✅ | ❌ | 每次调用加锁，性能差 |
| 双检锁 | ✅ | ✅ | ❌ | 需 volatile，经典 |
| 静态内部类 | ✅ | ✅ | ❌ | 推荐，无锁懒加载 |
| 枚举 | ✅ | ✅ | ✅ | 最简洁，官方推荐 |

**常见误区**：
1. 错误：双检锁里第二层判 null 是多余的 → 正确：内层判 null 才是防重复创建的关键 → 为什么：外层只防多数线程进锁，内层在锁内重新确认。
2. 错误：认为枚举单例"不能传参"所以不用 → 正确：可通过带参构造或静态工厂传参 → 为什么：需求简单时枚举是首选。
3. 错误：用反射 `setAccessible(true)` 能拿到单例 → 正确：枚举能防，普通类构造器加标志位防御 → 为什么：这是单例被击穿的常见攻击点。

**适用边界**：单例不解决"多次 new 的普通对象"，它保证的是**类级唯一**；Spring 里 @Bean 默认单例但由容器管理生命周期，和手写单例不是一个层面。

### 延伸追问（≥3）

1. **双检锁为什么必须 volatile？**
- 要点：防止 `new Singleton()` 的指令重排（分配内存→初始化→赋引用），否则另一线程可能拿到半初始化对象。
- 追问落点：JMM 的 happens-before 与 volatile 写读语义。
2. **静态内部类为什么线程安全？**
- 要点：类加载阶段由 JVM 加锁保证，Holder 类首次 getInstance 时才初始化，兼顾懒加载。
- 追问落点：类加载的初始化时机（主动引用 vs 被动引用）。
3. **枚举如何防御序列化攻击？**
- 要点：枚举没有构造方法可反射调用，序列化返回单实例；普通类需重写 readResolve。
- 追问落点：Effective Java 第 3 条。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，单例模式核心是保证一个类全局只有一个实例，关键在"懒加载"和"线程安全"这两个维度的权衡。

**【三点】** 第一，饿汉式最简单，类加载就创建实例，天然线程安全，但可能提前占用资源；如果对象创建成本不高、系统启动就要用，直接用饿汉就行，不必炫技。第二，懒汉式延迟到首次访问才创建，但要处理并发——最直接的是加 synchronized，但每次调用都加锁开销大；所以用双重校验锁，先用 volatile 修饰实例变量禁止指令重排，外面判一次 null 避免绝大多数线程进锁，锁内再判一次 null 防止重复创建，两层检查配合才能既懒加载又线程安全。第三，更优雅的是静态内部类 Holder——类加载时不会初始化内部类，首次调用 getInstance 才触发 Holder 初始化，由 JVM 类加载机制保证线程安全，无锁且懒加载，是权衡最优解；如果想最简洁，用枚举，JVM 保证枚举单实例，还天然防御反射和序列化攻击，Effective Java 也推荐。实际开发中我们经常直接饿汉或 Holder，除非对象创建特别昂贵才考虑懒汉。

**【边界】** 当然，单例不是万能——它保证的是类级唯一，解决不了"多次 new"的普通对象问题；而且 Spring 里 @Bean 默认单例是容器管理生命周期，和手写单例不是一个层面，别把两者混淆。另外如果单例持有大量内存或有状态，全局唯一反而可能成为性能瓶颈，这时候要评估是否需要换成多例。

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

### L1 · 30 秒速记

> 结论：登录体系先分清"单机登录 / 单点登录 SSO"，再讲 token 方案与安全细节。
> 关键词：Session → Token · Redis 存储 · SSO · JWT vs CAS · 同账号互踢
> 边界：内部系统常做"单机 + 同账号互踢"，对外多系统才需要真 SSO。

### L2 · 核心讲解

**核心考点定位**：面试官想听的是"你们怎么做的 + 为什么这么做"，重点是 SSO 的判定和 token 的存储/过期/互踢设计。

**机制链（≥3 环）**：
1. 演进 → 早期 Session 存在应用服务器内存，分布部署后不共享，改为**无状态 Token**。
2. 存储 → Token 放 Redis 并与账号绑定，可设置过期时间，支持**同账号互踢**（新 token 覆盖旧）。
3. 安全 → 密码加盐哈希（如 SHA256+盐/BCrypt）防彩虹表，验证码防爆破，登录审计记录 IP/时间。

**证据锚点**：
- `Redis`：存 token 实现分布式会话共享，value 可含用户信息，key 用 token 或 userId。
- `互踢`：同一 userId 只保留最新 token，旧 token 失效（key 覆盖 或 维护 token→userId 反向）。
- `SHA256+盐`：密码不存明文，加随机盐避免相同密码同哈希（防彩虹表）。
- `JWT`：无状态、自包含、跨域方便，但不可主动失效；CAS：集中认证中心，适合多系统统一登录。

**对比与权衡**：

| 方案 | 状态 | 跨域 | 主动失效 | 适用 |
|---|---|---|---|---|
| Session | 服务端有状态 | 需粘性/共享存储 | ✅ | 单应用 |
| Redis Token | 服务端有状态 | ✅ | ✅ | 分布式、可互踢 |
| JWT | 无状态 | ✅ | ❌（靠短过期） | 跨域、高并发 |
| CAS | 集中 | ✅ | ✅ | 多系统统一 SSO |

**常见误区**：
1. 错误：把"单机登录"说成"单点登录" → 正确：单机=一个应用内唯一会话，SSO=一次登录多系统复用 → 为什么：概念不同，SSO 强调跨系统。
2. 错误：token 只放内存 → 正确：放 Redis/共享存储才能分布式失效 → 为什么：多实例下内存无法共享。
3. 错误：密码直接 MD5 → 正确：加盐哈希（BCrypt 自带盐）→ 为什么：MD5 无盐易被彩虹表破解。

**适用边界**：如果系统只有一个应用且无跨域需求，Redis token 即可；多系统（如 ERP 下多个子系统）才升级 CAS/JWT SSO。

### 延伸追问（≥3）

1. **同账号互踢怎么实现？**
- 要点：登录时以 userId 为 key 覆盖旧 token（或删除旧 token 再写新），旧会话下次校验即失败。
- 追问落点：如何防止 token 泄漏后的重放（绑定 IP/UA、短过期）。
2. **Token 放 Redis 和 JWT 怎么选？**
- 要点：Redis 可主动失效、可互踢；JWT 无状态、跨域方便但难吊销。
- 追问落点：JWT 过期策略、refresh token 双 token。
3. **密码存储为什么必须加盐？**
- 要点：加盐让相同密码产生不同哈希，防彩虹表；BCrypt 自动生成盐并抗暴力。
- 追问落点：加盐时机、盐的存储位置（随哈希一起存）。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，我们 ERP 系统用的是**单机登录**，不是单点登录——它保证一个账号同一时间只有一个会话，用 Redis 存 token 实现。

**【三点】** 第一，我们最初用 Session，后来分布式部署后 Session 无法跨实例共享，就换成 Token 方案：登录成功发一个令牌，客户端后续带这个令牌访问，令牌存 Redis 里并和账号绑定，这样所有实例共享同一份会话状态。第二，实现同账号互踢是核心：同一账号再次登录时，用 userId 作为 Redis 的 key 覆盖旧 token，旧 token 下次校验就失效了，保证同一时间只有一个 token 在用一个账号——这对内部 ERP 防止账号共享很有用。第三，安全细节我们做了几层：登录时校验验证码防止暴力破解；密码不存明文，用 SHA256 + 独立盐哈希存储，防止拖库后彩虹表破解；同时记录登录的 IP、时间、机器型号做审计。因为这是纯内部系统，没接微信/第三方登录，账号出问题就找 IT 重置密码。

**【边界】** 当然，这套是"单机 + 互踢"，不是真正的单点登录——SSO 的核心是"一次登录，多个系统复用"，比如统一认证中心（CAS）或者 JWT 无状态跨域，适合 ERP 下面挂了多个子系统、用户要在子系统间免登录跳转的场景。我们只有单一系统，所以没上 SSO；如果以后系统变多，我会优先考虑 CAS 集中认证或 JWT 双 token，并权衡"可主动失效（Redis）"和"无状态跨域（JWT）"的取舍。

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

### L1 · 30 秒速记

> 结论：Redis 单线程指"命令执行单线程"，本质是内存快 + 非阻塞 IO + 避免并发复杂度。
> 关键词：内存操作 · 非阻塞 IO · 事件循环 · 无锁 · 6.0 多线程 IO
> 边界：单线程 = 执行命令串行；6.0 起 IO 读写多线程，命令执行仍单线程。

### L2 · 核心讲解

**核心考点定位**：面试官要的是"单线程为什么够用 + 单线程有什么代价"，不是背结论。

**机制链（≥3 环）**：
1. 内存快 → 全部数据在内存，命令操作是内存级（微秒），不需要多线程摊薄。
2. IO 瓶颈 → 真正的瓶颈在网络 IO（读写 socket），用**非阻塞 IO + 事件循环（epoll）**单线程也能并发处理大量连接。
3. 省复杂度 → 单线程串行执行命令，天然无锁、无上下文切换、无竞态，避免多线程的锁/同步开销。
4. 事件循环 → 单线程不断 epoll_wait 获取就绪 fd，逐个处理读→执行→写，一个循环内完成，连接并发但不执行并发。
5. 6.0 演进 → 网络 IO 读/写用多线程并行提升吞吐，命令执行仍单线程，保住原子性与一致性。

**证据锚点**：
- `epoll`：Linux 下 IO 多路复用，单线程监听大量 fd，就绪才处理，是"单线程扛高并发"的关键。
- `内存命令`：GET/SET 微秒级，CPU 不会成为瓶颈，瓶颈在内存带宽与网络。
- `单线程代价`：一个慢命令（KEYS、大 key、全量 RDB）阻塞所有后续命令。
- `6.0 多线程`：Redis 6.0 引入多线程 IO（读/写 socket 多线程），但命令执行仍单线程。
- `IO 多路复用`：select/poll 的 O(N) 扫描升级为 epoll 的 O(1) 就绪事件，支撑万级连接。
- `RDB 持久化`：bgsave 用子进程（fork），不阻塞主线程，但 fork 本身有停顿。
- `AOF 重写`：同样 fork 子进程，主线程继续服务命令，重写期间内存增量靠 rewrite buffer。
- `SLOWLOG`：记录执行时间超过阈值的命令，用于定位阻塞主线程的慢命令。
- `10 万 QPS`：单线程模型下 Redis 官方基准可稳定达到的并发量级。

**对比与权衡**：

| 方案 | 并发模型 | 优点 | 代价 |
|---|---|---|---|
| 单线程（<6.0） | 事件循环 | 无锁、简单、原子 | 慢命令阻塞全局 |
| 多线程（6.0+ IO） | 多线程 IO + 单线程执行 | 提升 IO 吞吐 | 部分命令处理仍串行 |
| 多线程（全） | 多线程执行 | 命令并行 | 锁/竞态/一致性复杂 |

**常见误区**：
1. 错误：Redis 单线程 = 只能处理一个连接 → 正确：单线程指命令执行，IO 多路复用可并发处理大量连接 → 为什么：epoll 是关键。
2. 错误：单线程是因为"多线程没用" → 正确：是因为内存快 + IO 是瓶颈 + 单线程免锁，是权衡结果 → 为什么：多线程的锁成本超过收益。
3. 错误：6.0 后 Redis 变成多线程 → 正确：6.0 只是 IO 多线程，命令执行仍单线程 → 为什么：保证命令原子性。
4. 错误：RDB/AOF 持久化会阻塞 Redis → 正确：bgsave/bgrewriteaof 用 fork 子进程，主线程不阻塞 → 为什么：这是 Redis 高可用不停机的设计。
5. 错误：慢命令只会影响它自己 → 正确：慢命令阻塞的是**全局单线程**，所有命令排队 → 为什么：单线程模型下任何慢命令都是全局影响。

**适用边界**：单线程模型下，大 key、KEYS/FLUSHALL、慢 Lua 都会阻塞，需要规避；6.0 后 IO 吞吐提升，但命令串行限制仍在。

### 延伸追问（≥3）

1. **Redis 6.0 的多线程改了什么？**
- 要点：只把 socket 读写（网络 IO）多线程化，命令执行仍单线程，提升 IO 吞吐不破坏原子性。
- 追问落点：为什么命令执行不并行（一致性/锁复杂度）。
2. **单线程为什么还能扛高并发？**
- 要点：非阻塞 IO + epoll 事件循环，单线程监听大量连接，就绪事件才处理。
- 追问落点：事件循环的读→执行→写流程。
3. **单线程的最大代价？**
- 要点：慢命令阻塞全局；需避免大 key、KEYS 命令、长时间 Lua。
- 追问落点：如何定位慢命令（SLOWLOG、monitor）。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，Redis 单线程指的是**命令执行是单线程**，它选择单线程不是"多线程没用"，而是内存快 + 非阻塞 IO + 省并发复杂度三者的权衡结果。

**【三点】** 第一，Redis 数据全在内存，命令操作是微秒级，CPU 根本不构成瓶颈，真正瓶颈在网络 IO——从连接建立到内存取数，最耗时的是网络读写，所以不需要多线程去摊薄计算。第二，它用**非阻塞 IO + 事件循环（epoll）**，单线程就能监听大量连接，有就绪事件才处理，所以单线程也能轻松扛 10 万级并发；如果换成多线程处理内部命令，反而引入锁、上下文切换、竞态这些复杂度，收益覆盖不了成本。第三，单线程串行执行命令天然无锁、原子性强，省去大量同步开销，这也是它能做到那么快的原因之一。Redis 6.0 之后虽然引入了多线程 IO——把 socket 的读写并行化提升吞吐，但**命令执行仍然是单线程**，就是为了保持命令的原子性和简单性。

**【边界】** 当然，单线程不是没有代价——一个慢命令会阻塞后面所有命令，比如大 key 的删除、KEYS 全量扫描、长时间运行的 Lua 脚本，都可能让整个 Redis 卡住。所以实际使用要规避大 key、慎用 KEYS、控制 Lua 执行时间，并用 SLOWLOG 定位慢命令。另外单线程是"命令执行"，不是"网络连接"，别把这两个概念混为一谈。

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

### L1 · 30 秒速记

> 结论：对象创建 = 类加载检查 → 分配内存 → 零值初始化 → 对象头 → 构造方法，并发分配靠 TLAB/CAS。
> 关键词：类加载检查 · 指针碰撞 · TLAB · 对象头 · 逃逸分析
> 边界：栈上分配（逃逸分析+标量替换）是优化，不是所有对象都进堆。

### L2 · 核心讲解

**核心考点定位**：面试官想听的是 new 一条指令背后 JVM 做了什么，重点是"分配内存的并发处理"和"对象内存布局"。

**机制链（≥3 环）**：
1. 类加载检查 → new 时先检查常量池能否定位到类的符号引用，类未加载则先加载/解析/初始化。
2. 分配内存 → 类加载检查通过后分配对象所需内存（大小在类加载时确定）；指针碰撞（连续）或空闲列表（碎片）。
3. 并发分配 → 多线程并发 new 需保证原子性：TLAB（线程本地分配缓冲）优先，不足时用 CAS + 失败重试。
4. 初始化 → 分配后零值初始化（保证字段默认值）、设置对象头（Mark Word + 类型指针）、执行构造方法。
5. 栈上分配 → 逃逸分析 + 标量替换通过时，对象不逃逸可整体拆成标量在栈上分配，免堆分配与 GC。

**证据锚点**：
- `指针碰撞`：堆内存规整（Serial/ParNew 带压缩），用指针分配，指针上移。
- `空闲列表`：堆不规整（CMS），用 FreeList，分配时找足够大的块。
- `TLAB`：每个线程预分配一块 Eden 区，new 先在 TLAB 分配，避免全局锁竞争。
- `对象头`：Mark Word（哈希、分代年龄、锁状态）+ 类型指针（指向类元数据）。
- `逃逸分析`：对象不逃逸且可标量替换，则栈上分配，免堆分配与 GC。
- `零值初始化`：分配后先置默认值（int=0、引用=null），再执行构造方法。
- `CAS + 重试`：TLAB 不足时全局分配用 CAS 更新指针，失败则重试，保证原子性。
- `符号引用`：new 指令操作数指向常量池 class 引用，是类加载检查的入口。
- `Mark Word`：对象头首字，32/64 位下存哈希、GC 分代年龄、锁标志位，与锁升级联动。
- `类元数据`：类型指针指向 Klass 结构，对象可定位到类的方法、常量池。

**对比与权衡**：

| 分配方式 | 前提 | 并发处理 | 适用 |
|---|---|---|---|
| 指针碰撞 | 堆规整 | CAS + 重试 / TLAB | Serial、ParNew |
| 空闲列表 | 堆碎片 | 需维护空闲链表 | CMS |
| 栈上分配 | 逃逸分析 + 标量替换 | 无（线程栈） | 非逃逸小对象 |

**常见误区**：
1. 错误：对象创建第一步就是分配内存 → 正确：先做**类加载检查** → 为什么：类未加载无法确定对象大小。
2. 错误：所有对象都在堆 → 正确：逃逸分析通过可栈上分配（标量替换）→ 为什么：这是 JIT 优化。
3. 错误：new 后对象字段是随机值 → 正确：分配后先**零值初始化**再执行构造 → 为什么：保证默认值语义。
4. 错误：对象分配都要全局锁 → 正确：TLAB 线程本地分配免锁 → 为什么：多数 new 在 TLAB 内完成。
5. 错误：对象头只有类型信息 → 正确：Mark Word 还存哈希、分代年龄、锁标志 → 为什么：锁升级靠它记录状态。
6. 错误：TLAB 满了直接失败 → 正确：TLAB 满先申请新 TLAB，仍不足才走全局 CAS 分配 → 为什么：保证大部分分配免锁。

**适用边界**：大对象（超过 TLAB）直接进老年代；对象创建流程对 TLAB 满、内存不足（OOM）时的处理需单独展开。

### 延伸追问（≥3）

1. **TLAB 是什么？解决了什么问题？**
- 要点：线程本地分配缓冲，预分配 Eden 一块，避免并发 new 的全局锁竞争。
- 追问落点：TLAB 满了怎么办（新 TLAB 或直接堆分配）。
2. **对象头里有什么？**
- 要点：Mark Word（哈希、GC 分代年龄、锁标志）+ 类型指针（类元数据）+ 数组长度（数组）。
- 追问落点：Mark Word 与锁升级的关系（偏向/轻量/重量锁状态位）。
3. **什么是逃逸分析？**
- 要点：对象未逃逸方法外，可栈上分配/标量替换/消除锁。
- 追问落点：为什么不是所有对象都能栈上分配。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，JVM 创建对象的核心流程是"类加载检查 → 分配内存 → 零值初始化 → 设置对象头 → 执行构造方法"五步，其中分配内存的并发处理是重点。

**【三点】** 第一，new 指令先检查常量池能否定位到类的符号引用，类未加载就先走加载、解析、初始化；类加载后对象大小才确定，才能分配内存。第二，分配内存要看堆是否规整——规整用指针碰撞（指针上移），不规整用空闲列表；而且多线程并发 new 必须保证原子性，JVM 用 **TLAB（线程本地分配缓冲）** 让每个线程先在 Eden 预分配一块区域，new 直接在 TLAB 分配，避免全局锁竞争，TLAB 不够再走 CAS + 失败重试。第三，内存分配后先做**零值初始化**（保证字段有默认值），再设置**对象头**（Mark Word 存哈希/分代年龄/锁状态 + 类型指针指向类元数据），最后执行构造方法。另外如果开启了逃逸分析且对象不逃逸方法外、能标量替换，对象可能直接**栈上分配**，不涉及堆分配和 GC。

**【边界】** 当然，不是所有对象都走这套堆分配——逃逸分析通过的对象会栈上分配，这是 JIT 优化；而且大对象会直接进老年代（TLAB 放不下）。这套流程在 TLAB 耗尽、堆内存不足（OOM）时还有额外的分配失败处理，如果面试官追问分配失败路径，要单独展开。

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

### L1 · 30 秒速记

> 结论：锁分两层——JVM 级（synchronized / AQS）与分布式（Redis / ZooKeeper），面试先分清层级再讲实现。
> 关键词：synchronized · AQS · 锁升级 · Redisson · 看门狗
> 边界：JVM 锁只能管单机；跨进程必须分布式锁。

### L2 · 核心讲解

**核心考点定位**：面试官想听的是"你分的清单机锁和分布式锁 + 每种锁的底层机制"，重点是锁升级链路与分布式锁的可靠性。

**机制链（≥3 环）**：
1. 分层 → 单机锁管进程内线程（synchronized、ReentrantLock/AQS）；分布式锁管跨进程/跨服务（Redis、ZK）。
2. synchronized → 基于**对象头 Mark Word** + monitor；从偏向锁 → 轻量级锁（CAS）→ 重量级锁（内核互斥）升级。
3. AQS → ReentrantLock 基于 **state + CLH 队列 + CAS**；公平/非公平由队列判据区分。
4. 分布式 → Redisson `tryLock`（SETNX + 过期 + watchdog 续期）或 ZooKeeper 临时节点 + 监听。
5. 锁升级 → 无锁→偏向（记录线程ID）→轻量（CAS 自旋）→重量（互斥量），单向不可逆，竞争加剧才升级。

**证据锚点**：
- `Mark Word`：锁状态记录在对象头，无锁/偏向/轻量/重量由最后两位标志。
- `偏向锁`：只有一个线程访问，记录线程 ID，CAS 加锁；竞争时升级。
- `CLH 队列`：AQS 的等待队列，线程挂起排队，前驱释放后唤醒后继。
- `state`：AQS 同步状态，0 无锁，>0 有锁（可重入计数）。
- `Redisson watchdog`：锁默认 30s 过期，看门狗每 1/3 时间续期，防业务超时锁自动释放。
- `hasQueuedPredecessors`：公平锁先判断队列是否已有等待线程，有则排队。
- `SETNX`：Redis 分布式锁原子占位命令，需配过期时间防死锁。
- `临时顺序节点`：ZK 锁用临时节点 + 序号，客户端断开自动删除，天然可重入公平。
- `monitor`：synchronized 底层的管程对象，进入/退出成对，可重入。

**对比与权衡**：

| 锁 | 层级 | 公平 | 底层 | 适用 |
|---|---|---|---|---|
| synchronized | JVM | 否 | Mark Word + monitor + 升级 | 同步块/方法，简单 |
| ReentrantLock | JVM | 可配 | AQS state + CLH | 可中断/超时/条件 |
| Redisson 锁 | 分布式 | 否 | SETNX + 过期 + watchdog | 跨进程互斥 |
| ZooKeeper 锁 | 分布式 | 是 | 临时顺序节点 | 强一致、高可靠 |

**常见误区**：
1. 错误：把 synchronized 说成"一直重量级锁" → 正确：偏向→轻量→重量**升级** → 为什么：无竞争时是偏向/轻量，很轻。
2. 错误：分布式锁只用 SETNX 不加过期 → 正确：必须过期时间 + 看门狗续期 → 为什么：防宕机死锁。
3. 错误：把 JVM 锁当分布式锁 → 正确：跨进程必须分布式锁 → 为什么：JVM 锁管不了别的进程。
4. 错误：非公平锁一定比公平锁差 → 正确：非公平锁吞吐更高，公平锁更少饥饿 → 为什么：非公平直接 CAS 抢，少挂起唤醒。
5. 错误：锁升级可以降级 → 正确：升级单向不可逆 → 为什么：撤销偏向锁成本高，不轻易回退。

**适用边界**：分布式锁在业务超时 > 锁过期时需看门狗续期；ZK 锁性能低于 Redis 但更可靠；锁粒度要尽量小。

### 延伸追问（≥3）

1. **synchronized 锁升级过程？**
- 要点：无锁 → 偏向（记录线程ID）→ 轻量级（CAS 自旋）→ 重量级（互斥量），单向不可逆。
- 追问落点：什么情况触发偏向锁撤销、轻量级自旋失败升级。
2. **AQS 的公平锁与非公平锁区别？**
- 要点：公平锁先查 `hasQueuedPredecessors` 是否有人排队；非公平锁直接 CAS 抢。
- 追问落点：非公平锁为什么吞吐更高（减少线程挂起）。
3. **Redisson 锁的看门狗机制？**
- 要点：默认 30s 过期，watchdog 定时续期；业务未完成锁自动续，防中途释放。
- 追问落点：为什么不设过期会死锁、设置太短业务没完成。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，锁要分清两层——JVM 级锁管进程内线程，分布式锁管跨进程，这是回答的起点。

**【三点】** 第一，Java 锁主要是 synchronized 和 ReentrantLock（AQS）。synchronized 基于对象头 Mark Word 和 monitor，并且会**升级**：无竞争时是偏向锁（记录线程 ID），有竞争变轻量级锁（CAS 自旋），自旋失败才升级重量级锁（内核互斥量），所以无竞争时很轻。ReentrantLock 基于 **AQS**，用 state 记录持有次数、CAS 更新状态、CLH 队列挂起等待线程，支持公平/非公平、可中断、超时、条件变量，比 synchronized 更灵活但代码更繁琐。第二，这两者都只控制单机内线程，分布式部署后其他进程的线程控制不了，所以要**分布式锁**。第三，常见的分布式锁用 Redis：Redisson 的 `tryLock` 用 SETNX 加过期时间保证原子，业务没完成靠**看门狗**每三分之一过期时间续期，防止业务超时锁被误释放；也可以选 ZooKeeper 临时顺序节点，性能稍低但更可靠、可公平。锁的核心都是让并发操作共享资源的线程互斥，保证原子性。

**【边界】** 当然，分布式锁要设过期时间防宕机死锁，但过期时间不能短于业务执行时间，否则业务没跑完锁就释放了——所以 Redisson 用看门狗续期。另外锁粒度要尽量小（锁 key 细化）、持有时间要短，避免成为性能瓶颈；如果对一致性要求极高（如金融扣款），ZK 锁或数据库唯一约束兜底比 Redis 更稳妥。

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

### L1 · 30 秒速记

> 结论：分页缓存要看数据规模与变更频率——小数据全量缓存、大数据只缓存热页，且必须处理一致性。
> 关键词：全量缓存 · 首页缓存 · 分页 key · 延迟双删 · 缓存穿透
> 边界：低频变更可全量；高频变更只缓存首页或短 TTL。

### L2 · 核心讲解

**核心考点定位**：面试官想听"缓存的粒度 + key 设计 + 一致性"，而不是"把结果放 Redis"一句话。

**机制链（≥3 环）**：
1. 粒度判断 → 数据量小且变更低频（如百人商户列表）→ 全量缓存，分页/排序在应用层做。
2. 热页缓存 → 数据量大且高频变更（如订单）→ 只缓存首页（第一页访问频率最高），后续页直接查库。
3. 一致性 → 缓存与 DB 双写，用**延迟双删**或版本号；更新时先删缓存，防旧数据被读。
4. key 设计 → 分页缓存 key 必须能唯一定位到"页 + 筛选条件"，读时反序列化，写时按 key 覆盖。
5. 穿透防护 → 查空结果缓存空值或布隆过滤器，防高频请求穿透到 DB 打挂库。

**证据锚点**：
- `key 设计`：分页缓存 key 常为 `page:{pageNo}:{pageSize}` 或加筛选条件 hash。
- `全量缓存`：适合小数据 + 低频变更，一次加载常驻，省多次 DB 查询。
- `首页缓存`：大数据只缓存第一页，命中率高、缓存量可控；后续页低频访问不入缓存。
- `延迟双删`：先删缓存 → 更新 DB → 延迟 N 秒再删，防并发读旧值回填。
- `缓存穿透`：查空结果也要缓存空值或布隆过滤器，防高频请求穿透到 DB。
- `TTL`：缓存过期时间按数据变更频率设，高频变更用短 TTL 自愈。
- `布隆过滤器`：判断 key 是否可能存在，不存在直接拦截，减少空查询。
- `版本号`：缓存带版本字段，更新时比对版本，旧版本不覆盖新数据。
- `一致性`：先删缓存再更新 DB，避免"先更新 DB 后删缓存"的旧值回填窗口。
- `SET`/`GET`：Redis 写缓存与读缓存命令，配合过期时间使用。
- `JSON 序列化`：分页结果以 JSON 字符串存储，读时反序列化恢复对象列表。
- `pageSize`：分页大小决定 key 粒度，过大 key 命中率低、过小 key 爆炸。
- `2 秒`：延迟双删的常见延迟窗口值，覆盖并发读回填窗口。

**对比与权衡**：

| 策略 | 适用 | 优点 | 代价 |
|---|---|---|---|
| 全量缓存 | 小数据、低频变更 | 命中最高 | 内存占用，全量重建 |
| 首页缓存 | 大数据、翻页少 | 内存小 | 非首页命中低 |
| 短 TTL 缓存 | 高频变更 | 自愈 | 频繁失效回源 |
| 不缓存 | 极冷数据 | 零一致性问题 | 每次查库 |
| 布隆过滤+空值 | 高并发读 | 防穿透 | 假阳性 |

**常见误区**：
1. 错误：分页结果直接 List 塞 Redis → 正确：按 key（page/size/条件）存 JSON，读时反序列化 → 为什么：需定位到具体页。
2. 错误：只加缓存不管一致性 → 正确：延迟双删 / 版本号 → 为什么：缓存与 DB 不一致是最大坑。
3. 错误：所有页都缓存 → 正确：只缓存热页（首页），翻页低频 → 为什么：避免缓存资源浪费。
4. 错误：缓存过期时间越长越好 → 正确：按变更频率设 TTL，高频变更短 TTL → 为什么：防脏数据长期滞留。
5. 错误：空结果不缓存 → 正确：空值缓存或布隆过滤器 → 为什么：防缓存穿透打挂 DB。

**适用边界**：如果数据每天高频变动，全量缓存会频繁失效，此时短 TTL 或只缓存首页更合适；排序/搜索复杂的查询不适合简单 key 缓存，要考虑结果集失效问题。

### 延伸追问（≥3）

1. **分页缓存 key 怎么设计？**
- 要点：`page:{pageNo}:{pageSize}` + 筛选条件，条件变化要拆 key 或做条件 hash。
- 追问落点：key 爆炸问题（条件组合多）怎么控制。
2. **缓存和数据库一致性能怎么保证？**
- 要点：先删缓存 → 更新 DB → 延迟双删；或版本号比对。
- 追问落点：为什么不能先更新 DB 再删缓存（旧值回填）。
3. **首页缓存命中率怎么保证？**
- 要点：第一页访问最高，缓存首页 + 短 TTL；非首页查库。
- 追问落点：缓存容量与命中率权衡。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，分页结果存 Redis 的关键不是"存进去"，而是"粒度、key、一致性"三个设计决策。

**【三点】** 第一，看数据规模与变更频率。我们之前有一类是商户信息，数据量小（一两百人）、变更频率低、基本由后台管理更新，就**全量缓存**到 Redis，分页、排序、搜索都在应用层代码里做，充分利用缓存；因为更新少，刷新缓存成本低。第二，如果是订单这种数据量大、高频变动的数据，就不适合全量缓存，我们**只缓存第一页**（首页访问频率最高），后续页直接查库——翻页的人少，没必要浪费缓存资源。第三，无论哪种，key 设计要能定位到具体页（比如 `page:1:20`，带上筛选条件），并且要处理一致性：更新时**先删缓存再更新 DB，延迟一段时间再删一次**（延迟双删），防止并发读把旧值回填缓存；如果查出来是空，缓存空值或布隆过滤器防缓存穿透。

**【边界】** 当然，这套策略不是固定——如果数据高频变动，全量缓存会频繁失效，不如短 TTL 或只缓存首页；如果查询排序条件组合非常多，简单 key 缓存会 key 爆炸，要考虑按条件 hash 或干脆走 DB + 索引。核心是判断"数据变更频率"和"缓存容量成本"，别为了缓存而缓存。

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

### L1 · 30 秒速记

> 结论：HashMap 1.8 四大优化——数组+链表+红黑树、头插改尾插、扰动函数、扩容省重算。
> 关键词：红黑树化 · 尾插 · 扰动 ^ · 扩容判高位
> 边界：树化条件是链表长度>8 且数组长度≥64；仍非线程安全，并发用 ConcurrentHashMap。

### L2 · 核心讲解

**核心考点定位**：面试官要"优化点 + 为什么这么优化"，重点是树化阈值、尾插防死链、扰动函数细节；需区分"性能优化"与"并发安全"两个不同命题。

**机制链（≥3 环）**：
1. 树化 → 链表查询 O(N)，超阈值转红黑树 O(log N)，缓解 hash 冲突严重时的退化。
2. 尾插 → 1.7 头插在并发扩容时会形成**环**（死链），1.8 改尾插避免链表断链成环。
3. 扰动 → `h ^ (h >>> 16)` 让高 16 位参与低 16 位，减少冲突，且比多次位运算开销低。
4. 扩容 → 1.8 不重算 hash，用 `(e.hash & oldCap)` 判断元素留在原位或移到 `原位置+oldCap`。
5. 阈值设计 → 树化阈值 8 来自泊松分布，负载因子 0.75 平衡时间与空间，扩容 2 倍保持 2 的幂。
6. 并发对照 → HashMap 所有优化都不解决并发，1.8 的 ConcurrentHashMap 才用 CAS + 锁头节点保证线程安全。

**证据锚点**：
- `树化阈值`：链表长度 > 8（默认 TREEIFY_THRESHOLD=8）且数组 ≥ 64（MIN_TREEIFY_CAPACITY）才转红黑树。
- `扰动函数`：`h ^ (h >>> 16)`，**异或**，不是按位与——注意别混淆。
- `扩容判定`：`(e.hash & oldCap) == 0` 原位，否则 `原位置 + oldCap`。
- `初始容量`：默认 16，负载因子 0.75，扩容 2 倍。
- `8 的由来`：泊松分布，链表长度达 8 概率极低（约 0.00000006），可视为冲突已严重。
- `UNTREEIFY_THRESHOLD`：树退化回链表的阈值 6。
- `TREEIFY_THRESHOLD`：转树阈值 8；`MIN_TREEIFY_CAPACITY`：最小数组容量 64。
- `hash & (n-1)`：定位桶下标，容量必须 2 的幂才能用位运算代替取模。
- `扩容`：容量翻倍后重新分布，只移动 `oldCap` 位为 1 的桶。
- `泊松分布`：哈希桶中节点数服从泊松分布，长度 8 概率约 0.00000006，树化阈值由此确定。
- `2 的幂`：初始容量 16 且每次扩容 ×2，保证 `hash & (n-1)` 等价取模且位置只差 oldCap。
- `ConcurrentHashMap`：1.8 用 CAS + synchronized 锁头节点，替代 1.7 的 Segment 分段锁。

**对比与权衡**：

| 版本 | 结构 | 插入 | 扰动 | 扩容 |
|---|---|---|---|---|
| 1.7 | 数组+链表 | 头插（并发会环） | 多次位运算 | 全量重算 hash |
| 1.8 | 数组+链表+红黑树 | 尾插 | h^(h>>>16) | 只判高位，部分移动 |

**常见误区**：
1. 错误：扰动是"按位与" → 正确：`h ^ (h >>> 16)` 是**异或** → 为什么：异或让高低位混合，与运算做不到。
2. 错误：链表>8 就树化 → 正确：需同时数组≥64，否则先扩容 → 为什么：数组小先扩容摊薄冲突更优。
3. 错误：1.8 是线程安全 → 正确：仍非线程安全，并发用 ConcurrentHashMap → 为什么：树化/扩容都可能竞态。
4. 错误：扩容必须重算所有 hash → 正确：只判断 `(hash & oldCap)` 移动部分元素 → 为什么：容量 2 的幂，位置只差 oldCap。
5. 错误：初始容量随便设 → 正确：默认 16，负载因子 0.75 → 为什么：0.75 平衡冲突与空间，避免频繁扩容。
6. 错误：红黑树能解决并发问题 → 正确：树化只是优化查询复杂度，不解决并发 → 为什么：并发安全需 ConcurrentHashMap 的 CAS + 锁分段。
7. 错误：扰动函数可有可无 → 正确：扰动让高 16 位参与，分布更均匀 → 为什么：key 哈希高位差异大时，不扰动会集中碰撞。

**适用边界**：HashMap 树化会因扩容/删除退化回链表（UNTREEIFY_THRESHOLD=6）；高并发下仍必须 ConcurrentHashMap 而非 HashMap；扩容是性能拐点，若已知元素数量应预估容量避免多次扩容；单线程读多写少可考虑只读副本，避免并发写冲突。

### 延伸追问（≥3）

1. **为什么树化阈值是 8？**
- 要点：泊松分布下链表长度 8 概率约 0.00000006，可视为冲突严重，再长该树化。
- 追问落点：负载因子 0.75 与 8 的推导关系。
2. **1.7 头插为什么并发扩容会死链？**
- 要点：头插在并发扩容迁移时，两个线程对同一链表头插导致节点互相指向成环，get 死循环。
- 追问落点：尾插为什么能避免。
3. **扩容为什么不用重算 hash？**
- 要点：容量 2 的幂，`hash & (n-1)` 决定位置；扩容后只需看 hash 的第 oldCap 位，`(hash & oldCap)==0` 原位否则 +oldCap。
- 追问落点：为什么容量必须 2 的幂。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，HashMap 1.8 的核心优化有四块——数据结构、插入方式、哈希扰动、扩容策略。

**【三点】** 第一，数据结构从"数组 + 链表"升级为"数组 + 链表 + **红黑树**"：当链表长度超过 8 且数组长度达到 64 时，链表转红黑树，把查询从 O(N) 降到 O(log N)，缓解极端 hash 冲突下的性能退化；这个 8 不是拍脑袋，而是泊松分布下链表长度到 8 的概率约 0.00000006，说明冲突已经很严重。第二，插入从头插改成**尾插**：1.7 的头插在并发扩容迁移时，两个线程对同一链表头插会让节点互相指向形成**环**，get 时死循环；尾插按原顺序追加，不会成环，虽然并发下仍非线程安全。第三，哈希扰动从多次位运算简化为 `h ^ (h >>> 16)`——把高 16 位与低 16 位**异或**，让高位信息参与定位，减少冲突，开销更低；扩容也不再全量重算 hash，因为容量是 2 的幂，用 `(hash & oldCap) == 0` 判断元素留在原位还是移到"原位置 + oldCap"，只处理部分元素。

**【边界】** 当然，这些优化**没有让 HashMap 变成线程安全**——并发环境下树化、扩容都可能竞态，必须用 ConcurrentHashMap；而且树化不是永久，元素减少到阈值 6 以下会退化回链表。另外 HashMap 不能保证顺序，如果面试官要有序，得用 LinkedHashMap 或 TreeMap。

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

### L1 · 30 秒速记

> 结论：下游超时按"降级 + 重试 + 兜底"处理，核心是候选路由、超时分级、幂等与熔断。
> 关键词：降级路由 · 超时分级 · 重试 · 熔断 · 幂等
> 边界：重试必须幂等；重试次数有限；失败走熔断/兜底。

### L2 · 核心讲解

**核心考点定位**：面试官想听"超时怎么分级、重试要不要幂等、失败怎么降级"，最好带真实场景。

**机制链（≥3 环）**：
1. 分级 → 连接超时 vs 读超时：连接超时先查网络/对端不可达，读超时先查对端处理慢。
2. 降级路由 → 有候选实例（多供应商/多机房）时，按成本/优先级/健康度排序，超时切换下一个。
3. 重试 → 有限次（默认 1-2 次）、带退避、**必须幂等**（防止重复扣款/重复写）。
4. 兜底 → 熔断（快速失败防雪崩）、降级（返回缓存/默认值）、异步化（MQ 重试补偿）。
5. 环检测 → 多级转发时用唯一链路 ID 记录来源，检测到环立即终止，防无限跳转。

**证据锚点**：
- `连接超时 vs 读超时`：连接超时=TCP 建连失败；读超时=连接建立但响应慢。
- `重试次数`：一般 1-2 次，过多放大下游压力；指数退避避免打爆。
- `幂等`：重试必须能安全重放（唯一请求 ID / 幂等键 / 状态机）。
- `熔断`：失败率阈值（如 50%）或慢调用比例触发，半开探测恢复。
- `兜底`：返回缓存值/默认值/友好错误，或丢 MQ 异步补偿。
- `链路 ID`：多级转发加唯一 ID，检测来源形成环则终止。
- `超时参数`：connectTimeout / readTimeout / writeTimeout 分开配置。
- `降级路由`：候选实例按成本、优先级、健康度排序，失败切换下一个。
- `指数退避`：重试间隔按 2^n 递增，避免瞬时重试打爆下游。
- `唯一请求 ID`：跨服务透传的 trace/request id，既是幂等键也是环检测依据。
- `状态机`：订单/支付状态流转，重试时校验当前状态避免重复推进。
- `半开`：熔断打开后定时放少量探针，成功则关闭，失败继续熔断。
- `兜底缓存`：非关键路径返回缓存旧值，保证用户体验。
- `MQ 补偿`：失败任务丢消息队列，由消费者异步重试，解耦同步阻塞。
- `降级开关`：配置中心开关控制降级策略，紧急时可全量降级。
- `健康检查`：候选实例定期探活，剔除不健康节点，避免路由到故障机。
- `慢调用比例`：熔断触发条件之一，如慢调用比例超阈值。
- `缓存旧值`：降级时返回上次成功缓存，牺牲实时性换可用性。
- `50%`：常见熔断失败率阈值，超过则打开熔断。
- `2 次`：常见默认重试次数，过多放大下游压力。
- `1 秒`：常见连接超时下限，读超时通常更长。
- `Sentinel`：常用熔断降级框架，支持慢调用比例、异常比例、异常数三种规则。
- `RocketMQ`：常用异步补偿通道，失败消息丢重试队列延迟消费。
- `Resilience4j`：轻量熔断限流库，支持基于并发数/失败率的熔断器。

**对比与权衡**：

| 手段 | 适用 | 优点 | 代价 |
|---|---|---|---|
| 重试 | 瞬时抖动 | 简单 | 需幂等，放大压力 |
| 降级切换 | 有候选实例 | 高可用 | 需候选池 |
| 熔断 | 下游持续故障 | 防雪崩 | 需恢复探测 |
| 兜底缓存/默认值 | 非关键路径 | 保用户体验 | 数据可能旧 |
| MQ 异步补偿 | 可异步化 | 解耦、不阻塞 | 延迟、需重试队列 |
| 环检测终止 | 多级转发 | 防死循环 | 需链路 ID 透传 |

**常见误区**：
1. 错误：超时无脑重试 → 正确：连接/读超时分清，重试幂等且有限次 → 为什么：放大下游、重复副作用。
2. 错误：重试不幂等 → 正确：重试必须幂等（幂等键/唯一 ID）→ 为什么：否则重复扣款/重复写。
3. 错误：只重试不熔断 → 正确：失败率高要熔断防雪崩 → 为什么：持续重试会把所有线程拖死。
4. 错误：熔断后不再恢复 → 正确：半开探测，放少量流量试探恢复 → 为什么：否则下游恢复后仍被拒。
5. 错误：所有超时共用一个值 → 正确：connect/read/write 分开配 → 为什么：连接慢和响应慢根因不同。
6. 错误：降级路由不考虑健康度 → 正确：候选先探活剔除不健康，再按成本/优先级选 → 为什么：否则一直路由到故障节点。
7. 错误：重试次数越多越好 → 正确：默认 1-2 次 + 指数退避 → 为什么：重试放大下游，可能拖垮服务。

**适用边界**：写操作（扣款、下单）重试必须幂等；读操作可安全重试；下游已过载时熔断比重试更重要。

### 延伸追问（≥3）

1. **连接超时和读超时分别怎么处理？**
- 要点：连接超时先查网络/对端；读超时先查对端处理慢、慢 SQL。
- 追问落点：超时参数怎么配（connect/read/write 分开）。
2. **重试为什么必须幂等？**
- 要点：重试是同一请求重复执行，写操作需幂等键/唯一 ID/状态机防重复副作用。
- 追问落点：幂等键怎么设计（请求 ID + 去重表）。
3. **熔断怎么恢复？**
- 要点：熔断打开后定时半开，放少量探针流量，成功则关闭。
- 追问落点：半开探测的阈值与策略。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，调用下游超时我按"超时分级 → 降级路由 → 幂等重试 → 熔断兜底"来处理。

**【三点】** 第一，先分清是**连接超时**还是**读超时**——连接超时说明 TCP 都没建上，查网络/对端不可达；读超时是连接建上了但对端处理慢，查对端慢 SQL/线程池。我之前的 API 平台下游挂了多个供应商，超时时按"产品类型 + 运营商 + 加密方式"筛选出候选，再按成本和优先级排序成列表，逐个尝试，成功就返回，失败换下一个；还会对结果做**预期校验**，低价供应商的结果不可信就丢弃再换。第二，重试必须**幂等**——因为超时后我们不知道对端到底有没有执行成功，如果重试的是扣款、下单这种写操作，不幂等会重复扣款；所以用唯一请求 ID 或幂等键去重。重试次数要有限（一般 1-2 次），用指数退避，避免放大下游压力。第三，如果所有候选都失败或失败率过高，就触发**熔断**快速失败，防止雪崩，同时**降级**返回缓存值或默认值，或丢 MQ 异步补偿。我们之前还遇到过死循环问题——供应商 A 转发到 B、B 又转回 A，最后加了唯一链接 ID 检测环，发现环就终止，避免无限跳转。

**【边界】** 当然，这套不是固定流程——读操作可以安全重试，写操作必须幂等；如果下游已经过载，熔断比重试更优先。而且熔断后要定时"半开"放少量探针流量探测恢复，不能一直熔断；超时参数也要 connect/read/write 分开配，别用一个大超时掩盖问题。

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

### L1 · 30 秒速记

> 结论：几百万数据先澄清上下文（总量 vs 日增量），再按"单表容量 + 查询模式"选分区/分表/归档。
> 关键词：表分区 · 分库分表 · 归档 · 分区裁剪 · 冷备
> 边界：几百万不一定要分库分表，先评估单表能否承载 + 查询是否走分区键。

### L2 · 核心讲解

**核心考点定位**：面试官想听"为什么分、怎么分、查询怎么走"，关键是先澄清"几百万是总量还是日增"，再谈单表容量与索引，最后才是分区/归档的取舍；数据增长模式是判断的起点。

**机制链（≥3 环）**：
1. 澄清 → 几百万是总量（一次存量）还是每天增量（持续增长）？这决定用分区还是归档：静态存量无需拆分，持续增量才需要分区 + 归档。
2. 单表容量 → 几百万行对 MySQL 单表通常可行（千万内），关键在**索引与查询模式**，不是行数。
3. 分区 → 按时间/哈希分区，查询**必须带分区键**走分区裁剪，避免全分区扫描。
4. 归档/冷备 → 冷数据定期迁移到归档表/ES/数仓，热表只保留近期数据。
5. 索引兜底 → 分区键外的查询条件建联合索引，避免无分区键时全扫；冷备用逻辑备份防物理文件损坏。
6. 选型依据 → 先看增长模式：静态存量走"单表 + 索引"，持续增量走"分区 + 归档"，两者结合才完整。

**证据锚点**：
- `表分区`：RANGE（按时间）适合日志/流水；HASH 适合按 key 打散；LIST 按枚举。
- `分区裁剪`：WHERE 含分区列时只查对应分区；否则扫所有分区。
- `分库分表`：数据达亿级/写瓶颈才用；几百万通常分区即可。
- `归档`：冷数据按时间迁移，热表瘦身；冷备选 ES/数仓而非仅表空间文件。
- `冷备教训`：表空间文件（ibd）单独上传对象存储易损坏，应整库逻辑备份或转冷备系统。
- `RANGE 分区`：按时间范围（如每天/每月一分区），适合流水日志。
- `HASH 分区`：按 key 哈希打散，均匀分布，适合无时间维度的数据。
- `联合索引`：分区键外的查询条件建复合索引，减少回表。
- `ES 冷备`：冷数据转 Elasticsearch 支持全文/聚合，替代仅文件备份。
- `分区键`：查询必须带分区列（如 create_time），否则退化为全分区扫描。
- `2000 万行`：常见单表告警水位，超过考虑拆分。
- `500 万行`：几百万量级典型场景，索引合理单表可承载。
- `mysqldump`：逻辑备份工具，替代物理 ibd 文件单独备份。
- `create_time`：流水表常用分区列，按天 RANGE 分区。
- `归档表`：冷热分离后的只读表，迁移时按时间批量插入。
- `InnoDB`：默认存储引擎，支持行级锁与表分区。
- `ALTER TABLE PARTITION`：在线加分区、删分区，运维按分区管理。
- `EXPLAIN PARTITIONS`：验证查询是否命中分区裁剪。
- `只读副本`：归档库只读，查询旧数据走归档，避免压热表。

**对比与权衡**：

| 方案 | 适用 | 优点 | 代价 |
|---|---|---|---|
| 普通单表 | 百万级、索引好 | 简单 | 数据持续增长会退化 |
| 表分区 | 时间维度流水 | 分区裁剪、运维按分区 | 查询须带分区键 |
| 分库分表 | 亿级、写瓶颈 | 横向扩展 | 分布式事务/跨片查询 |
| 归档 | 冷热分离 | 热表瘦身 | 需迁移任务 |

**常见误区**：
1. 错误：几百万就分库分表 → 正确：先评估单表（千万内通常可行）→ 为什么：分库分表复杂度高，用不上。
2. 错误：分区后查询不带分区键 → 正确：必须走分区裁剪 → 为什么：否则退化为全表扫。
3. 错误：冷备只备份表空间文件 → 正确：逻辑备份或转 ES/数仓 → 为什么：物理文件单独存易损坏（亲身踩坑）。
4. 错误：单表行数 = 性能 → 正确：关键在索引与查询模式 → 为什么：索引好千万行也快。
5. 错误：几百万静态数据也分区分表 → 正确：静态存量单表 + 索引即可 → 为什么：无增长无需拆分。
6. 错误：分区后所有查询都自动裁剪 → 正确：只有 WHERE 含分区键才裁剪 → 为什么：不带分区键会扫所有分区。
7. 错误：归档后冷数据就丢了 → 正确：归档库/ES 仍可查询，只是从热表移除 → 为什么：冷热分离不是删除数据。

**适用边界**：几百万静态数据 + 索引合理，单表足够；每天新增几百万的流水才需要按天分区 + 归档；分区必须带分区键查询，否则裁剪失效退化为全扫；若数据增长不可控或写成为瓶颈，才升级分库分表或引入分布式存储。

### 延伸追问（≥3）

1. **表分区和分库分表怎么选？**
- 要点：分区是逻辑隔离、同库；分库分表是物理拆分、跨节点，复杂。
- 追问落点：几百万为什么不用分库分表（收益 < 复杂度）。
2. **分区键怎么选？**
- 要点：选查询高频且分布均匀的列（时间/ID）；查询必须带该列。
- 追问落点：分区键不带时如何兜底（索引 + 限定时间范围）。
3. **冷数据归档怎么做？**
- 要点：按时间迁移到归档表/ES/数仓，定时任务或 CDC；热表保留近期。
- 追问落点：归档后查询旧数据走哪里（归档库只读）。
4. **表空间文件备份为什么不可靠？**
- 要点：ibd 物理文件依赖 redo/undo 一致性与文件完整性，单独上传易损坏且难恢复。
- 追问落点：正确冷备方式（逻辑备份 mysqldump / 转 ES 数仓 / 从库物理备份）。

### 面试者参考回答（400–700 字）

**【结论】** 面试官您好，几百万数据的设计第一步是**澄清上下文**——"几百万是总量还是每天新增"，这决定了用分区还是归档。

**【三点】** 第一，如果是一次性的几百万存量数据（比如几百万用户、商品），单表完全能扛——MySQL 单表千万行内只要索引和查询模式合理都没问题，关键是建好覆盖查询的联合索引，避免全表扫，**不需要分库分表**，分库分表是亿级、写瓶颈才上的方案，复杂度高，几百万用它是杀鸡用牛刀。第二，如果是每天新增几百万的流水（比如我们接口一天两三百万次调用产生的日志），就要**按天表分区**——每天一个分区，一个分区两三百万行，查询带时间条件就走**分区裁剪**只扫当天分区，性能可控；运维上还能按分区做清理和备份。第三，冷数据要定期**归档**——热表只保留近期数据，冷数据迁移到归档表或 ES/数仓，查询旧数据走归档库。这里我踩过一个坑：当时冷备只把表空间文件（ibd）上传对象存储，结果文件损坏无法恢复——物理文件单独备份不可靠，应该做整库逻辑备份，或者把冷数据转到 ES/数仓这类专门的冷备系统。

**【边界】** 当然，几百万不是分区的唯一理由——如果数据量不大但查询特别复杂（大范围扫、多条件聚合），索引和查询改写比分区更关键；分区要求查询一定带分区键，否则会退化成扫全部分区。所以核心是先看数据增长模式（存量 vs 增量），再决定"单表 + 索引"还是"分区 + 归档"，别一上来就上分布式。