1. 从AQS到ReentrantLock的实现脉络第一次拆解ReentrantLock源码时我被AbstractQueuedSynchronizerAQS这个看似复杂的框架震惊了。这个隐藏在java.util.concurrent包中的同步器实际上构建了Java并发编程的半壁江山。理解AQS的工作机制就像拿到了打开JUC包所有锁实现的金钥匙。AQS的核心是一个volatile修饰的int类型state变量和一个CLH队列Craig, Landin, and Hagersten lock queue的变种。这个state在不同子类中有不同语义——在ReentrantLock中表示重入次数在Semaphore中表示剩余许可数。CLH队列则是所有等待线程的排队通道采用双向链表实现每个节点保存着线程引用和等待状态。关键洞察AQS采用了模板方法模式将acquire/release等操作定义为final方法子类只需实现tryAcquire/tryRelease等钩子方法。这种设计让ReentrantLock只需关注锁获取与释放的逻辑排队、阻塞等复杂操作都由AQS统一处理。ReentrantLock在AQS基础上实现了公平与非公平两种策略。非公平锁在lock()时会直接尝试CAS修改state失败后才进入队列代码示例final void lock() { if (compareAndSetState(0, 1)) // 非公平锁的核心竞争逻辑 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); }而公平锁则永远遵循FIFO原则final void lock() { acquire(1); // 直接进入队列排队 }2. 锁的可重入性实现细节可重入性是ReentrantLock区别于synchronized之外最重要的特性。在AQS框架下重入计数通过state变量和exclusiveOwnerThread共同实现。当线程首次获取锁时state从0变为1同一线程再次获取时state会递增代码片段protected final boolean tryAcquire(int acquires) { final Thread current Thread.currentThread(); int c getState(); if (c 0) { if (!hasQueuedPredecessors() compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current getExclusiveOwnerThread()) { // 重入判断 int nextc c acquires; if (nextc 0) throw new Error(Maximum lock count exceeded); setState(nextc); // 不需要CAS因为只有持有线程能修改 return true; } return false; }重入锁释放时必须执行相同次数的unlock()操作。我曾遇到过因释放次数不匹配导致的死锁问题——某段代码在if分支中lock()却在多个return前忘记unlock()。这种bug在复杂业务逻辑中极难定位。避坑指南建议使用try-finally保证锁释放ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 临界区代码 } finally { lock.unlock(); // 确保任何情况下都会释放 }3. 条件变量(Condition)的底层机制ConditionObject是AQS的内部类每个Condition实例维护一个独立的条件队列。与synchronized的wait/notify相比Condition提供了更精细的等待/通知控制。典型的生产者-消费者模式实现private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); public 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(); } }条件变量的await()过程涉及复杂的队列转移创建节点加入条件队列完全释放锁考虑重入情况阻塞直到被signal()或中断重新获取锁后继续执行这个过程中节点会从条件队列转移到CLH队列。signal()操作只是将节点移入CLH队列并不立即唤醒线程——这解释了为什么有时signal()后线程没有立即执行。4. 性能优化与实战陷阱在百万级并发的压力测试中我发现非公平锁的吞吐量比公平锁高出40%以上。这是因为非公平锁允许插队行为减少了线程切换开销。但这也可能导致线程饥饿——在高并发场景下某些线程可能长时间获取不到锁。锁的优化技巧减小临界区范围只锁必须同步的代码段避免锁嵌套容易引发死锁使用tryLock()替代lock()带超时机制的锁获取if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { try { // 临界区 } finally { lock.unlock(); } } else { // 备选方案 }常见死锁场景分析交叉锁线程A持有锁1请求锁2线程B持有锁2请求锁1自死锁单线程重复调用lock()但未实现可重入资源死锁数据库事务与Java锁混合使用时出现的互相等待我在排查deadlock found when trying to get lock错误时发现线程转储(thread dump)是最有效的工具。JDK自带的jstack可以生成所有线程的调用栈信息结合可视化工具如fastthread.io能快速定位死锁环。5. AQS的扩展应用模式理解AQS后可以自定义实现各种同步器。比如实现一个简单的二元闭锁class BinaryLatch extends AbstractQueuedSynchronizer { protected int tryAcquireShared(int ignore) { return (getState() 1) ? 1 : -1; } protected boolean tryReleaseShared(int ignore) { setState(1); return true; } public void signal() { releaseShared(1); } public void await() throws InterruptedException { acquireSharedInterruptibly(1); } }这种模式也被用于CountDownLatch、Semaphore等JUC组件。AQS的共享模式与独占模式为不同场景提供了灵活的实现基础。在Java 8环境下AQS的实现有一些微优化比如取消了头节点的伪唤醒通过引入status字段。但核心机制保持不变这也是为什么基于Java 8的代码在不同版本间保持良好兼容性。对于could not acquire lock(s)这类错误除了检查死锁外还需要注意锁泄漏忘记释放锁导致其他线程永久等待锁粒度过粗的锁设计导致性能瓶颈锁分段ConcurrentHashMap式的分段锁优化方案在Oracle 19c等数据库中表级锁LOCK TABLE有不同模式如行共享、行独占这与ReentrantLock的公平/非公平策略有异曲同工之妙。理解这些底层机制能帮助我们在不同层级设计更优的并发控制方案。