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


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

为了解决这些问题，Java 1.5引入了`java.util.concurrent.locks`包，其中`ReentrantLock`、`ReentrantReadWriteLock`和`LockSupport`构成了现代Java并发控制的核心基石。它们并非对`synchronized`的简单替代，而是一次**并发控制范式的升级**。这些工具将“锁”从一个语言关键字转变为一个可以被编程、检查和定制的对象，赋予了开发者前所未有的灵活性和控制力。

本文将深入剖析这三个核心组件的源码、设计思想和使用场景，揭示它们如何协同工作，构建出高效、灵活且功能丰富的并发系统。我们将探讨Doug Lea及其团队在JSR-166中所展现的卓越工程智慧，并思考这些经典设计在现代云原生架构中的深远影响。

## 第一部分：`ReentrantLock`——可重入互斥锁的典范


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


根据Oracle官方Javadoc对 **`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()`等。


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


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`）的基石。

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


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

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

#### 抽象同步器`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)`）进行排队和阻塞。

##### `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`。

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


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

##### `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顺序，但极大地提高了锁的获取速度和整体吞吐量。

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


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

##### `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()`检查同步队列中是否有等待的线程。如果有，则当前线程必须排队，不能插队。

#### 公平性与`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)`。

## 第二部分：`ReentrantReadWriteLock`——读写分离的并发优化利器


### 第四章：读写锁的设计理念与核心特性


`ReentrantReadWriteLock`是对`ReentrantLock`思想的进一步扩展，它基于一个重要的观察：**在很多场景下，数据的读取操作远多于写入操作，且多个读取操作之间是互不冲突的**。

其官方文档明确指出：

>"This class has the following properties: ... This lock allows both readers and writers to reacquire read or write locks in the style of a `ReentrantLock`."


它的核心特性完美契合了这一理念：


- **读写分离**：允许多个读线程同时持有读锁，但写锁是独占的。读锁和写锁互斥。

- **可重入性**：读线程和写线程都可以重入自己持有的锁。

- **锁降级**：写线程可以在持有写锁的同时获取读锁，然后释放写锁，从而将写锁“降级”为读锁。这是实现“先检查后更新”模式的关键。**注意：锁升级（从读锁到写锁）是不允许的，会导致死锁**。

- **公平性策略**：同样支持公平和非公平两种模式，但其公平策略更为复杂，需要平衡读线程和写线程的等待。


### 第五章：源码精读——基于AQS的共享/独占模式


`ReentrantReadWriteLock`的实现比`ReentrantLock`更为复杂，因为它需要同时管理两种类型的锁：共享的读锁和独占的写锁。它通过扩展`AbstractQueuedLongSynchronizer`（AQLS，AQS的64位版本）来实现。

#### 同步状态的巧妙编码


`ReentrantReadWriteLock`的精华在于其对同步状态`state`（一个`long`值）的编码方式：

```
// Lock state is logically divided into two ints:
// The lower one representing the exclusive (writer) lock hold count,
// and the upper the shared (reader) hold count.
static final int SHARED_SHIFT = 32;
static final long EXCLUSIVE_MASK = (1L << SHARED_SHIFT) - 1;

static int sharedCount(long c) { return (int)(c >>> SHARED_SHIFT); }
static int exclusiveCount(long c) { return (int)(c & EXCLUSIVE_MASK); }
```
高32位存储**共享的读锁计数**，低32位存储**独占的写锁计数**。这种设计使得读写锁的状态可以用一个原子变量来表示，极大地简化了并发控制。

#### 读锁与写锁的实现


`ReentrantReadWriteLock`内部定义了两个公有静态内部类：`ReadLock`和`WriteLock`，它们都实现了`Lock`接口。


- **`WriteLock`**：其`lock()`和`unlock()`方法分别委托给`sync.acquire(1)`和`sync.release(1)`，这与`ReentrantLock`完全一致，走的是AQS的**独占模式**。

- **`ReadLock`**：其`lock()`和`unlock()`方法则委托给`sync.acquireShared(1)`和`sync.releaseShared(1)`，走的是AQS的**共享模式**。


#### 复杂的重入计数管理


由于允许多个读线程同时存在，`ReentrantReadWriteLock`必须为每个线程单独维护其读锁的重入计数。这是通过`ThreadLocal`来实现的：

```
static final class HoldCounter {
    int count; // initially 0
    final long tid = LockSupport.getThreadId(Thread.currentThread());
}

private transient ThreadLocalHoldCounter readHolds;
```
为了优化性能，它还使用了缓存机制（`cachedHoldCounter`）和针对第一个读线程的特殊优化（`firstReader`），避免了在无竞争场景下频繁访问`ThreadLocal`的开销。

### 第六章：经典使用场景——缓存与集合的并发优化


`ReentrantReadWriteLock`最经典的使用场景是在读多写少的数据结构上，例如缓存或大型集合。

#### 缓存的锁降级模式


官方文档给出了一个完美的示例——带失效机制的缓存：

```
void processCachedData() {
    rwl.readLock().lock();
    if (!cacheValid) {
        // 释放读锁，再获取写锁
        rwl.readLock().unlock();
        rwl.writeLock().lock();
        try {
            if (!cacheValid) {
                data = ...;
                cacheValid = true;
            }
            // 锁降级：在释放写锁前获取读锁
            rwl.readLock().lock();
        } finally {
            rwl.writeLock().unlock(); // 释放写锁，但仍持有读锁
        }
    }
    try {
        use(data);
    } finally {
        rwl.readLock().unlock();
    }
}
```
这个例子展示了锁降级的必要性：在更新数据后，我们希望在不释放锁的情况下，让后续的读操作能够立即看到新数据。直接释放写锁再获取读锁可能会导致在间隙期间数据再次失效。

#### 并发集合的读写分离


对于一个预期会被大量读取但偶尔更新的`Map`，使用`ReentrantReadWriteLock`可以显著提高并发性能：

```
class RWDictionary {
    private final Map<String, Data> m = new TreeMap<>();
    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    private final Lock r = rwl.readLock();
    private final Lock w = rwl.writeLock();

    public Data get(String key) {
        r.lock();
        try { return m.get(key); }
        finally { r.unlock(); }
    }

    public Data put(String key, Data value) {
        w.lock();
        try { return m.put(key, value); }
        finally { w.unlock(); }
    }
}
```
在这个例子中，多个线程可以同时调用`get`方法，而不会相互阻塞，极大地提升了读操作的吞吐量。

## 第三部分：`LockSupport`——线程阻塞与唤醒的底层基石


### 第七章：`LockSupport`的角色与重要性


如果说`ReentrantLock`和`ReentrantReadWriteLock`是面向开发者的高级并发工具，那么`LockSupport`就是它们共同依赖的**底层基石**。它提供了一套最基本的线程阻塞（park）和唤醒（unpark）原语。

虽然上传的文件内容主要聚焦于`ReentrantReadWriteLock`，但我们可以从其源码中窥见`LockSupport`的身影：

```
final long tid = LockSupport.getThreadId(Thread.currentThread());
```
这里使用了`LockSupport.getThreadId`来获取线程ID，这是一种比直接持有`Thread`引用更轻量、更能避免内存泄漏的方式。

`LockSupport`的核心方法是：


- `park()` / `park(Object blocker)`：阻塞当前线程。

- `unpark(Thread thread)`：唤醒指定的线程。


### 第八章：`LockSupport`与AQS的协同工作


AQS框架正是基于`LockSupport`来实现线程的阻塞和唤醒的。


- 当一个线程尝试获取锁失败时，AQS会将其封装成一个节点加入同步队列，然后调用`LockSupport.park(this)`使其进入等待状态。

- 当锁被释放时，AQS会从队列中取出下一个合适的节点（线程），并调用`LockSupport.unpark(node.thread)`来唤醒它。


`LockSupport`的`park/unpark`模型相比传统的`Object.wait/notify`模型有巨大优势：


- **解耦**：`unpark`可以在`park`之前调用，许可（permit）会被保存下来。这解决了`wait/notify`中因时序问题导致信号丢失的经典难题。

- **精准**：`unpark`可以精确地唤醒指定的线程，而`notify`只能随机唤醒一个等待线程。

- **不依赖于监视器**：`park/unpark`不需要在`synchronized`块中调用，使用更加灵活。


正是`LockSupport`提供的这种强大而可靠的底层原语，才使得`ReentrantLock`和`ReentrantReadWriteLock`等高级同步工具的实现成为可能。

## 第四部分：设计原则、模式与现代演进


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


这三个组件共同体现了软件工程中的多项核心原则：


- **单一职责原则 (SRP)**：`ReentrantLock`负责互斥，`ReentrantReadWriteLock`负责读写分离，`LockSupport`负责底层线程调度，职责清晰。

- **开放封闭原则 (OCP)**：通过`Sync`抽象类和公平/非公平子类，`ReentrantLock`和`ReentrantReadWriteLock`的策略可以轻松扩展。

- **组合优于继承**：`ReentrantReadWriteLock`通过组合`ReadLock`和`WriteLock`两个对象，而不是通过复杂的继承关系，来提供两种锁。


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


- **模板方法模式**：AQS是模板方法模式的极致体现。`acquire`和`release`等方法定义了算法骨架，而`tryAcquire`、`tryRelease`等钩子方法则由子类（如`ReentrantLock.Sync`）去实现具体逻辑。

- **策略模式**：公平与非公平模式是策略模式的直接应用。

- **享元模式/对象池**：`ReentrantReadWriteLock`中对`HoldCounter`的缓存复用，是一种轻量级的对象池思想，用于优化性能。


### 第十一章：从单机锁到云原生时代的演进


尽管这些工具本身是为单机多线程环境设计的，但其背后的设计思想在分布式系统中依然闪耀着光芒。


- **`ReentrantLock`的思想**：在Redis、ZooKeeper等中间件中都有对应的分布式锁实现，它们同样提供了可重入、可超时、可中断等特性。

- **`ReentrantReadWriteLock`的思想**：在数据库和分布式存储系统中，读写锁的概念被广泛应用，用于协调对共享资源的并发访问。

- **`LockSupport`的思想**：在异步编程和响应式系统中，基于回调和Future/Promise的协调机制，可以看作是`park/unpark`模型在更高层次上的抽象。


## 总结与展望


`ReentrantLock`、`ReentrantReadWriteLock`和`LockSupport`共同构成了Java并发编程的坚实基础。它们不仅是强大的工具，更是卓越设计思想的载体。理解它们的内部机制和设计哲学，对于任何希望编写高性能、高可靠并发程序的开发者来说，都是至关重要的。

在现代开发中，我们或许更多地会使用更高层次的并发工具（如`CompletableFuture`、响应式流），但这些工具的底层依然离不开这些基石。更重要的是，它们所倡导的“显式、可配置、可组合”的设计思想，已经超越了Java语言本身，成为构建任何复杂、可靠系统的通用准则。

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

Java源码分析：`ReentrantLock`、`ReentrantReadWriteLock`与`LockSupport`深度解析

编程语言

后端

算法

Java并发编程核心组件解析：深入ReentrantLock、ReentrantReadWriteLock和LockSupport的设计原理与使用场景，揭示JUC包如何通过AQS框架实现高效线程同步，探讨公平锁与非公平锁的性能差异，以及读写锁在缓存优化中的应用技巧。

分布式存储

软件工程

数据结构

中间件

数据库

云原生

Redis

Java

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

llmsgw

message-queue-catalog

tencentdb-catalog

对象存储COS新用户低至1元！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯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源码分析：`ReentrantLock`、`ReentrantReadWriteLock`与`LockSupport`深度解析-腾讯云开发者社区-腾讯云

Java源码分析：`ReentrantLock`、`ReentrantReadWriteLock`与`LockSupport`深度解析

Java源码分析：`ReentrantLock`、`ReentrantReadWriteLock`与`LockSupport`深度解析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐