当前位置：首页 > news >正文

synchronized 和 ReentrantLock 到底差在哪——从底层扒到应用场景

news 2026/6/25 21:07:21

前两篇写了线程怎么停、锁有哪些，这篇想深挖一下。

原因是有一天我在看代码的时候突然想到一个问题：synchronized 不用手动 unlock，ReentrantLock 要——那 synchronized 是怎么知道自己什么时候该释放锁的？它的底层到底在干什么？

我跑去翻了翻这方面的资料，发现比我想象的要有意思得多。

先说说 synchronized 在 JVM 里到底是怎么工作的

字节码层面：monitorenter 和 monitorexit

synchronized 是 Java 关键字，编译之后会在字节码里变成几条指令。

拿同步代码块来说，编译后你会看到字节码里插入了monitorenter和monitorexit指令。进入的时候执行 monitorenter，退出的时候（不管是正常结束还是抛异常）执行 monitorexit。

那同步方法呢？它不靠这两条指令，而是靠方法表里的一个标志位叫ACC_SYNCHRONIZED。JVM 看到这个标志，就知道这个方法需要先拿到锁再执行。

这解释了为什么 synchronized 不需要手动释放——编译器在生成字节码的时候就帮你安排好了释放的路径，包括异常路径。

对象头与 Mark Word：锁存在哪里

每个 Java 对象在内存里，除了你写的那些字段之外，还有一部分"隐藏"的信息，叫对象头。对象头里有一块叫Mark Word的区域，它存的东西会随着对象的状态变化而变化。

一开始它可能存的是哈希码、GC 分代年龄这些东西。一旦这个对象被当作锁来用了，Mark Word 里的内容就变成了锁的相关信息——比如当前持有锁的线程是谁、当前处于什么锁状态。

锁升级的过程，说白了就是 Mark Word 里的数据在不断被改写。

重量级锁与 ObjectMonitor

如果锁升级到了重量级锁（就是竞争很激烈的时候），JVM 会为这个锁创建一个ObjectMonitor对象。这个对象里维护了三个关键的结构：

_owner：当前拿着锁的线程是谁
_EntryList：想拿锁但是没拿到、在那等着的线程们
_WaitSet：调用了wait()方法先歇会儿的线程们

重量级锁的"重量"体现在哪呢？因为这个时候它要依赖操作系统的Mutex Lock（互斥量）来阻塞线程。把一个线程从用户态切到内核态阻塞，再切回来唤醒——这一来一回开销很大。所以才有锁升级那套机制，尽量让锁停留在轻量级状态，别走到重量级这一步。

锁升级：JDK 15 之后有变化

之前那篇博客里我简单提过锁升级的路径：无锁 → 偏向锁 → 轻量级锁 → 重量级锁。

但这里有个更新要交待一下。从JDK 15 开始，偏向锁已经被默认禁用了，并且标记为废弃。原因是偏向锁的撤销成本太高了——在高并发场景下，为了撤销偏向锁，JVM 需要做很多事情，算下来还不如直接走轻量级锁划算。

所以现在默认的路径变成：

无锁 → 轻量级锁（CAS） → 重量级锁（操作系统互斥量）

少了一个环节。

再说 ReentrantLock：它靠的是 AQS

ReentrantLock 跟 synchronized 不一样。它不属于 JVM 层面，而是 JDK 提供的 API——用纯 Java 代码写出来的锁。核心就是一个类：AbstractQueuedSynchronizer，缩写AQS。

我第一次看到 AQS 这个缩写的时候还以为是某个高深莫测的东西，读了一点发现，它的核心思路其实不复杂。

AQS 内部长什么样

AQS 内部维护了两个东西：

一个volatile int state变量。0 表示锁没人拿，1 表示有人拿着了（大于 1 表示可重入，同一个线程反复拿锁）。
一个双向链表（CLH 变体队列），用来排队的。拿不到锁的线程都被塞到这个链表里。

拿锁的过程

当线程调用lock()的时候，AQS 做的第一件事是：用CAS操作尝试把 state 从 0 改成 1。

如果用大白话说就是：

“我想拿锁，我先试一下看看 state 是不是 0。如果是，我就改成 1，锁归我了。如果不是，说明被人占了，我去排队。”

CAS 成功了，锁就拿到了，当前线程的 ID 会被记下来——这样下次这个线程再来拿锁，发现已经是自己了，就直接进去，这就是可重入的实现。

CAS 失败了，AQS 会把当前线程和它的等待状态包装成一个Node节点，挂到双向链表尾部。然后调用LockSupport.park()把线程阻塞住。

等持有锁的线程调用unlock()，会做三件事：

把 state 减回 0
把记录的线程 ID 清掉
调用LockSupport.unpark()唤醒队列头部的下一个线程

公平锁和非公平锁的区别

这俩的区别我一开始总搞混，后来记了一个简单的版本：

非公平锁（默认）：新来的线程不管队列里有没有人排队，先 CAS 抢一把。抢到了就插队进去了。抢不到才去排队。
公平锁：新来的线程先看一眼 AQS 队列里有没有人在排队。有人就乖乖去队尾站着，不抢。

非公平锁虽然"不公平"，但性能通常更好——因为线程刚释放锁，下一个线程立刻拿到的概率很大，省了线程挂起唤醒的开销。公平锁排队虽然公平，但是整体吞吐量会低一些。

那到底差在哪——从头到尾比一遍

1. 实现方式不同

synchronized	ReentrantLock
层面	JVM 关键字	JDK API 类
获取/释放	隐式，JVM 自动管	显式，手动 lock/unlock
怎么解锁的	编译器生成的字节码里有 monitorexit	开发者在 finally 里调用 unlock

2. synchronized 做不到的事

等待可中断：
synchronized 等锁的时候不会被 interrupt() 打断。ReentrantLock 有lockInterruptibly()，可以做到"等着等着被喊停"。

超时放弃：
synchronized 只能一直等。ReentrantLock 可以tryLock(5, TimeUnit.SECONDS)——等五秒拿不到就不等了。

公平锁：
synchronized 只有非公平。ReentrantLock 可以选公平。

精准唤醒：
这个差别挺大的。synchronized 配合 wait/notify/notifyAll 只有一个等待队列。调用 notifyAll 的时候，所有等着的线程都被叫醒了——哪怕有些线程等的是不同的条件，这叫惊群效应。

ReentrantLock 可以配合多个 Condition，每个 Condition 有自己的等待队列。比如：

class BoundedQueue { private final ReentrantLock lock = new ReentrantLock(); private final Condition notFull = lock.newCondition(); private final Condition notEmpty = lock.newCondition(); // notFull.await() — 等着不满 // notEmpty.signal() — 唤醒等着取数据的线程 }

生产者线程满了就等 notFull，消费者线程空了就等 notEmpty。唤醒的时候只唤醒对方，不会把所有人都吵醒。