Java源码分析：`ReentrantLock`、`ReentrantReadWriteLock`与`LockSupport`深度解析

引言从synchronized到可编程的锁在Java并发编程的世界里synchronized关键字曾是开发者控制线程同步的唯一选择。它简单、易用并由JVM保证其正确性。然而随着应用复杂度的提升其固有的局限性——如无法中断、无法设置超时、严格的块结构等——逐渐成为构建高性能、高响应性系统的障碍。为了解决这些问题Java 1.5引入了java.util.concurrent.locks包其中ReentrantLock、ReentrantReadWriteLock和LockSupport构成了现代Java并发控制的核心基石。它们并非对synchronized的简单替代而是一次并发控制范式的升级。这些工具将“锁”从一个语言关键字转变为一个可以被编程、检查和定制的对象赋予了开发者前所未有的灵活性和控制力。本文将深入剖析这三个核心组件的源码、设计思想和使用场景揭示它们如何协同工作构建出高效、灵活且功能丰富的并发系统。我们将探讨Doug Lea及其团队在JSR-166中所展现的卓越工程智慧并思考这些经典设计在现代云原生架构中的深远影响。第一部分ReentrantLock——可重入互斥锁的典范第一章官方定义、历史定位与核心特性根据Oracle官方Javadoc对ReentrantLock的描述“A reentrant mutual exclusionLockwith the same basic behavior and semantics as the implicit monitor lock accessed usingsynchronizedmethods and statements, but with extended capabilities.”这段话点明了ReentrantLock的根本属性它是synchronized的功能超集。它不仅提供了synchronized的所有基本语义如互斥、内存可见性还增加了许多synchronized无法企及的高级功能。其核心特性包括可重入性Reentrancy同一个线程可以多次获取同一把锁而不会导致死锁。锁的持有计数会随之增加必须释放相同次数才能真正解锁。公平性Fairness构造函数接受一个可选的fairness参数。公平锁倾向于授予最长等待的线程访问权而非公平锁则不保证任何特定的访问顺序。可中断InterruptibilitylockInterruptibly()方法允许在等待锁的过程中响应中断信号。超时尝试Timed TrytryLock(long, TimeUnit)允许线程在指定时间内尝试获取锁超时则放弃。状态检查提供了一系列用于监控和调试的方法如isHeldByCurrentThread(),getHoldCount(),hasQueuedThreads()等。正确使用的黄金法则Javadoc特别强调了ReentrantLock的标准使用范式classX{privatefinalReentrantLocklocknewReentrantLock();publicvoidm(){lock.lock();// 在try块之前调用try{// ... method body}finally{lock.unlock();// 在finally块的第一行调用}}}这个try-finally结构是保证锁被正确释放的关键任何偏离此模式的代码都可能导致死锁。这体现了ReentrantLock“显式优于隐式”的设计哲学——它赋予了程序员极大的灵活性但也要求程序员承担起相应的责任。第二章源码逐行解剖——AQS同步器的精妙复用ReentrantLock的实现并非从零开始而是巧妙地复用了Doug Lea设计的AbstractQueuedSynchronizerAQS框架。AQS是JUC包中几乎所有同步工具如Semaphore,CountDownLatch,ReentrantReadWriteLock的基石。核心字段与委托模式ReentrantLock的核心在于其内部的sync字段/** Synchronizer providing all implementation mechanics */privatefinalSyncsync;ReentrantLock将所有复杂的同步逻辑都委托给了sync对象来处理。这是一种典型的委托模式使得ReentrantLock的公共API非常简洁而具体的实现细节则被封装在Sync及其子类中。抽象同步器SyncSync是一个抽象内部类继承自AQSabstractstaticclassSyncextendsAbstractQueuedSynchronizer{// ...}AQS使用一个int类型的state变量来表示同步状态。对于ReentrantLock而言state的值直接代表了锁的持有计数。state0表示锁未被持有stateN表示锁已被某个线程重入了N次。Sync类定义了一个关键的抽象方法initialTryLock()并实现了Lock接口的所有方法如lock(),lockInterruptibly(),tryLockNanos()等。这些方法的通用逻辑是首先调用initialTryLock()进行快速尝试如果失败则委托给AQS的相应方法如acquire(1)进行排队和阻塞。tryRelease方法解析tryRelease是Sync中最重要的方法之一负责释放锁protectedfinalbooleantryRelease(intreleases){intcgetState()-releases;// 减少持有计数if(getExclusiveOwnerThread()!Thread.currentThread())thrownewIllegalMonitorStateException();// 非法释放booleanfree(c0);if(free)setExclusiveOwnerThread(null);// 计数为0清空持有者setState(c);returnfree;// 返回是否完全释放}该方法清晰地展示了可重入锁的释放逻辑只有锁的持有者才能释放锁每次释放都会减少计数只有当计数减到0时锁才被真正释放并唤醒等待队列中的下一个线程。第三章公平与非公平模式的深度对比ReentrantLock最引人注目的特性之一就是其可配置的公平性。这一特性通过Sync的两个具体子类来实现NonfairSync和FairSync。非公平模式 (NonfairSync)非公平模式是ReentrantLock的默认行为旨在最大化吞吐量。initialTryLock的“插队”逻辑NonfairSync的initialTryLock方法体现了其核心思想——“能抢就抢”finalbooleaninitialTryLock(){ThreadcurrentThread.currentThread();if(compareAndSetState(0,1)){// 第一次尝试是无保护的setExclusiveOwnerThread(current);returntrue;}elseif(getExclusiveOwnerThread()current){// 处理重入...returntrue;}elsereturnfalse;}关键在于第一行CAS操作。即使同步队列中有其他线程在等待新来的线程也会直接尝试抢占锁。这种“插队”barging行为打破了FIFO顺序但极大地提高了锁的获取速度和整体吞吐量。公平模式 (FairSync)公平模式牺牲了部分吞吐量以换取更可预测的、无饥饿的线程调度。initialTryLock的“守序”逻辑FairSync的initialTryLock方法严格遵守FIFO规则finalbooleaninitialTryLock(){ThreadcurrentThread.currentThread();intcgetState();if(c0){// 关键区别检查队列是否为空if(!hasQueuedThreads()compareAndSetState(0,1)){setExclusiveOwnerThread(current);returntrue;}}elseif(getExclusiveOwnerThread()current){// 处理重入...returntrue;}returnfalse;}与非公平模式不同公平模式在尝试获取锁之前会先调用hasQueuedThreads()检查同步队列中是否有等待的线程。如果有则当前线程必须排队不能插队。公平性与tryLock()的特殊行为Javadoc中有一个重要的提示“the untimedtryLock()method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting.”这意味着无论你创建的是公平锁还是非公平锁tryLock()方法总是会尝试立即获取锁如果成功就“插队”。如果你希望在公平锁上也遵守公平性应该使用tryLock(0, TimeUnit.SECONDS)。第二部分ReentrantReadWriteLock——读写分离的并发优化利器第四章读写锁的设计理念与核心特性ReentrantReadWriteLock是对ReentrantLock思想的进一步扩展它基于一个重要的观察在很多场景下数据的读取操作远多于写入操作且多个读取操作之间是互不冲突的。其官方文档明确指出“This class has the following properties: … This lock allows both readers and writers to reacquire read or write locks in the style of aReentrantLock.”它的核心特性完美契合了这一理念读写分离允许多个读线程同时持有读锁但写锁是独占的。读锁和写锁互斥。可重入性读线程和写线程都可以重入自己持有的锁。锁降级写线程可以在持有写锁的同时获取读锁然后释放写锁从而将写锁“降级”为读锁。这是实现“先检查后更新”模式的关键。注意锁升级从读锁到写锁是不允许的会导致死锁。公平性策略同样支持公平和非公平两种模式但其公平策略更为复杂需要平衡读线程和写线程的等待。第五章源码精读——基于AQS的共享/独占模式ReentrantReadWriteLock的实现比ReentrantLock更为复杂因为它需要同时管理两种类型的锁共享的读锁和独占的写锁。它通过扩展AbstractQueuedLongSynchronizerAQLSAQS的64位版本来实现。同步状态的巧妙编码ReentrantReadWriteLock的精华在于其对同步状态state一个long值的编码方式// Lock state is logically divided into two ints:// The lower one representing the exclusive (writer) lock hold count,// and the upper the shared (reader) hold count.staticfinalintSHARED_SHIFT32;staticfinallongEXCLUSIVE_MASK(1LSHARED_SHIFT)-1;staticintsharedCount(longc){return(int)(cSHARED_SHIFT);}staticintexclusiveCount(longc){return(int)(cEXCLUSIVE_MASK);}高32位存储共享的读锁计数低32位存储独占的写锁计数。这种设计使得读写锁的状态可以用一个原子变量来表示极大地简化了并发控制。读锁与写锁的实现ReentrantReadWriteLock内部定义了两个公有静态内部类ReadLock和WriteLock它们都实现了Lock接口。WriteLock其lock()和unlock()方法分别委托给sync.acquire(1)和sync.release(1)这与ReentrantLock完全一致走的是AQS的独占模式。ReadLock其lock()和unlock()方法则委托给sync.acquireShared(1)和sync.releaseShared(1)走的是AQS的共享模式。复杂的重入计数管理由于允许多个读线程同时存在ReentrantReadWriteLock必须为每个线程单独维护其读锁的重入计数。这是通过ThreadLocal来实现的staticfinalclassHoldCounter{intcount;// initially 0finallongtidLockSupport.getThreadId(Thread.currentThread());}privatetransientThreadLocalHoldCounterreadHolds;为了优化性能它还使用了缓存机制cachedHoldCounter和针对第一个读线程的特殊优化firstReader避免了在无竞争场景下频繁访问ThreadLocal的开销。第六章经典使用场景——缓存与集合的并发优化ReentrantReadWriteLock最经典的使用场景是在读多写少的数据结构上例如缓存或大型集合。缓存的锁降级模式官方文档给出了一个完美的示例——带失效机制的缓存voidprocessCachedData(){rwl.readLock().lock();if(!cacheValid){// 释放读锁再获取写锁rwl.readLock().unlock();rwl.writeLock().lock();try{if(!cacheValid){data...;cacheValidtrue;}// 锁降级在释放写锁前获取读锁rwl.readLock().lock();}finally{rwl.writeLock().unlock();// 释放写锁但仍持有读锁}}try{use(data);}finally{rwl.readLock().unlock();}}这个例子展示了锁降级的必要性在更新数据后我们希望在不释放锁的情况下让后续的读操作能够立即看到新数据。直接释放写锁再获取读锁可能会导致在间隙期间数据再次失效。并发集合的读写分离对于一个预期会被大量读取但偶尔更新的Map使用ReentrantReadWriteLock可以显著提高并发性能classRWDictionary{privatefinalMapString,DatamnewTreeMap();privatefinalReentrantReadWriteLockrwlnewReentrantReadWriteLock();privatefinalLockrrwl.readLock();privatefinalLockwrwl.writeLock();publicDataget(Stringkey){r.lock();try{returnm.get(key);}finally{r.unlock();}}publicDataput(Stringkey,Datavalue){w.lock();try{returnm.put(key,value);}finally{w.unlock();}}}在这个例子中多个线程可以同时调用get方法而不会相互阻塞极大地提升了读操作的吞吐量。第三部分LockSupport——线程阻塞与唤醒的底层基石第七章LockSupport的角色与重要性如果说ReentrantLock和ReentrantReadWriteLock是面向开发者的高级并发工具那么LockSupport就是它们共同依赖的底层基石。它提供了一套最基本的线程阻塞park和唤醒unpark原语。虽然上传的文件内容主要聚焦于ReentrantReadWriteLock但我们可以从其源码中窥见LockSupport的身影finallongtidLockSupport.getThreadId(Thread.currentThread());这里使用了LockSupport.getThreadId来获取线程ID这是一种比直接持有Thread引用更轻量、更能避免内存泄漏的方式。LockSupport的核心方法是park()/park(Object blocker)阻塞当前线程。unpark(Thread thread)唤醒指定的线程。第八章LockSupport与AQS的协同工作AQS框架正是基于LockSupport来实现线程的阻塞和唤醒的。当一个线程尝试获取锁失败时AQS会将其封装成一个节点加入同步队列然后调用LockSupport.park(this)使其进入等待状态。当锁被释放时AQS会从队列中取出下一个合适的节点线程并调用LockSupport.unpark(node.thread)来唤醒它。LockSupport的park/unpark模型相比传统的Object.wait/notify模型有巨大优势解耦unpark可以在park之前调用许可permit会被保存下来。这解决了wait/notify中因时序问题导致信号丢失的经典难题。精准unpark可以精确地唤醒指定的线程而notify只能随机唤醒一个等待线程。不依赖于监视器park/unpark不需要在synchronized块中调用使用更加灵活。正是LockSupport提供的这种强大而可靠的底层原语才使得ReentrantLock和ReentrantReadWriteLock等高级同步工具的实现成为可能。第四部分设计原则、模式与现代演进第九章核心设计原则解析这三个组件共同体现了软件工程中的多项核心原则单一职责原则 (SRP)ReentrantLock负责互斥ReentrantReadWriteLock负责读写分离LockSupport负责底层线程调度职责清晰。开放封闭原则 (OCP)通过Sync抽象类和公平/非公平子类ReentrantLock和ReentrantReadWriteLock的策略可以轻松扩展。组合优于继承ReentrantReadWriteLock通过组合ReadLock和WriteLock两个对象而不是通过复杂的继承关系来提供两种锁。第十章设计模式的精妙运用模板方法模式AQS是模板方法模式的极致体现。acquire和release等方法定义了算法骨架而tryAcquire、tryRelease等钩子方法则由子类如ReentrantLock.Sync去实现具体逻辑。策略模式公平与非公平模式是策略模式的直接应用。享元模式/对象池ReentrantReadWriteLock中对HoldCounter的缓存复用是一种轻量级的对象池思想用于优化性能。第十一章从单机锁到云原生时代的演进尽管这些工具本身是为单机多线程环境设计的但其背后的设计思想在分布式系统中依然闪耀着光芒。ReentrantLock的思想在Redis、ZooKeeper等中间件中都有对应的分布式锁实现它们同样提供了可重入、可超时、可中断等特性。ReentrantReadWriteLock的思想在数据库和分布式存储系统中读写锁的概念被广泛应用用于协调对共享资源的并发访问。LockSupport的思想在异步编程和响应式系统中基于回调和Future/Promise的协调机制可以看作是park/unpark模型在更高层次上的抽象。总结与展望ReentrantLock、ReentrantReadWriteLock和LockSupport共同构成了Java并发编程的坚实基础。它们不仅是强大的工具更是卓越设计思想的载体。理解它们的内部机制和设计哲学对于任何希望编写高性能、高可靠并发程序的开发者来说都是至关重要的。在现代开发中我们或许更多地会使用更高层次的并发工具如CompletableFuture、响应式流但这些工具的底层依然离不开这些基石。更重要的是它们所倡导的“显式、可配置、可组合”的设计思想已经超越了Java语言本身成为构建任何复杂、可靠系统的通用准则。如果您在阅读源码或理解其工作原理、以及其在云原生场景下的使用时遇到任何疑问或者觉得这篇深度解析对您有帮助欢迎在评论区留言交流。别忘了点赞、收藏、关注以便获取更多 Java 核心原理、源码解读与系统架构相关的硬核技术文章