LockSupport.park()是否会释放锁资源吗

发布时间：2021-12-21 09:17:49 作者：柒染
来源：亿速云阅读：245

# LockSupport.park()是否会释放锁资源吗

## 引言

在多线程编程中，线程的阻塞与唤醒是核心机制之一。Java提供了多种线程控制工具，其中`LockSupport`作为底层工具类，其`park()`和`unpark()`方法提供了更灵活的线程阻塞与唤醒能力。一个常见的问题是：**当调用`LockSupport.park()`时，当前线程持有的锁资源是否会被释放？**本文将深入分析这一机制，结合JVM实现原理、锁资源管理以及实际案例进行全面探讨。

---

## 一、LockSupport基础概念

### 1.1 LockSupport简介
`LockSupport`是Java并发包(`java.util.concurrent.locks`)中的工具类，主要提供线程阻塞和唤醒的基础操作。与`synchronized`或`Object.wait()`不同，它不需要依赖监视器锁，可直接操作线程。

#### 核心方法：
- `park()`：阻塞当前线程
- `unpark(Thread thread)`：唤醒指定线程

### 1.2 park()的行为特征
调用`park()`时，线程会进入`WTING`状态，直到以下条件之一满足：
1. 其他线程调用`unpark()`唤醒该线程
2. 线程被中断（`interrupt()`）
3. 虚假唤醒（spurious wakeup）

---

## 二、锁资源的定义与分类

### 2.1 什么是锁资源？
在Java中，锁资源通常指：
- **内置锁（synchronized）**：通过对象监视器（Monitor）实现
- **显式锁（ReentrantLock等）**：基于AQS实现的锁

### 2.2 锁的持有与释放
- 锁的释放必须显式或隐式地通过代码控制（如`synchronized`块结束或`lock.unlock()`）
- **关键点**：锁释放是主动行为，与线程状态变化无直接关联

---

## 三、park()与锁资源的关系

### 3.1 直接结论
**`LockSupport.park()`不会释放线程已经持有的任何锁资源**。这是因为：
1. `park()`仅是线程调度层面的阻塞，不涉及锁语义
2. 锁资源的管理独立于线程状态（如`WTING`/`BLOCKED`）

### 3.2 与wait()的对比
| 行为                | Object.wait()                  | LockSupport.park()          |
|---------------------|--------------------------------|-----------------------------|
| **是否需要锁**       | 必须持有监视器锁               | 不需要                      |
| **是否释放锁**       | 调用时会释放锁                 | 不释放任何锁                |
| **唤醒条件**         | notify()/notifyAll()或中断     | unpark()或中断              |

### 3.3 JVM层面的实现
通过OpenJDK源码分析（以HotSpot为例）：
- `park()`调用最终映射到`os::PlatformEvent::park()`，仅涉及线程状态修改
- 锁资源（如Monitor）的记录保存在对象头或AQS结构中，不受线程阻塞影响

---

## 四、典型场景验证

### 4.1 场景1：park()与synchronized锁
```java
public class ParkWithSynchronized {
    private static final Object lock = new Object();

    public static void main(String[] args) {
        synchronized (lock) {
            System.out.println("线程持有锁后park");
            LockSupport.park(); // 线程阻塞，但锁未释放
            System.out.println("线程被唤醒");
        }
    }
}

现象：其他线程尝试获取lock时会永久阻塞，证明锁未被释放。

4.2 场景2：park()与ReentrantLock

public class ParkWithReentrantLock {
    private static final ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) {
        lock.lock();
        try {
            System.out.println("线程持有ReentrantLock后park");
            LockSupport.park(); 
        } finally {
            lock.unlock(); // 若park()不返回，锁永远不会释放
        }
    }
}

结论：显式锁同样不会被自动释放。

五、可能引发的死锁问题

5.1 典型死锁案例

// 线程A
synchronized (lock) {
    LockSupport.park(); // 阻塞但不释放锁
}

// 线程B
synchronized (lock) {
    LockSupport.unpark(threadA); // 永远无法获取锁
}

结果：系统死锁，线程B因无法获取锁而无法唤醒线程A。

5.2 解决方案

确保park()前释放所有必要的锁
使用超时机制（如parkNanos()）
通过中断协作式取消

六、与其他线程状态的关联

6.1 线程状态查看

通过jstack或Thread.getState()可观察到： - park()导致线程进入WTING状态 - 锁资源仍标记为被该线程持有

6.2 与JUC工具的结合

AQS（AbstractQueuedSynchronizer）内部大量使用park()
例如ReentrantLock在获取锁失败时，会将线程加入队列并park()

七、最佳实践建议

避免在持有锁时调用park()
除非有明确的协调机制，否则极易导致死锁。

使用条件变量替代
对于需要释放锁的场景，优先选择Condition.await()：

lock.lock();
try {
   condition.await(); // 自动释放锁
} finally {
   lock.unlock();
}

明确unpark的调用责任
设计时应保证每个park()都有对应的唤醒逻辑。

八、总结

LockSupport.park()是纯粹的线程阻塞操作，不涉及锁资源的释放。
锁释放必须通过显式调用（如unlock()）或隐式规则（如synchronized块退出）完成。
错误使用park()可能导致严重的死锁问题，需谨慎设计线程协作逻辑。

最终结论：线程调用park()时，不会释放其已持有的任何锁资源。理解这一机制对编写正确的并发程序至关重要。 “`