Java 面试被问烂的 “锁机制”：synchronized vs Lock，一篇讲透

2509_93051135

581人浏览 · 2025-08-14 14:42:00

2509_93051135 · 2025-08-14 14:42:00 发布

在 Java 并发编程的世界里，锁机制是保证多线程安全的核心武器。无论是初学者还是资深开发者，在面试中几乎都绕不开synchronized与Lock这两个关键词。它们如同守护共享资源的两扇门，看似功能相似，实则在实现原理、使用场景和性能表现上存在着深刻差异。理解这两种锁的本质，不仅能帮助开发者写出更高效的并发代码，更能在面试中展现对 Java 底层机制的深入思考。

一、从基础定义看两种锁的本质区别

synchronized是 Java 语言内置的关键字，从 JDK1.0 时代就存在于语法体系中。它的设计理念是 **“简单易用”**，通过隐式的方式实现对共享资源的同步控制。当线程进入被synchronized修饰的代码块或方法时，会自动获取锁；退出代码块或方法时，又会自动释放锁，开发者无需手动干预。这种 “自动性” 虽然降低了使用门槛，但也在一定程度上限制了灵活性。

与之相对，Lock是 JDK1.5 引入的接口（位于java.util.concurrent.locks包下），它的出现弥补了synchronized的功能短板。Lock采用显式操作模式，线程需要通过lock()方法主动获取锁，通过unlock()方法手动释放锁，且unlock()通常需要放在finally块中以避免死锁。这种设计让开发者能更精细地控制锁的获取与释放过程，但也要求使用者具备更强的并发编程素养。

从本质上看，synchronized是一种 “内置锁” 或 “监视器锁”，其实现依赖于 JVM 底层的monitorenter和monitorexit指令；而Lock的实现则基于 Java 代码，例如ReentrantLock就通过 AQS（AbstractQueuedSynchronizer）框架实现了锁的同步逻辑，这种差异直接导致了两者在功能和性能上的分化。

二、使用方式对比：隐式与显式的碰撞

synchronized的使用场景主要有三种：修饰普通方法、修饰静态方法、修饰代码块。当修饰普通方法时，锁的对象是当前实例；修饰静态方法时，锁的对象是类的Class对象；修饰代码块时，锁的对象是()中指定的对象。这种多样化的修饰方式让synchronized能适应不同粒度的同步需求，例如：

TypeScript取消自动换行复制

// 修饰普通方法

public synchronized void method1() { ... }

// 修饰代码块

public void method2() {

synchronized (this) { ... }

}

Lock的使用则需要遵循固定的模板：创建Lock实例（通常是ReentrantLock），在try块中调用lock()获取锁，在finally块中调用unlock()释放锁。这种显式操作虽然代码量增加，但能实现更灵活的控制，例如：

TypeScript取消自动换行复制

Lock lock = new ReentrantLock();

public void method() {

lock.lock();

try {

// 业务逻辑

} finally {

lock.unlock();

}

值得注意的是，Lock还提供了tryLock()方法，该方法尝试获取锁时如果无法获取会立即返回false，而非阻塞等待。开发者可以利用这一特性实现 “超时等待” 或 “非阻塞获取锁” 的逻辑，这在synchronized中是无法实现的。例如，通过tryLock(long time, TimeUnit unit)可以指定等待时间，避免线程无限期阻塞：

TypeScript取消自动换行复制

if (lock.tryLock(1, TimeUnit.SECONDS)) {

try { ... }

finally { lock.unlock(); }

} else {

// 处理获取锁失败的逻辑

}

三、实现原理：从 JVM 指令到 AQS 框架

synchronized的底层实现涉及 Java 对象头中的 “Mark Word” 和监视器（Monitor）。当线程进入synchronized代码块时，JVM 会执行monitorenter指令，尝试获取对象对应的 Monitor 所有权；退出时则执行monitorexit指令释放所有权。Monitor 是一种重量级锁，在 JDK1.6 之前性能较差，但 JDK1.6 引入了 “锁升级” 机制，让synchronized的性能得到大幅优化：

偏向锁：当只有一个线程访问同步资源时，锁会记录线程 ID，避免每次获取释放锁的开销；

轻量级锁：当多个线程交替访问时，通过 CAS 操作尝试获取锁，避免进入内核态；

重量级锁：当多个线程竞争激烈时，升级为 Monitor 锁，依赖操作系统的互斥量实现同步。

Lock的典型实现ReentrantLock则基于 AQS 框架。AQS 通过维护一个双向链表作为等待队列，以及一个状态变量（state）来控制锁的获取与释放。当线程调用lock()时，会尝试通过 CAS 操作修改state的值（从 0 变为 1），成功则获取锁；失败则进入等待队列阻塞。释放锁时，线程会将state重置为 0，并唤醒队列中的其他线程。

AQS 的设计采用了 “模板方法模式”，ReentrantLock通过实现 AQS 的钩子方法（如tryAcquire、tryRelease）定义了独占锁的逻辑。这种基于 Java 代码的实现方式让Lock能灵活扩展功能，例如ReentrantReadWriteLock就是通过 AQS 实现了读写分离的锁机制。

四、功能差异：灵活性与安全性的权衡

除了使用方式和实现原理，synchronized与Lock的功能差异是面试中的高频考点，主要体现在以下几个方面：

可中断性：Lock的lockInterruptibly()方法允许线程在等待锁的过程中响应中断，而synchronized修饰的线程无法被中断，只能一直阻塞；

公平性：ReentrantLock可以通过构造函数指定为 “公平锁”，即线程获取锁的顺序与请求顺序一致；而synchronized是非公平锁，无法保证公平性；

绑定条件：Lock可以通过newCondition()方法创建多个Condition对象，实现更精细的线程通信（如区分 “生产者” 和 “消费者” 的等待与唤醒）；而synchronized只能通过wait()、notify()、notifyAll()方法与对象的单一条件队列交互；

锁的释放：synchronized会在异常、return、程序结束等场景下自动释放锁，而Lock必须手动释放，否则可能导致死锁。

这些差异决定了两者的适用场景：synchronized适合简单的同步场景，代码简洁且不易出错；Lock适合复杂的并发控制，例如需要超时获取锁、中断等待线程或实现读写分离的场景。

五、性能对比：从 “重量级” 到 “势均力敌”

在 JDK1.6 之前，synchronized由于基于重量级锁实现，性能远低于Lock。但随着 “锁升级” 机制的引入，synchronized与Lock的性能差距逐渐缩小，在多数场景下已趋于接近。

具体来看，在低竞争场景下，synchronized的偏向锁和轻量级锁性能优异，甚至略高于ReentrantLock；在中高竞争场景下，ReentrantLock由于实现更灵活（如非公平锁的优化），性能可能更占优势。但这种差异并非绝对，具体性能表现还需结合 JVM 版本、硬件环境和代码逻辑综合判断。

值得注意的是，synchronized作为 JVM 内置特性，未来可能会得到更多优化；而Lock的性能则依赖于 Java 代码的实现，提升空间相对有限。因此，在选择锁机制时，不应单纯以性能为唯一标准，而应优先考虑代码的可读性和维护性。

六、面试高频问题与实战建议

在面试中，面试官常常会结合实际场景提问，例如：“如何实现一个公平锁？”“线程 A 持有锁时，线程 B 和 C 如何高效等待？”“synchronized和Lock在异常处理上有何区别？”

回答这些问题时，需要结合两者的特性深入分析。例如，实现公平锁可以使用ReentrantLock的公平模式；处理线程等待可以利用Lock的Condition实现分组唤醒；异常处理方面，synchronized会自动释放锁，而Lock需要在finally中手动释放，否则可能导致锁泄漏。

在实战开发中，建议遵循 “简单优先” 原则：能用synchronized解决的问题，就不必使用Lock。只有在需要Lock的特殊功能（如超时、中断、多条件）时，才考虑使用ReentrantLock等实现类。同时，无论使用哪种锁，都要注意避免死锁，例如控制锁的获取顺序、避免在锁持有期间调用外部方法等。

七、总结：理解本质，灵活运用

synchronized与Lock并非对立关系，而是 Java 并发工具库中互补的两种锁机制。synchronized以其简洁性和安全性成为基础同步手段，Lock则以其灵活性和扩展性满足复杂场景需求。

理解两者的差异，关键在于把握 “隐式” 与 “显式”、“JVM 内置” 与 “Java 实现” 的核心区别。在面试中，能清晰阐述这些区别并结合场景分析优劣，是体现技术深度的重要标志；在实际开发中，能根据需求选择合适的锁机制，则是写出高效、安全的并发代码的前提。

随着 Java 版本的不断更新，锁机制的实现还在持续优化，但无论技术如何演进，掌握底层原理、理解设计思想，始终是应对变化的不变之道。