阿丁的猫写这篇拆解之前，先说个背景。我这两年在带团队做高并发交易系统时，发现很多同学对 synchronized 很熟，但一提到 ReentrantLock 就只说得出“比 synchronized 灵活”，再往下问 AQS、公平锁、Condition，就答不上来了。可恰恰是这类“差一口气”的地方，线上排查死锁、优化吞吐时最容易卡壳。这篇我打算从线程安全的本质讲起，把 ReentrantLock 的核心机制、源码思路、实战用法和踩坑经验一次说透，适合正在啃 Java 并发、准备面试、或者已经在生产环境跟锁打交道但想补全细节的开发者。
1. 从 synchronized 到 ReentrantLock：为什么需要一把“可重入”的锁
1.1 线程安全问题的本质：先看懂资源竞争
你说“线程安全”，到底在防什么？一句话：多个线程同时访问共享可变资源，导致结果不可预期。这个不可预期来自三个条件的叠加——多线程、共享数据、非原子操作。缺一个都不成立。
举个例子，网上流传最广的 i++ 自增问题。i++ 在字节码层面是三步：读取 i 的值、计算 i+1、把结果写回。两个线程同时执行，完全可能都读到旧值 100，都算成 101，再都写回，最终结果是 101 而不是 102。这就是经典的丢失更新。
要解决它，核心思路就一个：把“读-改-写”变成原子操作，让同一时刻只有一个线程能进入这段代码。这个“同一时刻只允许一个线程进入”的机制，就是锁。
Java 里实现锁的方式有很多，从最老的 synchronized，到 java.util.concurrent.locks 包下的 ReentrantLock、ReadWriteLock、StampedLock，再到底层基于 CAS 的 AtomicInteger。它们的底层支撑其实高度统一——都离不开 volatile 的内存可见性、CAS 的原子性，以及队列/阻塞机制来管理等待线程。理解了这个，你就知道锁不是玄学，而是“原子性 + 可见性 + 线程调度”的组合拳。
1.2 synchronized 的先天不足：不是不能用，是场景受限
JVM 对 synchronized 做过大量优化，锁升级从偏向锁到轻量级锁再到重量级锁，大多数场景下性能并不差。但它的短板也很明显，主要有四块：
第一，获取锁的过程不可中断。线程拿不到锁就死等，你在外面没法让它停下来。这在某些需要超时控制的场景下很致命，比如一个资源可能被占很久，另一个线程不想无限等下去。
第二，无法实现公平性。默认是非公平的，新来的线程可能插队，理论上存在“饥饿”的可能。虽然实际中概率不高，但基于 synchronized 做公平控制基本没门。
第三，超时控制能力为零。没有“等待 3 秒还获取不到就放弃”这种 API，只能靠 wait(long) 配合手写循环，绕来绕去还容易出错。
第四，只能通过 wait/notify 做线程协作，而且 wait/notify 用起来很容易踩坑——必须在持有锁的代码块里调用，否则抛 IllegalMonitorStateException，多个条件等待的场景更是要命。
这四点，正好是 ReentrantLock 要补的位。它和 synchronized 一样支持可重入（同一个线程可以重复获取同一把锁），但额外提供了中断响应、超时获取、公平锁、多 Condition 精确唤醒等能力。用不用它不是“比性能”这么简单，而是“synchronized 能不能表达你的并发控制需求”的问题。
1.3 ReentrantLock 核心特性一览：先建立全景图
ReentrantLock 从名字拆解就是“可重入的锁”。重入的意思是，同一线程已经拿到锁之后，再次进入同步代码块不需要重新排队抢锁，只需要对内部计数器加一即可。这个特性保证了一个场景的正确性：一个方法持有锁后又调用另一个需要同一把锁的方法——如果没有可重入性，这里就直接死锁了。
它最关键的几个能力，我列成速查，后面逐个展开：
- 基于
AbstractQueuedSynchronizer（AQS）实现，核心是一个volatile int state配合 FIFO 等待队列。 - 支持公平模式和非公平模式，构造器传
true开启公平。 lock()阻塞获取；tryLock()立即尝试；tryLock(timeout, unit)带超时；lockInterruptibly()可在等待时响应中断。newCondition()可以创建多个 Condition，实现比wait/notify精细得多的定向唤醒。- 必须手动
unlock()，且要与lock()成对出现，一般放在finally里。
我先把结论放这儿：ReentrantLock 不是 synchronized 的简单替代品，而是一套更精细的并发控制工具。它的复杂换来的是灵活，代价是更容易写错。下面我拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ReentrantLock 内部机制深度拆解：从源码层面看锁怎么工作
2.1 可重入性到底怎么实现的：一个计数器搞定
ReentrantLock 的可重入实现，比很多人想象中简单。它内部有一个整型变量 state，多少次获取锁成功，state 就加多少。
当线程 A 第一次拿到锁时，state 从 0 变成 1，AQS 的 exclusiveOwnerThread 字段记录下“当前持有锁的线程是 A”。A 再次调用 lock() 时，发现 exclusiveOwnerThread 就是自己，于是不排队、不竞争，直接把 state 变成 2。直到所有未配对的 unlock() 都执行完，state 归 0，锁才真正释放，其他线程才有机会获取。
这个设计非常优雅，它把“锁被谁持有”和“持有了几次”这两个信息用两个字段就表达清楚了。state 就是重入次数，exclusiveOwnerThread 就是所有者线程。
对应到源码层面，NonfairSync.tryAcquire 最终会调用到 nonfairTryAcquire，核心逻辑如下（我用伪代码还原思路）：
java复制final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 锁空闲，CAS 尝试获取，成功后记录 owner
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) {
// 锁被当前线程持有，直接加重入计数
int nextc = c + acquires;
if (nextc < 0) {
throw new Error("Maximum lock count exceeded");
}
setState(nextc);
return true;
}
return false;
}
你看，核心就两个分支：锁空闲就抢，锁在自己手里就重入计数。释放锁的逻辑反向操作，state 减一，减到 0 才把 owner 清空。这就是可重入的全部秘密，没有更多魔法。
2.2 AQS：所有同步器的公共地基
ReentrantLock 只是 AQS 的一个应用案例。AQS（AbstractQueuedSynchronizer）是 java.util.concurrent 包的地基，CountDownLatch、Semaphore、ReentrantReadWriteLock 全都建立在它之上。搞懂 AQS，等于一键解锁大半并发工具。
AQS 的核心数据模型是三样东西：
volatile int state：同步状态，含义由子类自己定义。ReentrantLock用它记重入次数，Semaphore用它记剩余许可数。CLH变体队列：一个 FIFO 双向链表，保存获取锁失败的线程节点。每个节点里装着线程引用和等待状态。Unsafe提供的 CAS 操作：用来无锁地修改 state 和队列指针。
lock() 的完整流程，本质上是一次“尝试获取 + 失败入队 + 阻塞等待”的循环。这个过程在源码里叫 acquire：
java复制public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
Thread.currentThread().interrupt();
}
}
我第一次读这段代码时觉得它短得可怕，但每一行都有含义。tryAcquire 是子类实现的快速尝试，成功就直接返回；失败的话，addWaiter 把当前线程包装成 Node 塞进等待队列尾部；acquireQueued 让线程在队列里自旋或者挂起，直到前驱节点释放锁唤醒它。
真正生产环境里，锁竞争激烈时，大量线程会在 acquireQueued 里被 LockSupport.park() 挂起，由前驱节点在释放锁时通过 unparkSuccessor 唤醒。这里你不一定要背源码，但必须理解两个点：第一，锁等待不是无限自旋，而是有阻塞有唤醒的；第二，排队机制保证了即使锁被释放，也不是所有等待线程一起冲上来抢，而是队首节点优先——意识上它是“有序放行”的。
2.3 公平锁与非公平锁：一个 CAS 的差别
ReentrantLock 默认是非公平锁，但源码里非公平和公平的实现差别极小，就在 tryAcquire 的开头多了一行判断。
FairSync.tryAcquire 里的关键代码是这样的：
java复制protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() && // 区别就在这一行
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// ... 重入逻辑与非公平锁一致
}
hasQueuedPredecessors() 检查队列里有没有排在自己前面的线程。如果有，即使锁正好空闲，公平锁也不抢，乖乖排队；非公平锁则不存在这个检查，直接 CAS 抢。
这就引出一个很有意思的工程问题：为什么默认是非公平的？
因为非公平锁在大多数场景下吞吐更高。设想一个场景：线程 A 持有锁，线程 B、C、D 都在排队，锁释放的瞬间，线程 E 恰好来了。非公平模式下，E 可以直接抢到锁，避免了 park/unpark 这种昂贵的内核态切换开销。而被插队的 B 多等了一会儿，但总体吞吐上去了。
类比坐地铁：非公平就是门一开大家都能冲，腿快的人先上去；公平就是排队顺序进，虽然绝对公平，但每次“轮到你”都要停下排队，整体节奏慢。高并发短临界区场景下，非公平锁的吞吐优势能到 10%~30%，这是我实测过的数字。但如果你对响应时延特别敏感、担心线程饥饿，又或者排队线程都是关键任务，那就用公平锁——代价是吞吐略降。
2.4 lock / tryLock / lockInterruptibly：四个入口怎么选
这四种获取锁的方式，本质上是四种不同的等待策略，选错了会出现非常诡异的线上问题。
lock() 是最朴素的方式：拿不到就阻塞等待，直到拿到为止。它的缺点是无法响应中断，线程只能干等。极端情况下，如果持锁线程因为某种原因不释放（比如 wait 状态的死锁），所有调用 lock() 的线程都会永久挂起。
tryLock() 是“试一下，拿不到就算了”，返回 boolean。适合做“抢不到就干别的事”的逻辑，比如：多个节点同时处理一个任务，谁抢到锁谁执行，抢不到就去处理其他任务，不需要阻塞。
tryLock(long timeout, TimeUnit unit) 是带超时上限的尝试，超过时间自动放弃，返回 false。这是我最推荐的上生产的方式，因为有兜底。比如：
java复制if (lock.tryLock(3, TimeUnit.SECONDS)) {
try {
// 业务逻辑
} finally {
lock.unlock();
}
} else {
// 记录日志，走降级逻辑
}
lockInterruptibly() 与 lock() 的区别是：在线程等待获取锁的过程中，如果别的线程调用 thread.interrupt()，这个线程会抛出 InterruptedException 提前退出。这在需要“优雅停机”的系统里很有用——你希望某个线程在等待锁时能被外部信号打断，而不是无响应地挂在那儿。
我画个简单的选择表，方便你记：
| 获取方式 | 是否阻塞 | 能否响应中断 | 能否超时 | 适合场景 |
|---|---|---|---|---|
| lock() | 是 | 否 | 否 | 简单的互斥保护 |
| tryLock() | 否 | 是（立刻返回） | 不适用 | 抢占式任务、非阻塞尝试 |
| tryLock(timeout, unit) | 是 | 是 | 是 | 上生产首选，避免无限等待 |
| lockInterruptibly() | 是 | 是 | 否 | 需要支持线程中断的阻塞场景 |
有个细节要提醒：tryLock() 如果抢不到返回 false，但调用 lock() 或可中断版本抛了 InterruptedException 之后，锁状态是未获取的，你不能在 finally 里无条件 unlock()，否则会抛 IllegalMonitorStateException。我见过不少人在异常处理上翻车，后面我会专门讲排查。
3. 实战：用 ReentrantLock 写出线程安全代码
3.1 最直观的场景：可重入计数器
我先写一个最典型的例子，用 ReentrantLock 保护一个计数器的自增逻辑。它的特别之处在于演示了“可重入”——increment 里又调用了 getCount 方法，而 getCount 也加了同一把锁。
java复制import java.util.concurrent.locks.ReentrantLock;
public class ReentrantCounter {
private final ReentrantLock lock = new ReentrantLock();
private int count = 0;
public void increment() {
lock.lock();
try {
// 模拟复杂业务逻辑
count++;
// 重入：已经持有锁，再次调用加锁方法也没问题
checkState();
} finally {
lock.unlock();
}
}
private void checkState() {
lock.lock();
try {
if (count < 0) {
throw new IllegalStateException("count 不可能为负数");
}
} finally {
lock.unlock();
}
}
public int getCount() {
lock.lock();
try {
return count;
} finally {
lock.unlock();
}
}
}
这里最值得学的是两个习惯：第一，lock() 之后立刻 try-finally 包住业务逻辑，unlock() 放在 finally 里。这样即使业务代码抛异常，锁也能正常释放，不会把锁“带病”传给下一个线程。第二，同一把锁可以被同一个线程反复持有，上层方法调下层方法时不需要担心死锁。
可能有人会问，既然 synchronized 也能实现相同功能，为啥要用 ReentrantLock？答案是：这个例子确实体现不出优势，所以继续往下看 Condition 的例子，那里才是 ReentrantLock 的主场。
3.2 进阶场景：Condition 实现精准唤醒的生产者-消费者
Object.wait/notify 最大的问题是：只能按“单条件”等待，而且 notifyAll 会把所有等待线程都唤醒，让它们自己判断条件是否满足。条件多的时候，代码写起来非常拧巴。
ReentrantLock 的 Condition 解决了这个问题：你可以创建多个条件队列，每个队列睡着自己的线程，唤醒时精准点名。下面这个例子，我用两个 Condition 分别管理“队列不满”和“队列不空”两种状态，这是经典的生产者-消费者模型里 wait/notify 很难优雅实现的版本。
java复制import java.util.LinkedList;
import java.util.Queue;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
public class MessageQueue {
private final ReentrantLock lock = new ReentrantLock();
private final Condition notFull = lock.newCondition();
private final Condition notEmpty = lock.newCondition();
private final Queue<String> queue = new LinkedList<>();
private final int capacity;
public MessageQueue(int capacity) {
this.capacity = capacity;
}
public void put(String message) throws InterruptedException {
lock.lock();
try {
while (queue.size() == capacity) {
// 队列满，生产者线程睡在 notFull 条件上
notFull.await();
}
queue.offer(message);
// 唤醒一个等待消费的线程
notEmpty.signal();
} finally {
lock.unlock();
}
}
public String take() throws InterruptedException {
lock.lock();
try {
while (queue.isEmpty()) {
// 队列空，消费者线程睡在 notEmpty 条件上
notEmpty.await();
}
String msg = queue.poll();
// 唤醒一个等待生产的线程
notFull.signal();
return msg;
} finally {
lock.unlock();
}
}
}
这个代码里有两个细节必须敲黑板。
await() 必须用 while 包住条件判断，而不是 if。原因是 await 被唤醒后，不能假定条件一定满足——“虚假唤醒”（spurious wakeup）在 JVM 规范里是明确允许的。用 while 循环重新检查条件，唤醒后如果队列还是满/空的，就继续睡。这是并发编程里一条铁律。
signal 和 signalAll 的区别。单生产者单消费者场景用 signal 足够，唤醒一个就会执行。但多生产者多消费者场景下，如果只用 signal，有可能唤醒的线程恰好不需要干活，比如生产者唤醒了一个生产者而不是消费者，导致消费者永远等不到信号。稳妥起见，绑定性不明确时用 signalAll，代价是性能略低，但正确性有保障。我线上系统基本都用 signalAll 兜底。
3.3 性能实测：公平锁、非公平锁、synchronized 怎么选
很多博客会告诉你“ReentrantLock 性能比 synchronized 好”，但这句话在 JDK 8 之后已经不完全准确了。我用一个简单压测说明问题：8 个线程并发对同一个计数器累加 1000 万次，分别用 synchronized、非公平 ReentrantLock、公平 ReentrantLock，结果大致是这样的规律：
| 锁类型 | 相对耗时（越低越快） | 特点 |
|---|---|---|
| synchronized | 1.00（基准） | JVM 锁升级后竞争不激烈时表现很好 |
| ReentrantLock 非公平 | 0.9~1.1 | 高竞争下略优，波动小 |
| ReentrantLock 公平 | 1.2~1.5 | 最慢，因为严格排队 |
这个结果说明一个真相：锁的选择，性能不是第一考量，特性匹配才是。如果你的场景只是简单互斥、没有超时需求，synchronized 依然是最省心的选择——它不需要手动解锁，不会因为漏写 finally 而出事故，JVM 层面还有各种优化。
但如果你需要中断、超时、公平性、多条件精准唤醒，就得用 ReentrantLock。选择依据从来不是“快”，而是“能不能做到”。我自己团队里的规范是：默认 synchronized，明确需要 ReentrantLock 的某一项能力时才换锁。这个原则写进 code review 清单，争议少很多。
4. 常见问题与排查技巧实录：这些坑我全踩过
4.1 死锁：如何快速定位与预防
ReentrantLock 用不好，第一个大坑就是死锁。典型场景：两个线程各自持有一把锁，又都尝试获取对方的锁，互相等待，谁也走不动。
定位死锁的方法，最有价值的是 jstack。先找到 Java 进程的 PID，然后执行：
bash复制jstack <pid> > thread_dump.txt
打开文件搜索 Found one Java-level deadlock，它下面会明确列出：
- 线程 A 持有哪把锁（
locked ...） - 线程 A 正在等待哪把锁（
waiting to lock ...） - 线程 B 持有哪把锁，又等待哪把锁
看到两个线程的锁互相交叉，死锁原因就清楚了。更优雅的做法是使用 ThreadMXBean 定时检测死锁：
java复制ThreadMXBean tmb = ManagementFactory.getThreadMXBean();
long[] ids = tmb.findDeadlockedThreads();
findDeadlockedThreads() 有返回值就说明存在死锁，然后遍历线程信息打印出来。我在监控系统里就是挂一个这样的定时任务，发现死锁立即告警并输出 dump，比事后翻日志高效得多。
预防死锁，工程上我常用三个手段：加锁顺序全局一致（所有方法都按同一顺序获取锁 A 再获取锁 B，就不会交叉）；用 tryLock 替代 lock（等不到就放弃，配合重试逻辑，从机制上消灭无限等待）；锁粒度尽量小（少持有锁做耗时操作，降低交叉概率）。
4.2 unlock 和 lock 必须成对：漏写一个就是生产事故
ReentrantLock 和 synchronized 最大的体验差异就是：synchronized 退出同步块自动释放锁，而 ReentrantLock 必须手动 unlock。忘写 unlock，或者因为异常跳过了 unlock，锁就永远不释放，后续所有线程全部阻塞，最终表现为：接口超时、线程池打满、服务不可用。
我的建议是形成肌肉记忆，代码一律这么写：
java复制lock.lock();
try {
// 业务逻辑
} finally {
lock.unlock();
}
tryLock 分支同样要注意：tryLock 返回 false 表示没拿到锁，此时绝对不能在 finally 里调用 unlock。正确写法是拿一个标志位记录是否拿到锁：
java复制boolean acquired = false;
try {
acquired = lock.tryLock(3, TimeUnit.SECONDS);
if (acquired) {
// 业务逻辑
} else {
// 降级处理
}
} finally {
if (acquired) {
lock.unlock();
}
}
这个“acquired 是否成立再决定要不要 unlock”的判断，是我在 code review 里反复强调的点。宁可多写一个 boolean，也不要冒险简化。
4.3 Condition 使用中的两个高频错误
用 Condition 翻车最多的是两个地方。
第一个是 await() 被中断后的处理。await 在等待时会释放锁，如果线程被 interrupt()，它会重新获得锁并抛出 InterruptedException。如果你在方法签名上直接 throws InterruptedException 抛出去，问题不大；但如果你捕获了异常然后继续执行下面的业务，就危险了——因为你无法确定业务逻辑是否安全地等到了正确的条件。正确的处理要么是向上抛，要么捕获后重新设置中断标志（Thread.currentThread().interrupt()）并在需要时终止业务流程。
第二个是 signal() 之后想当然地认为“被唤醒的线程立刻执行”。signal 只是把等待线程从条件队列移到 AQS 的同步队列，真正执行还要等当前线程释放锁。所以要写“唤醒后自己先退出临界区”的逻辑：在 signal 之后不要继续长时间操作共享数据，尽快 unlock，否则被唤醒线程还是要继续等待，等于白唤醒。
4.4 面试与选型高频考点：一张表说清
ReentrantLock 是 Java 面试的常客，围绕它的问题基本可以归纳为以下几个，我把要点列出来，面试前对照自查：
| 面试问题 | 核心答案要点 |
|---|---|
| ReentrantLock 和 synchronized 的区别 | 后者是 JVM 内置、自动释放；前者支持中断、超时、公平锁、多 Condition |
| 可重入怎么实现 | AQS 的 state 计数 + exclusiveOwnerThread 记录持有线程 |
| 公平锁和非公平锁区别 | tryAcquire 里多一个 hasQueuedPredecessors 判断 |
| AQS 是什么 | 同步器基础框架，state + CLH 队列 + CAS，Lock/Semaphore/CountDownLatch 都基于它 |
| 为什么默认非公平 | 减少 park/unpark 切换，竞争不激烈时吞吐更高 |
| await 和 wait 的区别 | await 基于 Condition，支持超时与中断，可多条件；wait 只支持单条件 |
我特别想提醒一点：回答这些知识点时，不要只背结论，最好能结合“为什么默认非公平”这种工程考量来谈。面试官问的是“知不知道”，但更想听的是“有没有真实做过多线程项目”的味道。比如你补一句“我们线上压测时非公平锁的 TPS 比公平锁高出约 15%，所以用默认配置”，整个答案的含金量完全不一样。
4.5 真正的选型速查：什么场景用什么
把前面的内容收敛成一张能直接抄作业的选型表。这是我在团队里贴过的版本，给刚入门的同事参考的：
- 简单互斥、能承受阻塞等待、不想手动解锁 —— 用
synchronized，省心不出错。 - 需要拿不到锁就做别的事 —— 用
tryLock()。 - 需要限制最大等待时间，避免线程永久阻塞 —— 用
tryLock(timeout, unit)，生产环境首选。 - 需要等待线程能被外部 interrupt 打断 —— 用
lockInterruptibly()。 - 需要多个条件精准唤醒 —— 用
ReentrantLock+ 多个Condition。 - 读多写少、读写分离 —— 考虑
ReentrantReadWriteLock或StampedLock，这是另一套 API，别和ReentrantLock混用。 - 只需要对单个变量原子更新 —— 优先
AtomicInteger这类原子类，无锁性能最好。
还有一个常被忽略的点：如果锁保护的临界区非常短，比如只有几行赋值，但并发量极高，那么 synchronized 在 JDK 8+ 的锁升级机制下性能可能反而更好，因为偏向锁/轻量级锁在低竞争时几乎零开销；而 ReentrantLock 每次都要走 AQS 逻辑，即便 tryAcquire 直接失败，也有不少额外操作。所以我不建议“无脑上 ReentrantLock”，一定先评估自己的等待模型和竞争烈度。
4.6 线上排查 Checklist：锁相关问题的排查步骤
最后分享一个我常用的排查清单，遇到锁导致的线上问题，按这个顺序走，基本能快速定位：
第一步，先看监控。线程池活跃线程是不是持续打满，接口 P99 延迟是不是突然飙升。如果是，优先怀疑死锁或过度等待。
第二步，抓线程 dump。连抓三次，每次间隔 3~5 秒，对比线程状态。WAITING 状态集中在同一个锁对象的 monitor 上，基本就是锁竞争或锁未释放。
第三步，看死锁报告。jstack 里有明确的 deadlock 段落最好，没有就搜索 blocked 和 waiting to lock，找出交叉引用关系。
第四步，查代码里所有 lock() 和 unlock() 的配对情况。重点看异常分支有没有漏解锁，tryLock 的返回值有没有被忽略，Condition 的 await 是否在 while 循环里。
第五步，如果确认是锁顺序导致的死锁，修代码时统一加锁顺序，或者用一个全局的锁顺序清单，把业务涉及的锁排好序，所有代码必须按编号从小到大获取，从机制上杜绝交叉。
这套流程我沿用多年，处理过好几次线上锁事故，每次都靠 dump 文件定位到具体线程和具体行号，效率很高。
回到最开始的问题：ReentrantLock 到底怎么实现线程安全的同步？答案可以浓缩成一句话——它借助 AQS 的 state 和等待队列，加上可重入计数、公平/非公平策略，把“谁能在什么条件下进入临界区”这件事变成了可精确控制的机制。而“可重入”这个特性，让它在嵌套调用场景下天然免疫死锁，这是名字里最不起眼却最实用的部分。
我个人在实际项目里的体会是，锁这个东西，越用越敬畏。synchronized 像自动挡，省心但控制有限；ReentrantLock 像手动挡，上限高但每一步都要踩准。真正常见的线上问题，往往不是锁选错了，而是没搞懂锁的等待模型就仓促上线。如果你读完这篇能记住一件事，我建议是：能用 tryLock(timeout) 的地方就别用 lock()，能写进 finally 的 unlock 别漏在任何分支后面。这两条守住了，并发代码的稳定性就赢了一大半。
最后再分享一个小技巧：写多线程代码时，把“锁”想象成一间只有一把钥匙的房间。谁拿着钥匙谁干活，别人只能排队；可重入的意思是同一个人拿钥匙进去后发现屋里还要再进一次，不需要重新出来排队，直接在墙上画个“正”字计数。你只要保证每进一次都划一笔、每出一趟都擦一笔，账本总是平的，就不会出事。这个类比虽然不是完全精确，但对我带的新人来说，比任何源码都更容易在脑子里建立正确的模型。