1. ReentrantLock核心机制解析

作为Java并发包中的重量级选手，ReentrantLock的实现远比表面看到的复杂。其底层采用AQS（AbstractQueuedSynchronizer）框架构建，这个设计模式堪称并发控制的瑞士军刀。AQS内部维护了一个volatile修饰的state变量和CLH队列，前者记录锁的重入次数，后者管理等待线程的排队秩序。

锁的公平性选择直接影响系统吞吐量。非公平锁（默认模式）在锁释放时会允许新请求线程与队列头线程竞争，这种设计虽然可能造成线程饥饿，但能减少线程切换带来的性能损耗。实测在激烈竞争场景下，非公平锁的吞吐量可比公平锁高出40%以上。而公平锁严格按照FIFO顺序获取锁，适合需要严格顺序执行的业务场景。

// 公平锁与非公平锁的底层实现差异 static final class FairSync extends Sync { final boolean initialTryLock() { Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (!hasQueuedThreads() && compareAndSetState(0, 1)) { setExclusiveOwnerThread(current); return true; } } // 省略重入判断... } } static final class NonfairSync extends Sync { final boolean initialTryLock() { Thread current = Thread.currentThread(); if (compareAndSetState(0, 1)) { // 直接尝试CAS抢锁 setExclusiveOwnerThread(current); return true; } // 省略重入判断... } }

2. 锁的实战应用模式

2.1 基础加锁范式

正确的锁使用必须遵循"获取-释放"的严格配对原则。推荐使用try-finally代码块确保锁释放，这种写法比synchronized更灵活但也更容易出错。特别注意，lock()方法会阻塞直到获取锁，而tryLock()支持带超时的非阻塞获取：

ReentrantLock lock = new ReentrantLock(); try { if (lock.tryLock(3, TimeUnit.SECONDS)) { // 等待3秒 try { // 临界区操作 } finally { lock.unlock(); } } else { // 超时处理逻辑 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); }

2.2 条件变量高级用法

Condition接口实现了管程模型的等待/通知机制。与Object.wait()/notify()不同，单个ReentrantLock可以创建多个Condition，实现精细化的线程调度。典型的生产者-消费者场景中，可以分别为队列满和队列空创建独立的条件变量：

class BoundedBuffer { final ReentrantLock 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(); // 队列满时等待 // 入队操作... notEmpty.signal(); // 唤醒消费者 } finally { lock.unlock(); } } // 省略take方法... }

3. 性能调优实战

3.1 锁竞争热点优化

通过ThreadMXBean可以检测锁竞争情况。当发现某个锁的等待时间超过操作本身的10倍时，就需要考虑锁细化（Lock Splitting）或锁分段（Lock Striping）。例如ConcurrentHashMap就采用了分段锁设计，将数据分成多个Segment独立加锁。

重要提示：JDK8的StampedLock在读多写少场景下性能更好，但要注意其不是可重入锁

3.2 死锁预防方案

开发中建议使用统一的锁获取顺序，或者通过tryLock实现死锁检测。下面是一个简单的死锁检测实现：

public class DeadlockDetector { private static final ThreadMXBean bean = ManagementFactory.getThreadMXBean(); public static void check() { long[] threadIds = bean.findDeadlockedThreads(); if (threadIds != null) { ThreadInfo[] infos = bean.getThreadInfo(threadIds); for (ThreadInfo info : infos) { System.err.println("Deadlock detected: " + info); } } } }

4. 源码级实现剖析

4.1 AQS队列运作机制

当锁被占用时，新请求线程会被封装成Node加入CLH队列。这个虚拟队列通过CAS操作维护，避免了真正的队列操作带来的性能损耗。节点状态waitStatus包含：

• CANCELLED(1)：线程已取消
• SIGNAL(-1)：后继节点需要唤醒
• CONDITION(-2)：处于条件等待
• PROPAGATE(-3)：共享模式传播

// AQS中的入队操作 private Node enq(Node node) { for (;;) { Node t = tail; if (t == null) { // 必须初始化 if (compareAndSetHead(new Node())) tail = head; } else { node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }

4.2 锁释放的级联唤醒

释放锁时会触发unparkSuccessor操作，从尾节点向前遍历找到最前面的未取消节点进行唤醒。这种反向遍历的设计是为了处理并发添加节点时next指针可能暂时为null的情况：

Node s = node.next; if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } if (s != null) LockSupport.unpark(s.thread);

5. 生产环境问题排查

5.1 锁泄漏检测

忘记释放锁是常见问题，可以通过继承ReentrantLock重写加锁方法加入堆栈跟踪：

public class TracedLock extends ReentrantLock { private Map<Thread, Exception> traces = new ConcurrentHashMap<>(); @Override public void lock() { super.lock(); traces.put(Thread.currentThread(), new Exception("Lock acquired here")); } @Override public void unlock() { super.unlock(); traces.remove(Thread.currentThread()); } public void checkLeaks() { traces.forEach((thread, ex) -> { System.err.println("Potential lock leak by " + thread.getName()); ex.printStackTrace(); }); } }

5.2 锁性能监控

通过自定义MBean可以暴露锁的等待时间、持有时间等关键指标：

public interface LockMonitorMBean { long getWaitCount(); double getAverageWaitTime(); long getHoldCount(); } // 使用时通过JMX客户端连接即可查看实时数据

在实际高并发场景中，我曾遇到过一个案例：某支付系统使用ReentrantLock保护账户余额变更，在促销期间出现性能骤降。通过ThreadDump发现锁等待链过长，最终采用锁分段方案，将账户按尾号分成16个锁段，QPS立即从200提升到3500。这个案例告诉我们：没有万能的锁策略，只有最适合业务场景的并发方案。