1. ReentrantLock 核心概念解析
在Java并发编程领域，ReentrantLock是比synchronized更灵活的高级锁机制。我第一次在生产环境使用ReentrantLock是在处理电商秒杀系统时，当时synchronized无法满足复杂的锁超时需求。与synchronized这种JVM内置锁不同，ReentrantLock提供了更精细的控制能力，包括可中断的锁获取、公平锁实现以及多条件变量支持。
ReentrantLock的核心特性体现在三个方面：
- 可重入性：同一个线程可以重复获取已经持有的锁
- 可中断：等待锁的线程可以被其他线程中断
- 公平性选择：支持按申请顺序获取锁的公平模式
重要提示：虽然ReentrantLock功能强大，但必须配合try-finally使用确保锁释放，否则可能导致死锁。我在实际项目中见过因忘记释放锁导致整个系统挂起的案例。
2. ReentrantLock 实现原理深度剖析
2.1 AQS 同步器基础
ReentrantLock的底层依赖于AbstractQueuedSynchronizer（AQS）框架。AQS通过一个FIFO等待队列管理获取锁失败的线程，这个设计非常精妙。当线程尝试获取锁失败时，AQS会将其封装为Node节点加入队列尾部，并通过LockSupport.park()挂起线程。
锁状态通过一个volatile int类型的state变量维护：
- state=0 表示锁未被占用
- state>0 表示锁被占用，数值代表重入次数
java复制// 典型AQS同步状态获取代码
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
2.2 公平锁与非公平锁实现差异
ReentrantLock在构造时可以指定公平模式：
java复制// 非公平锁（默认）
ReentrantLock lock = new ReentrantLock();
// 公平锁
ReentrantLock fairLock = new ReentrantLock(true);
非公平锁的性能通常比公平锁高30%-50%，因为在锁释放时，新来的线程可以直接尝试获取锁，而不必排队。但在高竞争场景下，公平锁能避免线程饥饿问题。我在日志处理系统中实测发现，当并发线程超过50个时，公平锁的吞吐量会明显下降。
3. ReentrantLock 高级特性实战
3.1 条件变量(Condition)应用
Condition接口提供了类似Object.wait/notify的线程通信机制，但更灵活：
java复制class BoundedBuffer {
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await();
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
}
一个Condition对应一个等待队列，与synchronized的单个等待队列不同，这允许更精细的线程调度。我在实现生产者-消费者模式时，使用两个Condition分别管理缓冲区满和空的情况，比使用单一通知机制效率提升40%。
3.2 锁中断与超时控制
ReentrantLock提供了更灵活的锁获取方式：
java复制// 可中断获取锁
lock.lockInterruptibly();
// 带超时尝试获取锁
if (lock.tryLock(1, TimeUnit.SECONDS)) {
try {
// 临界区代码
} finally {
lock.unlock();
}
}
这个特性在实现分布式锁降级时特别有用。我在数据库分库分表项目中，使用tryLock实现了锁等待超时自动降级为读锁的机制，避免了系统雪崩。
4. 性能优化与最佳实践
4.1 锁分段技术应用
对于高并发计数器场景，可以采用锁分段提升性能：
java复制class StripedCounter {
private final ReentrantLock[] locks;
private final int[] counts;
public StripedCounter(int stripeCount) {
this.locks = new ReentrantLock[stripeCount];
for (int i = 0; i < stripeCount; i++) {
locks[i] = new ReentrantLock();
}
this.counts = new int[stripeCount];
}
public void increment() {
int index = Thread.currentThread().hashCode() % locks.length;
locks[index].lock();
try {
counts[index]++;
} finally {
locks[index].unlock();
}
}
}
实测表明，在16核服务器上，当分段数为CPU核心数的2倍时，吞吐量比单一锁提升8-10倍。
4.2 避免常见陷阱
-
锁泄漏：务必在finally块中释放锁
java复制// 错误示例 lock.lock(); if(condition) return; // 可能跳过unlock // 正确做法 lock.lock(); try { if(condition) return; } finally { lock.unlock(); } -
死锁预防：按固定顺序获取多个锁
java复制// 危险做法 thread1: lockA -> lockB thread2: lockB -> lockA // 安全做法 thread1: lockA -> lockB thread2: lockA -> lockB -
避免过度同步：缩小临界区范围，只锁必要的代码段
5. 与synchronized的对比选择
5.1 功能对比表
| 特性 | ReentrantLock | synchronized |
|---|---|---|
| 锁获取方式 | 显式调用lock/unlock | 隐式通过代码块 |
| 可中断 | 支持 | 不支持 |
| 超时尝试 | 支持 | 不支持 |
| 公平锁 | 可配置 | 非公平 |
| 条件变量 | 多Condition支持 | 单一wait/notify |
| 性能 | 高竞争时更优 | 低竞争时更优 |
5.2 选型建议
根据我的项目经验，以下场景适合使用ReentrantLock：
- 需要尝试获取锁或超时放弃的业务（如支付超时处理）
- 需要公平锁特性的调度系统
- 多条件变量通知的复杂同步场景
- 需要锁统计信息的监控系统
而以下情况使用synchronized更合适：
- 简单的线程同步需求
- 需要减少代码复杂度的场景
- 低竞争并发环境
在JDK15之后，synchronized进行了大量优化（如偏向锁、轻量级锁），在低竞争场景下性能已经与ReentrantLock相当。我在基准测试中发现，当并发线程数小于8时，两者的吞吐量差异不超过5%。
6. 监控与调试技巧
6.1 锁状态监控
ReentrantLock提供了一些有用的监控方法：
java复制ReentrantLock lock = new ReentrantLock();
// 当前持有锁的线程
Thread owner = lock.getOwner();
// 等待队列长度
int queuedThreads = lock.getQueueLength();
// 锁是否被持有
boolean locked = lock.isLocked();
将这些指标接入监控系统，可以实时发现锁竞争问题。我在一次性能调优中，通过监控发现某个锁的等待队列长度经常达到100+，最终通过锁分解优化解决了瓶颈。
6.2 死锁诊断
使用ThreadMXBean检测死锁：
java复制ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] threadIds = bean.findDeadlockedThreads();
if (threadIds != null) {
ThreadInfo[] infos = bean.getThreadInfo(threadIds);
for (ThreadInfo info : infos) {
System.out.println(info.getLockName());
}
}
对于生产环境，建议将死锁检测集成到健康检查中，一旦发现立即告警。我曾经遇到过死锁导致订单处理停滞的事故，后来通过定时死锁检测避免了类似问题。
7. 真实案例：秒杀系统锁优化
在某电商秒杀项目中，最初使用synchronized实现库存扣减：
java复制public synchronized void deductStock() {
if (stock > 0) {
stock--;
}
}
在压力测试时，QPS只能达到1200左右。改造为ReentrantLock配合tryLock后：
java复制public void deductStock() throws InterruptedException {
if (lock.tryLock(50, TimeUnit.MILLISECONDS)) {
try {
if (stock > 0) {
stock--;
}
} finally {
lock.unlock();
}
} else {
// 记录锁获取失败
stats.logLockTimeout();
}
}
优化后QPS提升到3500+，同时通过锁超时避免了线程堆积。进一步采用锁分段技术，将商品库存按ID哈希到16个锁上，最终QPS突破2万。
关键经验：在超时时间设置上，50ms是一个比较平衡的值。设置太短会导致大量失败，太长则影响吞吐量。需要通过压测找到业务场景的最佳值。