1. ReentrantLock的抢座位模型解析在并发编程的世界里ReentrantLock就像电影院里的热门场次——当所有座位都被占满时新来的观众必须排队等待。这种机制在Java中被称为可重入锁它比传统的synchronized关键字提供了更灵活的线程控制能力。我第一次在线上支付系统使用ReentrantLock时发现它完美解决了高并发下的账户余额操作问题。当多个线程同时尝试修改同一个账户时这把锁能确保每次只有一个观众能进入临界区操作数据。1.1 锁的基本使用范式典型的ReentrantLock使用模式是这样的ReentrantLock lock new ReentrantLock(); //... lock.lock(); try { // 临界区代码 } finally { lock.unlock(); }这个模板代码中有几个关键点lock()调用必须在try块外部避免锁获取成功后因异常跳过解锁unlock()必须放在finally块中确保锁一定会被释放临界区代码应尽可能简短减少锁持有时间重要提示我曾在一个项目中见过开发者在lock()和unlock()之间放置了网络IO操作这直接导致了系统出现死锁。记住锁范围内永远不要进行可能阻塞的操作1.2 公平锁与非公平锁的选择ReentrantLock提供了两种工作模式公平锁Fair mode严格按照线程请求顺序分配锁非公平锁Nonfair mode允许插队提高吞吐量// 创建公平锁 ReentrantLock fairLock new ReentrantLock(true); // 创建非公平锁默认 ReentrantLock nonfairLock new ReentrantLock();在我们的性能测试中非公平锁的吞吐量比公平锁高出约40%这是因为减少了线程切换开销利用了线程执行的时间局部性避免了队首线程唤醒延迟但在严格要求顺序性的场景如金融交易公平锁仍然是更好的选择。我曾经在证券交易系统中强制使用公平锁虽然牺牲了部分性能但保证了交易记录的严格时序。2. AQS队列机制深度剖析AbstractQueuedSynchronizerAQS是ReentrantLock的基石它实现了一个精巧的CLH队列Craig, Landin, and Hagersten lock queue。这个队列不是我们常见的LinkedList或ArrayDeque而是一个基于CAS操作的虚拟队列。2.1 CLH队列实现细节AQS中的每个等待线程都被封装为一个Node对象这些Node通过两个指针组成双向链表static final class Node { volatile Node prev; volatile Node next; volatile Thread thread; //... }队列操作的核心方法包括enq()通过CAS自旋将节点安全加入队尾acquireQueued()让节点在队列中等待获取锁shouldParkAfterFailedAcquire()检查是否需要挂起线程我曾经用JProfiler跟踪过一个死锁案例发现AQS队列的调试信息特别有价值。当系统出现问题时可以通过以下方式获取队列状态ReentrantLock lock new ReentrantLock(); //... System.out.println(等待队列长度 lock.getQueueLength()); System.out.println(是否有等待线程 lock.hasQueuedThreads());2.2 状态变量与CAS操作AQS使用一个volatile的int变量表示同步状态private volatile int state;在ReentrantLock中state的含义是0锁未被占用1锁被一个线程占用1锁被同一个线程重入多次状态修改通过CASCompare-And-Swap操作保证原子性protected final boolean compareAndSetState(int expect, int update) { return unsafe.compareAndSwapInt(this, stateOffset, expect, update); }我在一次性能调优中发现CAS操作在高并发下可能成为瓶颈。当100线程竞争同一个锁时CAS失败率可能超过90%这时就需要考虑锁分解或改用读写锁。3. 源码关键路径分析让我们深入ReentrantLock的核心代码理解从加锁到排队的完整流程。3.1 非公平锁的lock()实现final void lock() { if (compareAndSetState(0, 1)) // 尝试直接获取锁 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); // 进入AQS获取流程 }这个实现体现了非公平的精髓不管是否有线程在排队新线程都先尝试插队插队失败才进入常规获取流程这种设计减少了线程切换提高了吞吐量我曾经在日志系统中用非公平锁替代synchronizedQPS提升了35%。但要注意这种优化只适用于锁竞争不激烈的场景。3.2 acquire()方法调用链public final void acquire(int arg) { if (!tryAcquire(arg) acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }这个方法实现了经典的获取-入队-阻塞流程tryAcquire()子类实现的尝试获取逻辑addWaiter()将当前线程包装为Node加入队尾acquireQueued()在队列中等待获取锁selfInterrupt()恢复中断状态在线上问题排查时我经常通过这个调用链判断线程卡在哪个阶段。比如如果卡在tryAcquire说明锁被长期占用如果卡在acquireQueued说明前面有大量等待线程3.3 tryAcquire的实现差异公平锁和非公平锁的tryAcquire实现关键区别在于hasQueuedPredecessors()检查// 公平锁版本 protected final boolean tryAcquire(int acquires) { if (getState() 0) { if (!hasQueuedPredecessors() // 检查是否有更早的等待者 compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } //...重入逻辑 } // 非公平锁版本 final boolean nonfairTryAcquire(int acquires) { // 直接尝试CAS不检查队列 if (getState() 0 compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } //...重入逻辑 }这个差异点解释了为什么公平锁的性能较低——每次获取前都需要检查队列状态。4. 性能优化与实战技巧基于多年的使用经验我总结了一些ReentrantLock的实战技巧。4.1 锁粒度的选择错误的锁粒度是性能问题的常见根源锁粒度过粗导致并发度下降锁粒度过细增加管理开销我曾经优化过一个商品库存系统原始方案对所有商品使用全局锁。改进后按商品ID哈希分成16个锁使用ReentrantLock数组冲突率从95%降到15%ReentrantLock[] locks new ReentrantLock[16]; // 初始化 for (int i 0; i locks.length; i) { locks[i] new ReentrantLock(); } // 使用 int bucket itemId.hashCode() (locks.length - 1); locks[bucket].lock(); try { // 操作对应商品的库存 } finally { locks[bucket].unlock(); }4.2 避免锁泄漏的检查清单锁泄漏忘记解锁是严重问题我的团队使用以下预防措施代码审查时重点检查finally块使用SonarQube静态分析在测试环境开启锁超时监控使用tryLock()替代lock()设置超时if (lock.tryLock(1, TimeUnit.SECONDS)) { try { // 临界区 } finally { lock.unlock(); } } else { // 记录告警日志 stats.incrementTimeoutCount(); }4.3 诊断工具与技巧当遇到锁相关问题时我常用的诊断方法JStack分析线程栈jstack pid | grep -A 20 parking to wait forJConsole观察锁竞争情况Arthas监控锁状态watch java.util.concurrent.locks.ReentrantLock getQueueLength自定义监控指标// 记录等待时间 long start System.nanoTime(); lock.lock(); long waited System.nanoTime() - start; stats.recordWaitTime(waited);5. AQS的扩展应用理解AQS不仅对使用ReentrantLock有帮助它还是Java并发包的基础设施。5.1 基于AQS实现自定义同步器我曾经实现过一个简单的限流器class SimpleLimiter extends AbstractQueuedSynchronizer { private final int limit; SimpleLimiter(int limit) { this.limit limit; setState(limit); } protected boolean tryAcquire(int acquires) { for (;;) { int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining 0; } } protected boolean tryRelease(int releases) { for (;;) { int current getState(); int next current releases; if (next limit) next limit; if (compareAndSetState(current, next)) return true; } } }这个实现展示了AQS的核心扩展点tryAcquire定义获取逻辑tryRelease定义释放逻辑state表示可用资源数5.2 AQS在JUC中的应用除了ReentrantLockAQS还被用于实现CountDownLatchSemaphoreReentrantReadWriteLockFutureTask理解AQS让我能更快掌握这些工具的内部机制。比如Semaphore本质上就是AQS的共享模式应用而CountDownLatch使用了AQS的state作为计数器。在数据库连接池的实现中我经常组合使用这些组件Semaphore控制最大连接数ReentrantLock保护连接池状态CountDownLatch用于初始化同步6. 常见问题排查实录6.1 死锁诊断案例某次线上事故中四个线程相互等待形成了环形死锁。通过以下步骤定位获取线程dumpjstack -l pid thread.dump查找BLOCKED状态的线程分析每个线程持有的锁和等待的锁使用可视化工具生成等待关系图最终发现是锁获取顺序不一致导致的经典问题。解决方案统一锁获取顺序引入tryLock超时添加死锁检测线程6.2 锁竞争优化案例一个消息处理系统出现性能瓶颈分析显示90%的时间花在AQS队列等待平均等待时间超过200ms锁持有时间过长包含数据库操作优化方案将大锁拆分为多个细粒度锁把数据库操作移出锁范围引入异步处理队列使用读写锁替代互斥锁优化后吞吐量提升了8倍平均等待时间降至20ms以内。6.3 内存泄漏排查某应用出现内存缓慢增长MAT分析显示大量Node对象未被回收这些Node来自AQS等待队列检查发现某个线程获取锁后未释放根本原因是lock.lock(); try { if (condition) { return; // 提前返回导致未解锁 } // ... } finally { lock.unlock(); }修复方案规范锁使用模板添加静态代码检查部署锁泄漏监控7. 高级特性与注意事项7.1 条件变量(Condition)的正确使用ReentrantLock的条件变量比Object的wait/notify更灵活Condition notEmpty lock.newCondition(); // 生产者 lock.lock(); try { queue.add(item); notEmpty.signal(); } finally { lock.unlock(); } // 消费者 lock.lock(); try { while (queue.isEmpty()) { notEmpty.await(); } return queue.poll(); } finally { lock.unlock(); }关键点await()会原子性地释放锁并挂起线程被唤醒后会重新获取锁必须用while检查条件避免虚假唤醒我在一个任务调度系统中使用Condition实现了精确的通知机制相比notifyAll()减少了70%的无用唤醒。7.2 锁中断与超时控制ReentrantLock提供了更灵活的获取方式lockInterruptibly()可中断的获取tryLock()非阻塞尝试tryLock(timeout)带超时的获取if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { try { // 临界区 } finally { lock.unlock(); } } else { // 超时处理 throw new BusyException(System is busy); }在微服务熔断场景中这种超时机制可以防止线程被无限期阻塞。7.3 锁的可见性保证ReentrantLock的内存语义保证了lock()操作具有acquire语义unlock()操作具有release语义确保临界区内的修改对后续获取锁的线程可见这个特性在双重检查锁定模式中特别有用private volatile Resource resource; Resource getResource() { if (resource null) { lock.lock(); try { if (resource null) { resource new Resource(); } } finally { lock.unlock(); } } return resource; }相比纯volatile方案这种实现减少了volatile读的开销。