JAVA +AI系列

第一章 JVM（8题）

1. JVM 内存结构（堆、栈、方法区、程序计数器、本地方法栈）

标准答案

JVM 运行时数据区分为线程私有和线程共享两大部分：

【线程私有】

1. 程序计数器（Program Counter Register）

• 作用：当前线程执行的字节码行号指示器，指向下一条要执行的字节码指令

• 特点：唯一不会抛出 OOM 的区域；线程切换后能恢复到正确执行位置

• 执行 Java 方法时记录字节码指令地址；执行 Native 方法时为空（Undefined）

2. 虚拟机栈（VM Stack）

• 作用：每个方法执行时创建一个栈帧（Stack Frame），存储局部变量表、操作数栈、动态链接、方法出口

• 局部变量表：存放基本数据类型（boolean/byte/char/short/int/float/long/double）、对象引用（reference）、returnAddress

• 异常：

  • StackOverflowError：栈深度溢出（递归过深）

  • OutOfMemoryError：栈扩展时内存不足

• 参数：-Xss 控制每个线程栈大小，JDK8 默认 1M

3. 本地方法栈（Native Method Stack）

• 作用：为 Native 方法服务，与虚拟机栈作用类似

• HotSpot 中直接将本地方法栈和虚拟机栈合二为一

【线程共享】

4. 堆（Heap）

• 作用：存放对象实例和数组，是 GC 的主要区域（"垃圾收集堆"）

• 分代结构：

  • 新生代（Young Generation）：Eden + S0（From Survivor）+ S1（To Survivor），默认比例 8:1:1

  • 老年代（Old Generation）

• 核心参数：

  • -Xms：初始堆大小

  • -Xmx：最大堆大小

  • -Xmn：新生代大小

  • -XX:SurvivorRatio=8：Eden 与 Survivor 比例

• 异常：OutOfMemoryError: Java heap space

5. 方法区（Method Area）

• 作用：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等

• 演进：

  • JDK7 及之前：永久代（PermGen）实现，参数 -XX:PermSize、-XX:MaxPermSize

  • JDK8 及之后：元空间（Metaspace）实现，使用本地内存，参数 -XX:MetaspaceSize、-XX:MaxMetaspaceSize

• 运行时常量池：方法区的一部分，存放编译期生成的字面量和符号引用

• 异常：OutOfMemoryError: Metaspace / PermGen space

【直接内存（Direct Memory）】

• 不是 JVM 运行时数据区的一部分，但也被频繁使用

• NIO 的 DirectByteBuffer 使用 Native 函数库直接分配堆外内存

• 参数：-XX:MaxDirectMemorySize，默认与 -Xmx 一致

高频追问

追问1：对象在内存中的布局是怎样的？

对象在内存中分为三部分：

| 部分 | 说明 | |------|------| | 对象头（Header） | Mark Word（哈希码、GC 分代年龄、锁状态标志、线程持有的锁等）+ 类型指针（指向方法区中类元数据的指针） | | 实例数据（Instance Data） | 对象真正存储的有效信息，即字段内容 | | 对齐填充（Padding） | 保证对象起始地址是 8 字节的整数倍，起到占位作用 |

追问2：对象创建的完整过程？

1. 类加载检查：检查常量池中是否能定位到类的符号引用，该类是否已加载、解析、初始化

2. 分配内存：

   • 堆内存规整（有压缩的 GC 算法）→ 指针碰撞（Bump the Pointer）

   • 堆内存不规整 → 空闲列表（Free List）

3. 初始化零值：将分配到的内存空间都初始化为零值（不包括对象头），保证对象字段不赋值也能使用

4. 设置对象头：设置 Mark Word、类型指针等元信息

5. 执行 <init> 方法：按程序员的意愿初始化对象（构造函数）

追问3：对象的访问定位方式有哪些？

• 句柄访问：堆中划分一块内存作为句柄池，reference 存储句柄地址，句柄中包含对象实例数据和类型数据的指针

  • 优点：对象移动时只改句柄中的指针，reference 本身不动

• 直接指针访问（HotSpot 采用）：reference 直接存储对象地址，对象中包含指向类型数据的指针

  • 优点：速度快，节省一次指针定位开销

追问4：为什么需要 Survivor 区？只有 Eden 行不行？

如果没有 Survivor，Eden 区每满一次就触发一次 Minor GC，存活对象直接进入老年代，老年代很快被填满触发 Full GC。

Survivor 的作用是减少被送到老年代的对象数量，只有经过 16 次（默认）Minor GC 仍存活的对象才会进入老年代。

设置两个 Survivor 区（S0、S1）是为了解决内存碎片化问题，使用复制算法保证始终有一个 Survivor 区是空的。

追问5：为什么默认分代年龄是 15 次？

因为对象头的 Mark Word 中用 4 个 bit 位存储分代年龄，最大值是 1111 即 15。

2. 类加载机制与双亲委派

标准答案

【类加载过程】

类从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期：

加载 → 验证 → 准备 → 解析 → 初始化 → 使用 → 卸载
        └──── 连接（Linking）────┘

1. 加载（Loading）

• 通过类的全限定名获取定义类的二进制字节流

• 将字节流代表的静态存储结构转化为方法区的运行时数据结构

• 在内存中生成代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口

2. 验证（Verification）

• 目的：确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求

• 四个阶段：

  • 文件格式验证：验证字节流是否符合 Class 文件格式规范

  • 元数据验证：语义分析，确保符合 Java 语言规范

  • 字节码验证：数据流和控制流分析，确保程序语义合法

  • 符号引用验证：对类自身以外的信息进行匹配性校验

3. 准备（Preparation）

• 为类变量（static 变量）分配内存并设置零值

• 这些变量使用的内存都将在方法区中分配

• 注意：初始值是数据类型的零值（0、null、false 等），不是代码中显式赋的值

• 如果是 static final 常量，则直接赋值为常量值

4. 解析（Resolution）

• 将常量池内的符号引用替换为直接引用的过程

• 符号引用：以一组符号来描述所引用的目标，与虚拟机内存布局无关

• 直接引用：直接指向目标的指针、相对偏移量或能间接定位到目标的句柄，与内存布局相关

• 解析主要针对：类或接口、字段、类方法、接口方法等

5. 初始化（Initialization）

• 执行类构造器 <clinit>() 方法的过程

• <clinit>() 由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生

• 虚拟机会保证在子类的 <clinit>() 执行前，父类的 <clinit>() 已经执行完毕

• 接口的 <clinit>() 不需要先执行父接口的 <clinit>()

• 虚拟机会保证一个类的 <clinit>() 方法在多线程环境中被正确地加锁、同步

【类加载器】

| 类加载器 | 职责 | 实现 | |----------|------|------| | 启动类加载器（Bootstrap ClassLoader） | 加载 JAVA_HOME/lib 目录中的核心类库 | C++ 实现 | | 扩展类加载器（Extension ClassLoader） | 加载 JAVA_HOME/lib/ext 目录中的扩展类 | Java 实现 | | 应用程序类加载器（Application ClassLoader） | 加载用户类路径（ClassPath）上的类，默认就是这个 | Java 实现 | | 自定义类加载器 | 继承 ClassLoader，重写 findClass 方法 | 用户自定义 |

【双亲委派模型】

工作过程：

1. 如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载，而是把这个请求委派给父类加载器去完成

2. 每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中

3. 只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载

优点：

• 避免类的重复加载：父类加载过了，子类就不用再加载

• 安全：防止核心 API 被篡改，比如自己写的 java.lang.String 不会被加载，因为最终由启动类加载器加载 rt.jar 中的 String 类

破坏双亲委派的场景：

1. SPI 机制（JNDI、JDBC 等）：启动类加载器加载的接口需要调用应用类加载器加载的实现类 → 线程上下文类加载器

2. 热部署/热加载：OSGi 实现模块化热部署，每个模块有自己的类加载器

3. Tomcat：每个 Web 应用有自己的类加载器，优先加载自己目录下的类

高频追问

追问1：什么时候会触发类初始化？（主动引用 vs 被动引用）

有且只有 5 种情况必须立即对类进行初始化（主动引用）：

1. 遇到 new、getstatic、putstatic、invokestatic 这 4 条字节码指令时

2. 使用 java.lang.reflect 包的方法对类进行反射调用时

3. 初始化一个类时，如果其父类还没初始化，先初始化父类

4. 虚拟机启动时，用户指定的主类（包含 main 方法的类）

5. 使用 JDK7 的动态语言支持时，MethodHandle 实例解析结果对应静态方法句柄

被动引用（不会触发初始化）：

• 通过子类引用父类的静态字段，不会导致子类初始化

• 通过数组定义来引用类，不会触发此类的初始化

• 常量在编译阶段会存入调用类的常量池中，不会触发定义常量的类的初始化

追问2：ClassLoader 的 loadClass 和 findClass 的区别？

• loadClass：是类加载的入口，实现双亲委派逻辑。先检查是否已加载，没有则调用父加载器的 loadClass，父加载器加载失败才调用自己的 findClass

• findClass：根据类名查找类的字节码并定义类。自定义类加载器时，推荐重写 findClass 而不是 loadClass，这样不会破坏双亲委派模型

追问3：如何自定义类加载器？使用场景？

实现方式：

1. 继承 java.lang.ClassLoader

2. 重写 findClass 方法（不建议重写 loadClass，否则会破坏双亲委派）

3. 在 findClass 中获取类的字节码（如从文件、网络、加密文件等）

4. 调用 defineClass 方法将字节码转换成 Class 对象

使用场景：

• 加密解密：Class 文件加密，加载时解密

• 热部署/热加载：不重启应用就能加载新的类

• 从非标准来源加载代码：如从网络、数据库等加载类

追问4：Tomcat 为什么要破坏双亲委派？怎么做的？

Tomcat 需要支持一个 Web 容器部署多个应用，且各应用之间相互隔离。如果使用默认双亲委派，所有应用都由 AppClassLoader 加载，不同应用中相同全限定名的类（比如不同版本的 Spring）会冲突。

Tomcat 的类加载机制：

• 每个 Web 应用对应一个 WebAppClassLoader

• 加载顺序：先自己在 WEB-INF/classes 和 WEB-INF/lib 下找，找不到再委托给父加载器

• 但为了安全，Java 核心库还是遵循双亲委派，不会让应用自己的类覆盖核心库类

追问5：什么是线程上下文类加载器？

线程上下文类加载器（Thread Context ClassLoader）是一种"逆向"使用类加载器的方式。

Java 中 SPI（Service Provider Interface）机制，如 JDBC：

• 接口在 rt.jar 中由 BootstrapClassLoader 加载

• 但实现类在 classpath 中由 AppClassLoader 加载

• BootstrapClassLoader 无法加载实现类

这时就需要线程上下文类加载器：

• 线程创建时会继承上下文类加载器，默认是 AppClassLoader

• DriverManager 通过 Thread.currentThread().getContextClassLoader() 获取上下文加载器来加载驱动实现类

• 这实际上是让父类加载器请求子类加载器去完成类加载动作，打破了双亲委派模型

3. Java 内存模型（JMM）是什么？

标准答案

Java 内存模型（Java Memory Model，JMM）是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段、静态字段和构成数组对象的元素）的访问方式。

【JMM 的目标】

定义程序中各个变量的访问规则，屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

【主内存与工作内存】

JMM 规定了所有变量都存储在主内存（Main Memory）中，每条线程还有自己的工作内存（Working Memory）。

• 主内存：所有线程共享，存储变量的"主副本"

• 工作内存：线程私有，保存该线程使用到的变量的主内存副本拷贝

• 线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，不能直接读写主内存中的变量

• 不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成

⚠️ 注意：主内存、工作内存与 Java 内存区域中的堆、栈、方法区不是同一层次的划分，两者基本没有关系。如果勉强对应：主内存对应堆中对象的实例数据部分，工作内存对应虚拟机栈中的部分区域。

【内存间交互操作】

JMM 定义了 8 种操作来完成主内存和工作内存之间的交互：

| 操作 | 作用于 | 说明 | |------|--------|------| | lock | 主内存 | 把一个变量标识为一条线程独占的状态 | | unlock | 主内存 | 把一个处于锁定状态的变量释放出来 | | read | 主内存 | 把变量的值从主内存传输到线程的工作内存中 | | load | 工作内存 | 把 read 得到的值放入工作内存的变量副本中 | | use | 工作内存 | 把工作内存中变量的值传递给执行引擎 | | assign | 工作内存 | 把从执行引擎接收到的值赋给工作内存的变量 | | store | 工作内存 | 把工作内存中变量的值传送到主内存中 | | write | 主内存 | 把 store 得到的值放入主内存的变量中 |

【三大特性】

1. 原子性（Atomicity）

• 由 JMM 直接保证的原子性变量操作包括 read、load、assign、use、store、write

• 基本数据类型的访问读写是具备原子性的（long 和 double 除外，32 位平台下的非原子性协定）

• 更大范围的原子性：synchronized（monitorenter/monitorexit）、Lock 接口

2. 可见性（Visibility）

• 当一个线程修改了共享变量的值，其他线程能够立即得知这个修改

• 实现可见性的关键字：

  • volatile：新值能立即同步到主内存，每次使用前立即从主内存刷新

  • synchronized：对一个变量执行 unlock 之前，必须把变量同步回主内存

  • final：被 final 修饰的字段在构造器中一旦初始化完成，其他线程就能看到 final 字段的值

3. 有序性（Ordering）

• 程序执行的顺序按照代码的先后顺序执行

• Java 中提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性

• volatile 本身包含禁止指令重排序的语义

• synchronized 由"一个变量在同一个时刻只允许一条线程对其进行 lock 操作"获得

【先行发生原则（Happens-Before）】

先行发生是 JMM 中定义的两项操作之间的偏序关系。如果操作 A 先行发生于操作 B，就是说在发生操作 B 之前，操作 A 产生的影响能被操作 B 观察到。

JMM 中"天然的"先行发生关系：

1. 程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作

2. 管程锁定规则：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作

3. volatile 变量规则：对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作

4. 线程启动规则：Thread 对象的 start() 方法先行发生于此线程的每一个动作

5. 线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测

6. 线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生

7. 对象终结规则：一个对象的初始化完成先行发生于它的 finalize() 方法的开始

8. 传递性：如果 A 先行发生于 B，B 先行发生于 C，那么 A 先行发生于 C

【指令重排序】

• 编译器优化的重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序

• 指令级并行的重排序：现代处理器采用了指令级并行技术，如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序

• 内存系统的重排序：由于处理器使用缓存和读/写缓冲区，使得加载和存储操作看上去可能是在乱序执行

as-if-serial 语义：不管怎么重排序，单线程程序的执行结果不能被改变。

高频追问

追问1：volatile 的实现原理？

volatile 有两个作用：保证可见性、禁止指令重排序。

可见性实现：

• 对 volatile 变量的写操作会在汇编层面加 lock 前缀指令

• lock 前缀指令会引起处理器缓存回写到内存（将当前处理器缓存行的数据写回到系统内存）

• 一个处理器的缓存回写到内存会导致其他处理器的缓存无效（MESI 协议）

• 其他处理器发现自己的缓存行对应的内存地址被修改，就会将自己的缓存行置为无效状态，下次读取时重新从内存加载

禁止指令重排序实现：

• volatile 通过插入内存屏障来禁止指令重排序

• 内存屏障（Memory Barrier）是一种 CPU 指令，用于控制特定条件下的重排序和内存可见性问题

• JMM 内存屏障策略：

  • volatile 写操作前插入 StoreStore 屏障

  • volatile 写操作后插入 StoreLoad 屏障

  • volatile 读操作后插入 LoadLoad 屏障

  • volatile 读操作后插入 LoadStore 屏障

追问2：volatile 能保证原子性吗？

不能。 volatile 只能保证可见性和有序性，对于复合操作（如 i++），volatile 无法保证原子性。

i++ 实际上是三个操作：读取 i 的值 → 加 1 → 写回新值。

在多线程环境下可能出现：

• 线程 A 读取 i 的值（假设为 0）

• 线程 B 也读取 i 的值（也是 0）

• 线程 A 加 1 并写回（i=1）

• 线程 B 加 1 并写回（i=1）

结果应该是 2，但实际是 1。

如果需要保证原子性，应该使用 synchronized、Lock 或 AtomicInteger 等原子类。

追问3：volatile 和 synchronized 的区别？

| 维度 | volatile | synchronized | |------|----------|--------------| | 作用范围 | 变量修饰符，只能修饰变量 | 可以修饰方法、代码块 | | 原子性 | 不保证 | 保证 | | 可见性 | 保证 | 保证 | | 有序性 | 保证（禁止重排序） | 保证（串行执行） | | 性能 | 轻量级，不会引起线程上下文切换 | 重量级，会引起线程阻塞和唤醒 | | 使用场景 | 一写多读、状态标记位、DCL | 多写场景、需要保证操作原子性 |

追问4：DCL（双重检查锁）单例为什么要加 volatile？

public class Singleton {
    private volatile static Singleton instance; // 必须加 volatile
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        if (instance == null) {          // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {  // 第二次检查
                    instance = new Singleton(); // 问题出在这里
                }
            }
        }
        return instance;
    }
}

问题在于 instance = new Singleton() 不是原子操作，会被分解为三步：

1. 分配对象内存空间

2. 初始化对象（执行构造函数）

3. 将 instance 指向分配的内存地址

由于指令重排序，可能出现 1→3→2 的顺序：

• 线程 A 执行 1 和 3，instance 不为 null 但还没初始化

• 线程 B 第一次检查发现 instance 不为 null，直接返回

• 线程 B 使用这个未初始化的对象，导致报错

加 volatile 后禁止指令重排序，保证 1→2→3 的顺序，避免拿到半初始化的对象。

追问5：long 和 double 的非原子性协定是什么？

Java 内存模型要求 lock、unlock、read、load、assign、use、store、write 这 8 个操作都具有原子性。

但对于 64 位的数据类型（long 和 double），JMM 允许将没有被 volatile 修饰的 64 位数据的读写操作划分为两次 32 位的操作来进行。这就是所谓的"long 和 double 的非原子性协定"。

也就是说，如果多个线程共享一个没有声明为 volatile 的 long 或 double 变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读到一个既不是原值也不是其他线程修改值的"半个变量"的数值。

不过目前各种平台下的商用虚拟机几乎都选择把 64 位数据的读写操作作为原子操作来对待，因此实际开发中一般不需要专门把 long 和 double 声明为 volatile。

4. 垃圾回收算法与垃圾收集器（G1、CMS）

标准答案

【如何判断对象已死】

1. 引用计数法

• 给对象添加一个引用计数器，每当有一个地方引用它时，计数器加 1；引用失效时，计数器减 1

• 优点：实现简单，判定效率高

• 缺点：无法解决对象之间相互循环引用的问题 → Java 不采用

2. 可达性分析算法（Java 采用）

• 通过一系列称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链

• 当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的

可作为 GC Roots 的对象：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象

• 方法区中类静态属性引用的对象

• 方法区中常量引用的对象

• 本地方法栈中 JNI（Native 方法）引用的对象

【四种引用类型】

| 引用类型 | 强度 | 回收时机 | 用途 | |----------|------|----------|------| | 强引用（Strong） | 最强 | 永远不回收 | 普通对象引用 | | 软引用（SoftReference） | 次强 | OOM 之前回收 | 内存敏感的缓存 | | 弱引用（WeakReference） | 次弱 | 下一次 GC 回收 | 缓存、ThreadLocal Map | | 虚引用（PhantomReference） | 最弱 | 随时可能回收 | 管理堆外内存 |

【垃圾回收算法】

1. 标记-清除算法（Mark-Sweep）

• 过程：首先标记出所有需要回收的对象，标记完成后统一回收

• 缺点：

  • 效率问题：标记和清除两个过程效率都不高

  • 空间问题：产生大量不连续的内存碎片，可能导致大对象分配时提前触发 GC

2. 复制算法（Copying）

• 过程：将可用内存按容量划分为大小相等的两块，每次只使用其中一块。用完了就将存活对象复制到另一块，然后清理已使用的空间

• 优点：实现简单，运行高效，不会产生内存碎片

• 缺点：内存代价高，可用内存缩小为原来的一半

• 应用：新生代的垃圾回收（Eden + S0 + S1，8:1:1）

3. 标记-整理算法（Mark-Compact）

• 过程：标记过程与"标记-清除"一样，但后续让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存

• 优点：没有内存碎片

• 缺点：需要移动对象，成本较高

• 应用：老年代的垃圾回收

4. 分代收集算法（Generational Collection）

• 根据对象存活周期的不同将内存划分为几块

• 新生代：每次 GC 大批对象死去，少量存活 → 选用复制算法

• 老年代：对象存活率高、没有额外空间担保 → 使用标记-清理或标记-整理算法

【垃圾收集器】

1. Serial 收集器

• 单线程收集器，进行垃圾收集时必须暂停其他所有工作线程（Stop The World）

• 新生代采用复制算法，老年代采用标记-整理算法

• 优点：简单高效，单 CPU 环境下没有线程交互开销

• 应用：Client 模式下的默认新生代收集器

2. ParNew 收集器

• Serial 收集器的多线程版本

• 除了使用多线程进行垃圾收集之外，其余行为与 Serial 完全一样

• 只有它能与 CMS 收集器配合工作

• 应用：Server 模式下首选的新生代收集器

3. Parallel Scavenge 收集器

• 新生代收集器，使用复制算法，并行多线程

• 目标是达到一个可控制的吞吐量（Throughput）

• 吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

• 被称为"吞吐量优先"收集器

• 自适应调节策略：虚拟机会根据当前系统运行情况动态调整参数

4. CMS 收集器（Concurrent Mark Sweep）

• 以获取最短回收停顿时间为目标的收集器

• 基于标记-清除算法

运作过程：

1. 初始标记（CMS initial mark）：Stop The World，仅标记 GC Roots 能直接关联到的对象，速度很快

2. 并发标记（CMS concurrent mark）：进行 GC Roots Tracing，与用户线程并发执行

3. 重新标记（CMS remark）：Stop The World，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，停顿时间比初始标记稍长

4. 并发清除（CMS concurrent sweep）：清除已标记的对象，与用户线程并发执行

优点： 并发收集、低停顿

缺点：

1. 对 CPU 资源非常敏感：并发阶段会占用一部分线程，导致应用变慢

2. 无法处理浮动垃圾：并发清除阶段用户线程还在运行，产生的新垃圾只能等下一次 GC 再清理

3. 基于标记-清除算法，会产生大量空间碎片，可能提前触发 Full GC

4. 需要更大的堆空间：并发收集时用户线程还在运行，需要预留足够空间

5. G1 收集器（Garbage First）

• 面向服务端应用的垃圾收集器，JDK9 后成为默认

• 特点：

  1. 并行与并发：利用多 CPU、多核环境缩短 STW 停顿时间

  2. 分代收集：不需要其他收集器配合就能独立管理整个 GC 堆

  3. 空间整合：整体上看是基于"标记-整理"算法，局部是基于"复制"算法，不会产生内存碎片

  4. 可预测的停顿：能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒

Region 概念：

• G1 将整个 Java 堆划分为多个大小相等的独立区域（Region）

• 新生代和老年代不再是物理隔离，都是一部分 Region 的集合

• 每个 Region 的大小在 1MB~32MB 之间，且都是 2 的 N 次幂

• 大对象直接进入 Humongous 区域

运作过程：

1. 初始标记（Initial Marking）：Stop The World，标记 GC Roots 能直接关联到的对象

2. 并发标记（Concurrent Marking）：从 GC Root 开始对堆中对象进行可达性分析，与用户程序并发执行

3. 最终标记（Final Marking）：Stop The World，修正并发标记期间的标记变动

4. 筛选回收（Live Data Counting and Evacuation）：对各个 Region 的回收价值和成本进行排序，根据用户期望的 GC 停顿时间来制定回收计划，选择回收价值最高的 Region 进行回收

G1 为什么可预测停顿时间？

• 因为 G1 可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集

• G1 跟踪各个 Region 里面的垃圾堆积的价值大小，在后台维护一个优先列表

• 每次根据允许的收集时间，优先回收价值最大的 Region（Garbage First 名称的由来）

高频追问

追问1：Minor GC、Major GC、Full GC 的区别？

| 类型 | 作用区域 | 触发条件 | 速度 | |------|----------|----------|------| | Minor GC | 新生代 | Eden 区满 | 快 | | Major GC | 老年代 | 老年代空间不足 | 比 Minor GC 慢 10 倍以上 | | Full GC | 整个堆 + 方法区 | 老年代不足、元空间不足、System.gc()、担保失败等 | 最慢 |

Full GC 触发条件：

1. 老年代空间不足

2. 方法区/元空间空间不足

3. 显式调用 System.gc()（建议加 -XX:+DisableExplicitGC 禁止）

4. 之前某次 Minor GC 后晋升到老年代的平均大小大于老年代的剩余空间（空间分配担保失败）

5. CMS GC 时出现 promotion failed 和 concurrent mode failure

追问2：对象什么时候进入老年代？

1. 年龄达到阈值：默认 15 岁，对象在 Survivor 区中每熬过一次 Minor GC，年龄就增加 1 岁。参数：-XX:MaxTenuringThreshold

2. 动态对象年龄判定：如果在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代

3. 大对象直接进入老年代：需要大量连续内存空间的 Java 对象（如很长的字符串以及数组），直接在老年代分配。参数：-XX:PretenureSizeThreshold

4. 空间分配担保：Minor GC 之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象总空间。如果不大于，且 HandlePromotionFailure 不允许冒险，则改为进行一次 Full GC

追问3：什么是 Stop The World？

Stop The World（STW）是指在执行垃圾收集时，Java 应用程序的其他所有线程都被挂起，暂停一切工作，等待 GC 完成。

• 所有的回收器都有 STW，只是停顿时间长短不同

• STW 是不可避免的，即使是 CMS、G1 这些并发收集器，也有需要停顿的阶段

• STW 期间，应用程序会暂停响应，对于用户来说就是"卡顿"

• 调优的目标就是尽可能缩短 STW 的时间，减少对用户体验的影响

追问4：CMS 的 concurrent mode failure 是什么？

CMS 在并发清理阶段，用户线程还在运行，会不断产生新的垃圾（浮动垃圾）。

如果 CMS 运行期间预留的内存无法满足程序需要，就会出现一次 "Concurrent Mode Failure"。

这时虚拟机将启动后备预案：临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

触发原因：

• 老年代空间不足，放不下晋升的对象

• 产生了大量的浮动垃圾

解决方法：

• 调大老年代空间

• 调整 -XX:CMSInitiatingOccupancyFraction 参数，让 CMS 更早启动

• 减少对象分配速率

追问5：G1 和 CMS 的区别？

| 维度 | CMS | G1 | |------|-----|----| | 算法 | 标记-清除，有内存碎片 | 整体标记-整理，局部复制，无碎片 | | 内存布局 | 传统分代，新生代老年代连续 | Region 划分，不需要物理连续 | | 停顿预测 | 只能尽量减少，无法精确控制 | 可预测停顿时间模型 | | 回收范围 | 整堆回收（老年代） | 筛选回收，只回收部分 Region | | 适用场景 | 重视响应速度，堆大小适中 | 服务端大内存应用，兼顾吞吐和停顿 |

5. JVM 调优思路

标准答案

【调优目标】

JVM 调优的核心目标是：在保证吞吐量的前提下，尽可能减少 GC 停顿时间，避免 Full GC，提高应用稳定性。

具体指标：

• 吞吐量：用户代码执行时间占总时间的比例，越高越好

• 停顿时间：GC 时应用暂停的时间，越短越好

• 内存占用：堆内存使用情况，合理控制

【调优原则】

1. 先监控后调优：不要凭感觉调优，必须基于实际监控数据

2. 优先优化代码：很多性能问题不是 JVM 参数能解决的，代码优化是根本

3. Minor GC 优先：能在新生代解决的，不要让对象进入老年代

4. 够用就好：不要盲目加大堆内存，堆越大 GC 时间越长

5. 分场景调优：不同应用场景调优策略不同（吞吐优先 vs 响应优先）

【调优步骤】

第一步：监控分析

1. 确定当前 JVM 参数配置

2. 收集 GC 日志，分析 GC 情况

3. 使用工具分析：jstat、jmap、jstack、VisualVM、Arthas 等

第二步：确定问题类型

• 频繁 Minor GC：新生代太小，对象分配速率快 → 影响吞吐量

• 频繁 Full GC：老年代空间不足、内存泄漏、大对象过多 → 严重影响响应时间

• 单次 GC 时间过长：堆太大，存活对象多 → 单次卡顿严重

第三步：针对性调优

【内存大小调优】

1. 堆大小设置

• -Xms 和 -Xmx 设置为相同值，避免堆自动扩展带来的性能抖动

• 一般堆大小设置为物理内存的 1/4 ~ 1/2

• 不是越大越好，堆越大单次 GC 时间越长

2. 新生代大小

• -Xmn 设置新生代大小，一般为整个堆的 1/3 ~ 1/2

• 新生代太小：对象提前进入老年代，触发 Full GC

• 新生代太大：Minor GC 时间变长

• 响应时间优先的应用：新生代可以设大一些，减少对象进入老年代

• 吞吐量优先的应用：新生代可以设大一些

3. 元空间大小（JDK8+）

• -XX:MetaspaceSize：初始元空间大小

• -XX:MaxMetaspaceSize：最大元空间大小

• 一般设置为 256M ~ 512M 足够

【GC 收集器选择】

| 场景 | 推荐收集器 | 说明 | |------|-----------|------| | 吞吐量优先 | Parallel Scavenge + Parallel Old | 后台计算型任务 | | 响应时间优先（中小堆） | CMS | Web 应用、接口服务 | | 响应时间优先（大堆） | G1 | JDK9 默认，大堆下表现更好 | | 超大堆（16G+） | G1 / ZGC / Shenandoah | TB 级堆，亚毫秒级停顿 |

【具体调优手段】

1. 减少对象创建

• 避免循环中创建对象

• 重用对象（如 StringBuilder、对象池）

• 减少不必要的临时对象

2. 减少大对象

• 大对象直接进入老年代，容易触发 Full GC

• 避免创建过大的数组、集合

• 大对象拆分处理

3. 调整对象晋升年龄

• -XX:MaxTenuringThreshold

• 对象存活时间长 → 调大阈值，让对象在新生代多待几轮

• 对象存活时间短但体积大 → 调小阈值，尽快进入老年代

4. 调整 Survivor 区比例

• -XX:SurvivorRatio=8（默认 Eden:S0:S1 = 8:1:1）

• Survivor 区经常满，对象提前进入老年代 → 增大 Survivor 比例

5. 调整 GC 触发时机

• CMS：-XX:CMSInitiatingOccupancyFraction，老年代占用达到多少百分比时触发 CMS GC

• 一般设置为 70~80，不能太高，要预留空间给浮动垃圾

【常用调优参数模板】

# 堆内存设置
-Xms2g -Xmx2g          # 初始堆和最大堆，建议设为相同值
-Xmn1g                 # 新生代大小
-XX:SurvivorRatio=8    # Eden 与 Survivor 比例

# 元空间设置（JDK8+）
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m

# GC 收集器选择
-XX:+UseG1GC                   # 使用 G1
-XX:MaxGCPauseMillis=200       # G1 最大停顿时间目标

# GC 日志
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC
-Xloggc:/path/to/gc.log

# 其他
-XX:+HeapDumpOnOutOfMemoryError  # OOM 时自动 dump 堆
-XX:HeapDumpPath=/path/to/dump   # dump 文件路径
-XX:+DisableExplicitGC           # 禁止 System.gc()

高频追问

追问1：如何判断是否需要进行 JVM 调优？

不是所有应用都需要 JVM 调优，满足以下情况时考虑调优：

1. 系统吞吐量达不到要求

2. 接口响应时间过长，且 GC 停顿占比较大

3. 频繁 Full GC，每次停顿时间长

4. 出现 OOM 异常

5. CPU 使用率高且 GC 线程占比高

如果系统运行稳定，GC 次数少、停顿时间短，就不需要盲目调优。很多时候优化代码比调 JVM 参数效果更好。

追问2：什么情况下会触发 Full GC？

1. 老年代空间不足：大对象直接进入老年代、对象晋升导致老年代满

2. 方法区/元空间不足：加载的类太多，元空间满

3. 显式调用 System.gc()：建议加 -XX:+DisableExplicitGC 禁止

4. 空间分配担保失败：Minor GC 前检查老年代空间不足

5. CMS 的 concurrent mode failure：CMS 并发清理时老年代空间不够

6. 晋升担保失败：Minor GC 后存活对象太多，Survivor 放不下，老年代也放不下

追问3：什么是内存泄漏？常见场景？

内存泄漏是指不再使用的对象无法被 GC 回收，持续占用内存，最终导致 OOM。

常见内存泄漏场景：

1. 静态集合类：static 的 Map、List 等，生命周期和 JVM 一样长

2. 各种连接未关闭：数据库连接、网络连接、IO 流等

3. 监听器未反注册：注册了监听器但没有反注册

4. 内部类/匿名内部类：持有外部类引用，外部类无法回收

5. ThreadLocal：使用完没有 remove，线程池场景下线程复用导致泄漏

6. 缓存：缓存没有过期策略，只进不出

追问4：吞吐量优先和响应时间优先分别怎么调优？

| 维度 | 吞吐量优先 | 响应时间优先 | |------|-----------|-------------| | 目标 | 最大化用户代码执行时间占比 | 最小化单次 GC 停顿时间 | | 收集器 | Parallel Scavenge + Parallel Old | CMS / G1 | | 新生代 | 设大一些，减少 Minor GC 频率 | 不能太大，太大 Minor GC 时间长 | | 堆大小 | 可以设大一些，减少 GC 总次数 | 适中，避免单次 GC 时间过长 | | 关注点 | 整体效率 | 用户体验 | | 适用场景 | 后台批处理、大数据计算 | Web 应用、API 服务、电商系统 |

追问5：为什么 -Xms 和 -Xmx 要设置为相同值？

1. 避免堆自动扩展的性能开销：

   • 如果 -Xms < -Xmx，当堆内存不够时，JVM 会向操作系统申请扩展内存

   • 扩展过程中会有性能开销和停顿

   • 设置为相同值，启动时就申请全部内存，避免运行时扩展

2. 避免内存碎片：

   • 堆的扩展和收缩可能导致内存碎片化

   • 固定大小的堆内存布局更稳定

3. 生产环境建议设置为相同值，开发测试环境可以不设置相同，节省内存。

6. OOM 排查流程

标准答案

【OOM 的几种类型】

| OOM 类型 | 说明 | 常见原因 | |----------|------|----------| | Java heap space | 堆内存溢出，最常见 | 堆太小、内存泄漏、对象过多过大 | | Metaspace / PermGen space | 方法区溢出 | 加载类太多、动态生成类过多 | | unable to create new native thread | 无法创建新线程 | 线程数太多，超过系统限制 | | Direct buffer memory | 直接内存溢出 | NIO DirectByteBuffer 分配过多 | | StackOverflowError | 栈溢出（严格来说不是 OOM） | 递归过深、栈大小太小 |

【OOM 排查整体流程】

第一步：保留现场

1. 保存堆 dump 文件（最重要）

   • 提前配置：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path

   • 手动 dump：jmap -dump:format=b,file=heap_$(date +%Y%m%d_%H%M%S).hprof <pid>

2. 保存 GC 日志

3. 保存线程栈信息：jstack <pid> > jstack.log

4. 记录系统状态：top、free、df 等

第二步：分析 OOM 类型 根据错误日志判断是哪种 OOM，针对性排查。

第三步：针对性排查

【堆内存 OOM 排查】

1. 确认堆内存设置是否合理

• 查看 -Xms、-Xmx 参数

• 用 jstat -gcutil <pid> 查看各代使用率

• 如果堆设置确实太小，先调大堆内存试试

2. 分析堆 dump 文件

• 使用 MAT（Memory Analyzer Tool）打开 hprof 文件

• 查看 Histogram：哪些类的实例数量最多、占用内存最大

• 查看 Dominator Tree：哪些对象持有大量引用，阻止 GC 回收

• 查看 Leak Suspects：自动分析可能的内存泄漏点

• 查看 Path to GC Roots：对象为什么没有被回收，引用链是什么

3. 判断是内存泄漏还是内存不足

• 内存泄漏：对象已经不用了但还被引用，无法回收

  • 特征：每次 GC 后堆使用率持续上升，降不下来

  • 解决：找到泄漏点，修复代码

• 内存不足：对象确实都有用，就是太多了

  • 特征：所有对象都有合理的引用，确实是业务需要

  • 解决：调大堆内存、优化代码减少对象创建、增加机器

【元空间 OOM 排查】

1. 查看元空间参数设置：-XX:MetaspaceSize、-XX:MaxMetaspaceSize

2. 分析加载的类：jmap -clstats <pid> 查看类加载统计

3. 常见原因：

   • 动态代理生成类过多（CGLIB、JDK 动态代理）

   • 热部署频繁，旧的类加载器没有回收

   • 引用了大量第三方 jar 包

4. 解决：调大 MaxMetaspaceSize、检查类加载器泄漏、减少不必要的动态代理

【线程数 OOM 排查】

1. 查看当前线程数：jstack <pid> | grep "java.lang.Thread.State" | wc -l

2. 查看系统限制：ulimit -u

3. 分析线程：

   • jstack 导出线程栈

   • 查看是否有大量相同状态的线程

   • 是否有线程泄漏（线程用完没销毁）

4. 常见原因：

   • 线程池配置不合理，最大线程数太大

   • 线程泄漏，创建了线程但没有销毁

   • 系统限制的最大线程数太小

5. 解决：合理配置线程池、修复线程泄漏、调整 ulimit 限制

【直接内存 OOM 排查】

1. 查看直接内存参数：-XX:MaxDirectMemorySize

2. 检查代码中 NIO 的使用：ByteBuffer.allocateDirect()、Netty 等

3. 常见原因：

   • 分配了大量 DirectByteBuffer 没有释放

   • 堆外内存泄漏

4. 解决：调大 MaxDirectMemorySize、检查堆外内存泄漏、使用 NMT 追踪

【栈溢出排查】

1. 查看栈大小：-Xss

2. 分析错误栈：

   • 看栈溢出时的调用栈

   • 是否有递归调用

   • 调用层次是否过深

3. 常见原因：递归死循环、方法调用层次太深、栈大小设置太小

4. 解决：修复递归逻辑、改递归为迭代、适当调大 -Xss

【常用排查工具】

| 工具 | 用途 | |------|------| | jps | 查看 Java 进程 ID | | jstat | GC 统计信息（jstat -gcutil <pid> 1000 10） | | jmap | 堆内存分析、导出 dump | | jstack | 线程栈分析 | | MAT | 堆 dump 分析工具，最常用 | | VisualVM | 可视化监控工具 | | Arthas | 在线诊断工具 |

高频追问

追问1：线上 OOM 了，第一时间做什么？

1. 保留现场最重要：

   • 如果配置了 HeapDumpOnOutOfMemoryError，确认 dump 文件已生成

   • 如果没配置，手动执行 jmap dump

   • 保存 GC 日志、线程栈、系统状态

2. 评估影响：

   • 是单节点还是多节点

   • 是否影响核心业务

   • 是否需要紧急回滚

3. 紧急恢复：

   • 多节点集群：先把出问题的节点从负载均衡摘掉

   • 重启服务恢复业务

   • 单节点的话先重启，事后再分析

4. 事后分析：

   • 用 MAT 分析 dump 文件

   • 定位根因

   • 修复问题、上线验证

原则：先恢复业务，再排查问题。但一定要保留现场数据，否则无法排查。

追问2：如何用 MAT 分析堆 dump？

MAT（Memory Analyzer Tool）使用步骤：

1. 打开 hprof 文件：File → Open Heap Dump

2. 选择 Leak Suspects Report（泄漏嫌疑报告），自动分析可能的泄漏点

3. 关键视图：

   • Histogram：按类列出实例数和占用大小，按 Retained Heap 排序

   • Dominator Tree：支配树，列出每个对象及其持有的所有对象

   • Leak Suspects：自动分析的泄漏嫌疑

   • Path to GC Roots：查看对象到 GC Root 的引用链

4. 分析思路：

   • 先看占用内存最大的对象是什么

   • 然后看这些对象是否应该存活

   • 如果不应该存活，看引用链，找到谁持有了它们的引用

   • 结合代码分析为什么没有释放

追问3：内存泄漏和内存溢出的区别？

| 概念 | 说明 | 比喻 | |------|------|------| | 内存泄漏（Memory Leak） | 对象已经不用了，但还被引用持有，GC 无法回收 | 占着茅坑不拉屎 | | 内存溢出（Out of Memory） | 内存不够用了，对象确实都需要 | 人太多坑位不够 |

关系：内存泄漏是原因之一，内存泄漏积累多了最终会导致内存溢出。但内存溢出不一定是内存泄漏导致的，也可能是内存确实不够用。

追问4：什么是对象的深堆和浅堆？

• 浅堆（Shallow Heap）：对象本身占用的内存大小，不包括它引用的其他对象

• 深堆（Retained Heap）：对象本身 + 它直接或间接引用的所有对象的总大小，也就是如果这个对象被 GC 回收，能释放的总内存大小

MAT 中看 Retained Heap 更有意义，能看出哪些对象是内存大户。

追问5：如何避免 OOM？

代码层面：

• 避免在循环中创建大量对象

• 及时释放资源（连接、流、文件等），用 try-with-resources

• 不用的对象及时解除引用，特别是静态集合

• 避免大对象，特别是大数组、大集合

• 合理使用缓存，设置过期策略和最大容量

• ThreadLocal 使用完要 remove

• 避免内存泄漏

JVM 参数层面：

• 合理设置堆大小，-Xms 和 -Xmx 设为相同

• 合理设置新生代和老年代比例

• 合理设置元空间大小

• 选择合适的 GC 收集器

• 配置 HeapDumpOnOutOfMemoryError，出问题方便排查

架构层面：

• 大对象拆分处理，不要一次性加载全部数据

• 分页查询，不要一次查全表

• 使用对象池、连接池复用对象

• 分布式部署，水平扩展

• 限流降级，保护系统

7. Arthas 常用命令及使用场景

标准答案

Arthas 是 Alibaba 开源的 Java 诊断工具，可以在线排查问题，无需重启，动态跟踪 Java 代码，实时监控 JVM 状态。

【Arthas 能做什么】

1. 查看方法调用的入参、返回值、异常

2. 监控方法执行耗时

3. 查看 JVM 实时运行状态

4. 热更新代码，无需重启

5. 排查类加载问题

6. 生成火焰图分析性能

7. 反编译线上代码

【启动方式】

# 下载 arthas-boot.jar
curl -O https://arthas.aliyun.com/arthas-boot.jar

# 启动
java -jar arthas-boot.jar

# 选择要诊断的 Java 进程

【常用命令分类】

【基础命令】

| 命令 | 说明 | |------|------| | help | 查看命令帮助 | | cls | 清屏 | | session | 查看当前会话 | | version | 查看版本 | | quit / exit | 退出当前客户端 | | stop | 关闭 Arthas 服务端，所有客户端退出 |

【JVM 相关命令】

1. dashboard — 实时数据面板

• 功能：显示当前系统的实时数据面板，包括线程、内存、GC、Runtime 等信息

• 使用场景：快速了解 JVM 整体运行状态

• 输出内容：线程状态、内存使用、GC 统计、Runtime 信息

2. jvm — 查看 JVM 信息

• 功能：查看 JVM 详细信息

• 包括：运行时信息、类加载统计、编译统计、GC 收集器、系统属性、JVM 参数等

3. sysprop — 查看和修改系统属性

• sysprop：查看所有系统属性

• sysprop <key>：查看单个属性

• sysprop <key> <value>：修改属性值

4. vmoption — 查看和修改 VM 参数

• vmoption：查看所有 VM 选项

• vmoption <name> <value>：修改选项值（支持动态修改的参数）

5. getstatic — 查看静态属性

• 功能：查看类的静态属性值

• 示例：getstatic com.example.UserService instance

【类/类加载相关命令】

1. sc（Search Class）— 搜索类

• 功能：搜索所有已经加载到 JVM 中的类信息

• 常用参数：

  • -d：输出类的详细信息，包括类加载器、所在 jar 包等

  • -f：输出类的成员变量信息（配合 -d 使用）

• 示例：sc -d com.example.UserService

2. sm（Search Method）— 搜索方法

• 功能：搜索已加载类的方法信息

• 示例：sm -d com.example.UserService getUser*

3. jad — 反编译

• 功能：反编译指定已加载类的源码

• 常用参数：--source-only 只输出源码

• 使用场景：线上代码和本地不一致时，确认线上运行的到底是什么代码

• 示例：jad --source-only com.example.UserService

4. classloader — 类加载器相关

• 功能：查看类加载器信息、继承树、加载的类

• 常用子命令：

  • classloader -l：列出所有类加载器

  • classloader -t：查看类加载器的继承树

• 使用场景：排查类加载冲突、NoClassDefFoundError 等问题

【方法监控/诊断命令】

1. watch — 方法执行监控

• 功能：观察指定方法的调用情况，能观察到入参、返回值、异常

• 格式：watch <类名> <方法名> <观察表达式> <条件表达式>

• 观察点：params（入参）、returnObj（返回值）、throwExp（异常）、target（目标对象）

• 常用参数：

  • -x：结果属性遍历深度，默认 1

  • -b：方法调用前观察

  • -e：方法异常时观察

  • -s：方法返回后观察

  • -n：执行次数，达到后自动停止

• 示例：

  watch com.example.UserService getUser "{params,returnObj}" -x 2
  watch com.example.UserService getUser "{params,throwExp}" -e -x 2
  

• 使用场景：线上问题排查，看方法入参和返回值是否正确

2. trace — 方法内部调用路径和耗时

• 功能：追踪方法内部的调用路径，并输出每个节点上的耗时

• 常用参数：-n 执行次数、--skipJDKMethod 跳过 JDK 方法

• 示例：trace com.example.UserService getUser

• 使用场景：方法执行慢，找出哪一步最耗时，定位性能瓶颈

3. stack — 方法调用栈

• 功能：查看当前方法被调用的栈路径

• 示例：stack com.example.UserService getUser

• 使用场景：想知道方法被谁调用了，调用链路是什么

4. tt（TimeTunnel）— 时间隧道

• 功能：记录方法每次调用的入参、返回值、耗时等信息，之后可以随时查看

• 常用子命令：

  • tt -t <类名> <方法名>：开始记录

  • tt -l：列出所有记录

  • tt -i <index>：查看指定索引的详细信息

  • tt -i <index> -p：重新触发一次调用（重放）

• 使用场景：偶现问题先记录，出问题时回溯；想重放某次调用

5. monitor — 方法执行监控统计

• 功能：对方法执行进行监控统计，统计成功次数、失败次数、平均耗时等

• 常用参数：-c 统计周期（默认 120 秒）

• 示例：monitor -c 10 com.example.UserService getUser

• 使用场景：统计方法的 QPS、平均耗时、成功率等

【性能分析命令】

1. profiler — 火焰图生成

• 功能：生成火焰图，分析 CPU 热点

• 常用子命令：

  • profiler start：开始采样

  • profiler stop --format html：停止采样，生成火焰图

  • profiler status：查看状态

• 使用场景：CPU 使用率高，找出哪些方法占用 CPU 最多

2. heapdump — 堆 dump

• 功能：导出堆 dump 文件，类似 jmap

• 示例：heapdump /tmp/heap.hprof

【其他实用命令】

1. ognl — 执行 OGNL 表达式

• 功能：执行 OGNL 表达式，调用任意方法

• 示例：

  ognl '@java.lang.System@out.println("hello")'
  ognl '@com.example.UserService@getInstance()'
  

• 使用场景：动态执行代码，查看/修改状态

2. redefine — 热更新代码

• 功能：加载外部的 .class 文件，redefine 到 JVM 中

• 格式：redefine <class 文件路径>

• 使用场景：紧急修复线上小问题，不用重启

• 注意：不能新增字段和方法，不能修改方法签名，只能修改方法体

【常见使用场景总结】

| 场景 | 推荐命令 | |------|----------| | 接口慢 | trace + watch | | CPU 高 | profiler 火焰图 | | 内存问题 | heapdump + MAT | | 偶现问题 | tt 记录回溯 | | 线上代码不对 | jad 反编译确认 | | 类加载冲突 | sc + classloader | | 紧急修复 | redefine 热更新 | | 方法调用统计 | monitor 统计 QPS、耗时 |

高频追问

追问1：Arthas 的实现原理是什么？

Arthas 基于 Java Agent + 字节码增强技术实现：

1. Java Agent 机制：

   • Arthas 是一个 Java Agent，通过 attach 机制挂载到目标 JVM 上

   • 使用 Instrumentation API 来修改已加载类的字节码

2. 字节码增强：

   • 使用 ASM 框架操作字节码

   • 对目标类的目标方法进行增强，插入监控代码

   • 比如 watch 命令，就是在方法入口和出口插入代码，获取入参和返回值

3. 通信机制：

   • Arthas 服务端运行在目标 JVM 进程内

   • 客户端通过 telnet 或 HTTP 连接到服务端

4. 为什么不需要重启？

   • 使用了 Instrumentation 的 retransformClasses 机制

   • 可以在运行时重新转换已加载的类

   • 对字节码进行增强，不需要重启应用

追问2：watch 和 trace 的区别？

| 维度 | watch | trace | |------|-------|-------| | 关注点 | 方法的输入输出 | 方法内部的执行路径和耗时 | | 看什么 | 入参、返回值、异常 | 调用了哪些子方法，每个耗时多少 | | 视角 | "面"上的观察，整体行为 | "线"上的追踪，内部细节 | | 适用场景 | 排查业务逻辑问题 | 排查性能问题 |

简单说：watch 看方法的输入输出，trace 看方法的内部耗时。

追问3：Arthas 会影响线上性能吗？

会有一定影响，但通常很小：

1. 影响程度：

   • 正常使用下，对性能影响很小，一般在 5% 以内

   • 如果监控的方法调用非常频繁，影响会大一些

   • trace 命令因为要追踪整个调用链，影响比 watch 大

2. 为什么影响小：

   • Arthas 只对指定的类和方法做增强，不是所有类

   • 增强的代码很轻量，主要是记录数据

   • 采样类的命令（如 profiler）是采样，不是全量

3. 注意事项：

   • 不要监控过于频繁的方法（如循环内调用的方法）

   • 使用 -n 参数限制执行次数，用完及时停止

   • 不要长时间开启大量监控

   • 高峰期谨慎使用

追问4：Arthas 可以排查哪些问题？不能排查什么？

可以排查的问题：

1. 方法调用问题：入参、返回值、异常、调用栈

2. 性能问题：方法耗时、CPU 热点、火焰图

3. 类加载问题：类冲突、类加载器、反编译

4. JVM 状态：内存、GC、线程、系统属性

5. 热修复：小问题可以 redefine 热更新

6. 内存问题：导出堆 dump

不能排查的问题：

1. 堆内存泄漏的详细分析（还是要用 MAT）

2. GC 详细调优（还是要 GC 日志）

3. 本地内存（堆外内存）泄漏

4. 操作系统层面问题（CPU、IO、网络等）

5. 新增字段/方法的热更新（redefine 有限制）

8. JVM 性能问题如何定位

标准答案

【性能问题的常见表现】

1. CPU 使用率高

2. 内存占用高 / OOM

3. 接口响应慢 / 吞吐量低

4. 频繁 GC / Full GC

5. 线程死锁 / 线程数过多

6. 磁盘 IO 高 / 网络 IO 高

【定位整体思路】

1. 先宏观后微观：先看整体系统状态，再深入细节

2. 先定位现象，再分析原因：先确定是哪类问题，再深挖原因

3. 先排除法，再深入：先排除明显不可能的，缩小范围

4. 数据驱动：一切以监控数据为准，不要猜

【CPU 使用率高定位流程】

第一步：确认 CPU 高

• top 命令：查看整体 CPU 使用率，找到占用高的进程 PID

第二步：定位到线程

• top -Hp <pid>：查看进程内所有线程的 CPU 使用情况

• 找到 CPU 使用率最高的线程 TID（十进制）

• printf "%x\n" <tid>：将线程 ID 转为十六进制

第三步：查看线程栈

• jstack <pid> > jstack.log：导出线程栈

• 在 jstack.log 中搜索十六进制的线程 ID

• 查看这个线程在做什么，执行到哪一行代码

第四步：分析原因

常见 CPU 高的原因：

1. 死循环：代码中有死循环，或者循环次数过多

2. 大量计算：复杂计算、加密、正则匹配等

3. 频繁 GC：GC 线程占用 CPU 高（转去查 GC 问题）

4. 正则表达式：复杂正则回溯，CPU 飙升

5. 序列化/反序列化：大量 JSON 序列化

6. 热点方法：某个方法被频繁调用

【内存问题定位流程】

第一步：确认内存问题

• top 命令：查看进程内存占用（RES 列）

• jstat -gcutil <pid>：查看堆各代使用情况

• 判断是堆内存高还是非堆内存高

第二步：判断是泄漏还是不足

• 内存持续上升，GC 后降不下来 → 内存泄漏

• 内存高但 GC 后能降下来，只是峰值高 → 内存不足或对象创建过多

第三步：导出堆 dump 分析

• jmap -dump:format=b,file=heap.hprof <pid>

• 用 MAT 分析：看占用最大的对象、泄漏嫌疑、引用链

第四步：针对性解决

• 内存泄漏：找到泄漏点，修复代码

• 内存不足：调大堆内存，或优化代码减少对象

【GC 问题定位流程】

第一步：收集 GC 数据

• 开启 GC 日志（推荐）：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

• 实时查看：jstat -gcutil <pid> 1000

第二步：分析 GC 情况

| 指标 | 异常表现 | 可能原因 | |------|----------|----------| | Minor GC 频率 | 太频繁 | 新生代太小或对象分配太快 | | Minor GC 耗时 | 太长 | 新生代太大或存活对象多 | | Full GC 频率 | 频繁 | 老年代不足、内存泄漏 | | Full GC 耗时 | 太长 | 老年代太大、存活对象多 | | 老年代趋势 | 持续上升 | 内存泄漏 |

第三步：定位 Full GC 原因

1. 老年代空间不足（对象晋升太快、大对象、内存泄漏）

2. 元空间不足（加载类太多）

3. 显式调用 System.gc()

4. 空间分配担保失败

第四步：优化方案

1. 调优内存大小（堆大小、新生代比例）

2. 调优对象生命周期（减少大对象、减少对象创建）

3. 更换 GC 收集器（Parallel → CMS/G1）

4. 解决内存泄漏

【接口慢/响应时间长定位流程】

第一步：确认慢的范围

• 所有接口都慢还是个别接口慢？

• 一直慢还是偶尔慢？

• 慢的比例有多少？

第二步：从外到内逐层排查（漏斗分析法）

客户端 → 网络 → 负载均衡/网关 → 应用服务 → 数据库/缓存/MQ → 外部依赖

第三步：应用层定位

1. 看日志：接口耗时日志、慢查询日志、异常日志

2. 用 Arthas：

   • trace：追踪方法内部调用链和耗时，找出最耗时的步骤

   • watch：看入参和返回值

   • stack：看调用栈

3. 看线程栈：

   • 大量线程 BLOCKED → 锁竞争

   • 大量线程 WAITING → 等待外部资源

   • 大量线程 RUNNABLE → CPU 密集或 IO 等待

第四步：常见慢的原因

1. 数据库慢：慢 SQL、没走索引、锁等待、连接池不够

2. 锁竞争：synchronized 或 Lock 竞争激烈，锁粒度太大

3. 外部调用慢：调用第三方接口超时，超时时间设置太长

4. GC 影响：GC 停顿导致接口耗时增加

5. 代码问题：循环嵌套、算法效率低、大量对象创建

【线程问题定位流程】

第一步：查看线程情况

• 线程总数：jstack <pid> | grep "java.lang.Thread.State" | wc -l

• 线程状态分布：

  jstack <pid> | grep "java.lang.Thread.State" | sort | uniq -c | sort -rn
  

第二步：分析线程状态

| 状态 | 说明 | 异常情况 | |------|------|----------| | RUNNABLE | 运行中 | 正常状态 | | BLOCKED | 阻塞，等待锁 | 大量 BLOCKED → 锁竞争严重 | | WAITING | 无限等待 | 大量 WAITING → 等待外部资源或线程池闲置 | | TIMED_WAITING | 计时等待 | sleep、wait 带超时 | | TERMINATED | 已终止 | 正常结束 |

第三步：死锁排查

1. jstack <pid> 输出最后会有 "Found one Java-level deadlock:"

2. 会列出死锁的线程和持有/等待的锁

3. 解决死锁：

   • 调整锁的顺序，所有线程按相同顺序获取锁

   • 减小锁粒度

   • 使用 tryLock 超时机制

   • 用并发工具类替代手动锁

【常用工具总结】

操作系统层面：

• top：CPU 和内存整体情况

• vmstat：系统整体负载

• iostat：磁盘 IO

• netstat / ss：网络连接

• pidstat：进程级别的 CPU、IO 统计

JDK 自带工具：

• jps：查看 Java 进程

• jstat：GC 统计

• jmap：堆内存分析、dump

• jstack：线程栈

• jinfo：JVM 参数

• jconsole / VisualVM：可视化监控

阿里工具：

• Arthas：在线诊断，最常用

• MAT：堆 dump 分析

• Druid：数据库连接池监控

高频追问

追问1：CPU 使用率 100% 怎么排查？

排查步骤：

1. top 找到占用 CPU 最高的 Java 进程 PID

2. top -Hp <pid> 找到进程内 CPU 最高的线程 TID

3. printf "%x\n" <tid> 将 TID 转成十六进制

4. jstack <pid> > jstack.log 导出线程栈

5. 在 jstack.log 中搜索十六进制 TID，找到对应的线程

6. 看线程的执行栈，定位到具体代码行

7. 分析代码为什么占用 CPU 高

常见原因：死循环、大量计算、正则回溯、频繁 GC、热点方法

追问2：如何判断是不是 GC 导致的性能问题？

判断方法：

1. 看 GC 日志：接口慢的时间点是否正好有 GC 发生？特别是 Full GC 的时间点是否和慢请求对应？

2. 看 jstat：持续观察 GC 频率和耗时，看 GC 后内存是否下降

3. 对比验证：GC 期间接口响应时间明显变长，GC 后恢复正常 → 基本可以确定是 GC 影响

如果 GC 频繁或停顿时间长，就需要进行 GC 调优。

追问3：线上服务突然变慢，怎么排查？

按从外到内、从宏观到微观的顺序：

1. 先看整体：

   • 服务器负载（CPU、内存、IO、网络）

   • 应用的 QPS、响应时间、错误率

   • 有没有发布变更？有没有流量突增？

2. 看应用层：

   • 错误日志有没有异常？

   • 慢接口是哪些？

   • JVM 监控：GC 情况、内存情况、线程情况

3. 看依赖：

   • 数据库：慢 SQL、连接数、锁等待

   • 缓存：命中率、连接数

   • MQ：堆积情况

   • 第三方接口：响应时间

4. 深入排查：

   • 用 Arthas trace 慢接口，找出慢的环节

   • 看线程栈，线程都在做什么

   • 看是否有锁竞争、死锁

常见原因：流量突增、发布引入 bug、数据库慢 SQL、第三方服务挂了、缓存雪崩、Full GC、死锁

追问4：什么是性能瓶颈的漏斗分析法？

漏斗分析法就是从请求的入口开始，逐层往下排查，像漏斗一样逐步缩小范围：

1. 第一层：客户端 → 网络（客户端本身？网络延迟？丢包？）

2. 第二层：负载均衡 / 网关（Nginx/网关层瓶颈？连接数？）

3. 第三层：应用服务（CPU 密集？IO 密集？哪个方法慢？）

4. 第四层：中间件（数据库？缓存？MQ？）

5. 第五层：外部依赖（第三方接口？其他服务？）

每一层都排查耗时占比，找到耗时最大的那一层，然后继续深入那一层排查，直到定位到根因。

追问5：如何建立性能监控体系？

完善的监控体系是快速定位性能问题的基础：

1. 基础监控：

   • 服务器层面：CPU、内存、磁盘 IO、网络

   • JVM 层面：堆内存、GC、线程数、类加载

   • 应用层面：QPS、响应时间、错误率

2. 链路监控：

   • 分布式调用链（SkyWalking、Pinpoint 等）

   • 能看到一次请求经过的所有环节和耗时

3. 业务监控：核心业务指标、接口维度监控

4. 告警体系：关键指标设置阈值告警，异常时及时通知

5. 日志体系：统一日志收集（ELK）、关键路径打点、慢查询日志、慢接口日志

📌 面试技巧：回答 JVM 性能定位问题时，一定要体现出系统性的排查思路，而不是零散的命令。先说整体方法论（先宏观后微观、数据驱动），再分场景展开，最后总结工具。这样面试官会觉得你有实际排查经验，而不是背题。

第二章 Java 并发（10题）

9. synchronized 底层原理

标准答案

synchronized 是 Java 中最基本的互斥同步机制，保证同一时刻只有一个线程执行被修饰的代码。

【三种使用方式】

| 使用方式 | 锁对象 | 作用范围 | |----------|--------|----------| | 修饰实例方法 | 当前实例对象（this） | 整个方法体 | | 修饰静态方法 | 当前类的 Class 对象 | 整个静态方法体 | | 修饰代码块 | 括号内的对象 | 代码块内部 |

【底层实现原理】

synchronized 的底层是基于 对象头的 Mark Word 和 monitor（监视器锁） 实现的。

1. 对象头 Mark Word

在 HotSpot 虚拟机中，对象在内存中分为三部分：对象头、实例数据、对齐填充。

对象头包含两部分信息：

• Mark Word：存储对象自身的运行时数据（哈希码、GC 分代年龄、锁状态标志等）

• 类型指针：指向方法区中类元数据的指针

Mark Word 在不同锁状态下的结构（32 位虚拟机）：

| 锁状态 | 25 bit | 4 bit | 1 bit | 2 bit | |--------|--------|-------|-------|-------| | 无锁 | 对象哈希码 | 对象分代年龄 | 0 | 01 | | 偏向锁 | 线程 ID + Epoch | 对象分代年龄 | 1 | 01 | | 轻量级锁 | 指向栈中锁记录的指针 | | | 00 | | 重量级锁 | 指向互斥量（monitor）的指针 | | | 10 | | GC 标记 | 空 | | | 11 |

2. monitor 监视器锁

• 每个对象都关联一个 monitor

• 当 monitor 被某个线程持有后，它便处于锁定状态

• 同步代码块：使用 monitorenter 和 monitorexit 指令实现

  • monitorenter：进入同步块，尝试获取 monitor 的所有权

  • monitorexit：退出同步块，释放 monitor 的所有权

• 同步方法：使用方法修饰符上的 ACC_SYNCHRONIZED 标志实现，本质也是获取 monitor

【锁升级过程】

JDK6 之后，synchronized 做了大量优化，引入了锁升级机制，锁的状态会随着竞争情况逐步升级：

无锁 → 偏向锁 → 轻量级锁 → 重量级锁

锁只能升级，不能降级（除了偏向锁可以重置）。

1. 偏向锁（Biased Locking）

• 适用场景：只有一个线程进入同步块，没有竞争

• 原理：当第一个线程进入同步块时，会在对象头的 Mark Word 中记录当前线程 ID，之后该线程进入/退出同步块时不需要 CAS 操作，直接判断线程 ID 是否是自己

• 优点：消除了无竞争情况下的同步原语，提高性能

• 撤销：当有另一个线程尝试获取锁时，偏向锁会撤销，升级为轻量级锁

2. 轻量级锁（Lightweight Locking）

• 适用场景：多个线程交替进入同步块，竞争不激烈

• 原理：

  • 线程进入同步块时，如果对象处于无锁状态，会在当前线程的栈帧中创建一个 Lock Record（锁记录）

  • 将对象头的 Mark Word 复制到 Lock Record 中

  • 使用 CAS 尝试将对象头的 Mark Word 更新为指向 Lock Record 的指针

  • 成功则获取轻量级锁，失败则说明有竞争，膨胀为重量级锁

• 解锁：使用 CAS 将 Lock Record 中的 Mark Word 复制回对象头，成功则解锁成功，失败则说明有竞争，膨胀为重量级锁

• 优点：在竞争不激烈的情况下，用 CAS 代替操作系统互斥量，减少线程切换开销

3. 重量级锁（Heavyweight Locking）

• 适用场景：多线程同时竞争，锁持有时间长

• 原理：依赖操作系统的互斥量（mutex）实现

• 特点：

  • 线程会被阻塞，需要从用户态切换到内核态，开销大

  • 但不会自旋消耗 CPU，适合锁持有时间长的场景

【其他优化】

1. 自旋锁（Spin Lock）

• 线程获取锁失败时，不立即阻塞，而是循环尝试获取锁（自旋）

• 优点：如果锁很快被释放，避免了线程上下文切换的开销

• 缺点：如果锁持有时间长，自旋会白白消耗 CPU

• JDK6 引入自适应自旋：自旋时间不固定，根据前一次在同一个锁上的自旋时间和锁拥有者的状态来决定

2. 锁消除（Lock Elimination）

• 虚拟机即时编译器在运行时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除

• 依据：逃逸分析技术，如果判断一段代码中堆上的所有数据都不会逃逸出去被其他线程访问到，就可以把它们当作栈上数据对待，认为是线程私有的，无需加锁

3. 锁粗化（Lock Coarsening）

• 如果有一系列连续的操作都对同一个对象反复加锁解锁，甚至加锁操作出现在循环体中，虚拟机会把锁的范围扩展（粗化）到整个操作序列的外部

• 减少频繁加锁解锁的开销

高频追问

追问1：synchronized 和 ReentrantLock 的区别？

| 维度 | synchronized | ReentrantLock | |------|-------------|---------------| | 实现层面 | JVM 层面，关键字 | JDK 层面，API 层面 | | 锁释放 | 自动释放，退出同步块自动释放 | 手动释放，必须在 finally 中 unlock() | | 可重入 | 可重入 | 可重入 | | 公平性 | 非公平锁 | 默认非公平，可设置为公平锁 | | 可中断 | 不可中断 | 可中断（lockInterruptibly） | | 超时获取 | 不支持 | 支持（tryLock 带超时时间） | | 条件变量 | 不支持（wait/notify） | 支持多个 Condition | | 性能 | 优化后性能不错 | 竞争激烈时更可控 |

追问2：什么是可重入性？synchronized 是可重入的吗？

可重入性：同一个线程可以多次获取同一把锁，不会自己把自己锁死。

synchronized 是可重入的。原理：

• 每个锁关联一个线程持有者和一个计数器

• 当计数器为 0 时表示锁未被持有

• 线程获取锁时，计数器 +1

• 同一个线程再次获取锁时，计数器继续 +1

• 退出同步块时计数器 -1，减到 0 时释放锁

这样就允许同一个线程多次进入同一个锁保护的代码块。

追问3：synchronized 是公平锁还是非公平锁？

synchronized 是非公平锁。

• 公平锁：按照线程请求锁的顺序来获取锁，先到先得

• 非公平锁：新来的线程可以插队，可能先于等待队列中的线程获取锁

为什么用非公平锁？

• 性能更好：减少线程挂起和唤醒的开销

• 新来的线程如果正好在锁释放时到达，可以直接获取，不用进入等待队列

• 缺点：可能产生饥饿现象，某些线程一直获取不到锁

ReentrantLock 默认也是非公平的，可以通过构造函数参数设置为公平锁。

追问4：对象头的 Mark Word 里存了什么？

Mark Word 存储对象自身的运行时数据，包括：

• 哈希码（HashCode）

• GC 分代年龄

• 锁状态标志位

• 线程持有的锁

• 偏向线程 ID

• 偏向时间戳

在不同的锁状态下，Mark Word 的内容是不同的，这是一种动态的数据结构，根据对象的状态复用存储空间。

追问5：为什么 wait/notify 方法要写在 synchronized 里面？

因为 wait/notify 是对象的 monitor 相关的操作，必须先持有对象的 monitor 才能调用。

具体原因：

1. wait 方法会释放对象的锁，如果没有锁就没法释放

2. notify 方法需要唤醒等待在这个对象 monitor 上的线程，如果没有锁就没法操作 monitor

3. 从语义上讲，等待/通知机制是基于共享状态的，需要同步来保证状态的可见性和原子性

如果不在 synchronized 中调用 wait/notify，会抛出 IllegalMonitorStateException。

10. volatile 的作用及内存可见性

标准答案

volatile 是 Java 提供的一种轻量级同步机制，有两个核心作用：保证可见性和禁止指令重排序。

【两大作用】

1. 保证内存可见性

• 当一个线程修改了 volatile 变量的值，新值对其他线程是立即可见的

• 实现原理：

  • 写操作时，加入 lock 前缀指令，将当前处理器缓存行的数据写回系统内存

  • 同时使其他处理器的缓存行无效（MESI 协议）

  • 其他线程读取时，发现缓存无效，重新从主内存加载最新值

2. 禁止指令重排序

• volatile 变量的读写操作前后，指令不能被重排序

• 实现原理：通过插入内存屏障（Memory Barrier）来实现

  • 在 volatile 写操作前插入 StoreStore 屏障

  • 在 volatile 写操作后插入 StoreLoad 屏障

  • 在 volatile 读操作后插入 LoadLoad 屏障

  • 在 volatile 读操作后插入 LoadStore 屏障

【volatile 能保证原子性吗？】

不能。 volatile 只能保证可见性和有序性，不能保证复合操作的原子性。

例如 i++ 操作，实际上是三步：

1. 读取 i 的值

2. 加 1

3. 写回新值

在多线程环境下，这三步可能被打断，导致结果不正确。

如果需要保证原子性，应该使用：

• synchronized

• ReentrantLock

• AtomicInteger 等原子类

【volatile 的应用场景】

1. 状态标记位

volatile boolean running = true;

// 线程 A
while (running) {
    // 执行业务逻辑
}

// 线程 B：可以安全地停止线程 A
running = false;

2. 双重检查锁（DCL）单例

public class Singleton {
    private volatile static Singleton instance; // 必须加 volatile
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        if (instance == null) {              // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {      // 第二次检查
                    instance = new Singleton(); // 禁止重排序
                }
            }
        }
        return instance;
    }
}

为什么要加 volatile？因为 new Singleton() 不是原子操作，可能被重排序，导致其他线程拿到半初始化的对象。

3. 一写多读的场景

• 一个线程写，多个线程读

• 写操作不频繁，读操作频繁

• volatile 的读性能和普通变量差不多，写性能稍差

【volatile 和 synchronized 的对比】

| 维度 | volatile | synchronized | |------|----------|--------------| | 作用范围 | 只能修饰变量 | 修饰方法、代码块 | | 原子性 | 不保证 | 保证 | | 可见性 | 保证 | 保证 | | 有序性 | 保证（禁止重排序） | 保证（串行执行） | | 性能 | 轻量级，无阻塞 | 重量级，有阻塞 | | 使用场景 | 状态标记、DCL 单例、一写多读 | 多写、复合操作、需要原子性 |

高频追问

追问1：volatile 的实现原理？

可见性实现：

• 写操作时加 lock 前缀指令

• lock 前缀指令会将当前处理器缓存行的数据写回主内存

• 通过 MESI 协议，使其他处理器的缓存行无效

• 其他线程读取时，缓存失效，重新从主内存加载

有序性实现：

• 通过内存屏障禁止指令重排序

• 内存屏障是 CPU 指令，确保屏障前后的指令按顺序执行

• JMM 为 volatile 定义了内存屏障插入策略

追问2：volatile 为什么不能保证原子性？

因为 volatile 只保证单次读/写的原子性，对于复合操作（如 i++），中间可能被其他线程打断。

举例：i = 0，两个线程同时执行 i++

• 线程 A 读取 i = 0

• 线程 B 读取 i = 0

• 线程 A 加 1，写回 i = 1

• 线程 B 加 1，写回 i = 1

• 结果应该是 2，实际是 1

volatile 只能保证每次读取的是最新值，但不能保证读-改-写的原子性。

追问3：DCL 单例为什么要加 volatile？

new Singleton() 不是原子操作，会被分解为三步：

1. 分配对象内存空间

2. 初始化对象（执行构造函数）

3. 将 instance 指向分配的内存地址

由于指令重排序，可能出现 1→3→2 的执行顺序：

• 线程 A 执行了 1 和 3，instance 不为 null 但还没初始化

• 线程 B 第一次检查发现 instance != null，直接返回

• 线程 B 使用未初始化的对象，导致报错

加 volatile 后，禁止指令重排序，保证 1→2→3 的顺序，避免拿到半初始化的对象。

追问4：volatile 读和写的内存屏障有什么不同？

volatile 写：

• 写之前插入 StoreStore 屏障：禁止之前的普通写和 volatile 写重排序

• 写之后插入 StoreLoad 屏障：禁止 volatile 写和之后的 volatile 读/写重排序

volatile 读：

• 读之后插入 LoadLoad 屏障：禁止 volatile 读和之后的普通读重排序

• 读之后插入 LoadStore 屏障：禁止 volatile 读和之后的普通写重排序

简单说：volatile 写之前的操作不能排到写之后，volatile 读之后的操作不能排到读之前。

追问5：happens-before 原则和 volatile 的关系？

happens-before 是 JMM 中定义的偏序关系，如果 A happens-before B，那么 A 的执行结果对 B 可见。

volatile 变量规则是 happens-before 的八大规则之一：

对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。

也就是说，线程 A 写了一个 volatile 变量，线程 B 读了同一个 volatile 变量，那么线程 A 在写 volatile 变量之前的所有操作，对线程 B 在读 volatile 变量之后都是可见的。

这就是 volatile 除了保证自身可见性之外，还能保证其前后普通变量的可见性的原因。

11. CAS 原理及 ABA 问题

标准答案

【什么是 CAS】

CAS（Compare And Swap，比较并交换）是一种无锁原子操作，用于在多线程环境下实现变量的原子更新。

操作过程： CAS 包含三个操作数：

• V：要更新的变量（内存位置）

• A：预期值（旧值）

• B：新值

只有当 V 的值等于 A 时，才将 V 的值更新为 B；否则不做任何操作。整个过程是原子的。

伪代码：

boolean compareAndSwap(V, A, B) {
    if (V == A) {
        V = B;
        return true;
    }
    return false;
}

【CAS 的底层实现】

CAS 是由 Unsafe 类提供的，底层是 CPU 的原子指令（如 x86 的 cmpxchg 指令）。

在 HotSpot 中：

• 单核 CPU：直接使用 cmpxchg 指令

• 多核 CPU：cmpxchg 指令 + lock 前缀，保证多核下的原子性

CAS 是一种乐观锁的实现：

• 假设没有冲突，直接操作

• 如果发现冲突（值不对），就重试，直到成功为止

• 不需要加锁，性能更高

【CAS 的应用】

1. 原子类（Atomic 系列）

java.util.concurrent.atomic 包下的原子类都是基于 CAS 实现的：

• AtomicInteger、AtomicLong、AtomicBoolean

• AtomicReference、AtomicStampedReference

• AtomicIntegerArray、AtomicLongArray

以 AtomicInteger 的 getAndIncrement() 为例：

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

// Unsafe 中的实现（自旋 + CAS）
public final int getAndAddInt(Object obj, long offset, int delta) {
    int v;
    do {
        v = getIntVolatile(obj, offset);  // 获取当前值
    } while (!compareAndSwapInt(obj, offset, v, v + delta)); // CAS 更新
    return v;
}

这就是典型的自旋 CAS：失败了就重试，直到成功。

2. 自旋锁

3. AQS 同步器框架

【ABA 问题】

什么是 ABA 问题？

CAS 在操作时会检查值有没有变化，如果值从 A 变成了 B，又变回了 A，CAS 会误认为值没有变化，但实际上已经被改过了。

线程1：读取值 A
线程2：将 A 改为 B
线程2：将 B 改回 A
线程1：CAS 操作，发现值还是 A，操作成功（但实际上值已经被改过了）

ABA 问题的影响：

• 在大多数场景下，ABA 问题不影响最终结果

• 但在某些场景下会有问题，比如栈操作、链表操作等，中间的变化可能导致数据结构不一致

如何解决 ABA 问题？

使用版本号或时间戳，每次修改都增加版本号，CAS 时不仅比较值，还要比较版本号。

Java 中提供了 AtomicStampedReference 和 AtomicMarkableReference：

1. AtomicStampedReference

• 给变量加上一个整数版本号（stamp）

• CAS 时同时比较引用和版本号

AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);

// 比较引用和版本号，都匹配才更新
ref.compareAndSet("A", "B", 0, 1);

2. AtomicMarkableReference

• 使用一个 boolean 标记（mark）代替整数版本号

• 只能标记"是否被修改过"，不能区分修改次数

• 适用于只关心是否被改过，不关心改了几次的场景

高频追问

追问1：CAS 的缺点是什么？

1. ABA 问题：值从 A 变 B 又变回 A，CAS 会误认为没变

   • 解决：加版本号（AtomicStampedReference）

2. 循环时间长开销大：

   • 自旋 CAS 如果长时间不成功，会一直循环，消耗 CPU

   • 解决：JVM 支持处理器提供的 pause 指令，提高自旋效率；或者限制自旋次数

3. 只能保证一个共享变量的原子操作：

   • CAS 只能对单个变量进行原子操作

   • 多个变量的复合操作无法用单个 CAS 保证原子性

   • 解决：用 AtomicReference 把多个变量封装成一个对象；或者用 synchronized

追问2：乐观锁和悲观锁的区别？

| 维度 | 悲观锁 | 乐观锁 | |------|--------|--------| | 思想 | 认为一定会有冲突，先加锁再操作 | 认为不会有冲突，直接操作，失败再重试 | | 实现 | synchronized、ReentrantLock | CAS、版本号 | | 适用场景 | 写多、竞争激烈 | 读多、竞争少 | | 性能 | 竞争少时开销大 | 竞争少时性能好，竞争激烈时自旋开销大 | | 举例 | 数据库行锁、表锁 | 数据库版本号、AtomicInteger |

追问3：CAS 和 synchronized 怎么选？

选择依据：

1. 竞争程度：

   • 竞争少 → CAS（乐观锁），性能更好

   • 竞争激烈 → synchronized，CAS 自旋消耗 CPU 反而更慢

2. 操作复杂度：

   • 单个变量的原子更新 → CAS（Atomic 系列）

   • 多个变量的复合操作 → synchronized 或 ReentrantLock

3. 功能需求：

   • 需要可中断、公平锁、超时、条件变量 → ReentrantLock

   • 简单的原子操作 → CAS

简单说：简单的原子操作用 CAS（Atomic 类），复杂的同步用 synchronized 或 Lock。

追问4：什么是 Unsafe 类？

Unsafe 是 sun.misc.Unsafe 包下的类，提供了一些底层操作，可以直接操作内存、线程、CAS 等。

主要功能：

1. 内存操作：分配内存、释放内存、直接读写内存

2. CAS 操作：compareAndSwapInt、compareAndSwapLong、compareAndSwapObject

3. 线程操作：park、unpark（挂起和唤醒线程）

4. 数组操作：获取数组第一个元素的偏移地址

5. 对象操作：获取字段的偏移地址，直接修改对象字段值

为什么叫 Unsafe？

• 因为这些操作很底层，使用不当可能导致内存泄漏、JVM 崩溃等问题

• 不建议直接在业务代码中使用

• 主要被 JDK 内部的并发包（JUC）使用

追问5：AtomicInteger 怎么实现的？

AtomicInteger 基于 CAS + 自旋实现：

1. 使用 Unsafe 类的 objectFieldOffset 获取 value 字段在对象中的偏移量

2. value 字段用 volatile 修饰，保证可见性

3. 所有原子操作都通过 Unsafe 的 CAS 方法实现

4. 如果 CAS 失败，就自旋重试，直到成功

核心代码：

public class AtomicInteger {
    private volatile int value;
    private static final long valueOffset;
    
    static {
        valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
    }
    
    public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
}

这是一种典型的无锁编程思想，不需要加锁就能保证原子性。

12. AQS 是什么？

标准答案

AQS（AbstractQueuedSynchronizer，抽象队列同步器）是 Java 并发包中用来构建锁和同步器的基础框架。

ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock、FutureTask 等都是基于 AQS 实现的。

【AQS 的核心思想】

如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列实现的。

【AQS 的核心组件】

1. 状态变量 state

• private volatile int state;

• 表示同步状态，用 volatile 修饰保证可见性

• 不同的同步器有不同的含义：

  • ReentrantLock：表示锁的重入次数

  • Semaphore：表示剩余许可数

  • CountDownLatch：表示剩余计数

• 提供三个方法操作 state：

  • getState()：获取状态

  • setState()：设置状态

  • compareAndSetState()：CAS 设置状态，保证原子性

2. CLH 同步队列

• 一个双向链表结构的队列，用来存放等待的线程

• 队列中的每个节点（Node）封装了线程、等待状态、前驱后继指针

• 队首节点是当前持有锁的线程（或者说，队首节点是正在获取锁的节点）

• 后续节点是等待获取锁的线程

Node 节点的重要属性：

• waitStatus：等待状态

  • SIGNAL（-1）：后继节点需要被唤醒

  • CANCELLED（1）：节点被取消

  • CONDITION（-2）：节点在条件队列中等待

  • PROPAGATE（-3）：传播状态（共享模式用）

  • 0：初始状态

• prev / next：前驱/后继节点

• thread：节点对应的线程

• nextWaiter：条件队列中的下一个节点

3. 两种资源共享方式

| 模式 | 说明 | 实现类 | |------|------|--------| | 独占模式（Exclusive） | 资源只能被一个线程持有 | ReentrantLock | | 共享模式（Share） | 资源可以被多个线程同时持有 | Semaphore、CountDownLatch、ReadWriteLock 的读锁 |

【AQS 的工作流程】

以独占模式获取锁为例：

1. 尝试获取锁（tryAcquire）

• 调用 tryAcquire(arg) 尝试获取锁

• 成功 → 直接返回，线程继续执行

• 失败 → 进入下一步

2. 加入等待队列

• 将当前线程封装成 Node 节点

• 使用 CAS 将节点加入到 CLH 队列的尾部

• 保证线程安全地入队

3. 阻塞等待（park）

• 节点入队后，找到前驱节点

• 如果前驱节点是 head（说明自己是第一个等待的），再尝试一次获取锁

• 还是失败，就调用 LockSupport.park() 挂起当前线程

• 等待被前驱节点唤醒

4. 释放锁（tryRelease）

• 持有锁的线程释放锁，调用 tryRelease(arg)

• 释放成功后，唤醒后继节点（LockSupport.unpark()）

• 后继节点被唤醒后，再次尝试获取锁

【AQS 的设计模式：模板方法】

AQS 使用了模板方法模式：

• AQS 定义了同步的骨架（入队、出队、阻塞、唤醒等）

• 具体的获取/释放逻辑由子类实现

子类需要实现的方法：

• tryAcquire(int)：独占方式尝试获取资源

• tryRelease(int)：独占方式尝试释放资源

• tryAcquireShared(int)：共享方式尝试获取资源

• tryReleaseShared(int)：共享方式尝试释放资源

• isHeldExclusively()：是否是独占模式

子类通过重写这些方法，结合 state 变量的含义，就能实现不同的同步器。

高频追问

追问1：AQS 为什么用双向队列？用单向队列行不行？

必须用双向队列，原因：

1. 节点取消时需要断开连接：

   • 当某个线程等待超时或被中断时，需要从队列中移除

   • 单向队列删除中间节点需要从头遍历，效率低

   • 双向队列可以直接找到前驱和后继，O(1) 时间删除

2. 唤醒后继节点时需要检查状态：

   • 释放锁时需要唤醒后继节点

   • 但后继节点可能已经取消（CANCELLED 状态）

   • 需要从后往前找第一个未取消的节点

   • 双向队列可以从 tail 往前找

3. 入队时的安全检查：

   • 入队时需要设置前驱节点的 next 指针

   • 如果 CAS 失败，需要重新尝试

   • 双向结构更安全

简单说：双向队列支持更高效的节点删除和状态检查。

追问2：AQS 中的 state 为什么用 volatile？

state 是 AQS 的核心状态变量，必须保证多线程下的可见性：

1. 可见性：一个线程修改了 state，其他线程能立即看到

2. 有序性：禁止指令重排序，保证 state 修改的顺序性

3. CAS 操作的基础：CAS 操作需要基于 volatile 的内存语义

state 的修改有两种方式：

• setState()：直接设置，用于已经持有锁的情况（单线程写）

• compareAndSetState()：CAS 设置，用于竞争情况下的原子更新

追问3：AQS 和 synchronized 的区别？

| 维度 | AQS | synchronized | |------|-----|-------------| | 实现层面 | Java 代码实现，JDK 层面 | JVM 层面，C++ 实现 | | 锁类型 | 可实现公平/非公平、独占/共享 | 非公平、独占 | | 可中断 | 支持 | 不支持 | | 超时获取 | 支持 | 不支持 | | 条件变量 | 支持多个 Condition | 只支持一个（wait/notify） | | 性能 | 功能更丰富，可控性强 | 优化后性能也不错 | | 使用方式 | 继承 AQS，实现模板方法 | 关键字，简单直接 |

AQS 是更灵活、功能更丰富的同步框架，synchronized 是更简单、更基础的同步机制。

追问4：什么是条件队列？AQS 的 Condition 怎么实现的？

Condition 是 AQS 提供的条件变量，相当于 synchronized 中的 wait/notify 机制，但更灵活，可以有多个条件队列。

实现原理：

• 每个 Condition 对象对应一个条件队列（单向链表）

• 调用 await() 时，线程释放锁，加入条件队列，阻塞等待

• 调用 signal() 时，唤醒条件队列中的第一个节点，转移到同步队列中

• 被唤醒的节点重新尝试获取锁

和 wait/notify 的区别：

• synchronized 只能有一个等待队列（对象的 wait set）

• AQS 的 Condition 可以有多个条件队列，每个条件对应一个队列

• 可以实现更精确的唤醒，比如只唤醒等待某个条件的线程

典型应用：ArrayBlockingQueue 的 notEmpty 和 notFull 两个条件。

追问5：为什么 AQS 的 CLH 队列要把 head 节点设置成空节点（哑节点）？

head 节点是一个"哑节点"（dummy node），不对应任何等待线程，它的作用：

1. 简化边界条件处理：

   • 如果没有哑节点，第一个节点入队和后续节点入队的逻辑不同

   • 有了哑节点，所有节点的入队逻辑都一样

   • 减少特殊情况的判断，代码更简洁

2. 避免头节点竞争：

   • head 是固定的哑节点，不会被多个线程同时修改

   • 只有 tail 会被多个线程竞争修改（入队）

   • 减少 CAS 竞争点

3. 释放锁时统一处理：

   • 释放锁时只需要唤醒 head 的后继节点

   • 不管队列中有多少节点，逻辑都一样

这是一种常见的链表优化技巧，用哨兵节点简化边界处理。

13. ReentrantLock 与 synchronized 区别

标准答案

ReentrantLock 和 synchronized 都是 Java 中常用的互斥同步机制，都实现了可重入锁，但在实现和功能上有很多区别。

【核心对比】

| 维度 | synchronized | ReentrantLock | |------|-------------|---------------| | 实现层面 | JVM 内置锁，关键字实现 | JDK 层面，基于 AQS 实现 | | 锁释放 | 自动释放，退出同步块自动释放 | 手动释放，必须在 finally 中 unlock() | | 可重入 | 支持 | 支持 | | 公平性 | 非公平锁 | 默认非公平，可设置为公平锁 | | 可中断 | 不可中断 | 支持可中断获取锁（lockInterruptibly） | | 超时获取 | 不支持 | 支持（tryLock 带超时时间） | | 条件变量 | 一个（wait/notify） | 支持多个 Condition | | 性能 | 优化后性能不错 | 竞争激烈时更可控 | | 灵活性 | 简单，不够灵活 | 灵活，功能丰富 | | 监控 | 难以监控 | 可以获取锁的状态、等待线程数等 |

【详细对比】

1. 实现层面

• synchronized：JVM 层面实现，由 monitorenter 和 monitorexit 指令实现

• ReentrantLock：JDK 层面实现，基于 AQS（AbstractQueuedSynchronizer）框架

2. 锁的释放

• synchronized：自动释放，方法正常退出或异常退出时自动释放锁，不会死锁

• ReentrantLock：手动释放，必须在 finally 中调用 unlock()，否则可能导致死锁

3. 公平性

• synchronized：非公平锁，新来的线程可以插队

• ReentrantLock：默认非公平，可以通过构造函数设置为公平锁

  ReentrantLock fairLock = new ReentrantLock(true);  // 公平锁
  ReentrantLock unfairLock = new ReentrantLock(false); // 非公平锁（默认）
  

4. 可中断性

• synchronized：不可中断，线程一旦进入等待，就只能等锁释放，不能中断

• ReentrantLock：支持可中断获取锁

  lock.lockInterruptibly(); // 等待锁的过程中可以被中断
  

5. 超时获取

• synchronized：不支持超时，只能一直等

• ReentrantLock：支持 tryLock 带超时时间

  if (lock.tryLock(5, TimeUnit.SECONDS)) {
      try {
          // 拿到锁了
      } finally {
          lock.unlock();
      }
  } else {
      // 超时了，没拿到锁
  }
  

6. 条件变量

• synchronized：只能有一个条件队列（对象的 wait set），wait/notify/notifyAll

• ReentrantLock：可以创建多个 Condition 对象，每个 Condition 对应一个条件队列

  ReentrantLock lock = new ReentrantLock();
  Condition notEmpty = lock.newCondition();
  Condition notFull = lock.newCondition();
  

  可以实现更精确的唤醒，比如只唤醒等待"非空"条件的线程。

7. 性能

• synchronized：经过多次优化（偏向锁、轻量级锁、自旋锁、锁消除、锁粗化），性能已经很好了

• ReentrantLock：在竞争激烈的情况下，性能更稳定，功能更丰富

【使用选择】

优先用 synchronized 的情况：

• 简单的同步需求

• 代码简洁，自动释放锁，不容易出错

• 不需要高级功能（公平、可中断、超时、多条件）

用 ReentrantLock 的情况：

• 需要公平锁

• 需要可中断获取锁

• 需要超时获取锁

• 需要多个条件变量

• 需要更细粒度的控制

高频追问

追问1：什么是可重入锁？为什么需要可重入？

可重入锁：同一个线程可以多次获取同一把锁，不会自己把自己锁死。

为什么需要可重入？

• 递归调用：一个同步方法调用另一个同步方法（同一个锁）

• 嵌套调用：同步代码块中又调用了同一个锁的同步方法

如果不可重入，线程在第二次获取锁时会被自己阻塞，导致死锁。

实现原理：

• 锁关联一个持有者线程和一个计数器

• 线程获取锁时，计数器 +1

• 同一个线程再次获取，计数器继续 +1

• 释放锁时计数器 -1，减到 0 时真正释放锁

synchronized 和 ReentrantLock 都是可重入的。

追问2：公平锁和非公平锁的区别？怎么实现的？

公平锁：按照线程请求锁的顺序获取，先到先得，不会产生饥饿。 非公平锁：新来的线程可以插队，可能先于等待队列中的线程获取锁。

性能对比：

• 非公平锁性能更好：减少线程挂起和唤醒的开销

• 公平锁更公平：不会有线程饥饿，但吞吐量低一些

ReentrantLock 的实现：

• 非公平锁（默认）：线程获取锁时先 CAS 尝试插队，失败了才入队

• 公平锁：线程获取锁时先检查队列中有没有在等待的线程，有就老老实实排队

追问3：ReentrantLock 的 tryLock 和 lock 有什么区别？

| 方法 | 是否阻塞 | 返回值 | 可中断 | 超时 | |------|----------|--------|--------|------| | lock() | 阻塞等待 | void | 不可中断 | 不支持 | | lockInterruptibly() | 阻塞等待 | void | 可中断 | 不支持 | | tryLock() | 不阻塞，立即返回 | boolean | 不可中断 | 不支持 | | tryLock(time, unit) | 阻塞等待超时 | boolean | 可中断 | 支持 |

使用场景：

• lock()：简单的同步，一定要拿到锁

• tryLock()：尝试获取，拿不到就做别的事，不阻塞

• tryLock(time)：可以等一会儿，超时就放弃

• lockInterruptibly()：等待过程中可以响应中断

追问4：ReentrantLock 怎么实现可重入的？

ReentrantLock 基于 AQS 实现可重入：

1. AQS 的 state 变量表示锁的持有次数

2. 线程获取锁时：

   • 如果 state == 0（锁空闲），CAS 设置 state = 1，设置当前线程为持有者

   • 如果 state > 0 且当前线程就是持有者，state++（重入）

   • 否则获取失败，进入等待队列

3. 线程释放锁时：

   • state--

   • 如果 state == 0，说明完全释放，清空持有者线程

   • 如果 state > 0，说明还有重入，不释放

4. 因为是独占锁，只有持有者线程才能释放，所以是线程安全的

追问5：什么是读写锁？ReentrantReadWriteLock 了解吗？

读写锁是一种特殊的锁，维护了一对锁：读锁和写锁。

规则：

• 读-读：不互斥，可以并发读

• 读-写：互斥，读的时候不能写，写的时候不能读

• 写-写：互斥，写的时候不能写

适用场景：读多写少的场景，比独占锁性能更好。

ReentrantReadWriteLock 的特点：

• 支持公平/非公平

• 支持可重入

• 写锁可以降级为读锁（锁降级），读锁不能升级为写锁

• 支持 Condition（写锁支持，读锁不支持）

state 变量的设计：

• 高 16 位：读锁持有次数

• 低 16 位：写锁持有次数（重入次数）

14. ThreadPoolExecutor 七大参数

标准答案

ThreadPoolExecutor 是 Java 中线程池的核心实现类，构造函数有 7 个核心参数。

【七大参数】

public ThreadPoolExecutor(
    int corePoolSize,           // 1. 核心线程数
    int maximumPoolSize,        // 2. 最大线程数
    long keepAliveTime,         // 3. 空闲线程存活时间
    TimeUnit unit,              // 4. 时间单位
    BlockingQueue<Runnable> workQueue,  // 5. 任务队列
    ThreadFactory threadFactory,        // 6. 线程工厂
    RejectedExecutionHandler handler    // 7. 拒绝策略
)

1. corePoolSize（核心线程数）

• 线程池中保持的核心线程数量

• 即使核心线程空闲，也不会被回收（除非设置了 allowCoreThreadTimeOut）

• 线程池初始化时，核心线程不会立即创建，而是有任务来的时候才创建

• 核心线程会一直存活，即使没有任务

2. maximumPoolSize（最大线程数）

• 线程池中允许的最大线程数量

• 当核心线程都在忙，且任务队列满了之后，会创建非核心线程来处理任务

• 总线程数 = 核心线程数 + 非核心线程数 ≤ maximumPoolSize

3. keepAliveTime（空闲线程存活时间）

• 非核心线程空闲时的存活时间

• 超过这个时间，空闲的非核心线程会被回收

• 如果设置了 allowCoreThreadTimeOut(true)，核心线程空闲超时也会被回收

4. unit（时间单位）

• keepAliveTime 的时间单位

• TimeUnit 枚举：NANOSECONDS、MICROSECONDS、MILLISECONDS、SECONDS、MINUTES、HOURS、DAYS

5. workQueue（任务队列）

• 存放等待执行的任务的阻塞队列

• 当核心线程都在忙时，新任务会先放入队列等待

常见的任务队列： | 队列类型 | 特点 | 适用场景 | |----------|------|----------| | ArrayBlockingQueue | 有界队列，基于数组 | 固定大小，可控 | | LinkedBlockingQueue | 无界队列（默认 Integer.MAX_VALUE），基于链表 | 任务量不大，不会爆队列 | | SynchronousQueue | 不存储任务，直接交给线程 | 任务量大，配合最大线程数 | | PriorityBlockingQueue | 优先级队列，按优先级执行 | 任务有优先级 | | DelayQueue | 延迟队列，定时任务 | 定时任务、延迟执行 |

6. threadFactory（线程工厂）

• 用来创建线程的工厂

• 可以给线程设置名字、优先级、是否守护线程等

• 默认使用 Executors.defaultThreadFactory()，创建的线程都是非守护的，优先级正常

7. handler（拒绝策略）

• 当线程池和队列都满了，新任务来的时候的处理策略

• JDK 提供了 4 种内置拒绝策略：

| 策略 | 说明 | |------|------| | AbortPolicy | 默认策略，直接抛出 RejectedExecutionException 异常 | | CallerRunsPolicy | 由提交任务的线程自己执行这个任务 | | DiscardPolicy | 直接丢弃任务，不抛异常 | | DiscardOldestPolicy | 丢弃队列中最老的任务，然后尝试重新提交 |

【线程池工作流程】

新任务来
   │
   ├─ 当前线程数 < corePoolSize → 创建核心线程执行任务
   │
   ├─ 当前线程数 >= corePoolSize → 尝试放入任务队列
   │     │
   │     ├─ 队列没满 → 放入队列等待
   │     │
   │     └─ 队列满了 → 检查是否达到 maximumPoolSize
   │           │
   │           ├─ 没达到 → 创建非核心线程执行任务
   │           │
   │           └─ 达到了 → 执行拒绝策略

一句话总结：核心线程 → 队列 → 非核心线程 → 拒绝策略

高频追问

追问1：为什么要用线程池？线程池的好处？

1. 降低资源消耗：通过复用已创建的线程，减少线程创建和销毁的开销

2. 提高响应速度：任务来了直接用已有线程，不用等线程创建

3. 提高线程的可管理性：

   • 统一管理线程数量，避免无限制创建线程

   • 可以监控和统计线程池的运行状态

4. 提供更多功能：定时执行、定期执行、延迟执行等

如果不用线程池，每个任务都创建一个新线程：

• 线程创建和销毁开销大

• 线程太多会占用大量内存

• 线程切换开销大

• 缺乏管理，容易失控

追问2：核心线程和非核心线程有什么区别？

| 维度 | 核心线程 | 非核心线程 | |------|----------|-----------| | 数量 | corePoolSize | maximumPoolSize - corePoolSize | | 存活时间 | 默认永久存活（除非 allowCoreThreadTimeOut） | 空闲超过 keepAliveTime 就回收 | | 创建时机 | 有任务就创建（初始为 0，懒加载） | 队列满了之后才创建 | | 任务执行 | 直接执行任务 | 直接执行任务 |

注意：线程池内部并没有区分核心线程和非核心线程，只是通过数量来控制。所有线程都是一样的，只是数量上有 corePoolSize 这个阈值。

追问3：常见的线程池有哪些？各自的适用场景？

Executors 提供了几种常用的线程池工厂方法：

| 线程池类型 | 核心参数 | 特点 | 适用场景 | |-----------|----------|------|----------| | FixedThreadPool | core=max，LinkedBlockingQueue | 固定线程数，无界队列 | 任务量稳定，长期任务 | | CachedThreadPool | core=0，max=Integer.MAX_VALUE，SynchronousQueue | 按需创建，60秒回收 | 任务量大但执行时间短 | | SingleThreadExecutor | core=max=1，LinkedBlockingQueue | 单线程，顺序执行 | 需要保证顺序执行的任务 | | ScheduledThreadPool | core 指定，max=Integer.MAX_VALUE，DelayedWorkQueue | 定时/延迟执行 | 定时任务、周期任务 |

⚠️ 注意：《阿里巴巴 Java 开发手册》强制要求不允许使用 Executors 创建线程池，因为：

• FixedThreadPool 和 SingleThreadPool：队列是无界的，可能堆积大量任务导致 OOM

• CachedThreadPool 和 ScheduledThreadPool：最大线程数是 Integer.MAX_VALUE，可能创建大量线程导致 OOM

应该用 ThreadPoolExecutor 构造函数手动创建，明确参数，控制资源。

追问4：线程池的状态有哪些？

ThreadPoolExecutor 有 5 种状态：

| 状态 | 说明 | |------|------| | RUNNING | 运行状态，接受新任务，处理队列中的任务 | | SHUTDOWN | 关闭状态，不接受新任务，但处理队列中的任务 | | STOP | 停止状态，不接受新任务，不处理队列任务，中断正在执行的任务 | | TIDYING | 整理状态，所有任务都终止了，工作线程数为 0 | | TERMINATED | 终止状态，terminated() 方法执行完成 |

状态转换：

RUNNING → SHUTDOWN → TIDYING → TERMINATED
RUNNING → STOP → TIDYING → TERMINATED

shutdown()：平滑关闭，不接受新任务，但队列中的任务会执行完 shutdownNow()：立即关闭，不接受新任务，队列中的任务也不执行了，尝试中断正在执行的任务

追问5：如何合理设置线程池参数？

线程池参数设置需要根据任务类型来定：

1. CPU 密集型任务

• 特点：大量计算，CPU 使用率高

• 核心线程数：CPU 核心数 + 1

  • +1 是为了防止某个线程因为偶然的页错误或其他原因暂停，保证 CPU 利用率

• 队列可以小一些

• 最大线程数和核心线程数差不多

2. IO 密集型任务

• 特点：大量 IO 操作（数据库、网络、文件），CPU 使用率低，线程大部分时间在等

• 核心线程数：CPU 核心数 × 2

  • 或者更精确的公式：核心数 × (1 + 等待时间/计算时间)

• 因为线程大部分时间在等，所以可以多开一些线程

• 队列可以大一些

3. 混合型任务

• 可以拆分成 CPU 密集型和 IO 密集型，分别用不同的线程池

• 或者根据实际情况调整

其他考虑因素：

• 任务优先级：用 PriorityBlockingQueue

• 任务执行时间：长时间任务和短时间任务分开

• 任务依赖：有依赖的任务要注意死锁问题

• 内存限制：队列不能太大，避免 OOM

没有固定的标准答案，需要根据实际业务场景和压测结果来调整。

15. CompletableFuture 常见用法

标准答案

CompletableFuture 是 JDK8 引入的异步编程工具，实现了 Future 和 CompletionStage 接口，支持函数式编程，可以链式调用，非常灵活。

【和 Future 的区别】

| 维度 | Future | CompletableFuture | |------|--------|-------------------| | 结果获取 | 阻塞等待（get()） | 支持回调，非阻塞 | | 链式调用 | 不支持 | 支持，链式组合多个异步任务 | | 异常处理 | 需手动 try-catch | 支持异常处理链 | | 组合能力 | 弱 | 强，支持 thenCompose、thenCombine 等 | | 手动完成 | 不支持 | 支持 complete 手动设置结果 |

Future 的问题：

• get() 是阻塞的，调用后线程就卡住了

• 不能链式调用，多个 Future 组合很麻烦

• 异常处理不方便

CompletableFuture 解决了这些问题，支持真正的异步编程。

【创建 CompletableFuture】

1. 直接创建

CompletableFuture<String> future = new CompletableFuture<>();
// 手动设置结果
future.complete("result");
// 手动设置异常
future.completeExceptionally(new RuntimeException("error"));

2. 提交任务（最常用）

// 无返回值，runAsync
CompletableFuture<Void> future1 = CompletableFuture.runAsync(() -> {
    System.out.println("异步任务");
});

// 有返回值，supplyAsync
CompletableFuture<String> future2 = CompletableFuture.supplyAsync(() -> {
    return "异步结果";
});

注意：默认使用 ForkJoinPool.commonPool()，也可以指定自定义线程池：

ExecutorService executor = Executors.newFixedThreadPool(10);
CompletableFuture.supplyAsync(() -> "result", executor);

【链式调用 - 结果处理】

1. thenApply / thenApplyAsync — 转换结果

• 接收上一步的结果，转换后返回新的结果

• 有返回值

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> "Hello")
    .thenApply(s -> s + " World")
    .thenApply(String::toUpperCase);
// 结果：HELLO WORLD

2. thenAccept / thenAcceptAsync — 消费结果

• 接收上一步的结果，消费掉，没有返回值

• 返回 CompletableFuture<Void>

CompletableFuture.supplyAsync(() -> "Hello")
    .thenAccept(s -> System.out.println("结果：" + s));

3. thenRun / thenRunAsync — 执行任务

• 不接收参数，也不返回值，上一步完成后执行一个任务

CompletableFuture.supplyAsync(() -> "Hello")
    .thenRun(() -> System.out.println("任务完成了"));

4. thenCompose / thenComposeAsync — 扁平化组合

• 接收上一步的结果，返回一个新的 CompletableFuture

• 用来连接两个 CompletableFuture，避免嵌套

// 不用 thenCompose 会嵌套
CompletableFuture<CompletableFuture<String>> nested = 
    CompletableFuture.supplyAsync(() -> "Hello")
        .thenApply(s -> CompletableFuture.supplyAsync(() -> s + " World"));

// 用 thenCompose 扁平化
CompletableFuture<String> flat = 
    CompletableFuture.supplyAsync(() -> "Hello")
        .thenCompose(s -> CompletableFuture.supplyAsync(() -> s + " World"));

【组合多个 CompletableFuture】

1. thenCombine — 两个任务都完成，组合结果

CompletableFuture<String> future1 = CompletableFuture.supplyAsync(() -> "Hello");
CompletableFuture<String> future2 = CompletableFuture.supplyAsync(() -> "World");

CompletableFuture<String> combined = future1.thenCombine(future2, (s1, s2) -> s1 + " " + s2);
// 结果：Hello World

2. allOf — 所有任务都完成

• 所有 CompletableFuture 都完成后才完成

• 返回 CompletableFuture<Void>，没有返回值

CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> "result1");
CompletableFuture<String> f2 = CompletableFuture.supplyAsync(() -> "result2");
CompletableFuture<String> f3 = CompletableFuture.supplyAsync(() -> "result3");

CompletableFuture<Void> all = CompletableFuture.allOf(f1, f2, f3);

3. anyOf — 任意一个任务完成

• 只要有一个 CompletableFuture 完成就完成

• 返回最先完成的结果

CompletableFuture<Object> any = CompletableFuture.anyOf(f1, f2, f3);

【异常处理】

1. exceptionally — 异常时返回默认值

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    throw new RuntimeException("出错了");
}).exceptionally(ex -> {
    System.out.println("异常：" + ex.getMessage());
    return "默认值";
});

2. handle — 不管正常还是异常都处理

• 有两个参数：结果和异常

• 可以同时处理正常和异常情况

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // 可能抛异常
    return "result";
}).handle((result, ex) -> {
    if (ex != null) {
        return "异常了，返回默认值";
    }
    return result;
});

3. whenComplete — 完成时的回调

• 不改变结果，只是在完成时执行一些操作

• 类似 finally

CompletableFuture.supplyAsync(() -> "result")
    .whenComplete((result, ex) -> {
        if (ex != null) {
            System.out.println("异常：" + ex.getMessage());
        } else {
            System.out.println("结果：" + result);
        }
    });

【获取结果】

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> "result");

// 1. 阻塞获取，抛受检异常
String result1 = future.get();

// 2. 阻塞获取，带超时
String result2 = future.get(5, TimeUnit.SECONDS);

// 3. 不阻塞，没完成就返回默认值
String result3 = future.getNow("default");

// 4. 阻塞，不抛受检异常
String result4 = future.join();

高频追问

追问1：thenApply 和 thenCompose 的区别？

| 方法 | 函数返回值 | 结果类型 | 用途 | |------|-----------|----------|------| | thenApply | 普通值 U | CompletableFuture<U> | 同步转换结果 | | thenCompose | CompletableFuture<U> | CompletableFuture<U> | 异步链式调用，扁平化 |

简单说：

• thenApply：函数返回普通值，用来做同步转换

• thenCompose：函数返回 CompletableFuture，用来连接两个异步操作，避免嵌套

类比：

• thenApply 像 Stream 的 map

• thenCompose 像 Stream 的 flatMap

追问2：thenApply 和 thenApplyAsync 的区别？

• thenApply：使用上一个任务的线程来执行（可能是调用线程，也可能是异步线程）

• thenApplyAsync：使用新的线程来执行（默认 ForkJoinPool，也可以指定线程池）

什么时候用 Async 版本？

• 如果任务比较耗时，不想占用当前线程

• 想指定特定的线程池来执行

• 想明确控制线程的使用

一般情况下，如果只是简单的转换，用 thenApply 就行，减少线程切换。

追问3：CompletableFuture 默认用的什么线程池？

默认使用 ForkJoinPool.commonPool()。

特点：

• 这是一个共享的线程池，整个 JVM 共用

• 默认线程数是 CPU 核心数 - 1

• 所有 CompletableFuture、并行流（parallelStream）都共用这个池

⚠️ 注意：

• 如果你的任务是 IO 密集型的，用默认线程池可能不够用

• 建议：生产环境中最好用自定义线程池，避免和其他任务竞争

  ExecutorService executor = new ThreadPoolExecutor(...);
  CompletableFuture.supplyAsync(() -> "result", executor);
  

追问4：CompletableFuture 的 complete 方法有什么用？

complete 方法可以手动设置 CompletableFuture 的结果，让它立即完成。

使用场景：

1. 异步转同步：把回调式的 API 转成 CompletableFuture

   // 比如一个回调式的接口
   CompletableFuture<String> future = new CompletableFuture<>();
   asyncCall(new Callback() {
       void onSuccess(String result) {
           future.complete(result);
       }
       void onError(Exception e) {
           future.completeExceptionally(e);
       }
   });
   

2. 超时处理：超时后设置默认结果

3. 测试：单元测试中模拟异步结果

注意：complete 只能调用一次，第二次调用会被忽略（返回 false）。

追问5：CompletableFuture 和 RxJava 有什么区别？

| 维度 | CompletableFuture | RxJava | |------|-------------------|--------| | 数据量 | 单个结果 | 多个结果（流） | | 背压 | 不支持 | 支持 | | 操作符 | 较少 | 非常丰富 | | 学习成本 | 低，简单 | 高，概念多 | | 适用场景 | 单个异步任务、简单组合 | 复杂流处理、事件驱动 |

简单说：

• 单个异步任务、简单的组合 → CompletableFuture，简单够用

• 复杂的数据流、事件流、需要背压 → RxJava，功能强大但复杂

16. ThreadLocal 原理及内存泄漏

标准答案

ThreadLocal 是 Java 中一种线程本地变量，每个线程都有自己的一份变量副本，线程之间互不干扰。

【ThreadLocal 的作用】

1. 线程隔离：每个线程有自己的变量副本，互不影响

2. 上下文传递：在同一个线程的不同方法间传递数据，不用层层传参

3. 线程安全：避免了多线程竞争，因为每个线程用自己的

常见使用场景：

• 保存用户登录信息（Session）

• 数据库连接（每个线程一个连接）

• 事务管理（Spring 的 TransactionSynchronizationManager）

• 日期格式化（SimpleDateFormat 线程不安全，用 ThreadLocal 每个线程一个）

• MDC 日志追踪（traceId 传递）

【ThreadLocal 的原理】

核心结构：

• 每个 Thread 对象都有一个 threadLocals 成员变量，类型是 ThreadLocal.ThreadLocalMap

• ThreadLocalMap 是一个自定义的 Map，key 是 ThreadLocal 对象，value 是线程本地变量的值

Thread
  └── threadLocals (ThreadLocalMap)
        ├── Entry[0]: key=ThreadLocal1, value=value1
        ├── Entry[1]: key=ThreadLocal2, value=value2
        └── ...

set 方法流程：

1. 获取当前线程

2. 获取当前线程的 ThreadLocalMap

3. 以 ThreadLocal 对象为 key，将值存入 Map

4. 如果 Map 不存在，创建一个

get 方法流程：

1. 获取当前线程

2. 获取当前线程的 ThreadLocalMap

3. 以 ThreadLocal 对象为 key，取出对应的值

4. 如果 Map 不存在，初始化并返回初始值

remove 方法流程：

1. 获取当前线程的 ThreadLocalMap

2. 移除对应的 Entry

【ThreadLocalMap 的结构】

ThreadLocalMap 是 ThreadLocal 的内部类，是一个自定义的哈希表：

Entry 节点：

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    Entry(ThreadLocal<?> k, Object v) {
        super(k);  // key 是弱引用
        value = v; // value 是强引用
    }
}

关键点：

• key（ThreadLocal）是弱引用（WeakReference）

• value 是强引用

为什么 key 用弱引用？

• 如果 ThreadLocal 对象没有外部强引用了，GC 时就会被回收

• 这样 ThreadLocalMap 中对应的 key 就变成了 null

• 避免 ThreadLocal 对象无法被回收

哈希冲突的解决：

• ThreadLocalMap 不用链表法，用的是线性探测法

• 冲突了就往后找下一个空位置

内存泄漏问题

【什么是内存泄漏？】

ThreadLocal 使用不当可能导致内存泄漏：不再使用的 value 无法被回收，持续占用内存。

【为什么会内存泄漏？】

原因分析：

1. ThreadLocalMap 的 key 是弱引用 → ThreadLocal 没有强引用时会被 GC 回收 → key 变成 null

2. 但是 value 是强引用 → key 变成 null 后，value 还在，无法通过 key 访问到

3. 如果线程一直存活（比如线程池中的线程），这个 value 就一直被引用，无法回收

4. 这样就产生了内存泄漏：key 没了，value 还占着内存

Thread（强引用）→ ThreadLocalMap（强引用）→ Entry（强引用）→ value（强引用）
                                          ↓
                                    key（弱引用）→ ThreadLocal（可能被GC回收）

【如何避免内存泄漏？】

1. 手动调用 remove() 方法（最重要）

• 使用完 ThreadLocal 后，手动调用 remove() 清除

• 这是最可靠的方式

try {
    threadLocal.set(value);
    // 使用
} finally {
    threadLocal.remove(); // 用完一定要 remove
}

2. ThreadLocalMap 自身的清理机制

• ThreadLocalMap 在 set、get、remove 等操作时，会顺便清理一些 key 为 null 的 Entry

• 但这是"启发式"的清理，不是每次都清理，不能完全依赖

3. 使用线程池时要特别注意

• 线程池中的线程会被复用，不会销毁

• 如果不 remove，下一个任务可能拿到上一个任务的值

• 而且 value 会一直存在，导致内存泄漏

【为什么 value 不用弱引用？**

因为 value 是我们存进去的数据，如果 value 也是弱引用，那 GC 时 value 可能就被回收了，我们再 get 的时候就拿不到了。

value 的生命周期应该由我们控制，所以必须是强引用。用完了手动 remove 就好。

高频追问

追问1：ThreadLocal 和 synchronized 的区别？

| 维度 | ThreadLocal | synchronized | |------|-------------|--------------| | 思路 | 空间换时间，每个线程一份副本 | 时间换空间，共用一份，加锁同步 | | 线程安全 | 隔离，不共享，所以安全 | 同步，串行访问，所以安全 | | 性能 | 高，没有竞争 | 低，有锁竞争和上下文切换 | | 适用场景 | 每个线程需要独立的副本 | 多个线程需要共享数据 | | 共享性 | 不共享 | 共享 |

简单说：

• 数据不共享 → ThreadLocal（每个线程自己用自己的）

• 数据要共享 → synchronized（大家排队用）

追问2：ThreadLocal 为什么用弱引用？不用强引用？

如果 key 用强引用：

• 即使 ThreadLocal 对象没有外部引用了，因为 ThreadLocalMap 还强引用着它

• ThreadLocal 对象就无法被 GC 回收

• 这样 ThreadLocal 对象本身也会内存泄漏

用弱引用的好处：

• ThreadLocal 没有外部强引用时，GC 会回收它

• key 变成 null，至少 ThreadLocal 对象本身不会泄漏

• 虽然 value 还可能泄漏，但比 key 和 value 都泄漏要好

这是一种权衡：用弱引用至少保证了 ThreadLocal 对象能被回收，value 的泄漏需要我们手动 remove 来解决。

追问3：ThreadLocal 用完为什么要 remove？不 remove 会怎样？

用完 remove 的原因：

1. 防止内存泄漏：线程池场景下线程复用，value 一直存在

2. 防止数据混乱：线程复用时，下一个任务可能读到上一个任务的值

3. 防止业务逻辑错误：比如用户信息串了

不 remove 的后果：

• 内存泄漏：value 一直占着内存，积累多了 OOM

• 数据串了：线程池复用线程，下一个任务拿到上一个的值，导致业务错误

所以最佳实践是：try-finally 中用完就 remove。

追问4：InheritableThreadLocal 了解吗？

InheritableThreadLocal 是 ThreadLocal 的子类，支持子线程继承父线程的 ThreadLocal 值。

普通 ThreadLocal：

• 子线程不能获取父线程的 ThreadLocal 值

• 因为每个线程有自己的 ThreadLocalMap

InheritableThreadLocal：

• 创建子线程时，会把父线程的 inheritableThreadLocals 复制一份给子线程

• 这样子线程就能获取到父线程设置的值

使用场景：

• 父子线程间传递数据

• 比如 traceId 传递，子线程也能拿到父线程的 traceId

注意：

• 是创建子线程时复制的，之后父线程再修改，子线程不会更新

• 线程池场景下要小心，因为线程是复用的，不是每次都创建新线程

追问5：ThreadLocalMap 为什么用线性探测法解决哈希冲突？不用链表？

ThreadLocalMap 使用线性探测法（开放寻址法）而不是链表法，原因：

1. 数据量小：

   • 每个线程的 ThreadLocal 数量一般不多

   • 冲突概率低，线性探测效率高

2. 内存连续：

   • 数组存储，内存连续，CPU 缓存命中率高

   • 访问速度快

3. Entry 是弱引用，需要清理：

   • ThreadLocalMap 需要清理 key 为 null 的 Entry

   • 数组结构清理起来更方便

   • 清理后可以 rehash 调整位置

4. 减少对象创建：

   • 链表法需要创建链表节点对象

   • 数组直接存储 Entry，对象更少

对于 ThreadLocal 这种数据量不大、但访问频繁的场景，线性探测法更合适。

17. ConcurrentHashMap 为什么线程安全

标准答案

ConcurrentHashMap 是 Java 中线程安全的 HashMap 实现，支持高并发的读写操作。

【演进历程】

JDK7：分段锁（Segment）

• 内部由 Segment 数组组成，每个 Segment 是一个独立的哈希表

• 每个 Segment 有自己的锁（继承 ReentrantLock）

• 不同 Segment 之间可以并发读写

• 并发度 = Segment 数量（默认 16）

• 缺点：分段数量固定，不够灵活；同一 Segment 内还是串行

JDK8：CAS + synchronized + 红黑树

• 放弃了分段锁，改用 Node 数组 + 链表/红黑树

• 读操作完全无锁（volatile + CAS）

• 写操作：

  • 数组元素为空时 → CAS 插入

  • 数组元素不为空时 → synchronized 锁桶头节点

• 锁粒度更细：锁的是每个桶（链表/红黑树的头节点）

• 并发度更高，性能更好

下面主要讲 JDK8 的实现。

【JDK8 ConcurrentHashMap 的线程安全实现】

1. 数组初始化的线程安全

• 使用 sizeCtl 变量控制初始化和扩容

• 初始化时用 CAS 保证只有一个线程能初始化数组

• 其他线程等待

2. put 操作的线程安全

计算哈希值 → 定位到桶
   │
   ├─ 桶为空 → CAS 插入新节点（无锁）
   │
   ├─ 桶不为空 → synchronized 锁桶头节点
   │     │
   │     ├─ 链表 → 遍历链表，找到相同 key 则更新，否则尾插
   │     │
   │     └─ 红黑树 → 红黑树插入逻辑
   │
   └─ 如果正在扩容 → 帮助扩容

关键点：

• CAS 插入：桶为空时，用 CAS 插入，不需要锁

• synchronized 锁桶头：桶不为空时，只锁这个桶的头节点，其他桶不受影响

• 锁粒度细：锁的是每个桶，而不是整个 Map

• 帮助扩容：如果发现正在扩容，当前线程也参与扩容，加快扩容速度

3. get 操作的线程安全

• get 操作完全无锁

• 因为 Node 的 val 和 next 用 volatile 修饰，保证可见性

• 数组用 volatile 修饰（实际是 Unsafe 操作），扩容时读的是新数组

• 读操作性能很高

4. 扩容的线程安全

• 多线程并发扩容

• 每个线程负责一段区间的桶迁移

• 用 transferIndex 控制迁移进度，CAS 分配任务

• 迁移时对每个桶加锁，保证迁移过程中数据一致

• 扩容期间，新的 put 操作会帮助扩容

5. size 计算的线程安全

• 用 baseCount + CounterCell[] 数组来计数

• 竞争少的时候直接 CAS 更新 baseCount

• 竞争激烈时，每个线程在自己的 CounterCell 里计数

• 最后统计时把所有 CounterCell 加起来 + baseCount

• 这是一种空间换时间的思路，避免计数时的竞争

【和 HashMap 的区别】

| 维度 | HashMap | ConcurrentHashMap | |------|---------|-------------------| | 线程安全 | 不安全 | 安全 | | 锁 | 无 | CAS + synchronized | | 性能 | 单线程下高 | 并发下高 | | null key/value | 支持 | 不支持 | | 迭代器 | fail-fast | weakly consistent（弱一致） |

【和 Hashtable 的区别】

| 维度 | Hashtable | ConcurrentHashMap | |------|-----------|-------------------| | 锁粒度 | 全表锁（synchronized 方法） | 桶级锁 | | 并发度 | 1 | 数组大小 | | 性能 | 差，所有操作串行 | 好，读无锁，写锁粒度细 | | 扩容 | 单线程扩容 | 多线程并发扩容 | | 状态 | 过时，不推荐 | 推荐使用 |

高频追问

追问1：JDK7 和 JDK8 的 ConcurrentHashMap 有什么区别？

| 维度 | JDK7 | JDK8 | |------|------|------| | 结构 | Segment 分段锁 | Node 数组 + 链表/红黑树 | | 锁机制 | ReentrantLock 锁 Segment | CAS + synchronized 锁桶头 | | 锁粒度 | Segment 级（默认 16 段） | 桶级（每个桶一个锁） | | 并发度 | Segment 数量 | 数组长度 | | 链表结构 | 链表 | 链表 + 红黑树（链表长度>8转红黑树） | | 扩容 | 单线程扩容 | 多线程并发扩容 | | 性能 | 分段内串行 | 更细粒度，性能更好 | | 计数方式 | segment 内计数，遍历求和 | baseCount + CounterCell |

JDK8 的改进主要是：锁粒度更细、并发度更高、性能更好。

追问2：ConcurrentHashMap 的 get 操作为什么不用加锁？

get 操作完全无锁，原因：

1. volatile 保证可见性：

   • Node 的 val 字段用 volatile 修饰

   • Node 的 next 字段用 volatile 修饰

   • table 数组的元素通过 Unsafe 的 volatile 方式读取

   • 保证一个线程修改后，其他线程能立即看到

2. 最终一致性：

   • get 操作不需要强一致性

   • 允许短暂的不一致（比如正在扩容时，可能读到旧数据）

   • 这是一种权衡：用弱一致性换取更高的读性能

3. 扩容时的处理：

   • 扩容时如果读的是旧桶，可能读到旧数据

   • 但最终会读到新数据

   • 这就是弱一致性（weakly consistent）

因为读操作远多于写操作，get 无锁大大提升了并发读的性能。

追问3：ConcurrentHashMap 为什么不支持 null key 和 null value？

ConcurrentHashMap 不允许 key 和 value 为 null，HashMap 允许。

原因：

1. 二义性问题：

   • 如果 get(key) 返回 null，你不知道是 key 不存在，还是 value 本身就是 null

   • 在单线程的 HashMap 中，可以用 containsKey 来判断

   • 但在并发环境下，containsKey 和 get 之间可能有其他线程修改了，结果不可靠

   • 为了避免这种歧义，ConcurrentHashMap 直接禁止 null value

2. 作者的设计哲学：

   • Doug Lea 认为 null 是导致歧义的根源

   • 并发容器中应该避免这种歧义

   • 所以 ConcurrentHashMap、ConcurrentSkipListMap 等都不支持 null

追问4：ConcurrentHashMap 的扩容过程是怎样的？

JDK8 的 ConcurrentHashMap 支持多线程并发扩容：

1. 触发条件：元素数量达到阈值（容量 × 负载因子）

2. 新容量：旧容量 × 2

3. 扩容过程：

   • 第一个线程发起扩容，初始化 nextTable

   • 用 transferIndex 标记迁移进度，从后往前迁移

   • 其他线程 put 时发现正在扩容，就参与进来帮忙

   • 每个线程领取一段区间的桶（默认 16 个桶）

   • 迁移一个桶时，先 synchronized 锁桶头节点

   • 把链表拆成两份（高位链和低位链），分别放到新数组的两个位置

   • 迁移完的桶设置为 ForwardingNode，表示已经迁移过了

   • 所有桶迁移完后，把 table 指向新数组

4. 帮助扩容：

   • put 时发现正在扩容（桶是 ForwardingNode），就调用 helpTransfer 帮忙

   • 这样可以利用多个线程的算力，加快扩容速度

追问5：ConcurrentHashMap 的 size() 怎么实现的？为什么不直接遍历计数？

ConcurrentHashMap 的 size() 不是精确值，是一个估计值。

实现方式：

1. 用 baseCount + CounterCell[] 数组计数

2. 元素增加/减少时，尝试用 CAS 更新 baseCount

3. 如果 CAS 失败（竞争激烈），就用 CounterCell 数组

   • 每个线程对应一个 CounterCell

   • 只更新自己的 CounterCell，没有竞争

4. size() 计算时，把 baseCount 和所有 CounterCell 的值加起来

为什么不直接遍历？

• 遍历整个数组计数太慢了

• 而且并发环境下，遍历过程中数据一直在变，结果也不准确

• 用 CounterCell 数组是空间换时间，计数操作 O(1)

这和 LongAdder 的思想是一样的，都是把一个值拆成多个，减少竞争。

18. CountDownLatch、CyclicBarrier、Semaphore 区别

标准答案

这三个都是 JUC 包下的同步工具类，用于线程间的协调，但用途不同。

【CountDownLatch — 倒计时门闩】

作用：一个线程等待多个线程完成任务后，自己再继续执行。

原理：

• 内部维护一个计数器，初始值为需要等待的线程数

• 每个线程完成任务后调用 countDown()，计数器减 1

• 等待线程调用 await()，当计数器减到 0 时，await 返回，继续执行

特点：

• 一次性使用，计数器减到 0 后不能重置

• 一个线程等多个线程（一对多）

• 不可重用

使用场景：

• 主线程等待多个子线程完成任务

• 模拟并发，多个线程同时开始（设为1，所有线程await，然后countDown）

CountDownLatch latch = new CountDownLatch(3);

// 3个工作线程
for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        // 做任务
        latch.countDown(); // 完成后计数减1
    }).start();
}

latch.await(); // 主线程等待，直到计数为0
System.out.println("所有任务都完成了");

【CyclicBarrier — 循环栅栏】

作用：一组线程互相等待，直到所有线程都到达屏障点，然后一起继续执行。

原理：

• 内部维护一个计数器，初始值为参与的线程数

• 每个线程到达屏障点时调用 await()，计数器减 1，然后等待

• 当计数器减到 0 时，所有等待的线程同时被唤醒，继续执行

• 计数器自动重置，可以重复使用（循环的意思）

特点：

• 可重复使用，计数器到 0 后自动重置

• 多个线程互相等待（多对多）

• 可重用

• 可以设置屏障动作（所有线程到达后执行一个任务）

使用场景：

• 多线程计算数据，最后合并结果

• 模拟并发，多个线程同时开始

• 阶段性的任务，每个阶段都要等所有线程完成

CyclicBarrier barrier = new CyclicBarrier(3, () -> {
    System.out.println("所有线程都到了，开始下一阶段");
});

for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        // 第一阶段任务
        barrier.await(); // 等待其他线程
        // 第二阶段任务
        barrier.await(); // 可以重复使用
        // 第三阶段任务
    }).start();
}

【Semaphore — 信号量】

作用：控制同时访问某个资源的线程数量，实现限流。

原理：

• 内部维护一个许可（permit）数量

• 线程访问资源前调用 acquire() 获取许可，许可数减 1

• 用完后调用 release() 释放许可，许可数加 1

• 如果许可用完了，acquire 就阻塞等待

特点：

• 控制并发数量

• 可以公平/非公平

• 可以一次性获取/释放多个许可

• 可重用

使用场景：

• 限流：控制同时访问某个资源的线程数

• 池化资源：连接池、对象池等

Semaphore semaphore = new Semaphore(10); // 最多10个线程同时访问

// 每个线程访问前获取许可
semaphore.acquire();
try {
    // 访问资源
} finally {
    semaphore.release(); // 释放许可
}

【三者对比】

| 维度 | CountDownLatch | CyclicBarrier | Semaphore | |------|---------------|---------------|-----------| | 作用 | 一个线程等多个线程完成 | 多个线程互相等待 | 控制并发线程数 | | 计数器 | 一次性，减到0就不能用了 | 可循环，自动重置 | 可增减，重复使用 | | 等待关系 | 1个等N个 | N个互相等 | N个等M个许可 | | 释放方式 | countDown 减计数 | await 减计数并等待 | acquire/release | | 可重用 | 不可 | 可 | 可 | | 典型场景 | 主线程等子线程 | 多线程阶段同步 | 限流、资源池 |

高频追问

追问1：CountDownLatch 和 CyclicBarrier 的区别？

这是最常问的对比题：

| 维度 | CountDownLatch | CyclicBarrier | |------|---------------|---------------| | 等待关系 | 1个线程等N个线程 | N个线程互相等 | | 计数器 | 一次性，不能重置 | 可循环，自动重置 | | 减计数方式 | countDown()，调用线程不阻塞 | await()，调用线程阻塞等待 | | 谁来减 | 工作线程减，主线程等 | 所有线程都减，都等 | | 屏障动作 | 没有 | 可以设置 Runnable，所有线程到齐后执行 | | 类比 | 发令枪：所有人准备好，裁判一声令下开始 | 团建：等人到齐了一起出发 |

简单记：

• CountDownLatch：倒计时，一个人等所有人

• CyclicBarrier：栅栏，大家一起等，到齐了一起走

追问2：CountDownLatch 和 join 的区别？

| 维度 | CountDownLatch | Thread.join() | |------|---------------|---------------| | 实现 | AQS 实现 | 基于 Object 的 wait/notify | | 灵活性 | 灵活，可以在任意位置 countDown | 必须等线程执行完 | | 控制粒度 | 可以控制到某个步骤就 countDown | 只能等整个线程结束 | | 线程池 | 适合线程池（线程不会退出） | 不适合线程池（线程复用不会结束） | | 用法 | 手动调用 countDown | 调用 thread.join() |

用线程池的时候，线程是复用的，不会退出，所以不能用 join，这时候 CountDownLatch 更合适。

追问3：Semaphore 的公平和非公平是什么意思？

Semaphore 有公平和非公平两种模式：

• 非公平模式（默认）：新来的线程可以插队，不一定按先来后到的顺序获取许可

  • 性能更好，减少线程切换

  • 可能产生饥饿

• 公平模式：按线程请求的顺序获取许可，先到先得

  • 公平，不会饥饿

  • 性能稍差，需要维护队列

和 ReentrantLock 的公平/非公平是一样的道理。

追问4：Semaphore 能实现互斥锁吗？和 ReentrantLock 有什么区别？

可以。Semaphore 初始化为 1 个许可，就可以实现互斥锁的效果。

但和 ReentrantLock 还是有区别：

| 维度 | Semaphore(1) | ReentrantLock | |------|-------------|---------------| | 可重入 | 不可重入（同一个线程 acquire 两次会死锁） | 可重入 | | 公平性 | 支持公平/非公平 | 支持公平/非公平 | | 可中断 | 支持 | 支持 | | 条件变量 | 不支持 | 支持 Condition | | 用途 | 主要用于限流 | 主要用于互斥同步 |

Semaphore 不是专门的锁，它的主要用途是控制并发数量。如果只是需要互斥锁，还是用 ReentrantLock 更合适。

追问5：什么是 Phaser？

Phaser（阶段器）是 JDK7 引入的更灵活的同步工具，可以看作是 CountDownLatch 和 CyclicBarrier 的结合体。

特点：

1. 可动态调整参与者数量：CountDownLatch 和 CyclicBarrier 的数量是固定的，Phaser 可以随时注册/注销

2. 可重复使用，支持多阶段：类似 CyclicBarrier，但更灵活

3. 支持分层：可以有父子 Phaser，减少竞争

适用场景：

• 参与者数量不固定的多阶段任务

• 比 CyclicBarrier 更灵活，但也更复杂

一般面试中 CountDownLatch、CyclicBarrier、Semaphore 问得更多，Phaser 了解一下就行。

📌 面试技巧：回答并发相关问题时，一定要结合实际场景来说，不要只说概念。比如讲 CountDownLatch 就说"主线程等多个子线程加载资源"，讲 Semaphore 就说"接口限流"。这样面试官会觉得你真的用过，而不是背题。

第三章 Spring（10题）

19. Spring IOC 原理

标准答案

IOC（Inversion of Control，控制反转）是 Spring 的核心思想之一，指的是对象的创建和依赖关系的管理交给 Spring 容器来负责，而不是由开发者手动 new 对象。

【什么是 IOC】

控制反转：

• 传统方式：自己 new 对象，自己管理依赖（主动控制）

• IOC 方式：对象由 Spring 容器创建和管理，需要的时候从容器拿（被动接收）

DI（Dependency Injection，依赖注入）：

• DI 是 IOC 的实现方式

• 指对象的依赖关系由容器注入，不需要自己创建依赖对象

• IOC 是思想，DI 是实现

IOC 的好处：

1. 解耦：对象之间的依赖关系由容器管理，降低耦合度

2. 便于测试：可以方便地替换实现，注入 Mock 对象

3. 提高可维护性：修改依赖关系不需要改代码，改配置就行

4. 对象生命周期管理：由容器统一管理

【IOC 容器的核心组件】

1. BeanFactory

• Spring 最底层的接口，是 IOC 容器的基本实现

• 提供了最基本的 bean 管理功能（getBean、containsBean 等）

• 特点：懒加载，第一次 getBean 的时候才初始化 bean

• 一般不直接使用，是 Spring 内部使用的

2. ApplicationContext

• BeanFactory 的子接口，功能更丰富

• 提供了更多企业级功能：

  • 国际化（i18n）

  • 资源加载（Resource）

  • 事件发布/监听（ApplicationEvent）

  • 环境变量（Environment）

• 特点：默认启动时就初始化所有单例 bean（非懒加载）

• 是我们平时用得最多的容器

常见的 ApplicationContext 实现：

• ClassPathXmlApplicationContext：从 classpath 加载 XML 配置

• FileSystemXmlApplicationContext：从文件系统加载 XML 配置

• AnnotationConfigApplicationContext：基于注解配置（最常用）

• AnnotationConfigWebApplicationContext：Web 环境下的注解配置

【Bean 的定义：BeanDefinition】

Spring 把每个 bean 的定义信息封装成一个 BeanDefinition 对象，包含：

• bean 的类名（className）

• 作用域（scope：singleton/prototype 等）

• 构造函数参数（constructor arguments）

• 属性值（property values）

• 自动装配模式（autowire mode）

• 懒加载（lazy-init）

• 初始化方法（init-method）

• 销毁方法（destroy-method）

• 等等...

BeanDefinition 就是 bean 的"配方"，Spring 根据这个配方来创建和管理 bean。

【IOC 容器的初始化流程】

以 AnnotationConfigApplicationContext 为例：

1. 容器启动

• 创建 ApplicationContext 对象

• 加载配置类（@Configuration 标注的类）

2. BeanDefinition 的加载（BeanDefinitionReader）

• 扫描指定包下的类（@ComponentScan）

• 识别 @Component、@Service、@Controller、@Repository、@Configuration 等注解

• 把每个类解析成 BeanDefinition 对象

• 注册到 BeanDefinitionRegistry 中（一个 Map）

3. BeanFactoryPostProcessor 处理

• 容器初始化后，bean 实例化前

• 可以修改 BeanDefinition 的属性

• 典型应用：PropertySourcesPlaceholderConfigurer（解析 ${} 占位符）

4. 实例化 bean

• 遍历所有 BeanDefinition

• 根据 BeanDefinition 创建 bean 实例

• 单例 bean 默认在容器启动时就创建（非懒加载）

• prototype 类型每次 getBean 时创建

5. 依赖注入

• 给 bean 的属性赋值

• 解析 @Autowired、@Resource 等注解

• 注入依赖的其他 bean

6. BeanPostProcessor 处理

• bean 初始化前后的后置处理器

• 可以对 bean 进行增强、包装

• 典型应用：

  • @PostConstruct 注解的处理

  • AOP 代理的创建（AnnotationAwareAspectJAutoProxyCreator）

7. 初始化 bean

• 调用 InitializingBean 的 afterPropertiesSet 方法

• 调用自定义的 init-method

8. 容器就绪

• 所有单例 bean 都创建好了

• 可以使用了

【依赖注入的方式】

1. 构造器注入

@Component
public class UserService {
    private final UserDao userDao;
    
    public UserService(UserDao userDao) {
        this.userDao = userDao;
    }
}

• 优点：依赖不可变、保证不为 null、保证完全初始化

• 推荐使用，Spring 官方推荐

2. Setter 注入

@Component
public class UserService {
    private UserDao userDao;
    
    @Autowired
    public void setUserDao(UserDao userDao) {
        this.userDao = userDao;
    }
}

• 优点：可选依赖，可以修改

• 适合可选的依赖

3. 字段注入（最常用但不推荐）

@Component
public class UserService {
    @Autowired
    private UserDao userDao;
}

• 优点：简单方便

• 缺点：依赖不可变、不能在构造时保证不为 null、不利于测试、循环依赖问题

• 生产代码中不推荐，测试代码中可以用

高频追问

追问1：BeanFactory 和 ApplicationContext 的区别？

| 维度 | BeanFactory | ApplicationContext | |------|-------------|-------------------| | 功能 | 基础的 bean 管理 | 完整的企业级功能 | | 国际化 | 不支持 | 支持 | | 资源加载 | 不支持 | 支持（Resource 接口） | | 事件机制 | 不支持 | 支持（ApplicationEvent） | | 环境变量 | 不支持 | 支持（Environment） | | 初始化时机 | 懒加载，getBean 时才初始化 | 默认启动时初始化所有单例 | | 使用场景 | Spring 内部使用 | 开发者使用 | | 层级 | 顶层接口 | BeanFactory 的子接口 |

简单说：BeanFactory 是低配版，ApplicationContext 是高配版。平时开发都用 ApplicationContext。

追问2：Spring 支持哪些作用域（scope）？

| 作用域 | 说明 | |--------|------| | singleton | 单例，整个容器中只有一个实例（默认） | | prototype | 原型，每次获取都创建新实例 | | request | Web 环境，每个 HTTP 请求一个实例 | | session | Web 环境，每个 Session 一个实例 | | application | Web 环境，整个 ServletContext 一个实例 | | websocket | WebSocket 环境，每个 WebSocket 连接一个实例 |

最常用的是 singleton 和 prototype。Web 相关的作用域需要在 Web 环境下才生效。

追问3：单例 bean 是线程安全的吗？

不一定。 Spring 的单例只是说容器中只有一个实例，但不保证线程安全。

• 如果 bean 是无状态的（没有成员变量，或者成员变量是只读的），就是线程安全的

• 如果 bean 是有状态的（有成员变量，且会被修改），就不是线程安全的

举例：

• Service 层一般是无状态的，只有方法，没有可变成员变量 → 线程安全

• 如果 Service 里有一个成员变量，多个线程同时修改 → 线程不安全

解决方法：

1. 尽量用无状态的 bean（推荐）

2. 用 ThreadLocal 保存状态

3. 用 synchronized 或 Lock 同步

4. 把作用域改成 prototype（不推荐，性能差）

追问4：什么是 BeanPostProcessor？有什么用？

BeanPostProcessor 是 bean 的后置处理器，可以在 bean 初始化前后做一些事情。

public interface BeanPostProcessor {
    // 初始化前调用
    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
    
    // 初始化后调用
    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}

常见应用：

1. @PostConstruct 注解处理：CommonAnnotationBeanPostProcessor

2. AOP 代理创建：AnnotationAwareAspectJAutoProxyCreator，在初始化后创建代理对象

3. 属性注入：AutowiredAnnotationBeanPostProcessor，处理 @Autowired

4. 自定义注解处理：自己实现，处理自定义注解

BeanPostProcessor 是 Spring 扩展点之一，很多功能都是通过它实现的。

追问5：什么是 FactoryBean？和 BeanFactory 的区别？

FactoryBean 是一个特殊的 bean，用来创建其他 bean。

public interface FactoryBean<T> {
    T getObject() throws Exception;      // 返回创建的对象
    Class<?> getObjectType();            // 返回对象类型
    boolean isSingleton();               // 是否单例
}

特点：

• getBean("beanName") 返回的是 FactoryBean 创建的对象（getObject() 的返回值）

• getBean("&beanName") 返回的是 FactoryBean 本身

使用场景：

• 创建复杂的 bean，创建过程很复杂

• 第三方框架集成，比如 MyBatis 的 SqlSessionFactoryBean

和 BeanFactory 的区别：

• BeanFactory：是 IOC 容器，用来管理所有 bean

• FactoryBean：是一个特殊的 bean，用来创建其他 bean

名字很像，但完全是两个东西。

20. Spring AOP 原理

标准答案

AOP（Aspect-Oriented Programming，面向切面编程）是对 OOP 的补充，用于处理系统中分散在各个模块的横切关注点（如日志、事务、权限、监控等）。

【什么是 AOP】

OOP 的问题：

• 日志、事务、权限这些功能，每个模块都需要

• 如果每个模块都写一遍，代码重复，维护困难

• 而且和业务逻辑混在一起，耦合度高

AOP 的解决思路：

• 把这些横切关注点抽出来，做成切面（Aspect）

• 通过动态代理的方式，在运行时把切面逻辑织入到业务方法中

• 业务代码只关心业务逻辑，不用管日志、事务这些

AOP 的好处：

1. 降低耦合：业务逻辑和横切逻辑分离

2. 代码复用：切面逻辑可以复用

3. 便于维护：修改切面逻辑只需要改一个地方

【AOP 的核心概念】

| 概念 | 说明 | |------|------| | Aspect（切面） | 横切关注点的模块化，比如日志切面、事务切面 | | Join Point（连接点） | 程序执行过程中的点，比如方法执行、异常抛出 | | Pointcut（切点） | 匹配连接点的表达式，定义哪些方法需要增强 | | Advice（通知） | 切面在特定连接点执行的动作，即增强逻辑 | | Weaving（织入） | 把切面逻辑应用到目标对象上，创建代理对象的过程 | | Target（目标对象） | 被增强的对象，原始对象 | | Proxy（代理） | AOP 框架创建的对象，包含目标对象和增强逻辑 |

Advice 的类型：

• Before：方法执行前执行

• After：方法执行后执行（不管正常还是异常）

• AfterReturning：方法正常返回后执行

• AfterThrowing：方法抛出异常后执行

• Around：环绕通知，方法执行前后都执行，最强大，可以决定是否执行原方法

【AOP 的实现原理：动态代理】

Spring AOP 基于动态代理实现，在运行时生成代理对象。

Spring 提供了两种动态代理方式：

1. JDK 动态代理

• 基于接口实现

• 目标类必须实现接口

• 生成的代理类实现目标类的所有接口

• 核心类：Proxy 和 InvocationHandler

• 优点：JDK 原生支持，不需要额外依赖

• 缺点：只能代理接口，不能代理类

2. CGLIB 动态代理

• 基于继承实现

• 目标类不需要实现接口

• 生成的代理类是目标类的子类

• 核心类：Enhancer 和 MethodInterceptor

• 优点：可以代理类，不需要接口

• 缺点：不能代理 final 类和 final 方法

Spring 的选择策略：

• 如果目标类实现了接口 → 默认用 JDK 动态代理

• 如果目标类没有实现接口 → 用 CGLIB

• 可以通过 @EnableAspectJAutoProxy(proxyTargetClass = true) 强制使用 CGLIB

【AOP 的织入时机】

| 织入时机 | 说明 | 实现方式 | |----------|------|----------| | 编译期织入 | 编译时把切面逻辑织入字节码 | AspectJ 编译器 | | 类加载期织入 | 类加载时织入 | AspectJ 加载时织入 | | 运行期织入 | 运行时生成代理对象 | Spring AOP（JDK/CGLIB 动态代理） |

Spring AOP 用的是运行期织入，在运行时生成代理对象。

【Spring AOP 的执行流程】

1. 容器启动时，扫描所有切面（@Aspect）

2. 解析切点表达式（@Pointcut）

3. bean 实例化后，BeanPostProcessor 检查是否需要被代理

4. 如果需要，根据目标类选择 JDK 或 CGLIB 生成代理对象

5. 调用方法时，调用的是代理对象的方法

6. 代理对象先执行切面逻辑（通知链），再执行目标方法

高频追问

追问1：JDK 动态代理和 CGLIB 的区别？

| 维度 | JDK 动态代理 | CGLIB | |------|-------------|-------| | 实现方式 | 基于接口 | 基于继承 | | 目标类要求 | 必须实现接口 | 不需要接口 | | 核心类 | Proxy、InvocationHandler | Enhancer、MethodInterceptor | | 性能 | 启动快，运行稍慢 | 启动慢，运行快 | | 限制 | 只能代理接口方法 | 不能代理 final 类和 final 方法 | | 默认使用 | 目标类有接口时默认 | 目标类无接口时默认 |

Spring Boot 2.x 之后，默认配置是 proxyTargetClass = true，也就是默认用 CGLIB。

追问2：Spring AOP 和 AspectJ 的区别？

| 维度 | Spring AOP | AspectJ | |------|-----------|---------| | 实现方式 | 动态代理（运行期织入） | 字节码操作（编译期/类加载期织入） | | 功能 | 简单，只支持方法级别的拦截 | 强大，支持字段、构造器等各种连接点 | | 性能 | 运行时生成代理，有一定开销 | 编译时织入，运行时无额外开销 | | 复杂度 | 简单，容易上手 | 复杂，需要学习 AspectJ 语法 | | 集成方式 | Spring 原生支持 | 需要 AspectJ 编译器或 agent | | 适用场景 | 简单的切面需求 | 复杂的切面需求 |

Spring AOP 是简化版的 AOP，满足大部分场景需求。如果需要更强大的功能，可以集成 AspectJ。

追问3：同一个方法被多个切面增强，执行顺序是怎样的？

多个切面增强同一个方法时，会形成一个拦截器链，按顺序执行。

默认顺序：

• 按切面的字母顺序执行（类名字典序）

• 不太可控

指定顺序的方式：

1. 实现 Ordered 接口：getOrder() 返回值越小，优先级越高

2. @Order 注解：value 值越小，优先级越高

3. @Priority 注解：value 值越小，优先级越高

执行顺序（以两个切面为例）：

高优先级切面 @Around 前
  低优先级切面 @Around 前
    目标方法
  低优先级切面 @Around 后
高优先级切面 @Around 后

类似洋葱模型，先进后出。

追问4：Spring 事务是怎么实现的？和 AOP 什么关系？

Spring 事务就是基于 AOP 实现的，事务切面就是一个 AOP 切面。

实现原理：

1. @EnableTransactionManagement 开启事务管理

2. 容器中注册一个 BeanPostProcessor（InfrastructureAdvisorAutoProxyCreator）

3. bean 实例化后，检查是否有 @Transactional 注解

4. 如果有，创建事务代理对象

5. 调用方法时，事务拦截器（TransactionInterceptor）拦截方法

6. 方法执行前：开启事务

7. 方法正常执行：提交事务

8. 方法抛出异常：回滚事务（默认 RuntimeException 和 Error 才回滚）

所以事务就是一个特殊的 AOP 切面，专门处理事务逻辑。

追问5：Spring AOP 为什么不能拦截 private 方法？

因为 Spring AOP 基于动态代理：

1. JDK 动态代理：基于接口，接口里的方法都是 public 的，没有 private 方法

2. CGLIB 动态代理：基于继承，子类不能重写父类的 private 方法

所以 private 方法不能被代理，也就不能被 AOP 拦截。

同样的，final 方法也不能被 CGLIB 代理（因为不能重写），static 方法也不能被代理。

如果需要拦截 private 方法，就得用 AspectJ（编译期织入）。

21. Bean 生命周期

标准答案

Spring Bean 的生命周期指的是 bean 从创建到销毁的整个过程。

【完整生命周期流程】

1. 实例化 Bean（调用构造函数）
   ↓
2. 属性注入（依赖注入，@Autowired）
   ↓
3. Aware 接口回调
   - BeanNameAware
   - BeanClassLoaderAware
   - BeanFactoryAware
   - ApplicationContextAware 等
   ↓
4. BeanPostProcessor 前置处理（postProcessBeforeInitialization）
   ↓
5. 初始化
   - @PostConstruct 注解
   - InitializingBean 接口的 afterPropertiesSet()
   - 自定义 init-method
   ↓
6. BeanPostProcessor 后置处理（postProcessAfterInitialization）
   ↓
7. Bean 就绪，可以使用了
   ↓
8. 销毁
   - @PreDestroy 注解
   - DisposableBean 接口的 destroy()
   - 自定义 destroy-method

【详细说明】

第一阶段：实例化

• 调用 bean 的构造函数，创建对象

• 此时对象已经创建，但属性还没赋值

第二阶段：属性注入

• 给 bean 的属性赋值，注入依赖

• 处理 @Autowired、@Resource、@Value 等注解

• 此时依赖的其他 bean 已经注入了

第三阶段：Aware 接口回调

• 如果 bean 实现了各种 Aware 接口，就回调对应的方法

• 让 bean 能获取到容器的一些资源：

  • BeanNameAware：获取 bean 的名字

  • BeanFactoryAware：获取 BeanFactory

  • ApplicationContextAware：获取 ApplicationContext

  • BeanClassLoaderAware：获取类加载器

  • EnvironmentAware：获取环境变量

  • 等等...

第四阶段：BeanPostProcessor 前置处理

• 调用所有 BeanPostProcessor 的 postProcessBeforeInitialization 方法

• 在初始化之前对 bean 做一些处理

• 比如 @PostConstruct 注解就是在这里处理的

第五阶段：初始化 按顺序执行：

1. @PostConstruct 注解标注的方法

2. InitializingBean 接口的 afterPropertiesSet() 方法

3. 自定义的 init-method（XML 或 @Bean(initMethod = "")）

这三个都是初始化方法，只是方式不同。

第六阶段：BeanPostProcessor 后置处理

• 调用所有 BeanPostProcessor 的 postProcessAfterInitialization 方法

• 在初始化之后对 bean 做一些处理

• AOP 代理就是在这里创建的

第七阶段：Bean 就绪

• bean 完全初始化好了，可以使用了

• 单例 bean 会一直存在容器中

• prototype 类型每次获取都创建新的

第八阶段：销毁 容器关闭时，按顺序执行：

1. @PreDestroy 注解标注的方法

2. DisposableBean 接口的 destroy() 方法

3. 自定义的 destroy-method

高频追问

追问1：@PostConstruct、InitializingBean、init-method 的执行顺序？

执行顺序：

1. @PostConstruct（注解方式，BeanPostProcessor 中处理）

2. InitializingBean.afterPropertiesSet()（接口方式）

3. init-method（XML/注解配置方式）

为什么 @PostConstruct 最先执行？ 因为 @PostConstruct 是在 BeanPostProcessor 的前置处理中执行的，在 InitializingBean 之前。

推荐使用哪种？

• 推荐用 @PostConstruct 注解，最灵活，和 Spring 耦合低

• InitializingBean 和 Spring 耦合度高

• init-method 是 XML 时代的产物，现在用得少了

追问2：BeanPostProcessor 和 BeanFactoryPostProcessor 的区别？

| 维度 | BeanFactoryPostProcessor | BeanPostProcessor | |------|-------------------------|-------------------| | 作用时机 | bean 实例化之前 | bean 实例化之后，初始化前后 | | 作用对象 | BeanDefinition（bean 的定义） | Bean 实例（已经创建好的对象） | | 能做什么 | 修改 bean 的定义信息 | 修改/包装 bean 实例 | | 典型应用 | PropertyPlaceholderConfigurer（解析占位符） | AOP 代理创建、@PostConstruct 处理 |

简单记：

• BeanFactoryPostProcessor：改配方（BeanDefinition）

• BeanPostProcessor：改成品（Bean 实例）

追问3：Spring 怎么解决循环依赖？

循环依赖：A 依赖 B，B 又依赖 A，形成循环。

Spring 解决循环依赖的方式：三级缓存 + 提前暴露对象

三级缓存：

1. singletonObjects：一级缓存，存放完全初始化好的 bean

2. earlySingletonObjects：二级缓存，存放提前暴露的 bean（实例化了但还没初始化）

3. singletonFactories：三级缓存，存放 bean 的工厂对象（ObjectFactory）

解决流程（以 A 和 B 循环依赖为例）：

1. 创建 A，实例化 A（调用构造函数）

2. A 还没初始化，把 A 的工厂对象放入三级缓存

3. 给 A 注入属性，发现需要 B

4. 去创建 B，实例化 B

5. B 还没初始化，把 B 的工厂对象放入三级缓存

6. 给 B 注入属性，发现需要 A

7. 去拿 A：一级缓存没有 → 二级缓存没有 → 三级缓存有 A 的工厂

8. 通过工厂拿到 A 的早期引用（还没初始化完的 A），放入二级缓存

9. B 拿到 A 了，B 初始化完成，放入一级缓存

10. 回到 A 的创建过程，A 拿到 B 了，A 初始化完成，放入一级缓存

注意：

• 只能解决单例的循环依赖

• 只能解决setter 注入的循环依赖（构造器注入不行，因为实例化时就需要依赖）

• prototype 作用域的循环依赖解决不了，直接抛异常

追问4：构造器注入为什么不能解决循环依赖？

因为构造器注入是在实例化的时候就需要依赖对象。

举例：A 的构造函数需要 B，B 的构造函数需要 A

• 创建 A → 调用构造函数 → 需要 B → 去创建 B

• 创建 B → 调用构造函数 → 需要 A → 去拿 A

• A 还没实例化完（构造函数都没执行完），三级缓存里也没有

• 拿不到 A → 抛异常

而 setter 注入是先实例化（调用构造函数），再注入属性。实例化完了就可以提前暴露到三级缓存中，所以能解决。

追问5：Bean 的生命周期中，哪些地方可以扩展？

Spring 提供了很多扩展点：

1. BeanFactoryPostProcessor：bean 实例化前，修改 BeanDefinition

2. BeanPostProcessor：bean 初始化前后，修改 bean 实例

3. Aware 接口：获取容器资源

4. InitializingBean：初始化逻辑

5. DisposableBean：销毁逻辑

6. @PostConstruct / @PreDestroy：初始化/销毁注解

7. init-method / destroy-method：自定义初始化/销毁方法

8. FactoryBean：自定义 bean 的创建逻辑

9. BeanDefinitionRegistryPostProcessor：注册 BeanDefinition

这些扩展点让 Spring 非常灵活，很多功能都是通过这些扩展点实现的。

22. Spring Boot 自动装配原理

标准答案

Spring Boot 的自动装配（Auto Configuration）是 Spring Boot 最核心的特性之一，能够根据 classpath 中的依赖自动配置 Spring 应用。

【什么是自动装配】

传统 Spring 开发需要手动配置大量的 XML 或注解，而 Spring Boot 只需要引入 starter 依赖，就能自动配置好对应的组件。

举例：

• 引入 spring-boot-starter-web → 自动配置好 Spring MVC、Tomcat、Jackson 等

• 引入 spring-boot-starter-data-redis → 自动配置好 RedisTemplate

• 引入 spring-boot-starter-jdbc → 自动配置好 DataSource、JdbcTemplate

自动装配的好处：

1. 开箱即用，不需要手动配置

2. 减少配置代码

3. 约定大于配置（Convention over Configuration）

【自动装配的核心注解：@SpringBootApplication】

Spring Boot 启动类上的 @SpringBootApplication 是一个组合注解，包含三个核心注解：

@SpringBootConfiguration  // 标记这是一个配置类
@EnableAutoConfiguration  // 开启自动装配（核心）
@ComponentScan            // 组件扫描
public @interface SpringBootApplication {
}

1. @SpringBootConfiguration

• 就是 @Configuration 的别名

• 标记这个类是 Spring 的配置类

2. @ComponentScan

• 扫描启动类所在包及其子包下的所有组件

• 把 @Component、@Service、@Controller 等注解的类注册到容器

3. @EnableAutoConfiguration

• 自动装配的核心注解

• 导入了 AutoConfigurationImportSelector

• 负责加载所有自动配置类

【自动装配的实现原理】

核心组件：AutoConfigurationImportSelector

@EnableAutoConfiguration 注解导入了 AutoConfigurationImportSelector，它的作用是：

1. 读取 META-INF/spring.factories 文件

2. 找到所有 key 为 org.springframework.boot.autoconfigure.EnableAutoConfiguration 的配置类

3. 根据条件过滤，筛选出需要的自动配置类

4. 把这些配置类导入到容器中

spring.factories 文件：

• 位于每个 starter 的 jar 包中

• 是一个 properties 文件，key=接口全限定名，value=实现类全限定名

• Spring Boot 启动时会加载所有 jar 包中的 spring.factories

• 自动配置类就是在这里定义的

条件注解（@Conditional）：

不是所有自动配置类都会生效，需要满足一定条件才会生效。Spring Boot 提供了一系列条件注解：

| 注解 | 作用 | |------|------| | @ConditionalOnClass | classpath 中有指定类才生效 | | @ConditionalOnMissingClass | classpath 中没有指定类才生效 | | @ConditionalOnBean | 容器中有指定 bean 才生效 | | @ConditionalOnMissingBean | 容器中没有指定 bean 才生效 | | @ConditionalOnProperty | 配置文件中有指定属性才生效 | | @ConditionalOnWebApplication | Web 应用才生效 | | @ConditionalOnNotWebApplication | 非 Web 应用才生效 | | @ConditionalOnExpression | SpEL 表达式为 true 才生效 |

这些条件注解让自动配置很智能：有对应的依赖才配置，用户自己配置了就用用户的。

【自动装配完整流程】

1. 启动 Spring Boot 应用，运行 main 方法
   ↓
2. 加载 @SpringBootApplication 注解
   ↓
3. @EnableAutoConfiguration 生效
   ↓
4. AutoConfigurationImportSelector 被加载
   ↓
5. 读取所有 META-INF/spring.factories 文件
   ↓
6. 获取所有自动配置类的全限定名
   ↓
7. 根据条件注解过滤（@ConditionalOnClass 等）
   ↓
8. 过滤后的自动配置类注册到容器
   ↓
9. 自动配置类中的 @Bean 方法创建对应的 bean
   ↓
10. 自动装配完成

【自定义 starter 的步骤】

如果要自己写一个 starter：

1. 创建一个自动配置类（@Configuration）

2. 在类上加上条件注解（@ConditionalOnClass 等）

3. 在类中定义 @Bean 方法，创建需要的 bean

4. 在 META-INF/spring.factories 中注册这个自动配置类

5. 打包发布

高频追问

追问1：spring.factories 文件的作用是什么？

spring.factories 是 Spring Boot 的扩展机制文件，位于 jar 包的 META-INF 目录下。

作用：

• 定义各种扩展点的实现类

• 格式是 properties 文件，key=接口/注解全限定名，value=实现类全限定名列表

• Spring Boot 启动时会加载所有 jar 包中的 spring.factories 文件

自动装配就是通过这个机制实现的：

• key = org.springframework.boot.autoconfigure.EnableAutoConfiguration

• value = 所有自动配置类的全限定名

除了自动配置，spring.factories 还用于：

• ApplicationContextInitializer

• ApplicationListener

• SpringApplicationRunListener

• 等等...

这是 Spring Boot 的 SPI 机制。

追问2：自动配置类的优先级是怎样的？

自动配置类的加载和应用有优先级机制：

1. 用户配置优先：

   • 如果用户自己配置了对应的 bean，自动配置就不生效

   • 通过 @ConditionalOnMissingBean 实现

   • 用户的配置覆盖自动配置

2. 自动配置类之间的顺序：

   • @AutoConfigureBefore：在某个配置类之前加载

   • @AutoConfigureAfter：在某个配置类之后加载

   • @AutoConfigureOrder：指定顺序，值越小优先级越高

3. 为什么需要顺序？

   • 有些配置依赖其他配置先完成

   • 比如 WebMvc 自动配置需要在 DataSource 自动配置之后？不，它们没关系

   • 比如 Redis 自动配置需要先有连接工厂

追问3：如何禁用某个自动配置？

方式一：在 @SpringBootApplication 上排除

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})

方式二：在配置文件中排除

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

方式三：用条件注解让它不满足条件

• 比如不引入对应的 starter 依赖

• 设置对应的配置属性为 false

追问4：@SpringBootApplication 注解包含哪几个注解？分别什么作用？

@SpringBootApplication 是一个组合注解，包含三个核心注解：

1. @SpringBootConfiguration

   • 就是 @Configuration 的别名

   • 标记这是一个 Spring 配置类

   • 可以在里面定义 @Bean

2. @EnableAutoConfiguration

   • 开启自动装配，最核心

   • 导入 AutoConfigurationImportSelector

   • 加载所有自动配置类

3. @ComponentScan

   • 组件扫描

   • 默认扫描启动类所在包及其子包

   • 把 @Component、@Service、@Controller 等注册到容器

另外还有一些其他注解，但这三个是核心。

追问5：Spring Boot 的 starter 是什么原理？

starter 是 Spring Boot 的一种依赖管理方式，把某个场景需要的所有依赖打包在一起。

starter 本身不包含代码，只是一个 pom.xml，声明了需要的依赖。

真正的自动配置代码在 autoconfigure 包里。

举例：spring-boot-starter-web

• starter 包：只有 pom.xml，引入了 spring-web、spring-webmvc、tomcat、jackson 等依赖

• autoconfigure 包：包含 WebMvcAutoConfiguration 等自动配置类

• spring.factories：注册自动配置类

starter 的好处：

• 不用自己找依赖、不用管版本兼容

• 引入一个 starter 就能用

• 约定大于配置

23. Spring MVC 请求执行流程

标准答案

Spring MVC 是 Spring 框架的 Web 模块，基于 Servlet 实现，采用了前端控制器模式。

【核心组件】

| 组件 | 作用 | |------|------| | DispatcherServlet | 前端控制器，所有请求的入口，负责调度 | | HandlerMapping | 处理器映射器，根据请求找到对应的 Handler（Controller） | | HandlerAdapter | 处理器适配器，调用 Handler 方法 | | Handler | 处理器，就是我们写的 Controller | | ModelAndView | 模型和视图，Handler 返回的结果 | | ViewResolver | 视图解析器，根据视图名解析出 View 对象 | | View | 视图，渲染页面 | | HandlerExceptionResolver | 异常处理器，处理异常 | | LocaleResolver | 国际化解析器 | | MultipartResolver | 文件上传解析器 |

【完整请求流程】

1. 用户发送请求 → DispatcherServlet（前端控制器）
   ↓
2. DispatcherServlet → HandlerMapping
   ↓ 查找对应的 Handler（Controller 方法）
3. HandlerMapping → 返回 HandlerExecutionChain（Handler + 拦截器链）
   ↓
4. DispatcherServlet → HandlerAdapter
   ↓ 选择合适的适配器
5. HandlerAdapter → 调用 Handler（Controller 方法）
   ↓
6. Handler 执行业务逻辑 → 返回 ModelAndView
   ↓
7. HandlerAdapter → 返回 ModelAndView 给 DispatcherServlet
   ↓
8. DispatcherServlet → ViewResolver（视图解析器）
   ↓ 根据视图名解析 View
9. ViewResolver → 返回 View 对象
   ↓
10. DispatcherServlet → 调用 View 的 render 方法渲染页面
    ↓ 把 Model 数据填充到 View 中
11. View 渲染完成 → 返回响应给用户

【详细说明】

第一步：请求到达 DispatcherServlet

• DispatcherServlet 是 Spring MVC 的核心，所有请求都经过它

• 它是一个 Servlet，在 web.xml 或 Servlet 3.0 中配置

• Spring Boot 中自动配置了 DispatcherServlet

第二步：HandlerMapping 查找 Handler

• DispatcherServlet 拿到请求后，调用 HandlerMapping

• HandlerMapping 根据请求 URL 找到对应的 Handler（Controller 方法）

• 返回的是 HandlerExecutionChain，包含 Handler 和拦截器链

• 常用的 HandlerMapping 实现：RequestMappingHandlerMapping（处理 @RequestMapping）

第三步：HandlerAdapter 调用 Handler

• DispatcherServlet 拿到 Handler 后，找对应的 HandlerAdapter

• 为什么需要适配器？因为 Handler 的形式不统一：

  • 有实现 Controller 接口的

  • 有 @RequestMapping 注解的

  • 有 HttpRequestHandler 的

• 适配器模式，统一调用接口

• 常用的 HandlerAdapter 实现：RequestMappingHandlerAdapter（处理 @RequestMapping）

第四步：Handler 执行

• HandlerAdapter 调用 Handler（Controller 方法）

• 执行过程中会经过拦截器链（preHandle）

• Handler 执行业务逻辑，返回 ModelAndView

• ModelAndView 包含模型数据和视图名

第五步：视图解析

• DispatcherServlet 拿到 ModelAndView 后，调用 ViewResolver

• ViewResolver 根据视图名解析出 View 对象

• 常用的 ViewResolver：InternalResourceViewResolver（解析 JSP）、ThymeleafViewResolver 等

第六步：视图渲染

• 调用 View 的 render 方法

• 把 Model 中的数据填充到 View 中

• 生成 HTML 或其他格式的响应

• 返回给用户

【拦截器的执行时机】

拦截器（HandlerInterceptor）有三个方法：

• preHandle：Handler 执行前调用，返回 false 则中断

• postHandle：Handler 执行后，视图渲染前调用

• afterCompletion：整个请求完成后调用（视图渲染完）

执行顺序：

preHandle1 → preHandle2 → Handler → postHandle2 → postHandle1 → 视图渲染 → afterCompletion2 → afterCompletion1

高频追问

追问1：Spring MVC 和 Struts2 的区别？

| 维度 | Spring MVC | Struts2 | |------|-----------|---------| | 入口 | Servlet（DispatcherServlet） | Filter（StrutsPrepareAndExecuteFilter） | | 粒度 | 方法级别的拦截，一个方法对应一个请求 | 类级别的拦截，一个类对应一个请求 | | 线程安全 | 单例，方法参数注入，线程安全 | 多实例，成员变量接收参数，线程安全但性能差 | | 性能 | 好，单例 + 方法级 | 稍差，每次请求创建新 Action | | 集成 Spring | 原生就是 Spring 的一部分 | 需要额外集成 | | 学习成本 | 低，注解驱动 | 高，配置多 | | 现状 | 主流 | 逐渐被淘汰 |

现在基本都用 Spring MVC 了，Struts2 用得越来越少。

追问2：Spring MVC 怎么获取请求参数？

常见的参数绑定方式：

1. 简单类型参数：直接写在方法参数上，按名字匹配

   public String test(String name, int age) { ... }
   

2. @RequestParam：显式指定参数名，required、defaultValue

   public String test(@RequestParam("name") String username) { ... }
   

3. POJO 对象：自动封装到对象中

   public String test(User user) { ... }
   

4. @PathVariable：RESTful 风格，路径变量

   @GetMapping("/user/{id}")
   public String test(@PathVariable Long id) { ... }
   

5. @RequestBody：JSON 格式的请求体

   public String test(@RequestBody User user) { ... }
   

6. @RequestHeader：获取请求头

7. @CookieValue：获取 Cookie

8. HttpServletRequest / HttpServletResponse：直接用原生 API

9. Map / Model / ModelMap：往 request 域放数据

追问3：@RequestMapping 注解的属性有哪些？

常用属性：

• value / path：请求路径

• method：请求方法（GET、POST、PUT、DELETE 等）

• params：请求参数条件

• headers：请求头条件

• consumes：请求的 Content-Type

• produces：响应的 Content-Type

衍生注解（更简洁）：

• @GetMapping：GET 请求

• @PostMapping：POST 请求

• @PutMapping：PUT 请求

• @DeleteMapping：DELETE 请求

• @PatchMapping：PATCH 请求

这些都是 @RequestMapping 的别名，只是指定了 method。

追问4：Spring MVC 的异常怎么处理？

Spring MVC 提供了多种异常处理方式：

1. @ExceptionHandler

• 在 Controller 中写一个方法，用 @ExceptionHandler 标注

• 只对当前 Controller 有效

@ExceptionHandler(Exception.class)
public String handleException(Exception e) {
    return "error";
}

2. @ControllerAdvice + @ExceptionHandler

• 全局异常处理，对所有 Controller 有效

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(Exception.class)
    public String handleException(Exception e) {
        return "error";
    }
}

3. HandlerExceptionResolver

• 实现 HandlerExceptionResolver 接口

• 更底层的异常处理方式

• Spring MVC 默认注册了几个，比如 ExceptionHandlerExceptionResolver（处理 @ExceptionHandler）

4. 配置 error-page

• 在 web.xml 中配置错误页面

• 比较老的方式了

最常用的是 @ControllerAdvice + @ExceptionHandler，全局统一异常处理。

追问5：什么是 RESTful API？Spring MVC 怎么实现？

RESTful 是一种 API 设计风格，用 HTTP 方法表示操作，用 URL 表示资源。

| HTTP 方法 | 操作 | 示例 | |-----------|------|------| | GET | 查询 | GET /users → 查询用户列表 | | GET | 查询单个 | GET /users/1 → 查询 id=1 的用户 | | POST | 新增 | POST /users → 新增用户 | | PUT | 修改 | PUT /users/1 → 修改 id=1 的用户 | | DELETE | 删除 | DELETE /users/1 → 删除 id=1 的用户 |

Spring MVC 实现：

• @GetMapping / @PostMapping / @PutMapping / @DeleteMapping

• @PathVariable 获取路径变量

• @RequestBody 接收 JSON 请求体

• @ResponseBody 返回 JSON 响应

• @RestController = @Controller + @ResponseBody

前后端分离的项目基本都是 RESTful 风格 + JSON 格式。

24. Spring 事务传播机制

标准答案

事务传播机制指的是：当一个事务方法调用另一个事务方法时，事务该如何传播、如何管理。

Spring 定义了 7 种事务传播行为，定义在 Propagation 枚举中。

【7 种传播行为】

| 传播行为 | 说明 | 特点 | |----------|------|------| | REQUIRED | 必须有事务（默认） | 有就用，没有就新建 | | SUPPORTS | 支持事务 | 有就用，没有就不用 | | MANDATORY | 强制事务 | 必须有，没有就抛异常 | | REQUIRES_NEW | 新建事务 | 不管有没有，都新建一个，挂起当前事务 | | NOT_SUPPORTED | 不支持事务 | 不管有没有，都以非事务方式运行，挂起当前事务 | | NEVER | 从不事务 | 必须没有，有就抛异常 | | NESTED | 嵌套事务 | 有事务就嵌套，没有就新建 |

【详细说明】

1. REQUIRED（默认，最常用）

• 如果当前有事务，就加入当前事务

• 如果当前没有事务，就新建一个事务

• 这是最常用的，默认值

举例：A 调用 B，都是 REQUIRED

• A 有事务 → B 加入 A 的事务，同一个事务

• A 没事务 → B 自己新建一个事务

2. SUPPORTS

• 如果当前有事务，就加入当前事务

• 如果当前没有事务，就以非事务方式执行

• 可有可无，随大流

3. MANDATORY（强制）

• 如果当前有事务，就加入当前事务

• 如果当前没有事务，就抛异常

• 必须在事务中运行，否则报错

4. REQUIRES_NEW

• 不管当前有没有事务，都新建一个事务

• 如果当前有事务，把当前事务挂起

• 新建的事务和原事务是独立的，提交/回滚互不影响

举例：A 调用 B，A 是 REQUIRED，B 是 REQUIRES_NEW

• A 有事务 → 挂起 A 的事务 → B 新建事务 → B 提交/回滚 → 恢复 A 的事务

• B 的回滚不影响 A，A 的回滚也不影响 B

5. NOT_SUPPORTED

• 以非事务方式执行

• 如果当前有事务，把当前事务挂起

• 不管有没有事务，都不用事务

6. NEVER

• 以非事务方式执行

• 如果当前有事务，就抛异常

• 必须不在事务中运行，否则报错

7. NESTED（嵌套事务）

• 如果当前有事务，就嵌套在当前事务中

• 如果当前没有事务，就新建一个事务（和 REQUIRED 一样）

• 嵌套事务有自己的回滚点（savepoint）

• 嵌套事务回滚不影响外层事务

• 外层事务回滚，嵌套事务也会回滚

NESTED 和 REQUIRES_NEW 的区别：

• REQUIRES_NEW：完全独立的两个事务，互不影响

• NESTED：嵌套在外层事务中，外层回滚内层也回滚，但内层回滚不影响外层

【事务的隔离级别】

Spring 也支持设置事务隔离级别，定义在 Isolation 枚举中：

| 隔离级别 | 说明 | 脏读 | 不可重复读 | 幻读 | |----------|------|------|-----------|------| | DEFAULT | 使用数据库默认 | - | - | - | | READ_UNCOMMITTED | 读未提交 | 是 | 是 | 是 | | READ_COMMITTED | 读已提交 | 否 | 是 | 是 | | REPEATABLE_READ | 可重复读 | 否 | 否 | 是 | | SERIALIZABLE | 串行化 | 否 | 否 | 否 |

MySQL 默认是 REPEATABLE_READ，Oracle 默认是 READ_COMMITTED。

高频追问

追问1：事务传播行为 REQUIRED 和 REQUIRES_NEW 的区别？

这是最常问的，一定要搞清楚：

| 维度 | REQUIRED | REQUIRES_NEW | |------|----------|-------------| | 事务数量 | 一个事务 | 两个独立事务 | | 外层有事务时 | 加入外层事务 | 挂起外层，新建自己的事务 | | 回滚影响 | 内部回滚 → 外部也回滚（同一个事务） | 内部回滚 → 不影响外部 | | 外部回滚影响 | 外部回滚 → 内部也回滚（同一个事务） | 外部回滚 → 不影响内部 | | 提交时机 | 一起提交 | 内部先提交，外部后提交 |

举例：A 调用 B

• A 是 REQUIRED，B 是 REQUIRED → 同一个事务，A 或 B 回滚都一起回滚

• A 是 REQUIRED，B 是 REQUIRES_NEW → 两个事务，B 回滚不影响 A，A 回滚不影响 B

追问2：NESTED 和 REQUIRES_NEW 的区别？

| 维度 | NESTED | REQUIRES_NEW | |------|--------|-------------| | 事务数量 | 一个物理事务，多个保存点 | 两个独立的物理事务 | | 外层回滚 | 内层也回滚 | 内层不受影响 | | 内层回滚 | 不影响外层，只回滚到保存点 | 不影响外层 | | 外层提交 | 内层一起提交 | 内层已经提交了 | | 实现方式 | savepoint（保存点） | 新建事务 |

简单说：

• REQUIRES_NEW：完全独立，各管各的

• NESTED：嵌套在外层里面，外层管着内层，但内层可以自己回滚一部分

NESTED 需要数据库支持 savepoint，JDBC 3.0 以上支持。

追问3：Spring 事务什么时候失效？

Spring 事务基于 AOP，只有通过代理对象调用才生效。以下情况事务会失效：

1. 方法不是 public 的

   • @Transactional 只能用在 public 方法上

   • 非 public 方法代理不了

2. 同类内部调用（this 调用）

   • 同一个类中方法 A 调用方法 B

   • A 调用 B 用的是 this，不是代理对象

   • B 的事务不生效

   • 解决：注入自己、用 AopContext.currentProxy()、拆成两个类

3. 异常类型不对

   • 默认只回滚 RuntimeException 和 Error

   • 受检异常（Exception）不回滚

   • 解决：@Transactional(rollbackFor = Exception.class)

4. 异常被 catch 了

   • 方法里 try-catch 了异常，没有抛出去

   • 事务不知道出异常了，不会回滚

   • 解决：catch 后重新抛出，或者手动设置回滚

5. 数据库引擎不支持事务

   • 比如 MySQL 的 MyISAM 引擎不支持事务

   • 要用 InnoDB

6. 没有被 Spring 管理

   • 类没有加 @Service 等注解，不在容器中

   • 没有代理对象，事务不生效

7. 多线程调用

   • 事务是和线程绑定的

   • 新线程里的方法不在事务中

这是高频面试题，一定要记住。

追问4：同类内部调用为什么事务不生效？怎么解决？

因为 Spring 事务基于 AOP 代理，只有通过代理对象调用才会走事务拦截。

同类内部调用时：

• 对象 A 的方法 1 调用方法 2

• 方法 1 里用的是 this 调用方法 2

• this 是原始对象，不是代理对象

• 所以方法 2 的 @Transactional 不生效

解决方法：

1. 注入自己

   @Service
   public class UserService {
       @Autowired
       private UserService self; // 注入自己（代理对象）
   
       public void method1() {
           self.method2(); // 用代理对象调用
       }
   
       @Transactional
       public void method2() { ... }
   }
   

2. AopContext.currentProxy()

   ((UserService) AopContext.currentProxy()).method2();
   

   需要开启 exposeProxy = true

3. 拆成两个类

   • 把方法 2 抽到另一个类中

   • 注入另一个类来调用

   • 最推荐的方式，结构清晰

4. 编程式事务

   • 用 TransactionTemplate 手动管理事务

   • 不依赖代理

追问5：什么是编程式事务和声明式事务？

| 维度 | 编程式事务 | 声明式事务 | |------|-----------|-----------| | 实现方式 | 手动写代码管理事务 | 注解/XML 配置 | | 代码侵入性 | 高，事务代码和业务代码混在一起 | 低，一个注解搞定 | | 灵活性 | 高，精细控制 | 低，只能到方法级别 | | 易用性 | 麻烦 | 简单 | | 推荐 | 少用，特殊场景用 | 推荐，日常开发用 |

声明式事务就是 @Transactional 注解，基于 AOP 实现，最常用。

编程式事务用 TransactionTemplate 或 PlatformTransactionManager，适合需要精细控制的场景。

25. Spring 事务失效场景

标准答案

Spring 事务基于 AOP 动态代理实现，只有通过代理对象调用的方法，事务才会生效。以下是常见的事务失效场景：

【场景 1：方法不是 public 的】

@Transactional 只能作用在 public 方法上，非 public 方法事务不生效。

原因：Spring 的事务拦截器（TransactionInterceptor）在拦截时，会检查方法是否是 public 的，非 public 直接跳过。

// 错误：protected 方法，事务不生效
@Transactional
protected void addUser() {
    // ...
}

解决：方法改成 public。

【场景 2：同类内部调用（this 调用）】

同一个类中，方法 A 调用方法 B，B 的事务不生效。

原因：A 调用 B 用的是 this（原始对象），不是代理对象，不走 AOP 拦截。

@Service
public class UserService {
    public void methodA() {
        this.methodB(); // this 调用，事务不生效
    }
    
    @Transactional
    public void methodB() {
        // ...
    }
}

解决：

1. 注入自己，用注入的代理对象调用

2. 用 AopContext.currentProxy() 获取代理对象

3. 拆成两个类

4. 用编程式事务

【场景 3：异常类型不对】

Spring 事务默认只回滚 RuntimeException 和 Error，受检异常（Exception）不回滚。

@Transactional
public void addUser() throws Exception {
    // 插入数据
    throw new Exception(); // 受检异常，不会回滚！
}

解决：

@Transactional(rollbackFor = Exception.class) // 指定回滚异常
public void addUser() throws Exception {
    // ...
}

或者用 rollbackForClassName 指定类名。

【场景 4：异常被 catch 了】

方法里 try-catch 捕获了异常，没有抛出去，事务不知道出异常了，不会回滚。

@Transactional
public void addUser() {
    try {
        // 插入数据
        int i = 1 / 0;
    } catch (Exception e) {
        e.printStackTrace(); // 异常被吞了，事务不回滚
    }
}

解决：

1. catch 后重新抛出异常

2. 手动设置事务回滚：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

【场景 5：数据库引擎不支持事务】

MySQL 的 MyISAM 引擎不支持事务，要用 InnoDB。

现在 MySQL 默认就是 InnoDB，但老项目可能还有 MyISAM 的表。

解决：把表引擎改成 InnoDB。

【场景 6：没有被 Spring 管理】

类没有被 Spring 容器管理（没有加 @Service、@Component 等注解），就不会创建代理对象，事务不生效。

// 错误：没有 @Service，不在 Spring 容器中
public class UserService {
    @Transactional
    public void addUser() { ... }
}

解决：加上 @Service 等注解，让 Spring 管理。

【场景 7：多线程调用】

事务是和线程绑定的（ThreadLocal），新线程不在事务中。

@Transactional
public void addUser() {
    new Thread(() -> {
        // 新线程里的操作，不在事务中
        userDao.insert(user);
    }).start();
}

解决：把事务加到线程内部的方法上，或者用编程式事务。

【场景 8：传播行为设置不对】

传播行为设置成了 SUPPORTS、NOT_SUPPORTED、NEVER 等，可能导致事务不生效。

比如设置成 NOT_SUPPORTED，就是以非事务方式运行。

解决：用默认的 REQUIRED 就行。

高频追问

追问1：同类内部调用事务失效，有哪些解决方式？

1. 注入自己（最常用）

   @Service
   public class UserService {
       @Autowired
       @Lazy // 解决循环依赖
       private UserService self;
   
       public void methodA() {
           self.methodB(); // 用代理对象调用
       }
   
       @Transactional
       public void methodB() { ... }
   }
   

2. AopContext.currentProxy()

   // 启动类加：@EnableAspectJAutoProxy(exposeProxy = true)
   ((UserService) AopContext.currentProxy()).methodB();
   

3. 拆成两个类（最推荐）

   • 把 methodB 抽到另一个 Service 中

   • 结构更清晰，符合单一职责

4. 编程式事务

   • 用 TransactionTemplate 手动管理

   • 不依赖代理

追问2：try-catch 了异常，事务还能回滚吗？

默认不能，因为异常被 catch 了，事务拦截器感知不到异常。

但可以手动设置回滚：

@Transactional
public void addUser() {
    try {
        // 业务逻辑
    } catch (Exception e) {
        // 手动标记回滚
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    }
}

或者 catch 后重新抛出异常：

@Transactional(rollbackFor = Exception.class)
public void addUser() throws Exception {
    try {
        // 业务逻辑
    } catch (Exception e) {
        // 处理后重新抛出
        throw e;
    }
}

追问3：@Transactional 加在什么地方？加在接口上还是实现类上？

都可以，但推荐加在实现类上。

原因：

1. 接口上的注解不能被继承（如果用 CGLIB 代理，基于类的代理可能拿不到接口注解）

2. 实现类上更直观，一看就知道哪些方法有事务

3. 接口是契约，事务是实现细节，应该放在实现里

加在类上：类中所有 public 方法都有事务 加在方法上：只有这个方法有事务 方法上的优先级高于类上的

追问4：事务的 ACID 特性是什么？

ACID 是事务的四大特性：

1. A - 原子性（Atomicity）

   • 事务是不可分割的最小单位

   • 事务中的操作要么全部成功，要么全部失败回滚

2. C - 一致性（Consistency）

   • 事务执行前后，数据保持一致状态

   • 比如转账，A 转给 B，转之前和转之后总金额不变

3. I - 隔离性（Isolation）

   • 多个事务之间互不干扰

   • 一个事务的修改对其他事务是隔离的

   • 隔离级别决定了隔离的程度

4. D - 持久性（Durability）

   • 事务一旦提交，对数据的修改就是永久的

   • 即使系统崩溃也不会丢失

追问5：Spring 事务的实现原理？

Spring 事务基于 AOP 实现：

1. @EnableTransactionManagement 开启事务

2. 容器中注册事务拦截器和自动代理创建器

3. bean 实例化后，检查是否有 @Transactional 注解

4. 如果有，创建事务代理对象（JDK 动态代理或 CGLIB）

5. 调用方法时，事务拦截器（TransactionInterceptor）拦截

6. 方法执行前：获取事务（开启事务）

7. 方法正常执行：提交事务

8. 方法抛出异常（根据配置的回滚异常判断）：回滚事务

核心就是 AOP + 事务管理器（PlatformTransactionManager）。

26. 循环依赖如何解决

标准答案

循环依赖指的是两个或多个 bean 之间相互依赖，形成闭环，比如 A 依赖 B，B 又依赖 A。

【什么是循环依赖】

@Component
public class A {
    @Autowired
    private B b;
}

@Component
public class B {
    @Autowired
    private A a;
}

A 创建需要 B，B 创建需要 A，形成循环。

【Spring 能解决哪些循环依赖】

| 循环依赖类型 | 能否解决 | 原因 | |-------------|---------|------| | 单例 + setter 注入 | ✅ 能 | 三级缓存 + 提前暴露 | | 单例 + 构造器注入 | ❌ 不能 | 实例化时就需要依赖 | | prototype 作用域 | ❌ 不能 | 每次都创建新的，无法缓存 | | 多例循环 | ❌ 不能 | 同上 |

Spring 只能解决单例的 setter 注入的循环依赖。

【三级缓存机制】

Spring 用三级缓存来解决单例的循环依赖：

// 一级缓存：存放完全初始化好的 bean
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

// 二级缓存：存放提前暴露的 bean（实例化了但还没初始化）
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

// 三级缓存：存放 bean 的工厂对象（ObjectFactory）
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

为什么需要三级缓存，一级不行吗？

一级缓存只能存完全初始化好的 bean，但循环依赖时，bean 还没初始化完就需要被引用了，所以需要提前暴露。

为什么需要二级和三级两个？

三级缓存存的是工厂（ObjectFactory），不是直接存对象。因为如果 bean 需要被 AOP 代理，提前暴露的应该是代理对象，而不是原始对象。三级缓存的工厂可以决定返回什么对象。

【解决循环依赖的完整流程】

以 A 和 B 循环依赖为例：

1. 创建 A
   ↓
2. 实例化 A（调用构造函数）→ A 对象创建了，但属性还没赋值
   ↓
3. 把 A 的 ObjectFactory 放入三级缓存（singletonFactories）
   ↓ 提前暴露，允许别人通过工厂拿到 A
4. 给 A 注入属性 → 发现需要 B
   ↓
5. 去创建 B
   ↓
6. 实例化 B → B 对象创建了
   ↓
7. 把 B 的 ObjectFactory 放入三级缓存
   ↓
8. 给 B 注入属性 → 发现需要 A
   ↓
9. 去获取 A：
   - 一级缓存（singletonObjects）→ 没有
   - 二级缓存（earlySingletonObjects）→ 没有
   - 三级缓存（singletonFactories）→ 有 A 的工厂
   ↓
10. 调用 A 的工厂的 getObject() → 拿到 A 的早期引用
    ↓ 如果需要 AOP，这里返回的是代理对象
11. 把 A 放入二级缓存，从三级缓存移除
    ↓
12. B 拿到 A 了 → B 属性注入完成
    ↓
13. B 初始化完成 → B 放入一级缓存
    ↓
14. 回到 A 的创建过程 → A 拿到 B 了
    ↓
15. A 属性注入完成 → A 初始化完成
    ↓
16. A 放入一级缓存，从二级缓存移除
    ↓
17. 完成！

【构造器注入为什么不能解决】

因为构造器注入是在实例化的时候就需要依赖：

创建 A → 调用构造函数 → 需要 B → 去创建 B
创建 B → 调用构造函数 → 需要 A → 去拿 A
A 还没实例化完（构造函数都没执行完）→ 三级缓存里也没有 A
→ 拿不到 A → 抛异常

而 setter 注入是先实例化（构造函数执行完了），再注入属性。实例化完了就可以放入三级缓存提前暴露了。

高频追问

追问1：三级缓存分别存什么？为什么需要三级？

| 缓存 | 存什么 | 时机 | |------|--------|------| | 一级（singletonObjects） | 完全初始化好的 bean | bean 完全创建好之后 | | 二级（earlySingletonObjects） | 提前暴露的 bean（实例化了，没初始化） | 第一次被引用时，从三级取出来放二级 | | 三级（singletonFactories） | bean 的 ObjectFactory | 实例化之后，属性注入之前 |

为什么需要三级？

• 一级不够：因为循环依赖时 bean 还没初始化完，不能放一级

• 二级不够：因为如果 bean 需要 AOP 代理，提前暴露的应该是代理对象，不是原始对象。三级的工厂可以生成代理对象。

三级缓存的核心作用是：让 bean 在还没初始化完的时候，就能提前暴露出去，并且可以决定暴露的是原始对象还是代理对象。

追问2：循环依赖和 AOP 代理的关系？

如果 bean 需要被 AOP 代理，那提前暴露的应该是代理对象，而不是原始对象。

三级缓存的 ObjectFactory 的作用就是：

• 如果 bean 需要代理，就返回代理对象

• 如果不需要代理，就返回原始对象

这样即使有 AOP，循环依赖也能正确解决，因为注入的是代理对象。

具体来说：

• 三级缓存里的 ObjectFactory 是一个 lambda 表达式

• 调用 getObject() 时，会调用 getEarlyBeanReference 方法

• 这个方法会走 BeanPostProcessor，如果需要 AOP 就创建代理

• 所以提前暴露的是代理对象，不是原始对象

追问3：prototype 作用域的循环依赖为什么解决不了？

因为 prototype 作用域的 bean 每次获取都创建新的，不会缓存。

举例：A 和 B 都是 prototype

• 创建 A → 需要 B → 创建 B → 需要 A → 创建 A → 需要 B → ...

• 死循环了

而单例的 bean 只创建一次，可以缓存起来，所以能解决。

prototype 的循环依赖 Spring 直接抛 BeanCurrentlyInCreationException。

追问4：怎么检测是否存在循环依赖？

Spring 用一个 Set 来记录正在创建中的 bean：

private final Set<String> singletonsCurrentlyInCreation = 
    Collections.newSetFromMap(new ConcurrentHashMap<>(16));

创建 bean 之前，把 beanName 加入这个 Set 创建完成后，从 Set 中移除

如果创建时发现 beanName 已经在 Set 里了，说明出现循环依赖了。

对于构造器注入的循环依赖，检测到后直接抛异常。 对于 setter 注入的循环依赖，检测到后用三级缓存解决。

追问5：怎么避免循环依赖？

虽然 Spring 能解决单例 setter 注入的循环依赖，但循环依赖本身不是好的设计，说明代码耦合度高。

避免方法：

1. 重新设计：

   • 梳理职责，是不是职责划分有问题

   • 把共同依赖的部分抽出来

2. 使用 @Lazy：

   • 延迟加载，用到的时候才创建

   @Autowired
   @Lazy
   private B b;
   

3. 使用 Setter 注入：

   • 构造器注入不行就改成 setter 注入

   • 让 Spring 能解决

4. 使用 ApplicationContext.getBean()：

   • 用到的时候再从容器拿

   • 不推荐，代码丑

5. 使用 @PostConstruct：

   • 在初始化方法里手动设置依赖

最好的方式还是重新设计，从根源上避免循环依赖。

27. Filter、Interceptor、AOP 区别

标准答案

Filter、Interceptor、AOP 都可以实现对请求或方法的拦截，但它们的层次和作用不同。

【三者的定位】

| 维度 | Filter（过滤器） | Interceptor（拦截器） | AOP（切面） | |------|-----------------|---------------------|------------| | 规范 | Servlet 规范 | Spring MVC 规范 | Spring AOP | | 层次 | Web 层，最外层 | Spring MVC 层，中间 | 业务层，最内层 | | 拦截对象 | HTTP 请求 | Controller 方法 | 任意 Bean 的方法 | | 依赖 | 依赖 Servlet 容器 | 依赖 Spring MVC | 依赖 Spring AOP | | 执行顺序 | 最前 | 中间 | 最后 |

【Filter（过滤器）】

定义：Filter 是 Java Servlet 规范中的组件，用于拦截 HTTP 请求和响应。

作用：

• 请求到达 Servlet 之前进行预处理

• 响应返回给客户端之前进行后处理

• 可以修改请求和响应

常见用途：

• 字符编码过滤（CharacterEncodingFilter）

• 登录验证

• CORS 跨域处理

• XSS 防护

• 日志记录

实现方式：实现 javax.servlet.Filter 接口

public class MyFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
            throws IOException, ServletException {
        // 请求前处理
        chain.doFilter(request, response); // 放行
        // 响应后处理
    }
}

执行时机：在 DispatcherServlet 之前执行，是请求的第一道关卡。

【Interceptor（拦截器）】

定义：Interceptor 是 Spring MVC 提供的组件，用于拦截 Controller 方法的调用。

作用：

• Controller 方法执行前拦截

• Controller 方法执行后拦截

• 视图渲染完成后拦截

常见用途：

• 登录验证

• 权限检查

• 日志记录

• 性能监控

实现方式：实现 HandlerInterceptor 接口

public class MyInterceptor implements HandlerInterceptor {
    // 方法执行前
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        return true; // 返回 false 则中断
    }
    
    // 方法执行后，视图渲染前
    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) {
    }
    
    // 整个请求完成后
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
    }
}

执行时机：在 DispatcherServlet 之后，Controller 方法之前。

【AOP（面向切面）】

定义：AOP 是 Spring 的核心特性之一，基于动态代理，可以拦截任意 Bean 的方法。

作用：

• 方法执行前后增强

• 可以拦截任意层次的方法（Service、Dao 等）

常见用途：

• 事务管理（@Transactional）

• 日志记录

• 性能监控

• 权限控制

• 缓存

实现方式：@Aspect 注解 + 切点表达式

@Aspect
@Component
public class MyAspect {
    @Around("execution(* com.example.service.*.*(..))")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        // 方法前
        Object result = joinPoint.proceed();
        // 方法后
        return result;
    }
}

执行时机：在方法调用时，通过代理对象拦截。

【执行顺序】

一个请求进来，执行顺序是：

请求 → Filter1 → Filter2 → DispatcherServlet → Interceptor.preHandle 
→ Controller → Interceptor.postHandle → 视图渲染 → Interceptor.afterCompletion 
→ Filter2 → Filter1 → 响应

如果 Controller 调用了 Service，Service 上有 AOP：

Controller → AOP 前置 → Service 方法 → AOP 后置 → Controller

从外到内：Filter → Interceptor → AOP

高频追问

追问1：Filter 和 Interceptor 的区别？

| 维度 | Filter | Interceptor | |------|--------|-------------| | 规范 | Servlet 规范 | Spring MVC 规范 | | 依赖 | 依赖 Servlet 容器 | 依赖 Spring 容器 | | 拦截范围 | 所有请求 | 只有 Controller 请求 | | 能否操作 request/response | 能 | 能 | | 能否访问 Controller 方法信息 | 不能 | 能（handler 参数） | | 能否访问 ModelAndView | 不能 | 能 | | 执行时机 | DispatcherServlet 之前 | DispatcherServlet 之后，Controller 之前 | | 数量限制 | 多个，形成过滤器链 | 多个，形成拦截器链 | | 中断方式 | 不调用 chain.doFilter() | preHandle 返回 false |

简单说：Filter 是 Servlet 层面的，Interceptor 是 Spring MVC 层面的。Filter 更外层，Interceptor 更精细。

追问2：Interceptor 和 AOP 的区别？

| 维度 | Interceptor | AOP | |------|-------------|-----| | 规范 | Spring MVC | Spring AOP | | 拦截对象 | Controller 方法 | 任意 Bean 的方法 | | 粒度 | 粗，只能拦 Controller | 细，可以拦任意方法 | | 配置方式 | 实现 HandlerInterceptor + 注册 | @Aspect + 切点表达式 | | 依赖 | 依赖 Web 环境 | 不依赖 Web 环境 | | 性能 | 稍好 | 稍差（动态代理） |

Interceptor 只能拦 Controller，AOP 可以拦任意层的方法（Service、Dao 等）。 如果只需要拦 Controller，用 Interceptor 更简单。 如果需要拦 Service 或其他层，用 AOP。

追问3：Spring MVC 的拦截器怎么注册？

方式一：实现 WebMvcConfigurer（推荐）

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new MyInterceptor())
                .addPathPatterns("/**")      // 拦截路径
                .excludePathPatterns("/login"); // 排除路径
    }
}

方式二：XML 配置（老项目）

<mvc:interceptors>
    <mvc:interceptor>
        <mvc:mapping path="/**"/>
        <bean class="com.example.MyInterceptor"/>
    </mvc:interceptor>
</mvc:interceptors>

可以配置多个拦截器，按注册顺序执行。

追问4：多个 Filter 的执行顺序怎么控制？

方式一：@Order 注解

@Order(1) // 值越小，优先级越高，越先执行
@Component
public class MyFilter implements Filter { ... }

方式二：FilterRegistrationBean

@Bean
public FilterRegistrationBean<MyFilter> myFilter() {
    FilterRegistrationBean<MyFilter> registration = new FilterRegistrationBean<>();
    registration.setFilter(new MyFilter());
    registration.addUrlPatterns("/*");
    registration.setOrder(1); // 顺序
    return registration;
}

方式三：web.xml 中按配置顺序（老项目）

执行顺序：值越小，优先级越高，越先执行。 响应返回时，顺序反过来，后执行的先返回。

追问5：什么场景用 Filter，什么场景用 Interceptor，什么场景用 AOP？

选择原则：从外到内，能在外层解决的就不用内层。

用 Filter 的场景：

• 和 Servlet 规范相关的

• 需要操作 request/response 的

• 需要过滤所有请求的

• 比如：编码过滤、CORS、XSS 防护、登录验证（全局的）

用 Interceptor 的场景：

• 只需要拦截 Controller 的

• 需要访问 Controller 方法信息的

• 需要操作 ModelAndView 的

• 比如：权限校验（Controller 级）、日志记录、性能监控

用 AOP 的场景：

• 需要拦截 Service 层或 Dao 层方法的

• 需要更细粒度控制的

• 和 Web 无关的通用逻辑

• 比如：事务、缓存、日志（Service 层）、权限（方法级）

简单记：

• Web 全局 → Filter

• Controller 层 → Interceptor

• Service/Dao 层 → AOP

28. Spring Cloud 常用组件及作用

标准答案

Spring Cloud 是一套微服务治理框架，基于 Spring Boot 构建，提供了微服务架构下的各种解决方案。

【Spring Cloud 核心组件】

| 组件 | 作用 | 替代方案 | |------|------|----------| | Eureka / Nacos | 服务注册与发现 | Consul、Zookeeper | | Ribbon / LoadBalancer | 负载均衡 | - | | Feign / OpenFeign | 声明式 HTTP 客户端 | RestTemplate | | Hystrix / Sentinel | 熔断降级 | Resilience4j | | Zuul / Gateway | 网关 | - | | Config | 配置中心 | Nacos Config、Apollo | | Bus | 消息总线 | - | | Sleuth + Zipkin | 链路追踪 | SkyWalking、Pinpoint |

【1. 服务注册与发现：Eureka / Nacos】

作用：服务的注册与发现，让各个服务能找到彼此。

为什么需要？

• 微服务架构下，服务很多，地址和端口可能变化

• 需要一个地方统一管理所有服务的地址信息

核心概念：

• 服务注册：服务启动时，把自己的地址信息注册到注册中心

• 服务发现：调用方从注册中心获取服务的地址列表

• 心跳续约：服务定期发送心跳，证明自己还活着

• 服务剔除：长时间没心跳的服务，从注册中心剔除

Eureka：

• Netflix 开源，Spring Cloud 早期默认

• AP 架构，保证可用性，不保证强一致性

• 自我保护机制：网络故障时，不会剔除服务实例

Nacos：

• 阿里开源，现在更流行

• 同时支持 AP 和 CP 模式

• 还支持配置中心，一个顶俩

• 控制台更友好

【2. 负载均衡：Ribbon / LoadBalancer】

作用：客户端负载均衡，从服务列表中选择一个实例调用。

为什么需要？

• 一个服务有多个实例，调用时选哪个？

• 负载均衡器负责选择，分摊压力

负载均衡策略：

• 轮询（Round Robin）：默认，依次轮询

• 随机（Random）：随机选

• 加权轮询：根据权重

• 最少连接：选连接数最少的

• 一致性哈希：相同请求到同一台

Ribbon：Netflix 开源，客户端负载均衡 LoadBalancer：Spring Cloud 自己的，Spring Cloud 2020 之后取代 Ribbon

【3. 声明式调用：OpenFeign】

作用：声明式的 HTTP 客户端，像调用本地方法一样调用远程服务。

为什么需要？

• 用 RestTemplate 调用远程服务，代码比较繁琐

• Feign 用接口 + 注解的方式，更优雅

使用方式：

@FeignClient("user-service")
public interface UserService {
    @GetMapping("/users/{id}")
    User getUserById(@PathVariable("id") Long id);
}

就像调用本地方法一样：userService.getUserById(1L)，实际是远程调用。

特点：

• 集成了 Ribbon/LoadBalancer，自带负载均衡

• 集成了 Hystrix/Sentinel，支持熔断降级

• 支持请求/响应压缩

• 支持日志配置

【4. 熔断降级：Hystrix / Sentinel】

作用：服务容错保护，防止故障蔓延，保护系统稳定性。

为什么需要？

• 微服务之间相互调用，一个服务挂了，可能导致调用它的服务也挂了

• 像雪崩一样，整个系统都崩了

• 需要熔断降级机制，保护系统

核心概念：

• 熔断（Circuit Breaker）：错误率达到阈值，直接熔断，不再调用

• 降级（Fallback）：调用失败或熔断时，返回兜底结果

• 限流（Rate Limit）：限制请求速率，保护服务

• 隔离（Bulkhead）：每个服务用独立的线程池，互不影响

Hystrix：Netflix 开源，经典的熔断器，现在进入维护模式 Sentinel：阿里开源，功能更丰富，现在更流行

【5. 网关：Zuul / Gateway】

作用：统一入口，所有请求先经过网关，再转发到后端服务。

为什么需要？

• 微服务很多，客户端不能直接调用每个服务

• 需要一个统一入口，做路由、鉴权、限流等

网关的功能：

• 路由转发：根据路径转发到对应的服务

• 认证鉴权：统一登录验证、权限检查

• 限流熔断：限流、降级、熔断

• 负载均衡：对后端服务负载均衡

• 日志监控：统一日志、监控

• 灰度发布：按比例路由

Zuul：Netflix 开源，基于 Servlet，阻塞式 Gateway：Spring 自己的，基于 WebFlux，响应式，性能更好

【6. 配置中心：Spring Cloud Config / Nacos Config】

作用：统一管理所有服务的配置，动态刷新。

为什么需要？

• 微服务很多，每个服务都有配置文件

• 修改配置要改每个服务，还要重启

• 需要统一管理，动态刷新

功能：

• 配置集中管理

• 配置动态刷新（不用重启）

• 配置版本管理

• 多环境支持（dev/test/prod）

Spring Cloud Config：Spring 官方，基于 Git/SVN/数据库存储 Nacos Config：阿里的，和注册中心一起用，更方便 Apollo：携程开源，功能强大，企业级

【7. 链路追踪：Sleuth + Zipkin】

作用：分布式链路追踪，追踪一个请求经过了哪些服务，每个环节耗时多少。

为什么需要？

• 微服务调用链很长，出问题了不知道在哪

• 性能瓶颈不知道在哪

• 需要链路追踪来定位问题

核心概念：

• Trace：一次请求的完整链路，一个 Trace 有唯一 TraceID

• Span：链路中的一个节点（一次调用），有唯一 SpanID

• 每个服务打印日志时带上 TraceID 和 SpanID，就能串联起来

Sleuth：Spring Cloud 的，生成 TraceID/SpanID，打印到日志 Zipkin：Twitter 开源的，收集和展示链路数据 SkyWalking：国产，功能更强大，无侵入，现在很流行

高频追问

追问1：什么是服务雪崩？怎么解决？

服务雪崩：一个服务挂了，导致调用它的服务也挂了，像多米诺骨牌一样，整个系统都崩了。

原因：

• 服务 A 调用服务 B，B 挂了

• A 的请求都阻塞在等 B 响应

• A 的线程都耗尽了，A 也挂了

• 调用 A 的服务也跟着挂了...

• 雪崩了

解决方法：

1. 熔断：错误率高了就熔断，不再调用，直接返回

2. 降级：调用失败返回兜底结果，不阻塞

3. 限流：限制请求量，保护服务不被打垮

4. 隔离：每个服务用独立的线程池，不互相影响

5. 超时：设置超时时间，不无限等待

6. 重试：偶尔失败可以重试，但要注意幂等性

核心思想：快速失败，不要让故障蔓延。

追问2：什么是服务熔断？什么是服务降级？区别？

服务熔断：

• 当错误率达到阈值（比如 50%），直接熔断，不再调用

• 像保险丝一样，电流太大就断开

• 熔断后过一段时间会进入半开状态，尝试放行几个请求

• 如果成功了就关闭熔断，失败了继续熔断

• 目的：保护后端服务，防止故障扩大

服务降级：

• 调用失败或者熔断时，返回一个兜底的结果

• 比如推荐服务挂了，返回默认推荐列表

• 目的：保证核心功能可用，牺牲非核心功能

区别：

• 熔断是一种保护机制，防止故障蔓延

• 降级是一种兜底方案，保证可用

• 熔断通常会触发降级，但降级不一定是因为熔断

• 熔断是自动的（达到阈值就熔断），降级可以是主动的

追问3：网关的作用是什么？为什么需要网关？

网关是微服务架构的统一入口，所有请求都经过网关。

作用：

1. 路由转发：根据路径、参数等转发到对应的服务

2. 统一认证：登录验证、Token 校验，不用每个服务都做

3. 统一鉴权：权限检查

4. 限流熔断：限流、降级、熔断，保护后端服务

5. 负载均衡：对后端服务实例负载均衡

6. 日志监控：统一日志、监控、统计

7. 灰度发布：按比例路由到新版本，灰度发布

8. 协议转换：HTTP 转 RPC 等

9. 跨域处理：统一处理跨域

为什么需要？

• 统一入口，客户端只需要知道网关地址

• 统一处理通用逻辑（认证、限流等），不用每个服务都做

• 保护内部服务，不直接暴露

追问4：Nacos 和 Eureka 的区别？

| 维度 | Eureka | Nacos | |------|--------|-------| | 出品方 | Netflix | 阿里巴巴 | | 一致性模型 | AP（只保证可用性） | 支持 AP 和 CP，可切换 | | 配置中心 | 不支持 | 支持（集成了配置中心） | | 控制台 | 比较简陋 | 功能丰富，界面友好 | | 健康检查 | 客户端心跳 | 支持多种（心跳、TCP、HTTP、MySQL 等） | | 权重/灰度 | 不支持 | 支持权重、灰度发布 | | 社区活跃度 | 2.x 停止开发 | 活跃，持续更新 | | 国内使用 | 越来越少 | 越来越多 |

现在国内基本都用 Nacos 了，功能更全，更符合国内需求。

追问5：什么是 CAP 定理？注册中心选 AP 还是 CP？

CAP 定理：分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三者不可兼得，最多满足两个。

• C 一致性：所有节点数据一致

• A 可用性：服务一直可用，正常响应

• P 分区容错性：网络分区时，系统仍能工作

分布式系统中 P 是必须的，所以只能在 C 和 A 之间选。

注册中心选 AP 还是 CP？

一般选 AP（可用性优先）。

原因：

• 注册中心最重要的是可用，不能挂

• 即使数据暂时不一致，问题也不大（大不了调用一个已经挂了的实例，失败了重试）

• 如果注册中心挂了，整个服务发现都用不了，影响更大

Eureka 是 AP 的，Nacos 默认也是 AP 的，可以切换到 CP。

但有些场景需要 CP，比如需要严格保证服务列表一致的场景。

📌 面试技巧：回答 Spring 相关问题时，要体现出你对 Spring 整体的理解，不要只背零散的知识点。比如讲 AOP 就联系到事务，讲 IOC 就联系到 bean 生命周期，讲自动装配就联系到 starter。知识串联起来，面试官会觉得你体系化掌握得很好。

第四章 MySQL（8题）

29. B+Tree 为什么适合数据库索引

标准答案

B+Tree 是 MySQL InnoDB 引擎默认的索引数据结构，它是 B 树的变种，专门为数据库索引优化设计。

【为什么不用其他数据结构】

1. 为什么不用数组？

• 插入删除慢，需要移动元素

• 范围查询可以，但插入删除性能差

2. 为什么不用链表？

• 查询慢，需要遍历

• 插入删除快，但查询慢

3. 为什么不用哈希表？

• 等值查询很快 O(1)

• 但不支持范围查询（>、<、between）

• 不支持排序

• 不支持最左前缀匹配

4. 为什么不用二叉搜索树？

• 可能退化成链表（有序插入时）

• 树的高度太高，IO 次数多

5. 为什么不用平衡二叉树（AVL/红黑树）？

• 平衡了，不会退化

• 但树的高度还是太高（每个节点只有两个子节点）

• 数据量大时，树高几十层，每次查询几十次 IO

• 磁盘 IO 是数据库性能瓶颈，要尽量减少 IO 次数

6. 为什么不用 B 树？

• B 树每个节点可以有多个子节点，高度低

• 但 B 树每个节点都存数据，非叶子节点也存数据

• 同样大小的节点，B 树能存的 key 更少，高度更高

【B+Tree 的结构】

B+Tree 是多路平衡查找树，特点：

1. 多路（多叉）

• 每个节点可以有多个子节点（几十到几百个）

• 树的高度很低，通常 3-4 层就能存千万级数据

• 高度低 = IO 次数少 = 性能好

2. 叶子节点才存数据

• 非叶子节点只存索引 key 和指针，不存数据

• 叶子节点存完整的数据（或主键值，取决于聚簇索引还是非聚簇索引）

• 好处：非叶子节点更小，同样大小能存更多 key，树更矮

3. 叶子节点之间用链表连接

• 所有叶子节点按 key 顺序排列，用双向链表连接

• 范围查询非常方便：找到起点，顺着链表往后遍历就行

• 排序也方便

4. 所有数据都在叶子节点

• 每次查询都要走到叶子节点

• 查询路径长度一致，性能稳定

• B 树可能在非叶子节点就找到数据，性能不稳定

【B+Tree vs B 树】

| 维度 | B 树 | B+Tree | |------|------|--------| | 数据存储 | 所有节点都存数据 | 只有叶子节点存数据 | | 查询性能 | 不稳定，可能在中间层找到 | 稳定，每次都走到叶子 | | 范围查询 | 需要中序遍历，麻烦 | 叶子节点链表，直接遍历 | | 节点大小 | 同样大小存的 key 少 | 同样大小存的 key 多 | | 树的高度 | 更高 | 更矮 | | IO 次数 | 更多 | 更少 |

【为什么 B+Tree 适合数据库索引】

1. 树矮，IO 少

• 每个节点可以有很多子节点（InnoDB 默认一页 16KB，能存几百个 key）

• 千万级数据只要 3-4 层

• 每次查询只要 3-4 次 IO

• 磁盘 IO 是数据库最大的性能瓶颈，减少 IO 就是提升性能

2. 范围查询快

• 叶子节点是有序链表

• 找到起点后，顺着链表往后遍历就行

• 不用中序遍历，效率高

3. 排序支持好

• 叶子节点有序

• order by、group by 都可以利用索引顺序

4. 查询性能稳定

• 每次查询都走到叶子节点

• 路径长度一致，性能稳定

• B 树可能在上面就找到，也可能走到最下面，性能不稳定

5. 磁盘预读友好

• 磁盘读取时，会预读一页数据（局部性原理）

• B+Tree 节点大小和磁盘页大小一致（InnoDB 是 16KB）

• 每次 IO 读一页，正好一个节点

• 充分利用磁盘预读

高频追问

追问1：InnoDB 一页多大？为什么是 16KB？

InnoDB 默认一页大小是 16KB。

为什么是 16KB？

• 太小：树变高，IO 次数变多

• 太大：一页内数据太多，单页查询时间变长

• 16KB 是一个经验值，平衡了树的高度和单页查询时间

可以通过 innodb_page_size 参数设置，默认 16KB，可选 4KB、8KB、16KB、32KB、64KB。

计算一下：假设一行数据 1KB，叶子节点一页存 16 行。非叶子节点存 key + 指针，假设 key 8 字节，指针 6 字节，一页能存约 1000 个 key。

• 2 层树：1000 × 16 = 16000 行

• 3 层树：1000 × 1000 × 16 = 1600 万行

• 4 层树：1000 × 1000 × 1000 × 16 = 160 亿行

所以千万级数据 3 层就够了，只要 3 次 IO。

追问2：B+Tree 的插入和删除过程？

插入：

1. 找到对应的叶子节点

2. 插入数据，保持有序

3. 如果叶子节点没满，直接插入

4. 如果叶子节点满了（超过 16KB），分裂成两个节点

5. 分裂后把中间的 key 提升到父节点

6. 如果父节点也满了，继续分裂，向上传递

7. 如果根节点也分裂了，树的高度 +1

删除：

1. 找到对应的叶子节点

2. 删除数据

3. 如果节点数据太少（低于阈值，通常是 50%），尝试合并

4. 先看兄弟节点能不能借一个（旋转）

5. 兄弟也不够，就和兄弟节点合并

6. 合并后父节点的 key 减少，可能导致父节点也需要合并

7. 一直向上传递

插入和删除都要保持树的平衡，保证高度不会太高。

追问3：什么是聚簇索引和非聚簇索引？

聚簇索引（Clustered Index）：

• 索引和数据存在一起

• 叶子节点存的是完整的行数据

• 一张表只能有一个聚簇索引

• InnoDB 的主键索引就是聚簇索引

• 数据按主键顺序物理存储

非聚簇索引（Secondary Index，二级索引）：

• 索引和数据分开存

• 叶子节点存的是主键值

• 一张表可以有多个非聚簇索引

• 查询时先查二级索引找到主键，再用主键查聚簇索引（回表）

详细对比见下一题。

追问4：哈希索引和 B+Tree 索引的区别？

| 维度 | 哈希索引 | B+Tree 索引 | |------|---------|-------------| | 等值查询 | O(1)，非常快 | O(log n)，也很快 | | 范围查询 | 不支持 | 支持，叶子链表 | | 排序 | 不支持 | 支持 | | 最左前缀 | 不支持 | 支持 | | 哈希冲突 | 有冲突问题 | 没有 | | 适用场景 | 纯等值查询 | 各种查询 |

MySQL 的 Memory 引擎支持哈希索引，InnoDB 有自适应哈希索引（自动优化，不用手动建）。

一般都用 B+Tree 索引，因为功能更全面。

追问5：什么是覆盖索引？

覆盖索引（Covering Index）：查询的所有字段都在索引中，不需要回表查询。

比如有一个联合索引 (name, age)：

SELECT name, age FROM user WHERE name = '张三';

这个查询只需要 name 和 age，索引里都有，直接从索引返回，不需要回表，就是覆盖索引。

好处：

• 不需要回表，减少 IO

• 性能更好

判断方法：explain 中 Extra 列显示 "Using index" 就是覆盖索引。

30. 聚簇索引与非聚簇索引

标准答案

聚簇索引和非聚簇索引是 InnoDB 中两种索引类型，核心区别在于叶子节点存的是什么。

【聚簇索引（Clustered Index）】

定义：索引和数据存储在一起，叶子节点存储完整的行数据。

特点：

• 叶子节点存完整的行数据

• 数据按主键顺序物理存储

• 一张表只能有一个聚簇索引

• InnoDB 中主键索引就是聚簇索引

• 如果没有主键，InnoDB 会选一个唯一非空索引作为聚簇索引

• 如果也没有，InnoDB 会隐式创建一个 row_id 作为聚簇索引

优点：

• 查询快，找到索引就找到了数据，不需要回表

• 范围查询快，叶子节点有序，直接遍历

• 按主键排序和查找效率高

缺点：

• 插入速度依赖主键顺序，乱序插入会导致页分裂，性能差

• 二级索引需要存主键，主键越大，二级索引越大

• 更新主键代价大，因为要移动数据

【非聚簇索引（Secondary Index，二级索引）】

定义：索引和数据分开存储，叶子节点存储的是主键值。

特点：

• 叶子节点存主键值（不是完整数据）

• 一张表可以有多个二级索引

• 查询时需要回表：先查二级索引找到主键，再用主键查聚簇索引

• 二级索引的叶子节点按索引字段排序

回表过程：

1. 查询二级索引 → 找到主键值
2. 用主键值查聚簇索引 → 找到完整行数据

两次 B+Tree 查询，比聚簇索引多一次。

【聚簇索引 vs 非聚簇索引】

| 维度 | 聚簇索引 | 非聚簇索引 | |------|---------|-----------| | 叶子节点存储 | 完整行数据 | 主键值 | | 数量 | 一张表只能一个 | 一张表可以多个 | | 是否需要回表 | 不需要 | 需要（除非覆盖索引） | | 查询速度 | 快，一次查询 | 慢，两次查询（回表） | | 物理存储 | 数据按索引顺序存储 | 索引和数据分开 | | 空间占用 | 索引就是数据，不额外占空间 | 额外占空间 | | 插入顺序影响 | 影响大，乱序插入页分裂 | 影响小 |

【MyISAM 和 InnoDB 的索引区别】

| 维度 | MyISAM | InnoDB | |------|--------|--------| | 聚簇索引 | 不支持，都是非聚簇 | 支持，主键是聚簇索引 | | 主键索引叶子 | 存数据地址 | 存完整数据 | | 二级索引叶子 | 存数据地址 | 存主键值 | | 回表 | 需要，但快（直接地址定位） | 需要，查聚簇索引 | | 主键顺序存储 | 不按顺序 | 按主键顺序物理存储 |

MyISAM 的索引都是非聚簇的，叶子节点存的是数据行的地址指针，通过地址直接定位数据。

InnoDB 的二级索引叶子节点存的是主键值，需要回表查聚簇索引。

高频追问

追问1：为什么主键建议用自增 ID？不用 UUID？

因为 InnoDB 的主键是聚簇索引，数据按主键顺序物理存储。

自增主键的好处：

1. 顺序插入：每次插入都在最后一页，不会产生页分裂

2. 性能好：没有页分裂，插入速度快

3. 空间利用率高：页不会有碎片，利用率高

UUID 的问题：

1. 乱序插入：UUID 是随机的，插入位置随机

2. 页分裂频繁：插入到中间，页满了就要分裂

3. 性能差：页分裂消耗性能，插入慢

4. 空间利用率低：页分裂后有很多碎片，空间利用率低

5. 主键大：UUID 16 字节，比 int（4 字节）大很多，二级索引也跟着变大

所以主键建议用自增的整型 ID，不要用 UUID。

追问2：二级索引为什么存主键值？不存数据地址？

原因：

1. 数据地址会变：

   • 聚簇索引的数据可能因为页分裂、插入、删除等移动位置

   • 如果二级索引存地址，数据移动时所有二级索引都要更新，代价太大

   • 存主键值就没这个问题，主键一般不变

2. 一致性好：

   • 主键是唯一标识，不会变

   • 数据移动不影响二级索引

3. 空间权衡：

   • 存主键值需要回表，多一次查询

   • 但维护成本低，整体更优

这是一种权衡：用一次额外的查询，换取更低的维护成本。

追问3：什么是回表？怎么减少回表？

回表：通过二级索引找到主键，再用主键去聚簇索引查完整数据的过程。

回表需要两次 B+Tree 查询，性能比直接查聚簇索引差。

减少回表的方法：

1. 覆盖索引：

   • 查询的字段都在索引中，不需要回表

   • 比如索引 (name, age)，查询 SELECT name, age FROM ... 就是覆盖索引

   • explain 中 Extra 显示 "Using index"

2. 用主键查询：

   • 直接用主键查，走聚簇索引，不需要回表

3. 减少查询字段：

   • 只查需要的字段，不要 SELECT *

   • 更容易用到覆盖索引

追问4：什么是索引下推（ICP）？

索引下推（Index Condition Pushdown，ICP）：把 where 条件下推到索引层面，在索引遍历的时候就过滤掉不符合条件的数据，减少回表次数。

举例：有联合索引 (name, age)

SELECT * FROM user WHERE name = '张三' AND age > 20;

没有 ICP 时：

• 先用 name 找到所有 name='张三' 的主键

• 回表查完整数据

• 再用 age > 20 过滤

• 回表次数多

有 ICP 时：

• 遍历索引时，同时用 age > 20 过滤

• 只把符合条件的主键回表

• 回表次数少

ICP 是 MySQL 5.6 引入的优化，默认开启。 explain 中 Extra 显示 "Using index condition" 就是用了 ICP。

追问5：主键索引和唯一索引的区别？

| 维度 | 主键索引 | 唯一索引 | |------|---------|---------| | 数量 | 一张表只能一个 | 可以多个 | | 是否允许 NULL | 不允许 | 允许（但 NULL 不算重复） | | 是否聚簇 | InnoDB 中是聚簇索引 | 非聚簇索引（二级索引） | | 作用 | 唯一标识一行 | 保证字段值唯一 | | 查询性能 | 快（聚簇索引，不回表） | 稍慢（二级索引，可能回表） |

主键一定是唯一的，但唯一索引不一定是主键。 一张表只能有一个主键，但可以有多个唯一索引。

31. 联合索引最左前缀原则

标准答案

联合索引（复合索引）是指包含多个字段的索引，最左前缀原则是联合索引的重要规则。

【什么是最左前缀原则】

联合索引遵循最左前缀匹配原则：查询时从索引的最左边开始匹配，一直到遇到范围查询（>、<、between、like 前缀匹配）就停止匹配。

举例：有联合索引 (a, b, c)

| 查询条件 | 是否走索引 | 说明 | |----------|-----------|------| | WHERE a = 1 | ✅ 走 | 匹配最左列 a | | WHERE a = 1 AND b = 2 | ✅ 走 | 匹配 a 和 b | | WHERE a = 1 AND b = 2 AND c = 3 | ✅ 走 | 匹配 a、b、c | | WHERE b = 2 | ❌ 不走 | 跳过了 a，不满足最左前缀 | | WHERE c = 3 | ❌ 不走 | 跳过了 a 和 b | | WHERE b = 2 AND c = 3 | ❌ 不走 | 跳过了 a | | WHERE a = 1 AND c = 3 | ✅ 部分走 | a 走索引，c 不走（跳过了 b），c 用 ICP 过滤 | | WHERE a = 1 AND b > 2 AND c = 3 | ✅ 部分走 | a 和 b 走，c 不走（b 是范围查询，后面的 c 不匹配） | | WHERE a LIKE '张%' AND b = 2 | ✅ 部分走 | a 走，b 不走（like 前缀匹配是范围查询） |

【为什么叫最左前缀】

因为联合索引的 B+Tree 是按从左到右的顺序构建的：

• 先按第一个字段排序

• 第一个字段相同的，再按第二个字段排序

• 第二个字段相同的，再按第三个字段排序

• 以此类推

所以查询时必须从最左边开始，才能利用索引的有序性。

就像字典的索引：先按拼音首字母排序，再按第二个字母排序...你不能跳过第一个字母直接查第二个字母。

【联合索引的好处】

1. 减少索引数量：一个联合索引相当于多个单列索引

2. 覆盖索引：查询的字段都在索引中，不需要回表

3. 提高查询效率：多个条件过滤，减少数据量

4. 减少回表：更多字段在索引中，更少回表

【联合索引的字段顺序怎么定？】

原则：

1. 等值查询的字段放前面：等值查询的字段可以一直匹配下去

2. 范围查询的字段放后面：范围查询后面的字段不能匹配索引

3. 区分度高的字段放前面：区分度高，过滤效果好

4. 经常查询的字段放前面：让更多查询能用到索引

举例：经常用 a = ? AND b > ? 查询

• a 是等值查询，b 是范围查询

• 索引应该建 (a, b)，不能是 (b, a)

• 因为 b 是范围查询，后面的 a 就用不到索引了

高频追问

追问1：范围查询为什么会中断最左匹配？

因为联合索引是按顺序排序的：

• 先按第一个字段排序

• 第一个字段相同的，再按第二个字段排序

• ...

如果前面的字段是范围查询（>、<、between），那后面的字段在索引中就不是有序的了。

举例：索引 (a, b)

a=1, b=1
a=1, b=2
a=1, b=3
a=2, b=1
a=2, b=2
a=3, b=1

如果查询 a > 1 AND b = 2：

• a > 1 的结果是 a=2 和 a=3

• 在 a=2 的范围内，b 是有序的

• 在 a=3 的范围内，b 也是有序的

• 但整体来看，b 不是有序的（a=2 的 b=2 和 a=3 的 b=1 乱序）

• 所以不能用 b 的索引来快速定位

所以范围查询后面的字段不能走索引。

追问2：like '%xxx' 为什么不走索引？like 'xxx%' 为什么走？

B+Tree 索引是按字段值的顺序排列的，前缀匹配可以利用顺序，后缀匹配不行。

like 'xxx%'（前缀匹配）：

• 可以利用索引的有序性

• 找到以 'xxx' 开头的位置，然后往后遍历

• 相当于范围查询，走索引

like '%xxx'（后缀匹配）：

• 后缀不确定，无法利用索引的有序性

• 只能全表扫描

• 不走索引

like '%xxx%'（中间匹配）：

• 更不行，全表扫描

如果需要后缀匹配怎么办？

• 可以把字段反过来存，查询的时候也反过来

• 或者用全文索引

• 或者用 ElasticSearch 等搜索引擎

追问3：为什么 OR 查询通常不走索引？

因为 OR 连接的条件，如果有一个字段没有索引，整个查询就不走索引。

举例：a 有索引，b 没有索引

SELECT * FROM user WHERE a = 1 OR b = 2;

• a = 1 可以走索引

• b = 2 没有索引，要全表扫描

• 既然都要全表扫描了，那 a 也不走索引了

• 直接全表扫描过滤

如果 a 和 b 都有索引呢？

• MySQL 可能用 index merge（索引合并）

• 分别查 a 和 b 的索引，然后合并结果

• 但效率不一定高，不如联合索引

所以尽量用 AND，少用 OR。

追问4：什么情况下索引会失效？

常见的索引失效场景：

1. 不满足最左前缀：联合索引跳过了前面的字段

2. 索引列上用函数：WHERE YEAR(create_time) = 2023

3. 索引列上有运算：WHERE age + 1 = 20

4. 隐式类型转换：字符串字段用数字查询，WHERE name = 123

5. like 前缀有 %：WHERE name LIKE '%张三'

6. OR 连接的条件有非索引列：WHERE a = 1 OR b = 2（b 没索引）

7. NOT IN / != / <>：这些通常不走索引（但要看优化器判断）

8. IS NULL / IS NOT NULL：不一定，看数据分布

9. 数据量太少：优化器觉得全表扫描更快

10. 使用了函数转换：WHERE UPPER(name) = 'ZHANGSAN'

注意：不是绝对的，MySQL 优化器会根据数据量、选择性等综合判断。

追问5：怎么判断查询有没有走索引？

用 EXPLAIN 命令查看执行计划。

EXPLAIN SELECT * FROM user WHERE name = '张三';

关键看这些列：

• type：访问类型，从好到差：system > const > eq_ref > ref > range > index > ALL

• key：实际使用的索引

• key_len：使用的索引长度

• rows：预计扫描的行数

• Extra：额外信息

如果 key 是 NULL，或者 type 是 ALL，就是没走索引，全表扫描。

32. 回表与覆盖索引

标准答案

回表和覆盖索引是 InnoDB 索引相关的两个重要概念。

【什么是回表】

InnoDB 的二级索引（非聚簇索引）叶子节点存的是主键值，不是完整数据。

查询时，如果需要的数据不在二级索引中，就需要：

1. 先查二级索引，找到主键值

2. 再用主键值查聚簇索引，拿到完整数据

这个过程就叫回表。

回表的过程：

二级索引 B+Tree → 找到主键值 → 聚簇索引 B+Tree → 找到完整行数据

两次 B+Tree 查询，比直接查聚簇索引多一次 IO。

举例：

-- name 有二级索引
SELECT * FROM user WHERE name = '张三';

1. 查 name 索引，找到主键 id = 1

2. 用 id = 1 查主键索引，拿到完整行数据

3. 返回结果

这就是一次回表。

【什么是覆盖索引】

覆盖索引（Covering Index）：查询需要的所有字段，都在索引中，不需要回表。

也就是说，索引"覆盖"了查询需要的所有字段。

举例： 有联合索引 (name, age)

SELECT name, age FROM user WHERE name = '张三';

• 查询的字段是 name 和 age

• 索引 (name, age) 里都有

• 直接从索引返回，不需要回表

• 这就是覆盖索引

怎么判断是不是覆盖索引：

• EXPLAIN 的 Extra 列显示 Using index

• 表示用了覆盖索引，直接从索引返回，不需要回表

【覆盖索引的好处】

1. 性能好：不需要回表，减少一次 B+Tree 查询，减少 IO

2. 减少 IO：索引比数据小，同样大小的内存能缓存更多索引

3. 避免随机 IO：回表是随机 IO，覆盖索引是顺序 IO

4. 减少内存占用：索引小，缓存命中率高

【怎么利用覆盖索引优化】

1. 只查需要的字段：不要 SELECT *，只查需要的字段，更容易用到覆盖索引

2. 建联合索引：把经常查询的字段建到联合索引中

3. 利用最左前缀：查询条件和返回字段都在索引中

举例：

-- 经常查询：SELECT name, age FROM user WHERE name = ?
-- 建联合索引
CREATE INDEX idx_name_age ON user(name, age);

这样查询就走覆盖索引，不需要回表。

高频追问

追问1：回表一定慢吗？什么时候回表影响大？

不一定，要看回表的次数。

• 回表次数少：比如根据唯一索引查一条，回表一次，影响不大

• 回表次数多：比如范围查询，返回很多行，每行都要回表，性能就差了

为什么回表次数多就慢？

• 二级索引是按索引字段顺序排列的，顺序读取

• 回表查聚簇索引是按主键查的，主键可能不连续

• 每次回表都是随机 IO

• 随机 IO 比顺序 IO 慢很多

所以：

• 少量数据回表 → 影响不大

• 大量数据回表 → 性能差很多，这时候覆盖索引就很有价值

追问2：SELECT * 为什么不好？

1. 用不到覆盖索引：SELECT * 要所有字段，索引不可能包含所有字段，一定要回表

2. 浪费带宽：返回不需要的字段，浪费网络带宽

3. 浪费内存：不需要的字段也加载到内存，浪费空间

4. 维护性差：表结构变了，SELECT * 可能返回多余的字段

优化建议：

• 只查需要的字段

• 尽量让查询能用到覆盖索引

追问3：覆盖索引和索引下推的区别？

| 维度 | 覆盖索引 | 索引下推（ICP） | |------|---------|----------------| | 作用 | 不需要回表，直接从索引返回 | 减少回表次数，在索引层过滤 | | Extra 显示 | Using index | Using index condition | | 性能提升 | 大，完全不回表 | 中，减少回表次数 | | 原理 | 所有字段都在索引中 | where 条件下推到索引层过滤 |

覆盖索引：完全不回表，直接从索引返回数据。 索引下推：还是要回表，但回表的次数少了（在索引层先过滤了一部分）。

两者可以同时存在，都是优化手段。

追问4：count(*) 会走索引吗？用什么索引？

会走索引，MySQL 会选择最小的索引来 count。

为什么？

• count(*) 只需要数行数，不需要数据

• 选最小的索引，占用空间小，扫描更快

• 一般选最小的二级索引（比如唯一索引、普通索引）

• 不会选聚簇索引（聚簇索引大，扫描慢）

所以 count(*) 通常会走二级索引，而且是最小的那个二级索引。

这也是一种覆盖索引的应用：只需要数行数，索引里就有足够的信息。

追问5：联合索引的字段顺序，考虑覆盖索引的话怎么排？

考虑覆盖索引时，联合索引的字段顺序要综合考虑：

1. 查询条件的字段放前面：满足最左前缀，where 条件能用索引

2. 返回的字段放后面：让返回字段也在索引中，实现覆盖索引

3. 等值查询放前面，范围查询放后面：范围查询后面的字段不能走索引

举例：

-- 查询：SELECT name, age FROM user WHERE name = ? AND age > ?
-- 索引：(name, age)

• name 是等值查询，放前面

• age 是范围查询，放后面

• 返回的 name 和 age 都在索引中

• 覆盖索引，不需要回表

如果索引是 (age, name)：

• age 是范围查询，后面的 name 不能走索引

• 只能用 age 过滤，name 不能用索引

• 而且 name 虽然在索引中，但查询条件不能充分利用索引

所以顺序很重要，要综合考虑查询条件和返回字段。

33. MySQL 为什么选择 MVCC

标准答案

MVCC（Multi-Version Concurrency Control，多版本并发控制）是 InnoDB 实现隔离级别的一种机制，让读写不冲突，提高并发性能。

【什么是 MVCC】

MVCC 的核心思想：每行数据有多个版本，读操作读历史版本，写操作创建新版本，读写不冲突。

• 读：读数据的历史版本（快照），不需要加锁

• 写：创建新版本，加锁

• 读写不冲突，大大提高并发性能

【为什么需要 MVCC】

没有 MVCC 的情况下：

• 读要加共享锁，写要加排他锁

• 读写互相阻塞

• 并发性能差

有了 MVCC：

• 读不加锁，读的是历史版本

• 写加锁，创建新版本

• 读写不冲突

• 并发性能好

MVCC 主要解决的问题：

1. 读写冲突：读不阻塞写，写不阻塞读

2. 提高并发：不用加锁就能读到一致性的数据

3. 实现隔离级别：实现 READ COMMITTED 和 REPEATABLE READ 隔离级别

【MVCC 的实现原理】

MVCC 基于三个东西实现：

1. 隐藏字段：每行数据有几个隐藏字段

2. undo log：保存数据的历史版本

3. Read View：读视图，判断哪个版本可见

1. 隐藏字段

InnoDB 每行数据都有几个隐藏字段：

• DB_TRX_ID：最后修改这行数据的事务 ID

• DB_ROLL_PTR：回滚指针，指向 undo log 中的上一个版本

• DB_ROW_ID：隐藏的行 ID（如果没有主键的话）

2. undo log（回滚日志）

• 每次修改数据时，都会把修改前的数据存到 undo log 中

• 通过 DB_ROLL_PTR 指针，把各个版本串成一个链表（版本链）

• 这样就能找到历史版本

3. Read View（读视图）

Read View 是一个读视图，用来判断当前事务能看到哪些版本的数据。

Read View 包含四个重要信息：

• m_ids：生成 Read View 时，当前活跃的事务 ID 列表（还没提交的）

• min_trx_id：活跃事务中最小的事务 ID

• max_trx_id：生成 Read View 时，下一个要分配的事务 ID（最大的 +1）

• creator_trx_id：生成这个 Read View 的事务的 ID

【可见性判断规则】

查询一个版本时，按以下规则判断是否可见：

1. 如果版本的 trx_id < min_trx_id → 可见（这个事务在 Read View 生成前就提交了）

2. 如果版本的 trx_id >= max_trx_id → 不可见（这个事务在 Read View 生成后才开始）

3. 如果版本的 trx_id 在 m_ids 中 → 不可见（这个事务还没提交）

4. 如果版本的 trx_id 不在 m_ids 中，且在 min 和 max 之间 → 可见（这个事务已经提交了）

简单说：生成 Read View 时已经提交的事务的修改可见，没提交的不可见，之后开始的也不可见。

如果当前版本不可见，就顺着版本链找前一个版本，继续判断，直到找到可见的版本。

【不同隔离级别下的 MVCC】

MVCC 在不同隔离级别下，Read View 的生成时机不同：

READ COMMITTED（读已提交）：

• 每次 SELECT 都生成一个新的 Read View

• 所以每次 SELECT 都能看到最新提交的数据

• 所以会有不可重复读的问题

REPEATABLE READ（可重复读）：

• 事务中第一次 SELECT 时生成一个 Read View

• 之后的 SELECT 都用同一个 Read View

• 所以整个事务中读到的数据都是一致的

• 解决了不可重复读的问题

这就是两种隔离级别的核心区别：Read View 的生成时机不同。

高频追问

追问1：MVCC 和锁的关系？

MVCC 和锁是配合使用的：

• 读操作：用 MVCC，不加锁，读历史版本

• 写操作：加锁（行锁），创建新版本

MVCC 解决的是读写冲突的问题，让读写不阻塞。 写写冲突还是要靠锁来解决。

另外：

• 快照读（普通 SELECT）：走 MVCC，不加锁

• 当前读（SELECT ... FOR UPDATE、INSERT、UPDATE、DELETE）：加锁，读最新版本

追问2：什么是快照读和当前读？

快照读（Snapshot Read）：

• 普通的 SELECT 语句

• 读的是快照版本（历史版本）

• 走 MVCC，不加锁

• 性能好

当前读（Current Read）：

• SELECT ... FOR UPDATE

• SELECT ... LOCK IN SHARE MODE

• INSERT、UPDATE、DELETE

• 读的是最新版本

• 需要加锁

• 性能稍差

简单说：普通 SELECT 是快照读，加锁的和写操作是当前读。

追问3：MVCC 能解决幻读吗？

在 REPEATABLE READ 隔离级别下：

• 快照读：MVCC 解决了幻读（因为用同一个 Read View，读到的行数不变）

• 当前读：MVCC 不能解决幻读，需要用 Next-Key Lock（间隙锁 + 行锁）来解决

所以 InnoDB 的 REPEATABLE READ 隔离级别，实际上通过 MVCC + Next-Key Lock 解决了幻读问题。

注意：标准 SQL 的 REPEATABLE READ 是不能解决幻读的，InnoDB 通过 Next-Key Lock 额外解决了。

追问4：undo log 和 redo log 的区别？

| 维度 | undo log | redo log | |------|---------|---------| | 作用 | 回滚数据，MVCC 版本链 | 崩溃恢复，保证持久性 | | 内容 | 修改前的数据 | 修改后的数据 | | 记录方式 | 逻辑日志 | 物理+逻辑日志 | | 写入时机 | 修改数据前 | 修改数据后，提交前 | | 循环写 | 不是，不断追加 | 是，固定大小，循环写 | | 配合 | MVCC、事务回滚 | WAL、崩溃恢复 |

简单记：

• undo log：回滚用的，存旧数据

• redo log：重做用的，存新数据

追问5：Read View 在 RC 和 RR 下有什么不同？

核心区别：生成时机不同

READ COMMITTED（读已提交）：

• 每次 SELECT 都生成一个新的 Read View

• 每次都能看到最新提交的数据

• 所以同一个事务中，两次 SELECT 可能读到不同的数据（不可重复读）

REPEATABLE READ（可重复读）：

• 事务中第一次 SELECT 时生成 Read View

• 之后的 SELECT 都复用这个 Read View

• 所以整个事务中读到的数据都是一致的

• 解决了不可重复读

这就是两种隔离级别的本质区别，其他都一样。

34. InnoDB 锁机制（行锁、间隙锁、Next-Key Lock）

标准答案

InnoDB 支持多种锁，用来保证并发下的数据一致性。

【锁的分类】

按粒度分：

• 全局锁：锁整个数据库

• 表级锁：锁整张表

• 行级锁：锁某一行

按模式分：

• 共享锁（S 锁，读锁）：多个事务可以同时加 S 锁，互斥 X 锁

• 排他锁（X 锁，写锁）：只有一个事务能加 X 锁，互斥所有锁

按算法分（行锁）：

• 记录锁（Record Lock）：锁单个记录

• 间隙锁（Gap Lock）：锁间隙，不锁记录本身

• Next-Key Lock：记录锁 + 间隙锁，左开右闭区间

【行锁（Record Lock）】

定义：锁定某一行记录。

什么时候加行锁：

• UPDATE、DELETE、INSERT 语句自动加 X 锁

• SELECT ... FOR UPDATE 手动加 X 锁

• SELECT ... LOCK IN SHARE MODE 手动加 S 锁

注意：行锁是加在索引上的，不是加在记录上的。如果没有索引，会升级为表锁。

【间隙锁（Gap Lock）】

定义：锁定两个索引之间的间隙，不锁记录本身。

作用：防止幻读。

为什么需要间隙锁？

如果只有行锁，事务 A 查了 id > 5 的记录，事务 B 插入一条 id = 6 的记录，事务 A 再查就多了一条，这就是幻读。

间隙锁把间隙也锁上，不让插入新数据，就防止了幻读。

间隙锁的特点：

• 只在 REPEATABLE READ 隔离级别下才有

• 锁的是间隙，不是记录

• 间隙锁之间不互斥（你锁你的，我锁我的，大家都锁同一个间隙也没关系）

• 间隙锁和插入操作互斥（不能往被锁住的间隙里插入）

间隙范围：

• 索引上的两个值之间的区间

• 包括负无穷到第一个值，最后一个值到正无穷

【Next-Key Lock】

定义：记录锁 + 间隙锁，锁定一个左开右闭的区间。

默认的行锁算法：InnoDB 默认用 Next-Key Lock 作为行锁算法。

举例：索引上有 10、20、30 三个值

• Next-Key Lock 区间：(负无穷, 10]、(10, 20]、(20, 30]、(30, 正无穷)

加锁规则（简化版）：

1. 加锁的基本单位是 Next-Key Lock（左开右闭）

2. 查找过程中访问到的对象才会加锁

3. 唯一索引等值查询，命中记录 → 退化为记录锁

4. 唯一索引等值查询，没命中 → 退化为间隙锁

5. 普通索引等值查询，命中记录 → 还要往后找，直到第一个不满足条件的，加间隙锁

加锁规则（详细版，两个原则 + 两个优化）：

• 原则 1：加锁的基本单位是 Next-Key Lock，左开右闭区间

• 原则 2：查找过程中访问到的对象才会加锁

• 优化 1：唯一索引等值查询，命中记录 → Next-Key Lock 退化为记录锁

• 优化 2：普通索引等值查询，向右遍历到第一个不满足条件的 → Next-Key Lock 退化为间隙锁

【锁的兼容性】

| | S 锁 | X 锁 | |---|------|------| | S 锁 | 兼容 | 互斥 | | X 锁 | 互斥 | 互斥 |

间隙锁之间是兼容的（两个事务可以同时锁同一个间隙），间隙锁和插入操作是互斥的。

高频追问

追问1：什么是幻读？怎么解决的？

幻读：同一个事务中，两次相同的查询，第二次查到了第一次没有的行（或者少了行），像出现了幻觉一样。

注意：幻读特指"新增的行"。更新导致的变化是不可重复读，不是幻读。

解决幻读的方法：

1. MVCC（快照读）：

   • 普通 SELECT 是快照读

   • 用同一个 Read View，读到的行数不变

   • 解决了快照读的幻读问题

2. Next-Key Lock（当前读）：

   • SELECT ... FOR UPDATE 等当前读

   • 用 Next-Key Lock（行锁 + 间隙锁）

   • 把间隙也锁上，不让插入新数据

   • 解决了当前读的幻读问题

所以 InnoDB 的 RR 隔离级别，通过 MVCC + Next-Key Lock 解决了幻读。

追问2：间隙锁为什么会导致死锁？

间隙锁之间是兼容的，两个事务可以同时锁住同一个间隙。

但间隙锁和插入操作是互斥的。

死锁场景：

1. 事务 A 加了间隙锁（锁住 (5, 10) 这个间隙）

2. 事务 B 也加了间隙锁（也锁住 (5, 10)，因为间隙锁之间兼容）

3. 事务 A 往 (5, 10) 插入 → 等事务 B 释放间隙锁

4. 事务 B 往 (5, 10) 插入 → 等事务 A 释放间隙锁

5. 互相等待 → 死锁

这就是间隙锁导致的死锁，很常见。

怎么避免？

• 降低隔离级别到 RC（没有间隙锁）

• 尽量用唯一索引等值查询（退化为记录锁，没有间隙）

• 控制事务大小，减少锁的持有时间

追问3：行锁是加在数据上还是索引上？

行锁是加在索引上的，不是加在数据行上。

为什么？

• InnoDB 的数据是按索引组织的（聚簇索引）

• 行锁通过索引来定位和锁定

• 如果查询没有走索引，就不能加行锁，会升级为表锁

举例：

-- name 没有索引
UPDATE user SET age = 20 WHERE name = '张三';

• 因为 name 没有索引，不能定位到具体行

• 会全表扫描，给所有行加锁（相当于表锁）

• 性能很差