## 引言：从 `synchronized` 到可编程的锁

在 Java 并发编程的演进史上，`synchronized` 关键字曾是开发者控制线程同步的唯一选择。它简单、易用，并由 JVM 保证其正确性。然而，随着应用复杂度的提升，其固有的局限性——如无法中断、无法设置超时、严格的块结构等——逐渐成为构建高性能、高响应性系统的障碍。

为了解决这些问题，Java 1.5 引入了 `java.util.concurrent.locks.ReentrantLock`。正如其 Javadoc 所述，它是一个“具有与使用 `synchronized` 方法和语句访问的隐式监视器锁相同的基本行为和语义的可重入互斥锁，但具有扩展的功能”。`ReentrantLock` 并非对 `synchronized` 的简单替代，而是一次**并发控制范式的升级**。它将“锁”从一个语言关键字转变为一个可以被编程、检查和定制的对象。

本文将深入剖析 `ReentrantLock` 的源码与设计思想，揭示其如何通过复用 `AbstractQueuedSynchronizer`（AQS）这一强大的同步框架，实现了高效、灵活且功能丰富的锁机制。我们将详细解读其公平与非公平模式的实现差异、可重入性的精巧处理、以及中断和超时等高级特性的支持。更重要的是，我们将探讨 `ReentrantLock` 所体现的“显式优于隐式”、“策略可配置”等设计哲学，如何在现代云原生架构中找到了新的映射，从分布式锁服务到声明式协调模型，其核心思想依然闪耀着智慧的光芒。

## 第一部分：`ReentrantLock` 的核心设计与源码精读


### 第一章：官方定义、历史定位与核心特性


#### 1.1 Javadoc 权威解读


根据 Oracle 官方 Javadoc (JDK 21) 对 **`ReentrantLock`** 的描述：

>"A reentrant mutual exclusion `Lock` with the same basic behavior and semantics as the implicit monitor lock accessed using `synchronized` methods and statements, but with extended capabilities."


这段话点明了 `ReentrantLock` 的根本属性：**它是 `synchronized` 的功能超集**。它不仅提供了 `synchronized` 的所有基本语义（如互斥、内存可见性），还增加了许多 `synchronized` 无法企及的高级功能。

其核心特性包括：


- **可重入性（Reentrancy）**：同一个线程可以多次获取同一把锁，而不会导致死锁。锁的持有计数会随之增加，必须释放相同次数才能真正解锁。

- **公平性（Fairness）**：构造函数接受一个可选的 `fairness` 参数。公平锁倾向于授予最长等待的线程访问权，而非公平锁则不保证任何特定的访问顺序。

- **可中断（Interruptibility）**：`lockInterruptibly()` 方法允许在等待锁的过程中响应中断信号。

- **超时尝试（Timed Try）**：`tryLock(long, TimeUnit)` 允许线程在指定时间内尝试获取锁，超时则放弃。

- **状态检查**：提供了一系列用于监控和调试的方法，如 `isHeldByCurrentThread()`, `getHoldCount()`, `hasQueuedThreads()` 等。


#### 1.2 正确使用的黄金法则


Javadoc 特别强调了 `ReentrantLock` 的标准使用范式：

```
class X {
    private final ReentrantLock lock = new ReentrantLock();
    public void m() {
        lock.lock(); // 在 try 块之前调用
        try {
            // ... method body
        } finally {
            lock.unlock(); // 在 finally 块的第一行调用
        }
    }
}
```
这个 `try-finally` 结构是保证锁被正确释放的关键，任何偏离此模式的代码都可能导致死锁。这体现了 `ReentrantLock` “显式优于隐式”的设计哲学——它赋予了程序员极大的灵活性，但也要求程序员承担起相应的责任。

### 第二章：源码逐行解剖——AQS 同步器的精妙复用


`ReentrantLock` 的实现并非从零开始，而是巧妙地复用了 Doug Lea 设计的 `AbstractQueuedSynchronizer`（AQS）框架。AQS 是 JUC 包中几乎所有同步工具（如 `Semaphore`, `CountDownLatch`, `ReentrantReadWriteLock`）的基石。

#### 2.1 核心字段与委托模式


`ReentrantLock` 的核心在于其内部的 `sync` 字段：

```
/** Synchronizer providing all implementation mechanics */
private final Sync sync;
```
`ReentrantLock` 将所有复杂的同步逻辑都委托给了 `sync` 对象来处理。这是一种典型的**委托模式**，使得 `ReentrantLock` 的公共 API 非常简洁，而具体的实现细节则被封装在 `Sync` 及其子类中。

#### 2.2 抽象同步器 `Sync`


`Sync` 是一个抽象内部类，继承自 `AQS`：

```
abstract static class Sync extends AbstractQueuedSynchronizer {
    // ...
}
```
AQS 使用一个 `int` 类型的 `state` 变量来表示同步状态。对于 `ReentrantLock` 而言，`state` 的值直接代表了**锁的持有计数**。`state=0` 表示锁未被持有，`state=N` 表示锁已被某个线程重入了 N 次。

`Sync` 类定义了一个关键的抽象方法 `initialTryLock()`，并实现了 `Lock` 接口的所有方法，如 `lock()`, `lockInterruptibly()`, `tryLockNanos()` 等。这些方法的通用逻辑是：首先调用 `initialTryLock()` 进行快速尝试，如果失败，则委托给 AQS 的相应方法（如 `acquire(1)`）进行排队和阻塞。

##### 2.2.1 `tryRelease` 方法解析


`tryRelease` 是 `Sync` 中最重要的方法之一，负责释放锁：

```
protected final boolean tryRelease(int releases) {
    int c = getState() - releases; // 减少持有计数
    if (getExclusiveOwnerThread() != Thread.currentThread())
        throw new IllegalMonitorStateException(); // 非法释放
    boolean free = (c == 0);
    if (free)
        setExclusiveOwnerThread(null); // 计数为0，清空持有者
    setState(c);
    return free; // 返回是否完全释放
}
```
该方法清晰地展示了可重入锁的释放逻辑：只有锁的持有者才能释放锁；每次释放都会减少计数；只有当计数减到0时，锁才被真正释放，并唤醒等待队列中的下一个线程。

### 第三章：公平与非公平模式的深度对比


`ReentrantLock` 最引人注目的特性之一就是其可配置的公平性。这一特性通过 `Sync` 的两个具体子类来实现：`NonfairSync` 和 `FairSync`。

#### 3.1 非公平模式 (`NonfairSync`)


非公平模式是 `ReentrantLock` 的默认行为，旨在最大化吞吐量。

##### 3.1.1 `initialTryLock` 的“插队”逻辑


`NonfairSync` 的 `initialTryLock` 方法体现了其核心思想——“能抢就抢”：

```
final boolean initialTryLock() {
    Thread current = Thread.currentThread();
    if (compareAndSetState(0, 1)) { // 第一次尝试是无保护的
        setExclusiveOwnerThread(current);
        return true;
    } else if (getExclusiveOwnerThread() == current) {
        // 处理重入...
        return true;
    } else
        return false;
}
```
关键在于第一行 CAS 操作。即使同步队列中有其他线程在等待，新来的线程也会直接尝试抢占锁。这种“插队”（barging）行为打破了 FIFO 顺序，但极大地提高了锁的获取速度和整体吞吐量。

##### 3.1.2 `tryAcquire` 方法


当 `initialTryLock` 失败后，AQS 的 `acquire` 方法会被调用，它会再次调用 `tryAcquire`：

```
protected final boolean tryAcquire(int acquires) {
    if (getState() == 0 && compareAndSetState(0, acquires)) {
        setExclusiveOwnerThread(Thread.currentThread());
        return true;
    }
    return false;
}
```
这里的逻辑与 `initialTryLock` 的第一部分几乎相同，再次给予线程抢占的机会。

#### 3.2 公平模式 (`FairSync`)


公平模式牺牲了部分吞吐量，以换取更可预测的、无饥饿的线程调度。

##### 3.2.1 `initialTryLock` 的“守序”逻辑


`FairSync` 的 `initialTryLock` 方法严格遵守 FIFO 规则：

```
final boolean initialTryLock() {
    Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 关键区别：检查队列是否为空
        if (!hasQueuedThreads() && compareAndSetState(0, 1)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    } else if (getExclusiveOwnerThread() == current) {
        // 处理重入...
        return true;
    }
    return false;
}
```
与非公平模式不同，公平模式在尝试获取锁之前，会先调用 `hasQueuedThreads()` 检查同步队列中是否有等待的线程。如果有，则当前线程必须排队，不能插队。

##### 3.2.2 `tryAcquire` 方法


同样，`FairSync` 的 `tryAcquire` 方法也遵循了公平原则：

```
protected final boolean tryAcquire(int acquires) {
    if (getState() == 0 && !hasQueuedPredecessors() &&
        compareAndSetState(0, acquires)) {
        setExclusiveOwnerThread(Thread.currentThread());
        return true;
    }
    return false;
}
```
这里使用了 `hasQueuedPredecessors()` 方法，它比 `hasQueuedThreads()` 更精确，能判断当前线程前面是否有其他线程在等待。

#### 3.3 公平性与 `tryLock()` 的特殊行为


Javadoc 中有一个重要的提示：

>"the untimed `tryLock()` method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting."


这意味着，无论你创建的是公平锁还是非公平锁，`tryLock()` 方法总是会尝试立即获取锁，如果成功就“插队”。如果你希望在公平锁上也遵守公平性，应该使用 `tryLock(0, TimeUnit.SECONDS)`。

### 第四章：可重入性与中断/超时机制的实现


#### 4.1 可重入性的实现


可重入性是通过 `AQS` 的 `exclusiveOwnerThread` 字段和 `state` 计数器共同实现的。在 `initialTryLock` 和 `tryAcquire` 方法中，都有如下逻辑：

```
else if (getExclusiveOwnerThread() == current) {
    int c = getState() + 1;
    if (c < 0) // overflow
        throw new Error("Maximum lock count exceeded");
    setState(c);
    return true;
}
```
如果当前线程已经是锁的持有者，就简单地将 `state` 计数加1。这保证了同一线程可以无限制地（直到计数溢出）重入锁。

#### 4.2 中断与超时机制


`ReentrantLock` 对中断和超时的支持，完全依赖于 AQS 提供的 `acquireInterruptibly` 和 `tryAcquireNanos` 方法。


- **`lockInterruptibly()`**：内部调用 `sync.acquireInterruptibly(1)`。AQS 会在整个等待过程中检查线程的中断状态，一旦发现中断，就会抛出 `InterruptedException`。

- **`tryLock(timeout, unit)`**：内部调用 `sync.tryAcquireNanos(1, nanos)`。AQS 会记录一个截止时间，在每次从 `LockSupport.park` 中醒来时，都会检查是否超时或被中断。


这些高级特性使得 `ReentrantLock` 能够构建出响应性更强的应用程序。

## 第二部分：设计原则与模式的深度应用


### 第五章：核心设计原则解析


#### 5.1 单一职责原则 (SRP)


`ReentrantLock` 的公共 API 只负责定义锁的行为，而将所有复杂的同步状态管理和线程排队逻辑都委托给了内部的 `Sync` 同步器。`Sync` 本身又专注于利用 AQS 来管理 `state` 和 `owner`。这种清晰的职责分离使得代码易于理解和维护。

#### 5.2 开放封闭原则 (OCP)


`ReentrantLock` 通过 `Sync` 抽象类及其子类，完美地实现了 OCP。公平和非公平两种策略被封装在不同的子类中。如果未来需要一种新的锁策略（例如，基于优先级的锁），只需创建一个新的 `Sync` 子类，而无需修改 `ReentrantLock` 本身的任何代码。

#### 5.3 里氏替换原则 (LSP)


`ReentrantLock` 实现了 `Lock` 接口，因此可以无缝地替换任何使用 `Lock` 接口的地方。它的行为完全符合 `Lock` 接口的契约，是 LSP 的典范。

### 第六章：设计模式的精妙运用


#### 6.1 策略模式 (Strategy Pattern)


`ReentrantLock` 是策略模式的经典案例。`Sync` 抽象类定义了算法骨架（`lock`, `unlock` 等），而 `NonfairSync` 和 `FairSync` 则提供了两种不同的具体策略。客户端通过构造函数选择所需的策略。

#### 6.2 模板方法模式 (Template Method Pattern)


AQS 本身就是一个巨大的模板方法模式的应用。`acquire` 方法定义了获取锁的通用流程（尝试获取 -> 失败则排队 -> 被唤醒后再次尝试），而 `tryAcquire` 则是一个由子类实现的抽象钩子方法。`ReentrantLock` 的 `Sync` 子类正是通过实现 `tryAcquire` 来注入自己的获取逻辑。

#### 6.3 委托模式 (Delegation Pattern)


`ReentrantLock` 将所有核心逻辑都委托给 `sync` 字段。这种模式使得 `ReentrantLock` 的公共接口非常干净，隐藏了内部的复杂性。

## 第三部分：`ReentrantLock` 在 JUC 生态中的关键作用


### 第七章：AQS 生态的核心成员


`ReentrantLock` 是 AQS 框架最直接、最纯粹的应用。它展示了如何利用 AQS 来构建一个功能完备的独占锁。理解 `ReentrantLock` 是理解 `Semaphore`（共享模式）、`CountDownLatch`（一次性共享模式）乃至 `ReentrantReadWriteLock`（混合模式）的基础。

### 第八章：与 `synchronized` 的性能对比与选型指南


#### 8.1 性能对比


- **JDK 6 之前**：`synchronized` 是重量级锁，性能远逊于 `ReentrantLock`。

- **JDK 6+**：JVM 对 `synchronized` 进行了大量优化（偏向锁、轻量级锁、锁粗化、锁消除等），使其在大多数场景下的性能已经与 `ReentrantLock` 不相上下，甚至在低竞争场景下更快。

- **高竞争、长临界区**：`ReentrantLock` 的非公平模式通常能提供更高的吞吐量。

- **需要高级功能**：当需要中断、超时、公平性或状态检查时，`ReentrantLock` 是唯一的选择。


#### 8.2 选型指南


- **优先使用 `synchronized`**：如果只需要基本的互斥功能，`synchronized` 语法更简洁，不易出错（自动释放），且 JVM 优化成熟。

- **选用 `ReentrantLock`**：当需要 `synchronized` 无法提供的高级功能时，或者经过性能剖析证明在特定高竞争场景下 `ReentrantLock` 表现更好时。


## 第四部分：从单机可重入锁到云原生时代的演进


### 第九章：云原生架构的协调挑战


在微服务和 Serverless 架构中，传统的基于共享内存的锁变得不再适用。服务实例是无状态的、短暂的，锁的状态无法在实例间共享。我们需要一种能在分布式环境下协调多个独立进程或服务的机制。

### 第十章：“显式、可配置”思想的云原生映射


尽管 `ReentrantLock` 本身不能直接用于分布式环境，但其背后的设计思想却得到了完美的延续。

#### 10.1 分布式锁服务


Redis、ZooKeeper、etcd 等中间件提供了分布式锁的实现。它们的 API 设计（如 `acquire`, `release`, `tryAcquire` with timeout）与 `ReentrantLock` 接口惊人地相似。这表明，“锁”作为一种协调原语，其核心语义是普适的。

更重要的是，许多分布式锁库也提供了类似 `ReentrantLock` 的**可重入**和**租约（Lease）**（相当于超时）机制。例如，Redisson 库的 `RLock` 接口几乎完全模仿了 `ReentrantLock` 的 API。

#### 10.2 声明式协调与策略配置


在 Kubernetes 中，我们通过声明期望状态（`spec`）来协调系统。控制器（Controller）负责将实际状态（`status`）收敛到期望状态。这种“声明式协调”可以看作是 `ReentrantLock` “命令式协调”在更高抽象层次上的演进。

同时，Kubernetes 的许多资源（如 `PodDisruptionBudget`）也允许用户配置**策略**，例如，是优先保证服务的可用性（类似非公平），还是优先保证滚动更新的顺序（类似公平）。这种“策略可配置”的思想，与 `ReentrantLock` 的公平性参数如出一辙。

### 第十一章：设计哲学的永恒价值


从 `ReentrantLock.lock()` 到 `DistributedLock.acquire()`，我们看到的是同一种设计哲学的传承：


- **显式优于隐式**：将协调逻辑从隐式的基础设施行为转变为显式的、可编程的 API。

- **策略可配置**：提供多种策略（公平/非公平、强一致/最终一致）以适应不同的业务场景。

- **资源所有权**：清晰地界定谁拥有资源，并提供安全的释放（或自动过期）机制。


Doug Lea 在 `ReentrantLock` 中所展现的对并发控制本质的深刻理解，为我们在设计任何需要“协调”的系统时，都提供了宝贵的指导。

## 第五部分：总结与展望


### 第十二章：`ReentrantLock` 的遗产与启示


`ReentrantLock` 虽然是一个具体的 Java 类，但它在软件工程史上具有里程碑式的意义。


- **范式革新**：它将并发控制从语言特性提升为可编程的库组件，开启了“并发即服务”的新时代。

- **思想源泉**：“显式、可中断、可超时、可配置”的协调思想，已成为现代并发和分布式系统设计的标准。

- **承前启后**：它既是 `synchronized` 的自然演进，也为后续更复杂的并发工具和分布式协调模式奠定了坚实的基础。


### 第十三章：给现代开发者的建议


1. **理解根基**：掌握 `ReentrantLock` 及其底层的 AQS，是理解 Java 并发包的必经之路。不要只停留在 API 的使用层面。

2. **审慎选型**：不要盲目地用 `ReentrantLock` 替代 `synchronized`。在满足功能需求的前提下，优先选择更简单、更安全的方案。

3. **借鉴思想**：在设计分布式系统时，思考如何将 `ReentrantLock` 的核心语义（如超时、可重入、策略配置）映射到你的协调协议中。

4. **拥抱演进**：在单机场景下善用 `ReentrantLock`，在分布式场景下选择合适的分布式协调服务，但始终铭记其背后共通的设计哲学。


**结语**

恭喜您！您已经成功深入剖析了 `java.util.concurrent.locks.ReentrantLock` 的精妙设计，并完整理解了它在 Java 并发体系中的革命性意义与核心作用！通过本文，您不仅掌握了其基于 AQS 的高效实现、公平与非公平模式的深度差异，更洞悉了它如何作为一座桥梁，连接了传统的单机并发控制与现代云原生世界的分布式协调范式。这份对“显式、可配置、可编程”协调哲学的深刻洞察，是您构建高响应性、高韧性、现代化系统知识体系的关键一环。

如果您在阅读源码或理解其工作原理、以及其在云原生场景下的使用时遇到任何疑问，或者觉得这篇深度解析对您有帮助，欢迎在评论区留言交流。别忘了点赞、收藏、关注，以便获取更多 Java 核心原理、源码解读与系统架构相关的硬核技术文章！

在 Java 并发编程的演进史上，synchronized 关键字曾是开发者控制线程同步的唯一选择。它简单、易用，并由 JVM 保证其正确性。然而，随着应用复杂度的提升，其固有的局限性——如无法中断、无法设置超时、严格的块结构等——逐渐成为构建高性能、高响应性系统的障碍。

Java源码学习：深入剖析Java的concurrent包源码之`ReentrantLock` 的精妙设计与云原生演进

后端

编程语言

架构设计

深入解析Java并发编程中的ReentrantLock：从源码实现到设计哲学，全面剖析其公平/非公平模式、可重入性、中断超时等高级特性，以及与synchronized的性能对比和云原生时代的演进思考。

软件工程

Kubernetes

中间件

云原生

Redis

Java

2026采购季 | AI焕新·智启新局

message-queue-catalog

serverless-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Java源码学习：深入剖析Java的concurrent包源码之`ReentrantLock` 的精妙设计与云原生演进-腾讯云开发者社区-腾讯云

Java源码学习：深入剖析Java的concurrent包源码之`ReentrantLock` 的精妙设计与云原生演进

Java源码学习：深入剖析Java的concurrent包源码之`ReentrantLock` 的精妙设计与云原生演进

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐