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虚拟机对象头主要包含两部分Mark Word标记字段这是核心中的核心存储了对象自身的运行时数据。它的长度在32位JVM中是32位64位JVM中是64位。你可别小看这几十个比特它是个“变脸大师”会根据对象的状态是否被锁定、是否可偏向等复用这些位来存储不同的信息。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适用场景当偏向锁被撤销或者一开始就关闭了偏向锁且存在多个线程交替执行同步块即竞争是“交替式”的而非“密集型”的此时升级为轻量级锁。加锁过程在当前线程的栈帧中创建一个名为锁记录Lock Record的空间。将对象头的Mark Word复制到锁记录中称为Displaced Mark Word。然后线程尝试使用CAS操作将对象头的Mark Word替换为指向锁记录的指针并将锁标志位设置为“00”轻量级锁状态。如果CAS成功当前线程获得锁。如果失败说明至少存在两条线程在竞争同一个锁会触发自旋锁。自旋锁Spin Lock竞争失败的线程不会立即阻塞进入重量级锁的_EntryList而是采用循环的方式自旋去尝试再次获取锁。这基于一个假设锁的持有者很快就会释放锁。自旋避免了线程上下文切换的开销用户态操作但会空耗CPU。如果自旋超过一定次数JDK中自适应自旋次数由前一次在同一个锁上的自旋时间及锁的持有者状态决定仍未成功锁就会膨胀为重量级锁。解锁过程使用CAS操作将Displaced Mark Word替换回对象头。如果成功则解锁完成。如果失败说明锁已经膨胀为重量级锁解锁过程会唤醒阻塞的线程。3. 重量级锁Heavyweight Locking如上文Monitor机制所述当轻量级锁竞争加剧自旋失败锁就会膨胀为重量级锁。此时Mark Word中存储的是指向Monitor对象的指针锁标志位变为“10”。未获得锁的线程会被阻塞进入_EntryList队列等待操作系统调度涉及用户态到内核态的切换开销最大。3.2 锁消除与锁粗化除了锁升级JVM还有两项重要的编译期优化锁消除Lock EliminationJIT编译器在运行时通过对“逃逸分析”技术的运用如果发现一个锁对象不可能被其他线程访问到即该对象没有“逃逸”出当前线程那么即使代码中显式地加了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讲起说明它是锁信息的载体。然后分情况讨论无竞争时可能启用偏向锁Mark Word存储线程ID。轻度竞争时升级为轻量级锁通过线程栈中的锁记录和CAS操作实现。重度竞争时膨胀为重量级锁Mark Word指向ObjectMonitor线程在操作系统的Monitor上排队。最后要提到JIT编译器的优化如锁消除和锁粗化。这样回答就展现了你对JVM运行时行为的深入理解。场景二synchronized和ReentrantLock的区别这是一个经典对比题不能只罗列API差异。特性synchronized (隐式锁)ReentrantLock (显式锁)实现层面JVM层面实现原生语法支持JDK层面实现基于AQSAbstractQueuedSynchronizer锁的获取与释放自动获取和释放进入同步块获取退出正常或异常释放必须手动lock()和unlock()通常放在try-finally块中灵活性有限。不可中断、不可设置超时、非公平默认灵活。可中断(lockInterruptibly())、可超时(tryLock(timeout))、可公平构造函数指定条件队列单一通过wait()/notify()/notifyAll()操作多个通过newCondition()创建多个Condition对象实现更精细的线程通信如生产者-消费者模型性能早期版本性能较差但经过大量优化锁升级后在低竞争场景下性能极佳在高竞争场景下由于其可配置的灵活性可能表现更稳定调试获取锁的信息较少堆栈信息可能不够清晰提供了一些监控方法如getHoldCount(),getQueueLength()等核心要点synchronized是“傻瓜相机”简单可靠JVM负责优化。ReentrantLock是“单反相机”功能强大但需要手动控制用不好容易出错如忘记解锁导致死锁。在不需要ReentrantLock高级特性的场景下优先使用synchronized。场景三什么是锁升级能详细描述一下过程吗这就是对本章节3.1内容的综合阐述。回答时要有条理目的为了在无竞争或低竞争时减少锁开销。步骤初始对象为无锁状态。第一个线程访问JVM启用偏向锁将线程ID CAS写入Mark Word。第二个线程来竞争撤销偏向锁。如果原线程已退出同步块则变为无锁新线程尝试加轻量级锁如果原线程仍持有则直接升级为轻量级锁。轻量级锁竞争线程通过CAS和自旋尝试获取锁。若自旋失败或自旋期间有第三个线程来竞争则膨胀为重量级锁。补充提及锁消除和锁粗化作为编译期优化。场景四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();这行代码并非原子操作它大致分为三步分配内存空间。初始化对象调用构造函数等。将内存地址赋值给instance引用。由于指令重排序编译器和处理器优化步骤2和步骤3的顺序可能颠倒。如果线程A执行到步骤3instance已不为null但步骤2还未完成时线程B执行到第一次检查if (instance null)会发现instance不为null于是直接返回一个尚未初始化完成的对象导致程序出错。volatile的作用volatile关键字在这里有两个作用禁止指令重排序确保instance new Singleton();操作的步骤1、2、3按顺序完成。保证可见性确保一旦instance被初始化完成其他线程能立即看到最新的值。因此DCL模式中synchronized保证了创建过程的原子性volatile保证了创建过程的有序性和结果的可见性二者缺一不可。6. 实战中的避坑指南与性能调优懂了原理还要会在实际项目中用好。这里分享几个我踩过的坑和调优经验。避坑指南1锁对象选择不当导致非预期同步// 反例1锁住了可变对象 private final ListString 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修饰会导致线程长时间持有锁其他线程严重阻塞。优化使用同步代码块只锁住真正需要保护的共享资源部分。或者根据不同的资源使用不同的锁对象锁分离例如读写锁分离。性能调优经验监控锁竞争使用jstack、jconsole、VisualVM等工具查看线程状态。大量线程处于BLOCKED状态等待monitor entry是锁竞争激烈的明显信号。考虑关闭偏向锁对于明确存在高并发竞争的服务如秒杀系统、消息队列的Worker可以在JVM启动参数中加上-XX:-UseBiasedLocking。因为偏向锁的撤销在高竞争下反而会成为负担直接使用轻量级锁起步可能效率更高。谨慎使用synchronized修饰静态方法这锁的是Class对象全局唯一影响范围广。除非确实需要全局同步否则优先考虑同步实例方法或代码块。理解自旋的代价轻量级锁的自旋虽然避免了上下文切换但在单核CPU或竞争非常激烈的情况下会白白浪费CPU周期。JVM的自适应自旋Adaptive Spinning机制会动态调整自旋次数通常不需要我们手动干预。synchronized的深度远不止于此它还与wait()、notify()、notifyAll()共同构成了Java原生的线程间通信机制与volatile共同构建了Java内存模型的happens-before规则。但掌握了对象头、Monitor、锁升级这三大核心支柱以及各种应用场景下的权衡你已经能应对市面上99%关于它的深度拷问了。记住面试官问synchronized很多时候不是在问一个关键字而是在考察你对Java并发体系、JVM运行机制的理解深度。把这一套东西内化你的并发功底自然就上了一个台阶。