synchronized 和 ReentrantLock 有什么区别？

详细解析#

synchronized 的实现#

• 修饰代码块时，编译后是 monitorenter 和 monitorexit 两条字节码指令。编译器还会生成一条异常处理路径，保证抛异常时也会执行 monitorexit，所以不会因为异常忘记释放锁
• 修饰方法时，方法的访问标志里带有 ACC_SYNCHRONIZED，JVM 调用方法时自动加锁、返回时自动释放
• 锁的都是对象：实例方法锁 this，静态方法锁当前类的 Class 对象，代码块锁括号里指定的对象
• 每个对象都可以关联一个监视器（monitor），记录持有锁的线程、重入次数、等待获取锁的线程，以及调用了 wait() 的线程。同一个线程再次进入时只增加重入次数，所以是可重入的

synchronized 的锁优化#

锁的状态记录在对象头的 Mark Word 里。HotSpot 的优化手段：

• 轻量级锁：没有竞争时，线程用一次 CAS 把对象头指向自己栈帧里的锁记录，就算加锁成功，不需要创建监视器，也不需要操作系统参与。这是 JDK 22 及以前的默认实现；JDK 23 起默认改用新的轻量级锁实现，不再借助栈上的锁记录，但同样是无竞争时一次 CAS 加锁
• 重量级锁：出现竞争后，锁膨胀为重量级锁，使用监视器对象。抢不到锁的线程先自适应地自旋一小会儿，还拿不到才挂起；挂起和唤醒要靠操作系统完成，开销较大
• 偏向锁：曾用来优化"总是同一个线程加锁"的场景，在对象头里记下线程 ID，之后这个线程加锁连 CAS 都不用。但有其他线程来竞争时，撤销偏向往往要在安全点进行，代价很高。偏向锁在 JDK 8 中默认开启，JDK 15 起默认禁用并被废弃（JDK 15～17 还能用 -XX:+UseBiasedLocking 手动打开），JDK 18 移除了它的实现（JDK 19 起再加这个参数会启动报错），JDK 21 中已经没有偏向锁
• 锁消除：JIT 通过逃逸分析发现锁对象不可能被其他线程访问时，直接去掉加锁操作，例如方法内部使用的局部 StringBuffer
• 锁粗化：对同一个对象反复加锁、解锁（比如连续调用 StringBuffer 的 append），JIT 会把它们合并成一次范围更大的加锁

ReentrantLock 和 AQS#

ReentrantLock 基于 AbstractQueuedSynchronizer（AQS）实现（下面用到的 volatile 和 CAS 见 volatile 和 Java 内存模型）：

1. 用一个 volatile 的 int state 表示锁状态：0 表示没有被持有，大于 0 表示已被持有，数值就是重入次数；同时记录持有锁的线程
2. 加锁时用 CAS 把 state 从 0 改成 1，成功就获得锁；如果是当前线程已经持有锁，就把 state 加 1
3. 获取失败的线程被包装成节点，加入 AQS 的 FIFO 等待队列，然后用 LockSupport.park 挂起
4. 释放时 state 减 1，减到 0 才真正释放，并唤醒队列中的下一个线程

对比#

怎么选#

• 普通的互斥场景优先用 synchronized（写法简单，不会忘记释放，JVM 也在持续优化它）；需要可中断、超时、公平锁或多个条件队列时，再用 ReentrantLock
• JDK 21 的虚拟线程在 synchronized 块里阻塞时，会钉住（pin）它所在的平台线程，让这个平台线程也没法去运行其他虚拟线程。所以在 JDK 21 中，包含长时间阻塞 I/O 的临界区建议改用 ReentrantLock；JDK 24 起 synchronized 不再导致这种钉住。虚拟线程见 线程池 一题

代码示例：用两个 Condition 实现阻塞队列#

import java.util.ArrayDeque;
import java.util.Deque;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

public class BoundedBuffer<T> {
    private final Deque<T> items = new ArrayDeque<>();
    private final int capacity;
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull = lock.newCondition();  // 生产者在这里等"队列不满"
    private final Condition notEmpty = lock.newCondition(); // 消费者在这里等"队列不空"

    public BoundedBuffer(int capacity) { this.capacity = capacity; }

    public void put(T item) throws InterruptedException {
        lock.lockInterruptibly(); // 等锁期间可以响应中断
        try {
            while (items.size() == capacity) {
                notFull.await(); // 释放锁并等待，被唤醒后重新竞争锁，再检查条件
            }
            items.addLast(item);
            notEmpty.signal(); // 只唤醒等待"不空"的消费者
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        lock.lockInterruptibly();
        try {
            while (items.isEmpty()) {
                notEmpty.await();
            }
            T item = items.removeFirst();
            notFull.signal(); // 只唤醒等待"不满"的生产者
            return item;
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        BoundedBuffer<Integer> buffer = new BoundedBuffer<>(2);
        Thread producer = new Thread(() -> {
            try {
                for (int i = 1; i <= 5; i++) buffer.put(i); // 队列满了就阻塞，等消费者取走
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        producer.start();
        for (int i = 0; i < 5; i++) System.out.println(buffer.take()); // 依次输出 1 到 5
        producer.join();
    }
}

用 synchronized 实现时只有一个等待集合，生产者和消费者混在一起，notify() 可能唤醒同类线程，通常只能用 notifyAll() 全部唤醒。

面试官可能追问#

易错点#

• lock() 要放在 try 之前，unlock() 放在 finally 里。如果把 lock() 写进 try，加锁之前或加锁时抛出异常，finally 里的 unlock 会因为当前线程没持有锁而抛出 IllegalMonitorStateException，把原来的异常掩盖掉
• synchronized 锁的是对象，不是代码：两个不同的实例调用同一个同步实例方法不会互斥；静态同步方法锁的是 Class 对象，和实例方法用的不是同一把锁
• 不要用字符串常量、Integer 这类可能被缓存和共享的对象当锁，否则可能和毫不相关的代码争同一把锁
• wait() 和 await() 都要放在 while 循环里检查条件，因为线程可能被虚假唤醒，或者被唤醒时条件已经又被别的线程改变了