奇伏禾

Java 并发编程：线程与锁深入浅出

Sun, 19 Jul 2026 00:00:00 +0000

前言

并发编程是 Java 后端面试的"必考题"。这篇文章从线程和锁两个核心维度出发，涵盖实习生面试的高频考点，并适度深入源码帮助理解。

一、线程基础

1.1 创建线程的三种方式

// 方式一：继承 Thread
class MyThread extends Thread {
    @Override
    public void run() {
        System.out.println("Thread running");
    }
}

// 方式二：实现 Runnable（推荐）
class MyTask implements Runnable {
    @Override
    public void run() {
        System.out.println("Task running");
    }
}

// 方式三：实现 Callable + FutureTask（带返回值）
class MyCallable implements Callable<String> {
    @Override
    public String call() {
        return "Result";
    }
}

面试点： Runnable 比 Thread 好在哪？

Java 单继承，实现接口不影响继承其它类
解耦任务定义与执行方式
方便线程池复用

1.2 线程生命周期

NEW ──start()──→ RUNNABLE ──获取锁──→ BLOCKED
                      │                    │
                等待CPU调度            释放锁后回到RUNNABLE
                      │
                得到时间片 → RUNNING
                      │
              ┌───────┼───────┐
              ↓       ↓       ↓
          WAITING  TIMED_WAITING  TERMINATED
        (wait/join)  (sleep(ms))

所有状态在 Thread.State 枚举中定义（JDK 源码）：

// 来自 OpenJDK Thread.java
public enum State {
    NEW,        // 新建，尚未start
    RUNNABLE,   // 可运行（就绪+运行合并）
    BLOCKED,    // 阻塞等待monitor锁
    WAITING,    // 等待（Object.wait, Thread.join, LockSupport.park）
    TIMED_WAITING, // 带超时的等待
    TERMINATED  // 已结束
}

二、synchronized 关键字

2.1 用法

// 1. 修饰实例方法 → 锁的是 this
public synchronized void method() { }

// 2. 修饰静态方法 → 锁的是 Class 对象
public static synchronized void staticMethod() { }

// 3. 同步代码块 → 锁指定对象
public void block() {
    synchronized (this) {
        // 临界区
    }
}

2.2 底层原理（重点）

synchronized 在 JVM 中是通过 Monitor（监视器锁）实现的。

看字节码：

public void method() {
    synchronized (this) {
        System.out.println("hello");
    }
}

反编译看关键字节码指令：

monitorenter  // 进入，尝试获取锁
...
monitorexit   // 退出，释放锁（正常路径）
monitorexit   // 退出，释放锁（异常路径，保证一定会释放）

JDK 6 之后的大优化： 锁不再是"重量级"的。JVM 引入了锁升级机制。

2.3 锁升级（无锁 → 偏向锁 → 轻量级锁 → 重量级锁）

无锁 → 偏向锁 → 轻量级锁（自旋锁）→ 重量级锁
←——————————————————————————————→ 只能升级，不能降级

阶段	触发条件	开销
偏向锁	只有一个线程访问同步块	极低，只在CAS一次
轻量级锁	少量线程交替获取，不竞争	自旋等待，不挂起
重量级锁	多线程真正竞争	线程挂起+唤醒，上下文切换

面试高频题：“synchronized 是重量级锁吗？”

答：JDK 6 之后不再是。默认是偏向锁，只有真正多线程竞争时才会升级为重量级锁。

三、Lock 接口与实现

3.1 ReentrantLock

Lock lock = new ReentrantLock(true); // fair = true 表示公平锁

lock.lock();
try {
    // 临界区
} finally {
    lock.unlock(); // 一定在finally中释放！
}

3.2 synchronized vs Lock

对比项	synchronized	ReentrantLock
锁获取/释放	自动	手动（必须finally释放）
可中断	❌	✅ lockInterruptibly()
超时尝试	❌	✅ tryLock(timeout)
公平性	非公平	可选公平/非公平
条件变量	wait/notify	Condition（更灵活）
性能	优化后≈Lock	差不多

3.3 AQS（AbstractQueuedSynchronizer）源码级理解

ReentrantLock 的核心是 AQS，这是 Java 并发包的基石。

// AQS 核心字段（简化理解）
public abstract class AbstractQueuedSynchronizer {
    // 核心：volatile 的 state
    // ReentrantLock 中，0=无锁，>0=持有锁（可重入计数）
    private volatile int state;
    
    // CLH 队列头尾（双向链表，存放等待线程）
    private transient Node head;
    private transient Node tail;
    
    // 独占模式：当前持有锁的线程
    private transient Thread exclusiveOwnerThread;
}

加锁流程（非公平锁）：

lock()
  ├─ CAS尝试设置 state=1（快速抢锁）
  │    ├─ 成功 → 设置 exclusiveOwnerThread = 当前线程
  │    └─ 失败 → acquire(1)
  │               ├─ tryAcquire：再次尝试（可能重入）
  │               └─ 失败 → addWaiter 加入CLH队列 → acquireQueued 阻塞
  └─ 公平锁跳过CAS抢锁，直接acquire

CLH 队列 是一个双向链表。每个 Node 持有 waitStatus（是否被取消、是否需要唤醒后继等）。

四、volatile 关键字

4.1 两大语义

private volatile boolean flag = true;

可见性：一个线程修改 flag，其它线程立即可见（绕过 CPU 缓存，直接读写主存）
禁止指令重排序：读写 volatile 变量前后的指令不能被重排序

4.2 经典例子：DCL 单例

public class Singleton {
    private static volatile Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {           // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {     // 第二次检查
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

为什么需要 volatile？ instance = new Singleton() 不是原子操作：

分配内存 → 初始化对象 → 赋值给引用
  ①           ②           ③

JIT 可能重排序为 ①→③→②，另一个线程读到非 null 但未初始化的对象。volatile 禁止这个重排序。

五、常见并发工具

5.1 CountDownLatch

// 等待 N 个线程完成
CountDownLatch latch = new CountDownLatch(3);

for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        // 工作...
        latch.countDown(); // 计数减1
    }).start();
}

latch.await(); // 主线程等待计数到0

5.2 Semaphore（信号量）

Semaphore sem = new Semaphore(3); // 同时允许3个线程

sem.acquire();  // 获取许可，没有则阻塞
// 访问资源
sem.release();  // 释放许可

5.3 面试题：三个线程交替打印ABC

private int state = 0;
private final Lock lock = new ReentrantLock();
private final Condition[] conditions = {
    lock.newCondition(),
    lock.newCondition(),
    lock.newCondition()
};

public void print(int id) {
    for (int i = 0; i < 10; i++) {
        lock.lock();
        try {
            while (state % 3 != id) {
                conditions[id].await();
            }
            System.out.print((char) ('A' + id));
            state++;
            conditions[(id + 1) % 3].signal();
        } finally {
            lock.unlock();
        }
    }
}

六、常见面试题汇总

题目	回答要点
线程和进程的区别？	进程=资源分配最小单位，线程=CPU调度最小单位，共享堆空间
sleep 和 wait 的区别？	sleep不释放锁，wait释放锁；sleep需要catch InterruptedException，wait需在synchronized块内
死锁的条件？	互斥、持有并等待、不可剥夺、循环等待
怎么避免死锁？	按固定顺序加锁、使用 tryLock 超时、减少锁粒度
ThreadLocal 了解吗？	每个线程维护自己的副本，用 Entry(WeakReference) 存储，注意内存泄漏
线程池参数？	corePoolSize, maxPoolSize, keepAliveTime, workQueue, threadFactory, handler

七、线程池

7.1 ThreadPoolExecutor 核心参数

new ThreadPoolExecutor(
    corePoolSize,       // 核心线程数
    maximumPoolSize,    // 最大线程数
    keepAliveTime,      // 空闲线程存活时间
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),  // 阻塞队列
    Executors.defaultThreadFactory(),
    new ThreadPoolExecutor.AbortPolicy()  // 拒绝策略
);

执行流程：

提交任务
  ├─ 线程数 < corePoolSize → 创建新线程执行
  ├─ 线程数 >= corePoolSize → 放入阻塞队列
  ├─ 队列满 → 线程数 < maxPoolSize → 创建临时线程
  └─ 队列满 & 线程数 >= maxPoolSize → 执行拒绝策略

7.2 拒绝策略

策略	行为
AbortPolicy（默认）	抛 RejectedExecutionException
CallerRunsPolicy	提交任务的线程自己执行
DiscardPolicy	直接丢弃
DiscardOldestPolicy	丢弃队列中最旧的任务

总结

并发编程的核心脉络：

线程：创建、状态、中断
共享：synchronized、volatile、Lock
协作：wait/notify、Condition、LockSupport
工具：CountDownLatch、Semaphore、CyclicBarrier
容器：ConcurrentHashMap、CopyOnWriteArrayList
线程池：ThreadPoolExecutor、参数调优

面试实习岗位，掌握前三个就足以应对大多数问题了。建议结合源码（AQS 加锁流程、synchronized 锁升级）深入理解而不是死记硬背。

JVM 核心知识：内存模型、GC 与类加载

Sun, 19 Jul 2026 00:00:00 +0000

前言

JVM（Java Virtual Machine）是 Java “一次编写，到处运行” 的基石。实习生面试中 JVM 主要考察三个模块：内存区域划分、垃圾回收、类加载机制。

一、JVM 内存区域

1.1 整体结构

┌────────────────────────────────────┐
│           Java 堆 (Heap)           │ ← 所有线程共享
│    ┌──────────┬──────────┐        │
│    │  新生代   │  老年代   │        │
│    │ Eden S0 S1│          │        │
│    └──────────┴──────────┘        │
├────────────────────────────────────┤
│           方法区 (元空间)            │ ← 类信息、常量、静态变量
├────────────┬───────────────────────┤
│  虚拟机栈   │    本地方法栈           │ ← 线程私有
│ (栈帧)     │    (native)           │
├────────────┴───────────────────────┤
│          程序计数器 (PC)             │ ← 线程私有
└────────────────────────────────────┘

1.2 各区域详解

堆（Heap） — GC 主要活动区域

存储对象实例和数组
所有线程共享
分代管理：新生代（Eden + Survivor）× 老年代
默认比例：-Xms 初始堆，-Xmx 最大堆

虚拟机栈（Stack） — 线程私有

每个方法调用创建一个栈帧，包含：
- 局部变量表（基本类型、对象引用）
- 操作数栈（计算临时数据）
- 动态链接（指向运行时常量池的方法引用）
- 方法出口（return 地址）

public int add(int a, int b) {
    return a + b;
}
// 字节码视角：
// 0: iload_1     ← 从局部变量表加载 a
// 1: iload_2     ← 从局部变量表加载 b
// 2: iadd        ← 操作数栈弹出a、b，相加，压回
// 3: ireturn     ← 返回结果

方法区 / 元空间（Metaspace）

JDK 8+ 将永久代（PermGen）替换为元空间
元空间使用本地内存，不再受 JVM 堆大小限制
存储：类信息、常量、静态变量、JIT 编译后的代码

1.3 面试题：String 到底存在哪？

String s1 = "hello";          // 字符串常量池（在堆中）
String s2 = new String("hello"); // 堆对象
String s3 = s2.intern();      // 返回常量池中的引用

System.out.println(s1 == s2); // false
System.out.println(s1 == s3); // true

JDK 7 之后字符串常量池从方法区移到了堆中，但"进入常量池"的逻辑不变。

二、垃圾回收（GC）

2.1 判断对象是否存活

引用计数法（主流 JVM 不用）：

每个对象维护引用计数，为 0 即死亡
问题：循环引用无法回收

可达性分析（JVM 实际使用）：

从 GC Roots 出发，不可达的对象就是垃圾

GC Roots 包括：
├─ 虚拟机栈（局部变量表）中引用的对象
├─ 方法区中静态属性引用的对象
├─ 方法区中常量引用的对象
├─ 本地方法栈中 JNI 引用的对象
└─ 活跃线程（Thread）

2.2 引用类型

类型	说明	GC 回收时机
强引用	`new Object()`	永不回收
软引用	SoftReference	内存不足时
弱引用	WeakReference	下次GC必然回收
虚引用	PhantomReference	任何时候可能回收，用于跟踪对象回收

ThreadLocal 内存泄漏：ThreadLocalMap 的 key 是弱引用，value 是强引用。如果 key 被 GC 回收，value 永远无法访问，造成泄漏。

2.3 分代收集理论

新生代（1/3堆）           老年代（2/3堆）
┌─────────┬──┬──┐       ┌─────────┐
│  Eden   │S0│S1│  →    │   Old   │
│  8/10   │1/10│1/10│   │         │
└─────────┴──┴──┘       └─────────┘
     │
  Minor GC 触发：
  存活对象 age++ 并移到 S1（或老年代）
  Eden + S0 清空，S0/S1 交换角色

对象晋升老年代的条件：

年龄达到阈值（默认15，通过 -XX:MaxTenuringThreshold 设置）
大对象直接进入老年代（-XX:PretenureSizeThreshold）
Survivor 区同年龄对象总和 > Survivor 一半

2.4 常见 GC 算法

算法	描述	适用区域
标记-清除	标记存活→清除死亡对象	老年代（CMS）
标记-复制	分成两块，存活复制到另一块	新生代
标记-整理	标记存活→向一端移动→清理边界外	老年代（G1）

2.5 常见垃圾收集器

Serial（单线程、暂停所有用户线程）
  │
Parallel Scavenge + Parallel Old（关注吞吐量）
  │
CMS（并发标记清除，关注最短停顿，有碎片问题）
  │
G1（区域化分代，默认 JDK 9+，大堆推荐）
  │
ZGC（JDK 17+ 生产可用，亚毫秒级停顿，适合超大堆）

G1 关键特点：

把堆分成多个 Region（1MB~32MB）
优先回收垃圾最多的 Region（Garbage First 名字来源）
通过 -XX:MaxGCPauseMillis 控制 GC 停顿时间
不需要连续内存，减少碎片

2.6 面试题：GC 什么时候触发？

Minor GC: Eden 区满时
Full GC:
  ├─ 老年代空间不足
  ├─ 元空间不足（JDK 8+）
  ├─ System.gc() 显式调用（只是建议，不保证）
  └─ promotion failed / concurrent mode failure（CMS）

三、类加载机制

3.1 类加载过程

加载 → 验证 → 准备 → 解析 → 初始化 → 使用 → 卸载
  │      │      │      │
  │      │      └── 分配静态变量内存+默认值
  │      └───────── 校验字节码合法性（CAFEBABE）
  └───────────── 读 class 文件二进制流

初始化阶段才执行 <clinit>() 方法（静态变量赋值 + 静态代码块）。

3.2 双亲委派模型

// 简化版 ClassLoader.loadClass()
protected Class<?> loadClass(String name) {
    // 1. 检查是否已加载
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 2. 交给父类加载器
            c = parent.loadClass(name);
        } catch (ClassNotFoundException e) {
            // 3. 父类找不到，自己找
            c = findClass(name);
        }
    }
    return c;
}

启动类加载器（Bootstrap ClassLoader）
  ↑ 委托
扩展类加载器（Extension ClassLoader）
  ↑ 委托
应用程序类加载器（Application ClassLoader）
  ↑ 委托
自定义类加载器

为什么双亲委派？ 安全。防止自己写一个 java.lang.String 替换 JDK 的核心类。

3.3 打破双亲委派

Tomcat 等 Web 容器为了隔离多个应用的类，自己先加载，找不到才给父类。这也是 SPI（Service Provider Interface）机制的实现方式——Thread.contextClassLoader。

四、JVM 调优基础

4.1 常用参数

# 堆设置
-Xms512m          # 初始堆大小
-Xmx2g            # 最大堆大小
-Xmn256m          # 新生代大小
-XX:MetaspaceSize=128m  # 元空间大小
-XX:+UseG1GC      # 使用G1收集器
-XX:MaxGCPauseMillis=200  # 目标GC停顿时间

# 问题排查
-XX:+PrintGCDetails -XX:+PrintGCDateStamps
-Xloggc:gc.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/dump

4.2 OOM 排查思路

1. 确认错误信息：java.lang.OutOfMemoryError: Java heap space
               还是 java.lang.OutOfMemoryError: Metaspace
               或者是 java.lang.OutOfMemoryError: unable to create new native thread

2. 获取 dump：加上 -XX:+HeapDumpOnOutOfMemoryError

3. 分析 dump：用 jvisualvm / MAT / jprofiler
   - 看大对象（byte[] 通常是文件/图片）
   - 看类数量（加载了太多类→元空间问题）
   - 看线程数（太多线程→native thread OOM）

五、JIT 即时编译

热点代码被 JVM 编译为本地机器码，而不是一直解释执行。

解释执行（启动快，执行慢）
    │ 计数达到阈值
    ↓
C1 编译器（Client 模式，轻度优化）
    │ 更热的代码
    ↓
C2 编译器（Server 模式，深度优化）

分层编译（tiered compilation）结合了两者优点：先用 C1 快速编译，热点再升级到 C2。

JDK 8 默认开启分层编译。

面试重点速记

题目	要点
JVM 内存区域有哪些？	堆、栈、方法区、程序计数器、本地方法栈，各司其职
new 对象的过程？	类加载检查→分配内存（指针碰撞/空闲列表）→初始化零值→设置对象头→执行 init
有哪些 GC 算法？	标记-清除、标记-复制、标记-整理
CMS 和 G1 区别？	CMS 并发但碎片化，G1 分区整理、可预测停顿
双亲委派机制？	向上委托，向下加载，安全+避免重复
OOM 怎么排查？	参数留痕→拿到 dump→找大对象/线程/类加载器

MySQL 与 InnoDB：存储引擎核心原理

Sun, 19 Jul 2026 00:00:00 +0000

前言

MySQL 是最流行的关系型数据库，而 InnoDB 是 MySQL 默认（且最常用）的存储引擎。实习生面试的重点：索引、事务隔离、MVCC、锁机制。

一、一条 SQL 的执行过程

客户端 → 连接器（认证+维持连接）
         → 查询缓存（8.0 已移除）
         → 解析器（词法分析 → 语法分析 → 生成 AST）
         → 预处理器（检查表/列是否存在）
         → 优化器（选择索引、决定 JOIN 顺序、生成执行计划）
         → 执行器（调用存储引擎接口，返回结果）

关键点：

连接器管理连接超时（wait_timeout，默认8小时）
优化器选错索引是慢查询的常见原因（可通过 force index 强制指定）
执行器真正调存储引擎的 read 接口，一行行返回

二、InnoDB 架构

2.1 内存结构

┌─ Buffer Pool（缓冲池）────────────────┐
│  ├─ 数据页缓存 (data pages)           │
│  ├─ 索引页缓存 (index pages)          │
│  ├─ 插入缓冲 (change buffer)          │
│  ├─ 自适应哈希索引 (Adaptive Hash Index)│
│  └─ 锁信息 (lock info)                │
└────────────────────────────────────────┘
      │
      │ 通过 redo log 保证持久性（WAL）
      ▼
┌─ 磁盘 ──────────────────────────────┐
│  .ibd 文件（表数据+索引）           │
│  redo log（ib_logfile0/1）          │
│  undo log（回滚段）                  │
│  binlog（Server 层，归档+主从）       │
└──────────────────────────────────────┘

Buffer Pool 是 InnoDB 的灵魂，用 LRU 变体 管理缓存页。innodb_buffer_pool_size 通常设为物理内存的 60%~80%。

2.2 WAL（Write-Ahead Logging）

“先写日志，再写磁盘。” 修改数据时：

更新内存中的 Buffer Pool (脏页)
     ↓
写入 redo log（顺序IO，很快） ← 做到这里就返回"修改成功"
     ↓
后台线程在合适时机将脏页刷回磁盘（随机IO，较慢）

为什么 WAL 快？

redo log 是顺序追加写（磁盘顺序 IO ≈ 1000MB/s）
数据文件是随机写（磁盘随机 IO ≈ 10MB/s）
顺序写比随机写快两个数量级

三、索引

3.1 B+ Tree 结构

InnoDB 使用 B+ Tree 作为索引结构。

           ┌───────────┐
           │  非叶子节点  │ ← 只存"索引键 + 指向子节点的指针"
           │   [50, 80] │    一个页(16KB)能存几百~上千个key
           └─────┬─────┘
                 │
         ┌───────┼───────┐
         ▼       ▼       ▼
   ┌────┐  ┌────┐  ┌────┐
   │1-49│  │51-79│  │81-+│  ← 非叶子节点
   └────┘  └────┘  └────┘
         ...
           ┌───────────┐
           │  叶子节点   │ ← 存"完整的行数据"（聚簇索引）
           │           │   或"主键值"（二级索引）
           └───────────┘
       叶子节点用双向链表连接 → 支持范围查询

B+ Tree 比 B-Tree 好在哪里？

非叶子节点不存数据，一个页能存更多 key → 树更矮 → IO 更少
叶子节点链表连接，范围查询只需遍历链表

3.2 聚簇索引 vs 二级索引

CREATE TABLE user (
    id INT PRIMARY KEY,       -- 聚簇索引
    name VARCHAR(50),
    age INT,
    INDEX idx_name (name)     -- 二级索引
);

	聚簇索引	二级索引
谁建立的	主键	自己建立的索引
叶子节点存什么	完整行数据	主键值
数量	1个	多个
回表	不需要	查二级索引得到主键→回聚簇索引查完整行

覆盖索引：如果查询只需要 name，二级索引 idx_name 的叶子节点就包含了 name，不需要回表。

-- 只查 name，idx_name 已经包含 name，无需回表
SELECT name FROM user WHERE name = 'Alice';

3.3 索引最左前缀原则

CREATE INDEX idx_city_age ON user(city, age);
-- 走索引：WHERE city = '北京'
-- 走索引：WHERE city = '北京' AND age = 25
-- 不走索引：WHERE age = 25 （跳过了city）

联合索引本质是按第一列排序→再按第二列排序。跳过第一列直接查第二列就没意义了。

3.4 面试题：为什么用 B+ Tree 而不是红黑树 / 哈希？

结构	优点	缺点
哈希	O(1) 精确查询	不支持范围查询、无法排序
红黑树	平衡二叉树	树太高，一个路径可能几十次 IO
B+ Tree	胖矮（3~4层），范围查询高效	结构略复杂

磁盘 IO 一次 ≈ 10ms，B+ Tree 3~~4 层 = 3~~4 次 IO，红黑树几十层 = 几十次 IO。

四、事务与 MVCC

4.1 ACID

特性	含义	InnoDB 实现
A（原子性）	要么全做，要么全不做	undo log（回滚）
C（一致性）	数据始终符合约束	应用+数据库共同保证
I（隔离性）	事务互不干扰	锁 + MVCC
D（持久性）	提交后数据不丢失	redo log + double write buffer

4.2 隔离级别

-- MySQL 四种隔离级别（由低到高）
READ UNCOMMITTED    -- 脏读、不可重复读、幻读都可能
READ COMMITTED      -- 解决了脏读（Oracle默认）
REPEATABLE READ     -- 解决了脏读+不可重复读（InnoDB默认）
SERIALIZABLE        -- 全部解决，但性能最低

InnoDB 默认是 REPEATABLE READ，但通过间隙锁解决了幻读。

4.3 MVCC 多版本并发控制

MVCC 是 InnoDB 实现高并发的核心。

核心数据结构：每行数据有两个隐藏列：

DB_TRX_ID：最近修改这行数据的事务 ID
DB_ROLL_PTR：指向 undo log 的指针，用于构建旧版本

ReadView（读视图）：事务在某个时刻看到的数据版本快照。

// ReadView 包含：
// m_ids     → 当前活跃的事务ID列表
// min_trx_id → m_ids 中的最小值
// max_trx_id → 下一个要分配的事务ID
// creator_trx_id → 创建这个 ReadView 的事务自己的ID

判断是否可见的规则：

DB_TRX_ID < min_trx_id  → 可见（已提交）
DB_TRX_ID > max_trx_id  → 不可见（未来的事务）
DB_TRX_ID in m_ids      → 不可见（活跃中）
creator_trx_id          → 自己改的，可见

RC（读已提交）级别： 每次 SELECT 都生成一个新的 ReadView RR（可重复读）级别： 事务中第一次 SELECT 生成 ReadView，之后复用

4.4 MVCC + 幻读

RR 级别下，MVCC 只能保证 快照读（普通 SELECT）没有幻读。

-- 事务A
SELECT * FROM user WHERE age > 20;  -- 查到了5行，生成ReadView
                                      -- 这就是快照读，能看到的历史版本
-- 事务B插入一条 age=25 的数据并提交

-- 事务A 再次执行
SELECT * FROM user WHERE age > 20;  -- 还是5行（MVCC快照隔离了B的插入）

-- 但如果事务A执行
UPDATE user SET name = 'x' WHERE age > 20;  -- 当前读，能看到事务B插入的行
-- 这时就能看到新行 → 幻读出现在"当前读"而非"快照读"

为了防止 当前读 幻读，InnoDB 加 间隙锁（Gap Lock）。

五、锁机制

5.1 行锁

InnoDB 锁的是 索引记录（不是数据行本身！）：

-- 走主键/唯一索引 → 锁住对应行（Record Lock）
UPDATE user SET name = 'a' WHERE id = 1;

-- 走普通索引 → 锁住索引记录+间隙（Gap Lock / Next-Key Lock）
UPDATE user SET name = 'a' WHERE age = 25;

-- 没走索引 → 锁全表！（所有行）
UPDATE user SET name = 'a' WHERE name LIKE '%x%';

没有索引就会锁全表！ 这是 InnoDB 最常见的性能陷阱。

5.2 行锁算法

类型	范围	场景
Record Lock	锁单个索引记录	等值匹配唯一索引
Gap Lock	锁间隙（区间），不锁记录	等值匹配普通索引 / 范围查询
Next-Key Lock	Gap + Row = 锁区间+记录	默认算法，防幻读

假设索引值：[5, 10, 15, 20]

WHERE age = 10 的 Next-Key Lock 锁 (5, 10] 和 (10, 15)
  ↓
另一个事务插入 age=8 或 age=12 会被阻塞（防止幻读）
插入 age=16 可以

5.3 死锁

-- 事务A
UPDATE user SET name = 'a' WHERE id = 1;
UPDATE user SET name = 'b' WHERE id = 2;

-- 事务B
UPDATE user SET name = 'c' WHERE id = 2;
UPDATE user SET name = 'd' WHERE id = 1;

InnoDB 自动检测死锁：会将一个事务回滚（选择的回滚成本较小的那个）。SHOW ENGINE INNODB STATUS\G 可以查看最近一次死锁信息。

避免方案：固定访问顺序（比如都按 id 从小到大操作）。

六、SQL 优化基础

6.1 EXPLAIN 怎么看

EXPLAIN SELECT * FROM user WHERE name = 'Alice'\G

关键字段：

字段	要关注的
type	const > ref > range > index > ALL（最好到最差）
key	实际使用的索引
rows	预估扫描行数
Extra	Using index（覆盖索引）、Using filesort（需要优化）、Using temporary（最差）

6.2 常见优化方向

1. 避免 SELECT *  → 减少回表，利用覆盖索引
2. 避免索引列上做计算 → WHERE age+1 > 20 不走索引
3. 避免隐式类型转换 → WHERE phone = 138... 如果phone是varchar，不走索引
4. LIKE '%abc' 不走索引（最左前缀），'abc%' 可以走
5. 分页优化 → 用游标（WHERE id > ? LIMIT 10）代替 LIMIT 100000, 10
6. JOIN 小表驱动大表 → 被驱动表关联字段加索引

面试重点速记

题目	要点
InnoDB 索引结构？	B+ Tree，聚簇索引存完整行，二级索引存主键
为什么用 B+ Tree？	树矮（3~4层）= 少 IO，叶子链表=范围查询高效
什么是回表？	二级索引查到主键→再查聚簇索引取完整行
MVCC 原理？	隐藏列(TRX_ID) + ReadView + undo log 构造快照
事务隔离级别？	RU/RC(RR InnoDB默认)/SERIALIZABLE，InnoDB RR防了幻读
行锁、间隙锁、Next-Key？	锁索引，无索引锁全表，Next-Key = Record + Gap

RabbitMQ 消息队列核心原理

Sun, 19 Jul 2026 00:00:00 +0000

前言

RabbitMQ 是基于 AMQP 协议的开源消息中间件，用 Erlang 编写。核心模型是 生产者 → 交换机 → 队列 → 消费者。

面试重点：五种消息模型、可靠投递、死信队列、如何避免消息堆积。

一、核心概念

1.1 架构

           ┌────────────── Virtual Host ──────────────┐
           │                                          │
Producer ──→ Exchange（交换机）──binding──→ Queue ←── Consumer
           │                     routing key           │
           │                    ┌──────────────┐      │
           │                    │   绑定关系     │      │
           │                    │ queueA → rk1  │      │
           │                    │ queueB → rk2  │      │
           │                    └──────────────┘      │
           └──────────────────────────────────────────┘

组件	作用
Producer	消息的发送者
Exchange	路由器，根据 routing key 将消息发给一个或多个队列
Queue	消息的缓冲区，消费者从中取消息
Consumer	消息的接收处理者
Virtual Host	逻辑隔离，一个 Broker 可以划分多个 VHost

1.2 四种交换机类型

// 1. Direct Exchange（直连）
// 路由键精确匹配 → 点对点
channel.basicPublish("directExchange", "error", null, msg.getBytes());
// queue绑定 "error" → 只有这个queue能收到

// 2. Fanout Exchange（广播）
// 忽略 routing key，发给所有绑定的队列
channel.basicPublish("fanoutExchange", "", null, msg.getBytes());

// 3. Topic Exchange（主题，最灵活）
// 通配符匹配：* 匹配一个词，# 匹配零个或多个词
channel.basicPublish("topicExchange", "order.created", null, msg.getBytes());
// 可以绑定：order.*  → 收到 order.created、order.paid
//          order.#  → 收到 order.created、order.created.success

// 4. Headers Exchange（不常用）
// 用 header 属性匹配，不用 routing key

1.3 面试题：RabbitMQ 消息模型选型

场景	推荐模型
一个订单消息发给一个处理服务	Direct + Work Queue
事件通知（用户注册→发邮件+发短信+更新积分）	Fanout
根据类型路由（订单日志→不同队列处理）	Topic

二、消息可靠投递

2.1 生产者 → RabbitMQ（确认机制）

// Spring Boot 配置
spring.rabbitmq.publisher-confirm-type=correlated  // 开启确认
spring.rabbitmq.publisher-returns=true              // 开启回退

// 回调
@Bean
public RabbitTemplate.ConfirmCallback confirmCallback() {
    return (correlationData, ack, cause) -> {
        if (ack) {
            // 消息已到达交换器
        } else {
            // 消息未到达交换器 → 处理失败（记录日志/重试）
            log.error("消息发送失败: {}", cause);
        }
    };
}

@Bean
public RabbitTemplate.ReturnsCallback returnsCallback() {
    return returned -> {
        // 消息到达交换器但无匹配队列
        log.warn("消息路由失败: {}", returned.getMessage());
    };
}

2.2 RabbitMQ → 消费者（ACK）

// 手动确认模式（推荐！）
spring.rabbitmq.listener.simple.acknowledge-mode=manual

@RabbitListener(queues = "order.queue")
public void handle(Order order, Message message, Channel channel) {
    try {
        // 处理业务
        process(order);
        // 处理完成，确认消息
        channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
    } catch (Exception e) {
        // 处理失败
        channel.basicNack(message.getMessageProperties().getDeliveryTag(), 
                         false, true);  // true=重新入队
    }
}

三种 ACK 状态：

basicAck    → 成功处理，删除消息
basicNack requeue=true  → 处理失败，重新入队
basicNack requeue=false → 处理失败，丢弃或进入死信队列（推荐用这个）

2.3 幂等性

// 消息可能被重复消费 → 必须幂等
@RabbitListener(queues = "order.queue")
public void handle(Order order) {
    // 方案1：数据库唯一键约束
    String msgId = order.getMsgId();
    if (duplicateCheck.exists(msgId)) {
        return; // 已处理过
    }
    
    // 方案2：Redis SET NX
    Boolean ok = redisTemplate.opsForValue()
        .setIfAbsent("msg:" + msgId, "1", Duration.ofHours(1));
    if (Boolean.FALSE.equals(ok)) {
        return;
    }
    
    process(order);
}

三、死信队列（DLQ）

3.1 什么情况会变死信？

1. 消息被 consumer 拒绝（basicNack/basicReject）且 requeue=false
2. 消息 TTL 过期
3. 队列达到最大长度（溢出）
              ↓
      进入死信交换机（DLX）
              ↓
      死信队列（DLQ）

3.2 配置

// 普通队列（指定死信交换机）
@Bean
public Queue orderQueue() {
    return QueueBuilder.durable("order.queue")
        .deadLetterExchange("order.dlx")       // 绑定死信交换机
        .deadLetterRoutingKey("order.dead")     // 死信的路由键
        .ttl(60000)                              // 消息过期时间
        .maxLength(10000)                        // 最大长度
        .build();
}

// 死信队列
@Bean
public Queue deadQueue() {
    return QueueBuilder.durable("order.dlq").build();
}

@Bean
public Binding deadBinding() {
    return BindingBuilder.bind(deadQueue())
        .to(new DirectExchange("order.dlx"))
        .with("order.dead");
}

死信队列的价值： 把处理失败的消息先存起来，便于重试和排查，不会阻塞主流程。

四、消息可靠投递总结

生产者 → Exchange → Queue → Consumer
   │          │        │        │
   └─confirm  └─return │        └─ack（手动确认）
                       │
                 队列持久化 + 消息持久化
                 durable=true, deliveryMode=PERSISTENT

最可靠的模式：

Publisher Confirm（确认消息到了交换器）
Mandatory + ReturnCallback（确保路由到队列）
队列和消息持久化（重启不丢失）
手动 ACK（不丢失消息）
死信队列兜底（处理不了的消息不会丢）

五、Spring Boot 集成

5.1 配置

spring:
  rabbitmq:
    host: localhost
    port: 5672
    virtual-host: /
    publisher-confirm-type: correlated
    publisher-returns: true
    listener:
      simple:
        acknowledge-mode: manual
        prefetch: 1  # 每次只消费一条，处理完再拿下一条
        retry:
          enabled: true
          max-attempts: 3
          initial-interval: 2000

5.2 完整生产消费示例

// 配置类
@Configuration
public class RabbitConfig {
    @Bean
    public DirectExchange orderExchange() {
        return new DirectExchange("order.exchange", true, false);
    }
    
    @Bean
    public Queue orderQueue() {
        return QueueBuilder.durable("order.queue")
            .deadLetterExchange("order.dlx")
            .build();
    }
    
    @Bean
    public Binding binding() {
        return BindingBuilder.bind(orderQueue())
            .to(orderExchange()).with("order");
    }
}

// 生产者
@Service
public class OrderProducer {
    @Autowired
    private RabbitTemplate rabbitTemplate;
    
    public void send(Order order) {
        CorrelationData cd = new CorrelationData(UUID.randomUUID().toString());
        rabbitTemplate.convertAndSend("order.exchange", "order", order, cd);
    }
}

// 消费者
@Component
public class OrderConsumer {
    @RabbitListener(queues = "order.queue")
    public void handle(Order order, Message msg, Channel channel) throws IOException {
        try {
            process(order);
            channel.basicAck(msg.getMessageProperties().getDeliveryTag(), false);
        } catch (Exception e) {
            channel.basicNack(msg.getMessageProperties().getDeliveryTag(), false, false);
        }
    }
}

六、常见问题

6.1 消息堆积

原因	解法
消费者处理太慢	增加消费者数量(`concurrency`)，或优化处理逻辑
消息突增	临时增加消费者，或队列设置最大长度防 OOM
消费者挂了	报警 + 自动恢复 + 死信队列兜底

RabbitMQ 本身存消息是磁盘，堆积太多会大量占用磁盘，严重影响性能。

6.2 延迟队列

RabbitMQ 没有原生的延迟队列，通过 TTL + 死信队列 实现：

消息设置 TTL=10秒 → 进入 延时队列 → TTL 过期 → 死信队列 → 消费者

或者用 rabbitmq-delayed-message-exchange 插件：

rabbitTemplate.convertAndSend("delayed.exchange", "routingKey", message,
    msg -> {
        msg.getMessageProperties().setDelay(10000); // 延迟10秒
        return msg;
    });

面试重点速记

题目	要点
RabbitMQ 四种交换机？	Direct / Fanout / Topic / Headers
怎么保证消息不丢？	Publisher Confirm + 持久化 + 手动 ACK + DLQ
消息重复处理？	消费端幂等（唯一约束 / Redis 判重）
死信队列作用？	存处理失败/过期的消息，便于排查和重试
消息堆积怎么处理？	增加消费者、优化消费逻辑、增加队列容量
延迟队列怎么实现？	TTL + DLQ 方案 / delayed-message 插件

Redis 核心知识与实战

Sun, 19 Jul 2026 00:00:00 +0000

前言

Redis 是面试中出场率最高的中间件之一。它定位为 内存数据库，核心场景是缓存、分布式锁、计数器、消息队列等。

核心特点：纯内存 + 单线程模型（6.x之前） + IO多路复用 = 10万+ QPS。

一、五大数据结构

1.1 概览

类型	示例	底层编码	使用场景
String	`set key "value"`	int / embstr / raw	缓存、计数器、分布式锁
Hash	`hset user:1 name "alice"`	ziplist / hashtable	对象存储
List	`lpush list a b c`	quicklist	消息队列、最新消息列表
Set	`sadd set a b c`	intset / hashtable	去重、共同好友
ZSet	`zadd rank 100 "a"`	ziplist / skiplist	排行榜、延迟队列

1.2 String 的内部编码

// Redis 源码 object.c
if (len <= 20 && canEncodeAsInteger(value)) {
    // 用 int 编码（8字节）
} else if (len <= 44) {
    // 用 embstr 编码（一次分配内存，连续存储）
} else {
    // 用 raw 编码（两次分配）
}

面试题：String 最大能存多少？ 512 MB。

1.3 ZSet 底层 — 跳表（SkipList）

ZSet 用 跳表 + 哈希表 实现：

哈希表：存 member → score 映射（O(1) 查分）
跳表：存 score 排序（O(log N) 范围查询）

跳表结构：
Level 3: 1 ──────────────────────────→ 15
Level 2: 1 ───────→ 7 ──────────────→ 15
Level 1: 1 ─→ 3 ─→ 7 ─→ 9 ─→ 12 ─→ 15
Level 0: 1→2→3→4→7→8→9→10→12→14→15

每层是下层的一个子集，搜索时从最高层开始，空间换时间。

为什么用跳表而不是红黑树？ 跳表实现简单、区间遍历方便（链表结构天然支持）、不需要 rebalance。

二、持久化

2.1 RDB（快照）

# redis.conf
save 900 1      # 900秒内至少1个key修改 → 触发bgsave
save 300 10     # 300秒内至少10个key修改
save 60 10000   # 60秒内至少10000个key修改

# 手动执行
> BGSAVE  # 后台 fork 子进程生成 dump.rdb

流程：

主进程 fork() → 子进程写临时RDB文件 → 替换旧RDB文件
           ↓
子进程通过写时复制（Copy-on-Write）共享内存页

优点：文件小，恢复快。缺点：可能丢数据（两次快照之间的数据）。

2.2 AOF（追加日志）

日志格式：

*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n

三种刷盘策略：

appendfsync always    # 每次写操作都fsync → 最安全最慢
appendfsync everysec  # 每秒fsync → 默认，最多丢1秒数据
appendfsync no        # 交给OS刷盘 → 可能丢30秒+数据

AOF 重写（AOF Rewrite）：

BGREWRITEAOF
  → 子进程遍历内存数据，生成新的AOF文件
  → 将多个历史操作合并为当前数据的最小命令集合

2.3 混合持久化（Redis 4.0+，推荐）

aof-use-rdb-preamble yes

AOF 文件开头是 RDB 格式（快速恢复），后面是 AOF 增量日志（减少丢失）。

三、高可用

3.1 主从复制

主节点  ←——— 从节点1
              ←——— 从节点2

同步流程：

从节点发送 PSYNC 命令
主节点执行 BGSAVE 生成 RDB 发给从节点
同时将新写操作缓存在缓冲区（replication buffer）
从节点加载 RDB → 主节点发送缓冲区增量数据

3.2 哨兵（Sentinel）

监控 + 自动故障转移：

Sentinel集群(3个节点，奇数)
    │ 监控
    ▼
主节点 ── 从节点1, 从节点2

主观下线 → 客观下线（多个Sentinel确认） → 选举新主节点

3.3 集群（Cluster）

数据分片（16384 个槽）：

CRC16(key) % 16384 → 确定由哪个节点处理

节点1: 0~5460
节点2: 5461~10922
节点3: 10923~16383

客户端直连任意节点，如果 key 不在该节点上，返回 MOVED 重定向。

四、缓存设计与常见问题

4.1 过期策略

惰性删除：访问 key 时检查是否过期，过期则删除
         + 
定期删除：每 100ms 随机抽查一批带有过期时间的 key，删除过期的

如果过期 key 太多没删完，内存满了怎么办？→ 内存淘汰策略

4.2 内存淘汰策略

maxmemory-policy volatile-lru  # 默认

策略	说明
noeviction	内存满直接报错（默认，但很多系统改为别的）
allkeys-lru	淘汰最近最少使用的 key
volatile-lru	在设置了过期时间的 key 中 LRU
allkeys-lfu	淘汰使用频率最低的 key（4.0+）
volatile-ttl	淘汰即将过期的 key

LRU 近似算法：Redis 不维护精确的访问时间，而是采样 5 个 key（可配置）淘汰最旧的。

4.3 缓存三大问题

缓存穿透：查一个不存在的数据（缓存和 DB 都没有）

解法：布隆过滤器（Bloom Filter）"一定不存在的 key 直接拒绝"
      或缓存空值（短期），但注意不要被恶意 key 打满

缓存击穿：热点 key 失效，大量请求打到 DB

解法：互斥锁（SETNX），只让一个线程去查 DB，其它等待
      或者设置热点 key "永不过期" + 后台线程主动刷新

缓存雪崩：大量 key 同时过期 / Redis 宕机

解法：过期时间加随机值（基础时间 ± 随机值）
      构建高可用（主从+哨兵/集群）
      本地缓存做二级缓存

4.4 缓存一致性（最棘手的题）

// 常见的"先更新DB，再删缓存"模式（Cache-Aside）
public void updateUser(User user) {
    db.update(user);           // 1. 先更新数据库
    cache.del(user.getId());   // 2. 再删除缓存（不是更新缓存）
}
// 为什么要删而不是更新？避免并发写导致缓存里写旧值

不一致的情况：

线程A: 更新DB → ❌系统挂了，没删缓存
线程B: 读缓存（旧数据）

保证最终一致：

延时双删：先删缓存→更新 DB→延时再删缓存
订阅 binlog（Canal）+ 删除或者更新缓存
高一致性场景：用分布式锁或直接读 DB

面试中不要只说一种方案，要说明一致性要求越高，性能越低，根据业务选择。

五、分布式锁

// 用 Redisson 实现（推荐，自带了看门狗 Watchdog）
RLock lock = redissonClient.getLock("myLock");
lock.lock(10, TimeUnit.SECONDS);
try {
    // 业务逻辑
} finally {
    lock.unlock();
}

Redis 分布式锁要点：

SET NX EX（加锁+过期，原子操作）
删除锁时用 Lua 脚本校验 value（防止删别人的锁）
Redisson Watchdog 自动续期（避免业务没执行完锁过期）
RedLock 算法（多节点+大多数同意才算拿到）— 仅在极端安全场景需要

面试重点速记

题目	要点
Redis 为什么快？	纯内存 + 单线程（避免上下文切换） + IO多路复用
String 底层？	int/embstr/raw，小于44字节用 embstr
ZSet 底层？	跳表 + 哈希表，O(logN)
持久化怎么选？	RDB恢复快但丢数据，AOF安全但文件大，混合最好
过期策略？	惰性删除 + 定期删除
淘汰策略？	allkeys-lru 最常用
缓存穿透/击穿/雪崩？	布隆过滤器 / 互斥锁 / 随机过期时间
分布式锁怎么实现？	SET NX EX + Lua 校验 + Redisson Watchdog

Spring Boot 核心原理与最佳实践

Sun, 19 Jul 2026 00:00:00 +0000

前言

Spring Boot 之所以"火"，在于它把 Spring 繁琐的配置变成了约定大于配置。你用 3 行代码就能跑起一个 Web 服务，背后是一整套自动配置体系在支撑。

面试重点：自动配置原理、启动流程、常用 Starter。

一、最简示例

@SpringBootApplication  // 这是一个组合注解
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello Spring Boot!";
    }
}

一分钟启动，搞定一个 HTTP 接口。

二、@SpringBootApplication 源码级拆解

2.1 组合注解

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration      // 等同于 @Configuration（声明配置类）
@EnableAutoConfiguration      // 开启自动配置（核心）
@ComponentScan(excludeFilters = { ... })  // 扫描当前包及子包
public @interface SpringBootApplication { ... }

三个核心注解：

注解	作用
`@SpringBootConfiguration`	标记此为主配置类，本质是 @Configuration
`@EnableAutoConfiguration`	开启自动配置机制（核心）
`@ComponentScan`	默认扫描启动类所在包及其子包的 @Component

三、自动配置原理（核心重点）

3.1 它是怎么知道要配什么的？

@EnableAutoConfiguration 源码：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(AutoConfigurationImportSelector.class)  // 关键！
public @interface EnableAutoConfiguration { ... }

AutoConfigurationImportSelector 会做一件事：

读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件
  ↓
里面列出了所有自动配置类（Spring Boot 内部提供的）
  ↓
Filter 过滤掉不需要的（通过 @Conditional 条件判断）
  ↓
注册符合条件的配置类 → 生成对应的 Bean

看 spring-boot-autoconfigure 包里的该文件内容节选：

org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
...

3.2 @Conditional — 条件装配

@Configuration
// 只有引入 H2 数据库的依赖时才生效
@ConditionalOnClass(H2Database.class)
// 只有没有自定义 DataSource 时才生效
@ConditionalOnMissingBean(DataSource.class)
public class DataSourceAutoConfiguration {
    
    @Bean
    @ConditionalOnMissingBean
    public DataSource dataSource() {
        // 自动配置一个默认的 DataSource
        return new HikariDataSource();
    }
}

常用条件注解：

注解	生效条件
@ConditionalOnClass	类路径存在指定类
@ConditionalOnMissingClass	类路径不存在指定类
@ConditionalOnBean	容器中存在指定 Bean
@ConditionalOnMissingBean	容器中不存在指定 Bean
@ConditionalOnProperty	配置文件中存在指定属性
@ConditionalOnExpression	SpEL 表达式为 true

3.3 自动配置示例：Redis

<!-- 只要引入依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

# 配一下连接信息
spring:
  redis:
    host: localhost
    port: 6379

然后就自动有了 RedisTemplate、StringRedisTemplate 可以直接注入使用。

背后的自动配置类：

@Configuration
@ConditionalOnClass(RedisOperations.class)  // 引入依赖后才有这个类
@EnableConfigurationProperties(RedisProperties.class)  // 绑定配置项
public class RedisAutoConfiguration {
    
    @Bean
    @ConditionalOnMissingBean(name = "redisTemplate")
    public RedisTemplate<Object, Object> redisTemplate(
            RedisConnectionFactory connectionFactory) {
        // 创建默认模板
        RedisTemplate<Object, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        return template;
    }
}

为什么我自定义了 RedisTemplate 就不生效了？ 因为 @ConditionalOnMissingBean — 你已经有一个了，自动配置就不覆盖你。

四、Spring Boot 启动流程

SpringApplication.run()
  │
  ├─ 1. 推断应用类型（REACTIVE / SERVLET / NONE）
  │
  ├─ 2. 加载所有 SpringApplicationRunListener
  │     （监听启动事件，支持扩展）
  │
  ├─ 3. 获取并准备 Environment（环境变量 + 配置文件）
  │     → application.yml 会被加载到这里
  │
  ├─ 4. 创建 ApplicationContext
  │     → 如果是 Web 应用 → AnnotationConfigServletWebServerApplicationContext
  │     → 非 Web → AnnotationConfigApplicationContext
  │
  ├─ 5. 准备工作：注册启动类、设置 Environment
  │
  ├─ 6. refreshContext() → 这才是真正的 Spring 容器启动！
  │     ├─ BeanFactory 初始化
  │     ├─ 执行 BeanFactoryPostProcessor（扫描 + 解析配置）
  │     ├─ 注册 BeanPostProcessor
  │     ├─ 初始化 MessageSource
  │     ├─ 初始化事件广播器
  │     ├─ 注册监听器
  │     ├─ 实例化所有非懒加载单例 Bean（含自动配置）
  │     └─ 启动内嵌 Web 服务器（Tomcat）
  │
  └─ 7. 发布 ApplicationReadyEvent → 启动完成

核心步骤就是第6步 refresh()，这是 Spring Framework 的容器启动方法，Spring Boot 在它前、后加了自动配置和 Web 服务器启动。

五、内嵌 Web 容器

Spring Boot 默认内嵌 Tomcat（也可以换成 Jetty 或 Undertow）。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <!-- 排除默认的 Tomcat -->
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<!-- 换成 Undertow（性能比 Tomcat 高） -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

内嵌容器怎么工作的？

// EmbeddedWebServerFactoryCustomizerAutoConfiguration 中
// 根据 classpath 是否存在 Tomcat/Jetty/Undertow 来决定创建哪种
@ConditionalOnClass(Tomcat.class)
public static class TomcatWebServerFactoryCustomizerConfiguration {
    @Bean
    public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
        return new TomcatServletWebServerFactory();
    }
}

六、核心 Starter 一览

Starter	作用
spring-boot-starter-web	Web 开发（Tomcat + Spring MVC）
spring-boot-starter-data-jpa	JPA + Hibernate
spring-boot-starter-data-redis	Redis
spring-boot-starter-amqp	RabbitMQ
spring-boot-starter-validation	参数校验（Hibernate Validator）
spring-boot-starter-test	测试（JUnit + Mockito + AssertJ）
spring-boot-starter-actuator	监控（健康检查、指标、审计）

yml 配置详解（按优先级排序）

1. 命令行参数：--server.port=8081
2. JNDI 属性
3. application-{profile}.yml（如 application-dev.yml）
4. application.yml
5. @PropertySource（如果有）

server:
  port: 8080                    # 端口
  servlet:
    context-path: /api          # 上下文路径

spring:
  profiles:
    active: dev                 # 激活环境
  datasource:
    url: jdbc:mysql://localhost:3306/db
    username: root
    password: 123456
  jpa:
    hibernate:
      ddl-auto: update          # 自动建表
    show-sql: true

七、异常处理与最佳实践

7.1 统一异常处理

@RestControllerAdvice
public class GlobalExceptionHandler {
    
    @ExceptionHandler(BusinessException.class)
    public Result<Void> handleBusiness(BusinessException e) {
        return Result.error(e.getCode(), e.getMessage());
    }
    
    @ExceptionHandler(Exception.class)
    public Result<Void> handleUnknown(Exception e) {
        log.error("未知异常", e);
        return Result.error(500, "服务器内部错误");
    }
}

7.2 分层架构

controller/       ← 接收请求、返回响应（很薄的一层）
service/          ← 业务逻辑
repository/dao/   ← 数据访问
dto/              ← 数据传输对象
entity/           ← 数据库实体
config/           ← 配置类

阿里巴巴开发手册的规范：

Controller 层只做参数校验和结果封装
Service 层做业务逻辑
避免在 Controller 里直接调用另一个 Service

7.3 配置管理

# application-dev.yml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/dev_db

# application-prod.yml
spring:
  datasource:
    url: jdbc:mysql://prod-host:3306/prod_db

# 启动时指定环境
java -jar app.jar --spring.profiles.active=prod

面试重点速记

题目	要点
自动配置原理？	@EnableAutoConfiguration → 加载 META-INF 文件 → @Conditional 按条件生效
启动流程？	推断应用类型→准备环境→创建容器→refresh()->启动内嵌 Tomcat→发布事件
内嵌 Web 容器？	默认 Tomcat，可换成 Jetty/Undertow
Condition 注解体系？	@ConditionalOnClass / OnMissingBean / OnProperty 等
application.yml 加载顺序？	命令行参数 > profile 配置 > 默认配置 > @PropertySource
Spring Boot 工程结构？	controller / service / repository / dto / entity / config

Spring 核心：IoC 与 AOP 源码级解析

Sun, 19 Jul 2026 00:00:00 +0000

前言

Spring 是 Java 后端开发的基石。面试必问的两个核心概念：IoC（控制反转） 和 AOP（面向切面编程）。

学会 Spring 的源码级理解，是面试和实际工作的分水岭。

一、IoC（控制反转）与 DI（依赖注入）

1.1 是什么

不用 IoC 的做法：

public class UserService {
    private UserDao userDao = new UserDao(); // 自己 new，硬编码
}

用了 Spring 的做法：

@Service
public class UserService {
    @Autowired
    private UserDao userDao; // 由 Spring 注入，对象什么时候创建、什么时候销毁不归我管
}

控制反转：对象创建和管理的控制权从程序员转交给 Spring 容器。 依赖注入：容器帮我们创建对象并注入到需要的地方（字段/构造器/Setter）。

1.2 Spring IoC 容器

容器管理所有 Bean 的生命周期：

启动 → 扫描 → 解析配置(注解/XML) → 定义BeanDefinition
    → 实例化Bean → 填充属性(依赖注入) → BeanPostProcessor前置处理
    → 初始化(InitializingBean/@PostConstruct) → BeanPostProcessor后置处理
    → 就绪(可使用) → 销毁(DisposableBean/@PreDestroy)

1.3 BeanFactory vs ApplicationContext

// BeanFactory — 最底层容器（延迟加载）
BeanFactory factory = new XmlBeanFactory(new ClassPathResource("beans.xml"));
UserService userService = factory.getBean(UserService.class);

// ApplicationContext — 更常用（预加载+额外功能）
ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = ctx.getBean(UserService.class);

	BeanFactory	ApplicationContext
Bean 加载	延迟（getBean时创建）	默认预加载（scope=singleton）
事件机制	❌	✅ 事件发布+监听
国际化	❌	✅ MessageSource
AOP 支持	需手动集成	✅ 自动支持
注解支持	❌	✅ @ComponentScan 等

1.4 Bean 的作用域

@Component
@Scope("singleton")     // 默认：一个容器只有一个实例
public class UserService { }

@Scope("prototype")     // 每次 getBean 都是一个新的
@Scope("request")       // 每个 HTTP 请求一个（Web 应用）
@Scope("session")       // 每个 Session 一个（Web 应用）

注意：prototype 作用域的 Bean 在注入到 singleton Bean 时，每次获取的都是同一个。解决方式：

// 方法一：方法注入（@Lookup）
@Component
@Scope("singleton")
public class SingleBean {
    @Lookup
    public PrototypeBean getPrototypeBean() { return null; }  // Spring会代理重写
}

// 方法二：ObjectFactory
@Autowired
private ObjectFactory<PrototypeBean> prototypeBeanFactory;

1.5 循环依赖（重点）

@Service
public class AService {
    @Autowired
    private BService bService;
}

@Service
public class BService {
    @Autowired
    private AService aService;
}

如果没三级缓存，这种就报错了。Spring 怎么解决的？

三级缓存（DefaultSingletonBeanRegistry）：

public class DefaultSingletonBeanRegistry {
    // 一级：完整创建好的单例（成品）
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    
    // 二级：提前暴露的、未完成初始化的 Bean（半成品）
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
    
    // 三级：ObjectFactory，生产二级缓存中的对象
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
}

解决流程（简化）：

1. 创建 A → 实例化 A（调构造器，得到一个"半成品"A）
2. 将 A 放入三级缓存（singletonFactories），存的是 lambda：提前暴露 A 的引用
3. 填充 A 的属性：发现需要 B
4. 去容器找 B → 发现 B 还没创建 → 创建 B
5. 实例化 B（半成品）
6. 填充 B 的属性：发现需要 A
7. 从三级缓存拿到 A（通过工厂生成）→ 放入二级缓存 → B 拿到了 A 的引用（虽然 A 还没初始化完）
8. B 创建完成 → 放入一级缓存
9. 回到 A → 继续初始化 → 把完整 A 放入一级缓存

关键条件：

只解决 singleton + 字段/Setter 注入 的循环依赖
构造器注入 的循环依赖无法解决（实例化时就卡住了）

二、AOP（面向切面编程）

2.1 核心概念

┌─ Aspect（切面）─────────────────────────────────┐
│  ┌─ Pointcut（切点）：WHERE — 哪些方法需要增强    │
│  │   execution(* com.example.service.*.*(..))    │
│  ├─ Advice（通知）：WHAT — 执行什么增强逻辑       │
│  │   @Before / @AfterReturning / @Around 等      │
│  ├─ JoinPoint（连接点）：WHEN — 方法执行时的某个时机 │
│  └─ Weaving（织入）：将切面应用到目标对象的过程    │
└─────────────────────────────────────────────────┘

2.2 使用示例

@Aspect
@Component
public class LogAspect {
    
    @Around("execution(* com.example.service.*.*(..))")
    public Object logAround(ProceedingJoinPoint pjp) throws Throwable {
        // 前置
        long start = System.currentTimeMillis();
        log.info("调用: {}", pjp.getSignature());
        
        Object result = pjp.proceed(); // 执行目标方法
        
        // 后置
        long cost = System.currentTimeMillis() - start;
        log.info("耗时: {}ms", cost);
        return result;
    }
}

2.3 AOP 源码级理解 — 代理机制

AOP 底层是代理模式。Spring 会根据目标类是否实现接口，选择不同的代理方式：

目标类实现接口 → JDK 动态代理（反射+InvocationHandler）
目标类没有接口 → CGLIB 代理（字节码增强，生成子类）

JDK 动态代理原理：

// 简化版源码逻辑
public class JdkDynamicAopProxy implements InvocationHandler {
    private Object target; // 目标对象
    
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // 1. 执行 @Before 通知
        for (MethodInterceptor interceptor : advisors) {
            interceptor.invoke(/* ... */);
        }
        
        // 2. 执行目标方法
        Object result = method.invoke(target, args);
        
        // 3. 执行 @AfterReturning 通知
        return result;
    }
}

CGLIB 原理：

目标类 → CGLIB Enhancer → 生成目标类的子类
                           → 子类重写父类方法
                           → 重写的方法中加入拦截器链

注意：CGLIB 通过继承实现，不能代理 final 类和方法。

2.4 Spring AOP 限制

Spring AOP 是基于代理的 AOP，==> 只能拦截 public 方法。同一个类内部调用被拦截方法也不会生效：

@Service
public class UserService {
    public void methodA() {
        this.methodB(); // 这个调用不会走 AOP 拦截！
        // 因为 this 是原始对象，不是代理对象
    }
    
    @Transactional
    public void methodB() { }
}

解法：

// 方法一：注入自己（代理对象）
@Autowired
private UserService userService;

// 方法二：AopContext.currentProxy()
((UserService) AopContext.currentProxy()).methodB();
// 需要 @EnableAspectJAutoProxy(exposeProxy = true)

// 方法三：拆到不同 Service 中

AspectJ（编译期织入）没有这个限制，因为它直接修改了字节码。

三、事务管理

3.1 @Transactional 原理

@Transactional 本质是 AOP 的应用：

@Around("@annotation(transactional)")
public Object handleTransaction(ProceedingJoinPoint pjp) throws Throwable {
    // 1. 获取或创建事务
    TransactionStatus status = transactionManager.getTransaction(definition);
    try {
        Object result = pjp.proceed();  // 执行目标方法
        transactionManager.commit(status);  // 2. 提交
        return result;
    } catch (Exception e) {
        transactionManager.rollback(status);  // 3. 回滚
        throw e;
    }
}

3.2 事务传播行为

@Transactional(propagation = Propagation.REQUIRED)  // 默认：有就用，没有就新建
@Transactional(propagation = Propagation.REQUIRES_NEW) // 每次新建事务
@Transactional(propagation = Propagation.NESTED)    // 内嵌事务（Savepoint）
@Transactional(propagation = Propagation.MANDATORY) // 必须有事务，没有就抛异常

经典场景：

// REQUIRED — 日志和业务在同个事务，日志回滚业务也回滚
// REQUIRES_NEW — 日志单独事务，不管业务是否回滚，日志都记录

3.3 事务失效的常见原因

1. @Transactional 加到 private 方法上（代理只能拦截 public）
2. 方法内部调用（this.xxx()，同上）
3. 异常被 catch 了没抛出去
4. 抛的异常不是 RuntimeException（默认只回滚 RuntimeException 和 Error）
   → @Transactional(rollbackFor = Exception.class)
5. 数据源没配置事务管理器

面试重点速记

题目	要点
IoC 是什么？	对象创建控制权交给容器，DI 是 IoC 的实现方式
Bean 生命周期？	实例化→填充属性→BeanPostProcessor→初始化→就绪→销毁
三级缓存解决什么？	singleton + field/setter 注入的循环依赖
AOP 底层原理？	JDK 动态代理（有接口） / CGLIB（无接口）
AOP 哪些方法不拦截？	private、内部 this 调用、final 方法
事务失效原因？	private、内部调用、catch 未抛、异常类型不对

Hugo 博客部署到 Cloudflare Workers 踩坑记

Sat, 18 Jul 2026 00:00:00 +0000

前言

这个博客使用 Hugo + Stack 主题构建，部署到 Cloudflare 的 Workers + Pages 统一平台。部署过程遇到几个坑，记录一下。

问题一：部署后只看到 “Hello World”

用 wrangler deploy 部署后，访问分配的 .workers.dev 域名，页面只有一行 “Hello World”，而不是 Hugo 生成的博客页面。

原因： Cloudflare 统一了 Workers 和 Pages 平台，默认部署方式创建的是一个 Worker，不会自动托管静态资源。Hugo 生成的 public/ 目录需要作为静态资产提供。

解决： 创建 wrangler.toml 配置静态资产目录：

name = "qifuhe"
compatibility_date = "2026-07-18"

[assets]
    directory = "public"
    not_found_handling = "404-page"

然后用 --assets 标志部署：

wrangler deploy --assets public/ --name qifuhe

问题二：wrangler.toml 的 [build] command 在 Windows 上失败

最开始在 wrangler.toml 里加了构建命令：

[build]
command = "curl -sL https://github.com/gohugoio/hugo/releases/download/v0.164.0/hugo_extended_0.164.0_linux-amd64.tar.gz -o hugo.tar.gz && tar xzf hugo.tar.gz && rm hugo.tar.gz && ./hugo --gc --minify"

这在 Linux/Mac 上没问题，但 Windows 跑不了 Linux 二进制。更坑的是，Wrangler 一定会执行 [build] 里的命令，即使加了 --assets 参数也无法跳过。

解决： 删掉 [build] 段，在本地手动构建：

/tmp/hugo.exe --gc --minify
wrangler deploy --assets public/ --name qifuhe

问题三：Cloudflare 统一平台后的域名认知

2025 年底 Cloudflare 统一了 Workers 和 Pages，合并为一个平台。之前 Pages 用 .pages.dev，Workers 用 .workers.dev。统一后仍然使用 .workers.dev 域名，文档里有些旧教程提到的 .pages.dev 已不存在。

完整的部署流程

在本地开发：

# 本地预览（含草稿文章）
/tmp/hugo.exe server -D

# 写完后构建并部署
/tmp/hugo.exe --gc --minify
wrangler deploy --assets public/ --name qifuhe

小结

Hugp 构建必须在本地完成，Wrangler 的 [build] 命令在 Windows 上不适配
wrangler.toml 只需要 [assets] 配置，不用加 [build]
.workers.dev 是正确的域名

你好，世界

Wed, 01 Jan 2025 00:00:00 +0000

欢迎来到我的博客！

这是第一篇文章，之后会陆续发布更多内容。