ReentrantLock 锁代码示例

### 使用 `ReentrantLock` 锁定 Java 代码块 为了确保多线程环境下的数据一致性，可以使用 `ReentrantLock` 来锁定特定的代码块。下面是一个具体的例子来展示如何利用 `ReentrantLock` 实现这一点。 ```java import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class Counter { private int value = 0; private final Lock lock = new ReentrantLock(); public void increment() { lock.lock(); try { value++; } finally { lock.unlock(); } } public int getValue() { return value; } } ``` 在这个示例中，定义了一个名为 `Counter` 的类，其中包含一个整型变量 `value` 和一个 `ReentrantLock` 类型的对象 `lock`。每当调用 `increment()` 方法时，会先尝试获取锁；如果成功，则增加计数值并最终释放锁[^1]。 值得注意的是，在实际开发过程中应当始终遵循良好的实践习惯——即在 `finally` 块内解锁，从而保证无论是否抛出了异常都能正常地释放资源[^3]。 此外，还可以设置不同的参数来自定义 `ReentrantLock` 行为，比如指定其采用公平或非公平模式工作： - **非公平锁**（默认行为）：允许插队现象的发生，提高吞吐量； - **公平锁**：按照请求顺序分配访问权限，减少饥饿问题发生的可能性。 对于大多数应用场景而言，默认配置已经足够满足需求。然而针对某些特殊场景，调整这些选项或许能够带来性能上的优化效果[^2]。

<think>好的，我现在要回答用户关于ReentrantLock锁定机制以及它在Java并发编程中如何与线程交互的问题。首先，我需要回忆一下ReentrantLock的基本概念和相关知识。根据提供的引用内容，ReentrantLock是Java中的一个可重入互斥锁，位于java.util.concurrent.locks包下。它是一个独占锁，意味着同一时间只能有一个线程持有该锁。 接下来，我需要解释ReentrantLock如何锁住线程。根据引用[3]，ReentrantLock的lock()方法调用了sync.lock()，而sync是内部类Sync的实例，Sync继承自AbstractQueuedSynchronizer（AQS）。这里可能需要区分公平锁和非公平锁的实现。根据引用[4]，非公平锁在lock时会先尝试通过CAS获取锁，如果失败则进入队列等待，而公平锁则直接按照请求顺序获取锁。 我需要详细说明lock()方法的工作流程，包括CAS操作、状态变量state的维护，以及线程阻塞和唤醒的机制。同时，要提到可重入性的实现，即同一个线程可以多次获取锁，每次获取state递增，释放时递减，直到为0才完全释放。 还需要对比公平锁和非公平锁的不同，如引用[4]提到的非公平锁在lock时会尝试两次获取锁，而公平锁严格按照队列顺序。要解释这种设计对性能的影响，比如非公平锁可能减少线程切换的开销，但可能导致饥饿现象。 另外，必须提到使用ReentrantLock时需要注意正确释放锁，通常在finally块中调用unlock()，以避免死锁。可能还需要简要比较ReentrantLock和synchronized关键字的区别，比如前者更灵活，支持尝试获取锁、可中断等特性。 现在需要组织这些信息，确保结构清晰，分步骤解释锁定机制，并结合引用内容。同时生成相关问题，可能涉及性能优化、应用场景、与synchronized的对比等。最后检查是否符合格式要求，如使用正确的中文，LaTeX公式格式无误，引用标识正确放置。</think>### ReentrantLock 锁定机制与线程交互详解 #### 1. 锁的基础实现原理 ReentrantLock 基于 **AQS（AbstractQueuedSynchronizer）** 框架实现，通过维护一个 **状态变量 `state`** 控制锁的获取与释放： - **`state=0`**：锁未被占用 - **`state>0`**：锁被占用，数值表示重入次数 锁的获取通过 **CAS（Compare-And-Swap）** 操作修改 `state` 值实现[^3]。例如，非公平锁的 `lock()` 方法会先尝试直接抢占锁： ```java // 非公平锁示例 final void lock() { if (compareAndSetState(0, 1)) // 尝试快速获取锁 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); // 进入AQS队列等待 } ``` #### 2. 线程阻塞与唤醒机制 当锁获取失败时，线程会被封装为 **Node 节点**加入 **CLH 队列**（双向链表结构的等待队列），并通过 `LockSupport.park()` 进入阻塞状态[^4]。锁释放时，AQS 会唤醒队列头部节点的线程重新尝试获取锁。 #### 3. 可重入性实现 通过记录当前持有锁的线程（`exclusiveOwnerThread`）和重入计数器实现： ```java // 重入示例 final boolean nonfairTryAcquire(int acquires) { Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { // 判断是否为当前线程 setState(c + acquires); // 增加重入次数 return true; } return false; } ``` #### 4. 公平锁 vs 非公平锁 | 类型 | 实现特点 | 性能影响 | |------------|--------------------------------------------------------------------------|------------------------------| | **非公平锁** | 线程可直接插队尝试获取锁（最多尝试2次CAS） | 吞吐量高，可能产生线程饥饿 | | **公平锁** | 严格按照CLH队列顺序获取锁 | 响应时间稳定，吞吐量较低 | #### 5. 标准使用模板 必须配合 `try-finally` 保证锁的释放： ```java ReentrantLock lock = new ReentrantLock(); public void safeMethod() { lock.lock(); // 可替换为tryLock()等变体 try { // 临界区代码 } finally { lock.unlock(); // 确保任何情况都释放锁 } } ``` #### 6. 与synchronized关键字的对比 | 特性 | ReentrantLock | synchronized | |-----------------------|----------------------------------------|-------------------------| | 锁获取方式 | 显式调用 `lock()/unlock()` | 隐式通过代码块 | | 可中断性 | 支持 `lockInterruptibly()` | 不支持 | | 超时机制 | 支持 `tryLock(long timeout, TimeUnit)` | 不支持 | | 公平性控制 | 可配置公平/非公平模式 | 完全非公平 | | 条件变量 | 支持多个Condition | 单个内置条件 |