1. 面试题深度解析的价值与定位

最近在帮团队做技术面试，也和一些同行交流，发现一个挺有意思的现象：很多工作了三五年的Java开发者，简历上“精通Java并发”写得明明白白，但一聊到synchronized这个最基础、最核心的锁机制，能讲清楚其底层实现、锁升级过程以及各种应用场景下细微差别的，凤毛麟角。大多数人还停留在“它是一个关键字，用来加锁，保证线程安全”的层面。这其实挺危险的，因为synchronized是理解Java内存模型（JMM）、并发编程思想乃至JVM运行时优化的绝佳入口。一个看似简单的面试题，比如“说说synchronized的底层原理”，背后串联的是对象头、Monitor、锁膨胀、偏向锁、轻量级锁、重量级锁、自旋锁、锁消除、锁粗化等一系列硬核知识点。今天，我就以一个面试官和一线开发者的双重身份，把围绕synchronized可能问到的、最硬核的那些面试题，掰开揉碎了讲给你听。目标不是让你背答案，而是帮你建立起一个从Java代码到JVM实现，再到CPU指令的完整知识图谱，下次面试时能真正“言之有物”。

2. synchronized的基石：Java对象头与Monitor机制

要彻底搞懂synchronized，绝对不能从关键字本身开始，而要从它作用的对象——或者说，任何Java对象——的内存布局说起。这是所有后续问题的根基。

2.1 对象内存布局探秘

一个普通的Java对象在堆内存中，除了我们熟悉的实例数据（instance data）和对齐填充（padding）之外，最容易被忽略但至关重要的部分就是对象头（Object Header）。对于HotSpot虚拟机，对象头主要包含两部分：

1. Mark Word（标记字段）：这是核心中的核心，存储了对象自身的运行时数据。它的长度在32位JVM中是32位，64位JVM中是64位。你可别小看这几十个比特，它是个“变脸大师”，会根据对象的状态（是否被锁定、是否可偏向等）复用这些位来存储不同的信息。
2. Klass Pointer（类型指针）：指向对象所属类的元数据（Class对象）的指针，JVM通过它来确定这个对象是哪个类的实例。

我们重点看Mark Word。在对象未被同步锁定的普通状态下，它存储的是对象的哈希码（identity hash code）、GC分代年龄等信息。但是，一旦这个对象被synchronized盯上，它的Mark Word就立刻“变身”，用来存储指向重量级锁（Monitor）的指针，或者用来存储轻量级锁、偏向锁的线程ID和锁记录指针。

这里有个关键细节：对象的哈希码。如果一个对象已经计算过hashCode()（注意，这里指的是System.identityHashCode(Object)返回的，而非用户重写的hashCode），这个哈希码会存储在Mark Word中。而偏向锁和哈希码是互斥的。因为偏向锁需要占用Mark Word的空间来存储线程ID，如果已经存了哈希码，就没地方存线程ID了，所以这个对象永远无法进入偏向锁状态。这是一个常被忽略但非常重要的考点。

2.2 Monitor：重量级锁的实体

当synchronized升级为重量级锁时，Mark Word里存储的指针，指向的就是一个ObjectMonitor对象，这就是我们常说的管程（Monitor）。你可以把它想象成一个“房间”，这个房间有唯一的入口，并且房间里有一些特殊的设施。

一个ObjectMonitor对象内部有几个关键字段：

• _owner：指向持有该Monitor的线程。如果为NULL，表示锁未被任何线程持有。
• _WaitSet：一个等待队列，所有调用Object.wait()方法而进入等待状态的线程，会被放入这个集合。
• _EntryList：一个阻塞队列，所有尝试获取锁但发现_owner不为空（锁已被占用）的线程，会被放入这个队列，等待锁释放后被唤醒竞争。

synchronized修饰的代码块在编译后，会被翻译成monitorenter和monitorexit（或通过异常表确保执行的monitorexit）这一对字节码指令。当线程执行到monitorenter时，它会尝试进入这个“房间”（Monitor）。如果_owner为空，它就把自己设为_owner，然后执行同步块内的代码。如果_owner不为空，它就得去_EntryList里排队等着。执行完代码后，monitorexit指令会释放锁，将_owner置空，并唤醒_EntryList或_WaitSet中的线程来竞争。

注意：很多人误以为synchronized是“非公平锁”。严格来说，在重量级锁状态下，当锁被释放时，_EntryList中的线程和新来的线程（尚未进入_EntryList）会一起竞争，这个竞争过程是“非公平”的，新来的线程有可能“插队”成功。但JVM内部有一些优化，情况比较复杂，面试时通常说它是“非公平锁”是可以接受的。

3. 锁的升级与优化：从偏向锁到重量级锁

如果每次加锁都直接走重量级锁的流程（涉及操作系统内核态的互斥量操作，需要从用户态切换到内核态，性能开销大），那Java并发性能就太糟糕了。所以JVM设计了一套精妙的锁升级（膨胀）策略，目的是在绝大多数无竞争或低竞争的场景下，用更小的开销来实现同步。

3.1 锁升级的全景图

锁的状态升级是不可逆的（偏向锁可以被撤销回到无锁，但升级过程是单向的），总体路径是：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁。这个升级过程是由竞争激烈程度驱动的。

1. 偏向锁（Biased Locking）

• 设计初衷：研究发现，在很多情况下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获得。偏向锁就是为了消除这个线程重入锁的开销。
• 工作原理：当第一个线程访问同步块时，JVM会使用CAS操作，将线程ID记录到对象头的Mark Word中，并将锁标志位设置为“01”（偏向模式）。之后，这个线程再进入和退出同步块时，不需要进行任何同步操作（如CAS、锁释放），只需检查Mark Word里存储的线程ID是不是自己。如果是，就直接通行，开销极小。
• 撤销（Revoke）：一旦有另一个线程来尝试竞争这个锁，偏向锁模式就要被撤销。撤销过程需要等待全局安全点（此时没有正在执行的字节码），然后暂停持有偏向锁的线程，检查它是否还活着或已退出同步块。如果已退出，则将对象头恢复为无锁状态（或升级为轻量级锁状态），允许新线程竞争；如果仍持有，则升级为轻量级锁。
• 注意事项：偏向锁有延迟激活机制（默认JVM启动后4秒），并且由于撤销开销较大，在明确存在高竞争的场景下（如生产者-消费者队列），可以通过JVM参数-XX:-UseBiasedLocking关闭偏向锁，直接使用轻量级锁。

2. 轻量级锁（Lightweight Locking）

• 适用场景：当偏向锁被撤销，或者一开始就关闭了偏向锁，且存在多个线程交替执行同步块（即竞争是“交替式”的，而非“密集型”的），此时升级为轻量级锁。
• 加锁过程：
  1. 在当前线程的栈帧中，创建一个名为锁记录（Lock Record）的空间。
  2. 将对象头的Mark Word复制到锁记录中（称为Displaced Mark Word）。
  3. 然后，线程尝试使用CAS操作，将对象头的Mark Word替换为指向锁记录的指针，并将锁标志位设置为“00”（轻量级锁状态）。
  4. 如果CAS成功，当前线程获得锁。如果失败，说明至少存在两条线程在竞争同一个锁，会触发自旋锁。
• 自旋锁（Spin Lock）：竞争失败的线程不会立即阻塞（进入重量级锁的_EntryList），而是采用循环的方式（自旋）去尝试再次获取锁。这基于一个假设：锁的持有者很快就会释放锁。自旋避免了线程上下文切换的开销（用户态操作），但会空耗CPU。如果自旋超过一定次数（JDK中自适应自旋，次数由前一次在同一个锁上的自旋时间及锁的持有者状态决定）仍未成功，锁就会膨胀为重量级锁。
• 解锁过程：使用CAS操作，将Displaced Mark Word替换回对象头。如果成功，则解锁完成。如果失败，说明锁已经膨胀为重量级锁，解锁过程会唤醒阻塞的线程。

3. 重量级锁（Heavyweight Locking）

• 如上文Monitor机制所述，当轻量级锁竞争加剧（自旋失败），锁就会膨胀为重量级锁。此时，Mark Word中存储的是指向Monitor对象的指针，锁标志位变为“10”。未获得锁的线程会被阻塞，进入_EntryList队列，等待操作系统调度，涉及用户态到内核态的切换，开销最大。

3.2 锁消除与锁粗化

除了锁升级，JVM还有两项重要的编译期优化：

锁消除（Lock Elimination）：JIT编译器在运行时，通过对“逃逸分析”技术的运用，如果发现一个锁对象不可能被其他线程访问到（即该对象没有“逃逸”出当前线程），那么即使代码中显式地加了synchronized，编译器也会安全地将这个锁操作消除掉。最常见的例子就是在方法内部创建的局部StringBuffer，它的append方法是同步的，但由于该对象不会逃逸，锁会被消除。

锁粗化（Lock Coarsening）：如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁解锁操作出现在循环体内，即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。JVM会探测到这种零碎的锁操作，并将多个连续的锁范围扩大（粗化）为一个更大的锁范围，从而减少锁的获取和释放次数。例如，在循环体内调用一个同步方法，JVM可能会将锁提到循环体外。

4. synchronized的三种应用方式与字节码差异

synchronized有三种使用方式，它们在语义上等价，但在字节码实现和锁的粒度上有所不同。

1. 同步实例方法

public synchronized void instanceMethod() { // 同步代码 }

• 锁对象：当前实例对象（this）。
• 字节码：方法的访问标志（ACC_SYNCHRONIZED）被设置。当线程调用该方法时，会检查此标志。如果设置了，执行线程需要先成功持有管程（即this对象的Monitor），才能执行方法体，方法执行完成后（无论是正常返回还是异常抛出）自动释放管程。monitorenter和monitorexit指令的调用是隐式的。

2. 同步静态方法

public static synchronized void staticMethod() { // 同步代码 }

• 锁对象：当前类的Class对象（如MyClass.class）。这是一个全局唯一的对象。
• 字节码：同样通过ACC_SYNCHRONIZED标志实现，但锁对象是类的Class对象。

3. 同步代码块

public void method() { // 非同步代码... synchronized (lockObject) { // 同步代码 } // 非同步代码... }

• 锁对象：显式指定的任意对象（lockObject）。这是最灵活的方式，可以控制更细粒度的锁。
• 字节码：编译后会在同步代码块前后明确生成monitorenter和monitorexit指令。monitorexit会有两个，一个用于正常退出，一个放在异常表中用于异常退出，确保锁一定被释放。

重要对比与选择：

• 粒度：同步代码块的锁粒度最细，可以锁定任意对象，有助于减少锁竞争，提升并发度。同步方法锁定了整个方法作用的对象（this或Class对象），粒度较粗。
• 性能：在早期版本中，有人认为同步代码块性能稍好，因为同步区域更小。但在现代JVM强大的优化下，这种差异微乎其微。选择哪种方式，首要考虑的是逻辑正确性和锁的粒度，而非这点性能差异。
• 一个经典误区：synchronized(this)和同步实例方法锁的是同一个对象（当前实例），但synchronized(MyClass.class)和同步静态方法锁的也是同一个对象（Class对象）。不要混淆。

5. 高频硬核面试题场景剖析

现在，我们把这些知识应用到具体的面试题场景中，看看如何组织答案。

场景一：synchronized的底层实现原理？

• 初级回答：它是Java关键字，通过monitor实现，编译后会产生monitorenter和monitorexit指令。
• 硬核回答：应从Java对象头（Mark Word）讲起，说明它是锁信息的载体。然后分情况讨论：
  1. 无竞争时：可能启用偏向锁，Mark Word存储线程ID。
  2. 轻度竞争时：升级为轻量级锁，通过线程栈中的锁记录和CAS操作实现。
  3. 重度竞争时：膨胀为重量级锁，Mark Word指向ObjectMonitor，线程在操作系统的Monitor上排队。
  4. 最后要提到JIT编译器的优化，如锁消除和锁粗化。这样回答，就展现了你对JVM运行时行为的深入理解。

场景二：synchronized和ReentrantLock的区别？这是一个经典对比题，不能只罗列API差异。

核心要点：synchronized是“傻瓜相机”，简单可靠，JVM负责优化。ReentrantLock是“单反相机”，功能强大但需要手动控制，用不好容易出错（如忘记解锁导致死锁）。在不需要ReentrantLock高级特性的场景下，优先使用synchronized。

场景三：什么是锁升级？能详细描述一下过程吗？这就是对本章节3.1内容的综合阐述。回答时要有条理：

1. 目的：为了在无竞争或低竞争时减少锁开销。
2. 步骤：
   • 初始：对象为无锁状态。
   • 第一个线程访问：JVM启用偏向锁，将线程ID CAS写入Mark Word。
   • 第二个线程来竞争：撤销偏向锁。如果原线程已退出同步块，则变为无锁，新线程尝试加轻量级锁；如果原线程仍持有，则直接升级为轻量级锁。
   • 轻量级锁竞争：线程通过CAS和自旋尝试获取锁。若自旋失败（或自旋期间有第三个线程来竞争），则膨胀为重量级锁。
3. 补充：提及锁消除和锁粗化作为编译期优化。

场景四：synchronized是公平锁吗？

• 直接回答：不是，默认是非公平锁。
• 解释：在重量级锁状态下，当锁释放时，正在_EntryList中等待的线程和新来的线程会一起竞争，新来的线程有可能直接获取到锁，这对已等待的线程是不公平的。ReentrantLock可以通过构造函数选择公平或非公平策略。

场景五：双重检查锁定（DCL）单例模式中，为什么要加volatile？这是synchronized与volatile结合的经典考题。

public class Singleton { private static volatile 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引用。
• 由于指令重排序（编译器和处理器优化），步骤2和步骤3的顺序可能颠倒。如果线程A执行到步骤3（instance已不为null）但步骤2还未完成时，线程B执行到第一次检查if (instance == null)，会发现instance不为null，于是直接返回一个尚未初始化完成的对象，导致程序出错。
• volatile的作用：volatile关键字在这里有两个作用：
  1. 禁止指令重排序：确保instance = new Singleton();操作的步骤1、2、3按顺序完成。
  2. 保证可见性：确保一旦instance被初始化完成，其他线程能立即看到最新的值。
• 因此，DCL模式中synchronized保证了创建过程的原子性，volatile保证了创建过程的有序性和结果的可见性，二者缺一不可。

6. 实战中的避坑指南与性能调优

懂了原理，还要会在实际项目中用好。这里分享几个我踩过的坑和调优经验。

避坑指南1：锁对象选择不当导致非预期同步

// 反例1：锁住了可变对象 private final List<String> lock = new ArrayList<>(); public void method() { synchronized(lock) { lock.add("something"); // 锁对象本身被修改，虽然引用未变，但极不推荐，容易引起混淆。 } } // 反例2：锁住了缓存对象（如Integer, String常量池中的对象） private static final String LOCK = "LOCK"; public void method() { synchronized(LOCK) { // 危险！"LOCK"在常量池中是唯一的，可能被其他毫不相干的代码段使用，导致意外的锁竞争和死锁。 // ... } }

• 最佳实践：专门声明一个私有的、不可变的（final）、仅用于锁定的对象。

  private final Object lock = new Object(); // 专锁专用 public void method() { synchronized(lock) { // ... } }

避坑指南2：锁粒度太粗引发性能瓶颈一个类里所有同步方法都锁this，或者一个庞大的方法被synchronized修饰，会导致线程长时间持有锁，其他线程严重阻塞。

• 优化：使用同步代码块，只锁住真正需要保护的共享资源部分。或者，根据不同的资源，使用不同的锁对象（锁分离），例如读写锁分离。

性能调优经验

1. 监控锁竞争：使用jstack、jconsole、VisualVM等工具，查看线程状态。大量线程处于BLOCKED状态（等待monitor entry）是锁竞争激烈的明显信号。
2. 考虑关闭偏向锁：对于明确存在高并发竞争的服务（如秒杀系统、消息队列的Worker），可以在JVM启动参数中加上-XX:-UseBiasedLocking。因为偏向锁的撤销在高竞争下反而会成为负担，直接使用轻量级锁起步可能效率更高。
3. 谨慎使用synchronized修饰静态方法：这锁的是Class对象，全局唯一，影响范围广。除非确实需要全局同步，否则优先考虑同步实例方法或代码块。
4. 理解自旋的代价：轻量级锁的自旋虽然避免了上下文切换，但在单核CPU或竞争非常激烈的情况下，会白白浪费CPU周期。JVM的自适应自旋（Adaptive Spinning）机制会动态调整自旋次数，通常不需要我们手动干预。

synchronized的深度远不止于此，它还与wait()、notify()、notifyAll()共同构成了Java原生的线程间通信机制，与volatile共同构建了Java内存模型的happens-before规则。但掌握了对象头、Monitor、锁升级这三大核心支柱，以及各种应用场景下的权衡，你已经能应对市面上99%关于它的深度拷问了。记住，面试官问synchronized，很多时候不是在问一个关键字，而是在考察你对Java并发体系、JVM运行机制的理解深度。把这一套东西内化，你的并发功底自然就上了一个台阶。