并发编程面试实战：synchronized、volatile、Lock、AQS 应答技巧

2501_90914799

572人浏览 · 2026-03-22 13:02:41

2501_90914799 · 2026-03-22 13:02:41 发布

在 Java 并发编程面试中，synchronized、volatile、Lock 和 AQS 绝对是“重中之重”—— 它们既是基础同步机制的核心，也是面试官区分候选人“只会用”和“懂原理”的关键标尺。很多候选人面试时栽在这部分，不是因为不会用 API，而是无法讲清底层逻辑、不会结合实际场景分析，甚至被追问两句就语无伦次。

本文将打破“死记硬背”的误区，梳理每个知识点的高频考点、结构化应答思路，补充实战案例和避坑点，帮你快速掌握应答技巧，在面试中从容应对，轻松拉开与其他候选人的差距。

一、synchronized：Java 内置的隐式锁（面试基础必问）

synchronized 是 Java 最基础、最常用的同步机制，无需手动管理锁的释放，属于“隐式锁”。面试中，它的考察频率极高，从基础使用到底层优化，几乎是必问内容，核心考察候选人对 JVM 锁机制的理解。

1.1 高频考点梳理（必记核心）

核心功能（3大特性，缺一不可）

原子性：保证被修饰的代码块，同一时间只有一个线程能执行，杜绝多线程并发修改导致的数据不一致。比如多线程执行 i++，用 synchronized 包裹后，能保证最终结果正确。
可见性：当线程释放锁时，会将工作内存中修改后的数据强制刷新到主内存；当线程获取锁时，会清空工作内存中的数据，重新从主内存读取最新值，避免“脏读”。
有序性：通过锁的排他性，间接禁止指令重排序，保证代码执行顺序与编写顺序一致（注意：synchronized 不禁止指令重排序，只是通过排他性让线程“串行执行”，从而保证有序性）。

实现原理（底层核心，面试加分关键）

synchronized 的实现依赖“对象头”和“监视器锁（Monitor）”，这也是面试官最爱追问的点，结合 JDK 1.6 后的优化，讲清这两点就能体现你的基础扎实度。

对象头：Java 中每个对象都有对象头，其中 Mark Word（标记字段）是核心，用于存储锁的状态（无锁、偏向锁、轻量级锁、重量级锁）。不同锁状态下，Mark Word 的存储内容不同，比如无锁状态存储对象哈希值，偏向锁状态存储持有锁的线程 ID。
监视器锁（Monitor）：synchronized 的重量级锁依赖底层操作系统的互斥量（Mutex）实现。当线程竞争锁时，会涉及用户态与内核态的切换，这也是重量级锁性能开销大的核心原因。而 JDK 1.6 后的优化，本质就是减少这种切换的频率。

锁升级过程（核心难点，必须讲清逻辑）

JDK 1.6 之前，synchronized 只有“重量级锁”，性能较差；JDK 1.6 引入了锁升级机制，根据竞争强度动态切换锁状态，实现“按需分配”开销，这也是面试中高频追问的点。锁升级顺序：无锁 → 偏向锁 → 轻量级锁 → 重量级锁，不可逆。

无锁：对象刚创建时，Mark Word 处于无锁状态，此时没有线程竞争，无需加锁，性能最优。
偏向锁：当第一个线程获取锁时，Mark Word 会记录该线程的 ID，后续该线程再次获取锁时，无需做 CAS 操作，直接获取锁——核心目的是减少“无竞争场景”的锁开销（比如单线程频繁执行同步代码块）。
轻量级锁：当有其他线程尝试竞争锁时，偏向锁会被撤销，此时线程会通过 CAS 操作，将锁记录（Lock Record）放入自己的栈帧中，自旋尝试获取锁。自旋的本质是“忙等”，避免线程直接阻塞（适合低竞争场景，自旋次数默认 10 次）。
重量级锁：当多个线程竞争激烈，自旋失败后，锁会升级为重量级锁。此时线程会放弃自旋，进入 Monitor 的等待队列（阻塞状态），由操作系统负责调度，避免 CPU 空转，但会产生用户态与内核态的切换开销。

使用场景对比（基础考点，避免混淆）

synchronized 有三种使用方式，不同方式的锁对象不同，面试中常考“锁对象是谁”，避免混淆：

修饰实例方法：锁对象为当前类的实例（this），多个实例之间的锁相互独立。
修饰静态方法：锁对象为当前类的 Class 对象，所有实例共享同一把锁。
修饰代码块：锁对象为 synchronized(lockObj) 中的 lockObj，可灵活指定锁对象（推荐使用，能缩小锁范围，提升性能）。

1.2 应答思路与技巧（面试实战重点）

面试中，关于 synchronized 的问题，核心是“结构化答题”，不要东拉西扯，按“框架+细节+场景”的思路回答，既清晰又全面。

问题 1：synchronized 和 Lock 的区别？（高频对比题，必背）

答题框架：底层实现 → 灵活性 → 功能 → 场景总结，最后补充性能差异（加分点）。

底层实现：synchronized 是 JVM 内置锁，依赖对象头和 Monitor 实现，属于“隐式锁”；Lock 是 Java 并发包提供的接口（如 ReentrantLock），基于 AQS 框架实现，属于“显式锁”。
灵活性：synchronized 自动加锁、自动释放锁（异常时也会释放），无需手动操作；Lock 必须手动调用 lock() 加锁，unlock() 释放锁（必须放在 finally 中，避免死锁），支持中断获取、超时获取等灵活操作。
功能：Lock 支持公平锁/非公平锁、条件变量（Condition）、可重入性；synchronized 仅支持非公平锁和可重入性，不支持条件变量。
场景总结：简单同步场景（如单线程写、多线程读，或简单的原子操作）用 synchronized，代码简洁、不易出错；复杂场景（如超时控制、多条件等待、需要中断锁获取）用 Lock，灵活性更高。
加分点：JDK 1.6 后，synchronized 经过锁升级、自旋锁等优化，性能与 Lock 接近；但高竞争场景下，Lock（如 ReentrantLock）性能更优，因为它能减少线程切换开销。

问题 2：synchronized 的锁升级过程？为什么要设计锁升级？（核心难点题）

答题框架：按锁升级顺序讲解 → 每个阶段的触发条件 → 设计锁升级的原因，避免只罗列阶段，不讲逻辑。

锁升级顺序：无锁 → 偏向锁 → 轻量级锁 → 重量级锁（不可逆），具体阶段如 1.1 所述。
设计原因：核心是“优化性能，适配不同竞争场景”。不同场景下，锁的开销不同：无竞争时用偏向锁（几乎无开销），低竞争时用轻量级锁（自旋减少阻塞），高竞争时用重量级锁（避免 CPU 空转）。如果直接使用重量级锁，即使无竞争场景也会有内核态切换开销；如果只使用轻量级锁，高竞争场景下自旋会浪费 CPU 资源——锁升级实现了“按需分配”，最大化提升并发性能。

二、volatile：轻量级的可见性保证（易混淆，避坑重点）

volatile 是 Java 提供的轻量级同步机制，很多候选人会混淆它与 synchronized 的功能，面试中常考“volatile 能否保证线程安全”“volatile 的底层原理”，核心考察对“可见性、有序性、原子性”的理解。

2.1 高频考点梳理（必记核心，避免踩坑）

核心功能（明确边界，重中之重）

可见性：一个线程修改 volatile 修饰的变量后，会立即将修改后的值刷新到主内存；其他线程读取该变量时，会直接从主内存读取最新值，避免“工作内存与主内存数据不一致”导致的脏读。
有序性：禁止指令重排序。JVM 在编译或 CPU 执行时，会对无依赖的指令进行重排序以提升性能，但 volatile 会通过插入内存屏障，禁止特定指令的重排序，保证代码执行顺序与预期一致。
不保证原子性：这是最容易踩坑的点！volatile 无法保证复合操作（如 i++、i += 1）的原子性，因为复合操作包含“读-改-写”三步，多线程下会出现数据不一致。

底层实现（面试加分，讲清核心）

volatile 的功能依赖“内存屏障”和“CPU 缓存一致性协议（MESI）”，这也是面试官追问的核心。

内存屏障：JVM 会在 volatile 变量的读写前后插入特定的内存屏障，禁止指令重排序，强制刷新数据：
- 写操作后：插入 StoreStore 屏障（保证之前的写操作都已刷新到主内存）和 StoreLoad 屏障（保证当前写操作刷新到主内存后，再执行后续的读操作）。
- 读操作前：插入 LoadLoad 屏障（保证之前的读操作都已完成）和 LoadStore 屏障（保证当前读操作完成后，再执行后续的写操作）。
MESI 协议：CPU 缓存一致性协议，用于保证多 CPU 核心之间的缓存同步。当一个 CPU 核心修改了缓存中的 volatile 变量，会通知其他核心的缓存该变量失效，其他核心读取时会重新从主内存获取最新值，从而保证可见性。

典型使用场景（结合实战，避免滥用）

volatile 适合“单线程写、多线程读”的场景，不适合多线程写的场景，常见使用场景有两个：

状态标记：用于标记线程的运行状态，如 volatile boolean isRunning = true; 线程 A 修改 isRunning 为 false，线程 B 能立即感知到，从而停止运行。
双重检查锁（DCL）中的单例对象：这是面试中高频场景，必须讲清为什么要用 volatile 修饰单例对象（下文会详细讲解）。

2.2 应答思路与技巧（避坑+实战）

问题 1：volatile 能保证线程安全吗？为什么？（高频避坑题）

答题框架：明确回答“不能” → 解释原因（原子性缺失） → 举例验证 → 总结适用场景，逻辑清晰，避免含糊。

核心结论：不能保证线程安全。
原因：volatile 仅保证可见性和有序性，但不保证复合操作的原子性。复合操作（如 i++）包含“读-改-写”三步，这三步不是原子操作，多线程下会出现“多个线程同时读、分别改、覆盖写”的问题。
示例验证：假设两个线程同时执行 i++，初始 i=0：
- 线程 1 读取 i=0（主内存值），存入自己的工作内存；
- 线程 2 同时读取 i=0，存入自己的工作内存；
- 线程 1 将 i 改为 1，写入主内存；
- 线程 2 也将 i 改为 1，写入主内存；
- 最终 i=1，而正确结果应为 2，说明 volatile 无法保证原子性。
总结：volatile 适合单线程写、多线程读的场景（如状态标记），不适合多线程写的场景；如果需要保证原子性，需结合 synchronized 或 Lock。

问题 2：DCL 单例模式中为什么要用 volatile 修饰 instance？（高频实战题）

答题框架：展示 DCL 代码 → 分析指令重排序风险 → 说明 volatile 的作用，结合代码讲解，更有说服力。

DCL 单例代码（核心关键行）：

public class Singleton {
    // 为何用 volatile 修饰？
    private static volatile Singleton instance; 
    private Singleton() {} // 私有构造，防止外部实例化
    
    public static Singleton getInstance() {
        if (instance == null) { // 第一次检查（无锁，提升性能）
            synchronized (Singleton.class) { // 加锁，保证原子性
                if (instance == null) { // 第二次检查（避免多次实例化）
                    instance = new Singleton(); // 可能发生指令重排序
                }
            }
        }
        return instance;
    }
}

指令重排序风险：instance = new Singleton() 看似是一句代码，实则可分解为 3 步： JVM 为了提升性能，可能会对这 3 步进行重排序，比如调整为“1 → 3 → 2”。此时，instance 已经不为 null，但对象还未初始化；如果其他线程此时进入 getInstance() 方法，第一次检查 instance != null，会直接返回未初始化的对象，导致程序报错。
- 分配内存空间；
- 初始化对象（调用构造方法）；
- 将 instance 指向分配的内存地址（此时 instance 不为 null）。
volatile 的作用：禁止上述 2 和 3 步的指令重排序，保证“对象初始化完成后，再将 instance 指向内存地址”，从而避免其他线程获取到未初始化的对象，保证单例的安全性。

三、Lock 接口与 ReentrantLock：灵活的显式锁（进阶考点）

Lock 是 Java 并发包（java.util.concurrent.locks）提供的显式锁接口，其核心实现类是 ReentrantLock（可重入锁）。它比 synchronized 更灵活，功能更丰富，是面试中“进阶考察”的重点，主要考察候选人对并发工具的灵活运用能力。

3.1 高频考点梳理（核心功能+特性）

核心方法（必须掌握，避免使用错误）

Lock 接口的核心方法，重点记住“如何获取锁、如何释放锁”，以及不同获取方式的区别：

lock()：获取锁，如果锁被其他线程持有，则阻塞等待（类似 synchronized 的阻塞机制）。
tryLock()：尝试获取锁，非阻塞；如果获取成功，返回 true；如果锁被持有，返回 false（可用于避免死锁）。
tryLock(long timeout, TimeUnit unit)：超时获取锁；如果在指定时间内获取到锁，返回 true；超时未获取，返回 false。
lockInterruptibly()：可中断地获取锁；如果线程在获取锁时被中断，会抛出 InterruptedException 异常，停止获取锁（灵活处理中断场景）。
unlock()：释放锁，必须放在 finally 中调用（无论是否发生异常，都要释放锁，避免死锁）。
newCondition()：创建条件变量（Condition），用于实现多条件等待（如生产者消费者模式）。

ReentrantLock 的核心特性（面试高频）

可重入性：同一线程可多次获取同一把锁，与 synchronized 一致。比如线程 A 已经获取锁，再次调用 lock() 时，无需等待，直接获取锁（锁的持有计数会递增）。
公平锁/非公平锁：通过构造方法 ReentrantLock(boolean fair) 指定：
- 公平锁：线程按等待顺序获取锁（先到先得，类似排队），避免线程饥饿，但性能略低。
- 非公平锁：线程获取锁时，先尝试 CAS 获取，成功则跳过排队（可能“插队”），性能更高，是默认模式。
条件变量（Condition）：通过 newCondition() 创建多个条件变量，支持多场景等待。比如生产者消费者模式中，可创建“notEmpty”（队列非空，唤醒消费者）和“notFull”（队列非满，唤醒生产者）两个条件变量，实现精准唤醒。

与 synchronized 的性能对比（客观分析，不绝对）

很多候选人会被问“Lock 和 synchronized 哪个性能好”，记住：没有绝对的优劣，取决于场景：

低竞争场景：两者性能接近，synchronized 甚至更优（因为 Lock 有额外的对象创建、方法调用开销）。
高竞争场景：ReentrantLock 性能更优，因为它的阻塞机制更高效，能减少线程切换的开销。

3.2 应答思路与技巧（实战场景为主）

问题 1：ReentrantLock 的公平锁和非公平锁有什么区别？如何选择？（高频对比题）

答题框架：锁分配规则 → 性能差异 → 适用场景，结合底层实现加分。

锁分配规则：
- 公平锁：线程获取锁时，会先检查等待队列，如果有线程在排队，就加入队列尾部，按“先到先得”的顺序获取锁，不允许插队。
- 非公平锁：线程获取锁时，会先尝试 CAS 直接获取锁（插队），如果 CAS 失败，再加入等待队列，按顺序获取锁。
性能差异：公平锁需要维护等待队列的顺序，每次获取锁都要检查队列，开销较大，性能低于非公平锁；非公平锁减少了线程唤醒的开销，吞吐量更高。
选择依据：
- 需要避免线程饥饿（如长任务场景，避免某些线程一直得不到锁）→ 选择公平锁。
- 追求高吞吐量、无线程饥饿风险 → 选择非公平锁（默认模式）。
加分点：公平锁的实现依赖 AQS 的 CLH 等待队列，非公平锁在调用 lock() 方法时，会先尝试 CAS 修改 AQS 的 state 变量获取锁，失败后再入队。

问题 2：如何用 ReentrantLock 实现生产者消费者模式？（实战场景题）

答题框架：核心思路 → 代码示例 → 优势对比，重点讲清 Condition 的使用，体现灵活性。

核心思路：
- 用 ReentrantLock 保证队列操作的原子性（生产、消费操作必须同步）；
- 创建两个 Condition：notEmpty（队列非空，用于唤醒消费者）和 notFull（队列非满，用于唤醒生产者）；
- 生产者：当队列满时，调用 notFull.await() 阻塞等待；生产数据后，调用 notEmpty.signal() 唤醒消费者；
- 消费者：当队列空时，调用 notEmpty.await() 阻塞等待；消费数据后，调用 notFull.signal() 唤醒生产者。
核心代码示例（简化版）：
优势对比：相比 synchronized 的 wait()/notify()，Condition 能实现“精准唤醒”—— 比如只唤醒消费者或只唤醒生产者，避免 notify() 唤醒无关线程导致的无效开销，提升性能。

四、AQS：并发工具的基础框架（核心难点，拉开差距）

AQS（AbstractQueuedSynchronizer，抽象队列同步器）是 Java 并发包的“基石”—— ReentrantLock、CountDownLatch、Semaphore 等常用并发工具，均基于 AQS 实现。面试中，AQS 是区分“初级”和“中级”候选人的关键，核心考察对底层框架的理解和自定义同步器的能力。

4.1 高频考点梳理（核心设计+操作）

核心设计（AQS 的三要素，必须掌握）

AQS 的核心设计围绕“状态管理、等待队列、模板方法”展开，这也是理解 AQS 的关键：

状态变量（state）：用 volatile int state 存储同步状态，是 AQS 的核心。不同的并发工具，state 的含义不同：
- ReentrantLock（独占锁）：state 表示锁的持有计数（state=0 无锁，state>0 表示被持有，数值为持有次数）；
- CountDownLatch（倒计时器）：state 表示剩余计数（state=0 时，所有等待线程被唤醒）；
- Semaphore（信号量）：state 表示可用资源的数量。
CLH 队列：用双向链表实现的等待队列，用于存放获取资源失败的线程。每个线程会被封装为一个 Node 节点，加入队列尾部；当资源释放时，会唤醒队列头部的线程，尝试获取资源。CLH 队列是 AQS 实现“公平锁”的核心。
模板方法：AQS 提供了一系列模板方法（如 acquire()、release()），定义了获取和释放资源的核心流程；子类（如 ReentrantLock）只需重写 tryAcquire()、tryRelease() 等抽象方法，实现具体的资源获取/释放逻辑，无需关心队列管理和线程阻塞/唤醒。

核心操作（获取资源+释放资源）

AQS 的核心操作分为“获取资源”和“释放资源”，流程固定，子类只需实现具体的尝试逻辑：

获取资源（acquire(int arg)）：
- 调用子类重写的 tryAcquire(arg) 方法，尝试获取资源；
- 如果获取成功，直接返回；
- 如果获取失败，将当前线程封装为 Node 节点，加入 CLH 队列；
- 调用 park() 方法，将线程阻塞，等待被唤醒。
释放资源（release(int arg)）：
- 调用子类重写的 tryRelease(arg) 方法，尝试释放资源；
- 如果释放成功，唤醒 CLH 队列头部的线程；
- 被唤醒的线程再次尝试获取资源（循环执行 tryAcquire()）。

基于 AQS 的常用工具类（关联记忆，避免混淆）

记住这些工具类与 AQS 的关联，面试中能快速回答“XXX 是基于什么实现的”：

独占锁：ReentrantLock，基于 AQS 的独占模式实现，重写 tryAcquire()（获取独占锁）、tryRelease()（释放独占锁）。
共享锁：CountDownLatch、Semaphore，基于 AQS 的共享模式实现，重写 tryAcquireShared()（获取共享资源）、tryReleaseShared()（释放共享资源）。
其他：ReentrantReadWriteLock（读写锁），同时支持独占模式（写锁）和共享模式（读锁），底层也是基于 AQS 实现。

4.2 应答思路与技巧（难点突破）

问题 1：AQS 的核心原理是什么？如何基于 AQS 实现一个简单的锁？（核心难点题）

答题框架：先讲 AQS 三要素 → 再讲核心操作流程 → 最后给出自定义锁实现，体现对 AQS 的理解和实战能力。

核心原理：AQS 以“状态变量（state）”为核心，通过“CLH 等待队列”管理阻塞线程，提供“模板方法”定义核心流程，子类通过重写抽象方法实现具体的同步逻辑，实现“分离通用逻辑与具体逻辑”，降低并发工具的实现难度。
自定义锁实现（简单独占锁）：
加分点：说明 Node 节点的状态（如 CANCELLED：线程被取消，SIGNAL：当前节点的后继节点需要被唤醒），以及这些状态在线程唤醒机制中的作用——比如当线程被取消时，会从队列中移除，避免无效唤醒。

问题 2：CountDownLatch 和 CyclicBarrier 的实现原理有何不同？（基于 AQS）（高频对比题）

答题框架：分别讲两者的实现原理（结合 AQS） → 对比核心差异，避免混淆两者的功能和实现。

CountDownLatch（倒计时器）：
- 实现原理：基于 AQS 的共享模式实现。state 表示“剩余计数”，初始化时传入计数次数（如 new CountDownLatch(3)，state=3）；
- 核心操作：countDown() 方法调用 tryReleaseShared()，将 state 减 1；await() 方法调用 tryAcquireShared()，等待 state 变为 0，当 state=0 时，所有等待线程被唤醒；
- 特点：state 递减到 0 后，不可重置，是“一次性”工具（比如主线程等待 3 个子线程执行完毕，执行一次后就失效）。
CyclicBarrier（循环屏障）：
- 实现原理：不直接基于 AQS，内部通过 ReentrantLock（基于 AQS）和 Condition 实现；
- 核心操作：维护一个“已到达线程数”计数器，当到达的线程数达到预设阈值时，通过 Condition.signalAll() 唤醒所有等待线程；
- 特点：支持 reset() 方法，可重置计数器，实现“循环使用”（比如多个线程循环执行任务，每次都需要所有线程到达后再继续）。
核心差异：
- 实现基础：CountDownLatch 基于 AQS 共享模式，CyclicBarrier 基于 ReentrantLock 和 Condition；
- 可复用性：CountDownLatch 一次性，CyclicBarrier 可循环使用；
- 功能侧重：CountDownLatch 侧重“等待多个线程完成”，CyclicBarrier 侧重“多个线程同步到达某一屏障，再一起继续执行”。

五、面试实战经验总结（重中之重，避坑+提分）

很多候选人掌握了知识点，但面试时发挥不好，核心是“不会表达”“不会结合场景”。结合多年面试经验，总结以下 5 个实战技巧，帮你快速提分：

1. 原理与场景结合，拒绝死记硬背

面试中，面试官最反感“死记硬背知识点”，比如解释锁升级时，不要只罗列“无锁→偏向锁→轻量级锁→重量级锁”，而要说明“为什么需要偏向锁”（无竞争场景减少开销）、“轻量级锁为何用自旋”（短时间等待避免阻塞）、“重量级锁适合什么场景”（高竞争场景避免 CPU 空转）。

示例：回答“volatile 的使用场景”时，不要只说“状态标记”，要补充“比如用 volatile boolean isRunning 标记线程是否停止，线程 A 修改 isRunning 为 false，线程 B 能立即感知，从而安全退出”，体现对知识的灵活运用。

2. 对比类问题，按固定逻辑答题

并发面试中，对比类问题极多（如 synchronized vs Lock、CountDownLatch vs CyclicBarrier），按“功能→原理→性能→场景”四步答题，结构清晰，不易遗漏要点，面试官也能快速抓住你的核心思路。

3. 代码示例，简洁聚焦核心

面试中，手写代码是常考环节（如 DCL 单例、生产者消费者模式），重点是“聚焦核心逻辑”，避免冗余。比如手写 DCL 单例，只需写出关键行（volatile 修饰 instance、双重检查、私有构造），无需写多余的注释和异常处理；写 Lock 相关代码，重点体现“lock() 加锁、finally 中 unlock() 释放锁”，避免死锁隐患。