Java on 奇伏禾

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→找大对象/线程/类加载器

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 未抛、异常类型不对