写这种并发编程的文章最怕的就是上来就贴代码讲完API就收工读者看的时候觉得都懂写代码的时候还是用不好。ReentrantLock作为Java并发包里最重要的显式锁网上的资料其实不少但大多要么太浅只教你怎么用要么太深直接怼AQS源码。我今天想换个思路来聊从你到底为什么会用它这个角度切入先讲清楚它解决了synchronized哪些麻烦再把公平锁、中断响应、超时获取这些特性一个个拆开揉碎最后把我实际写代码时踩过的坑和排查思路也一并分享出来。这篇东西适合已经会用synchronized、想进阶理解JUC锁机制的Java开发也适合正在准备面试、想系统梳理锁相关知识点的人。1. 从synchronized说起为什么还需要ReentrantLock1.1 synchronized的几个小脾气绝大多数Java开发者第一次接触锁都是从synchronized开始的。它确实好用方法上加个关键字、代码块外面套一层编译器和JVM就帮你处理好了用完自动释放锁哪怕方法里抛了异常也不用担心锁泄漏。我刚开始写并发代码的那两年基本上一个synchronized走天下觉得这就够了。但写的东西多了synchronized的几个问题就慢慢暴露出来了。最让我难受的是它没法在获取锁的时候超时退出。举个例子你有两个线程一个持有锁A在等锁B另一个持有锁B在等锁A一旦出现这种循环等待两个线程就永远卡死了。synchronized对这种死锁一点办法都没有你只能重启应用连个自救的机会都没有。第二个问题是没有办法响应中断。如果线程在synchronized上排队等锁调用Thread.interrupt()去打断它这个线程并不会停下来它会继续傻傻地等锁。在某些场景下比如线程池关闭、任务取消我们希望等待锁的线程能感知到中断信号并及时退出synchronized就做不到了。第三个问题是读写的场景。经典的缓存读写场景里读操作其实可以完全并行只有写的时候才需要互斥。用synchronized的话所有读操作都得排队串行。这个性能浪费在并发量不高的时候不明显一旦读多写少而且读操作本身有点耗时差距就非常明显了。1.2 ReentrantLock补齐了哪些短板ReentrantLock就是为解决这些问题而生的。它是JUCjava.util.concurrent包下的显式锁实现实现了Lock接口把加锁和解锁的控制权完全交到了我们手里。它具备以下几个synchronized给不了的能力可中断地获取锁调用lockInterruptibly()方法等待锁的过程中可以被中断并做出响应。支持超时获取锁调用tryLock(long timeout, TimeUnit unit)等不到锁就放弃不会无限期阻塞。公平锁机制能给等待时间最长的线程先分配锁避免线程饥饿。多个条件变量通过newCondition()可以创建多个等待队列让线程按不同条件等待和唤醒。性能在某些场景下优于synchronized尤其是竞争激烈、持有锁时间短的情况下。我在实际项目里最常用到的其实是超时获取锁这个能力。比如写一个分布式任务处理框架任务线程需要抢一个本地锁来执行任务如果抢不到就换个任务继续执行而不是一直卡在那里。这种场景用synchronized非常别扭用ReentrantLock的tryLock就顺手多了。当然ReentrantLock也继承了显式锁的通病必须手动加锁和解锁忘记在finally里unlock一次问题就藏起来了轻则性能下降重则死锁。所以每次用ReentrantLock我都有一种手里拿着精密仪器每一步都得小心操作的感觉。2. 基础用法精讲动手写第一个ReentrantLock程序2.1 标准加锁模板try-finally永远是唯一答案先看最基本的用法这里没有任何花样就是最标准的加锁和解锁。import java.util.concurrent.locks.ReentrantLock; public class SafeCounter { private final ReentrantLock lock new ReentrantLock(); private int count 0; public void increment() { lock.lock(); try { count; } finally { lock.unlock(); } } public int getCount() { lock.lock(); try { return count; } finally { lock.unlock(); } } }这里有一个铁律lock()之后必须在finally块里调用unlock()。我看到很多人写的代码是这样的public void increment() { lock.lock(); count; lock.unlock(); }代码本身看着没什么问题但假如count这一行抛了异常虽然实际不太可能锁就永远释放不了了其他线程全部卡死。一旦这种代码上线排查起来的痛苦程度谁排谁知道。所以不管锁内代码多简单一律finally收尾。这不是洁癖这是保命。顺便说一下unlock必须是lock的线程自己来调用。ReentrantLock内部有个线程持有记录持有锁的线程才能成功解锁其他线程调用unlock会抛IllegalMonitorStateException。这一点和synchronized不一样synchronized由JVM托管不存在这个误用问题。2.2 可重入特性的正确理解ReentrantLock允许同一个线程多次获取同一把锁这是Reentrant这个名字的由来。举个例子public class Widget { private final ReentrantLock lock new ReentrantLock(); public void outerMethod() { lock.lock(); try { innerMethod(); } finally { lock.unlock(); } } public void innerMethod() { lock.lock(); try { // do something } finally { lock.unlock(); } } }outerMethod里面调用了innerMethod两次获取的都是同一把锁但是不会死锁。这个特性非常实用因为业务方法之间的调用链往往会层层嵌套如果锁不可重入任何一个内部方法加锁都会导致自身死锁那代码就没法写了。底层实现上ReentrantLock内部维护了一个state计数器和持有线程引用。每次当前线程获取锁state加1每次解锁state减1只有state减到0锁才算真正释放其他线程才有机会获取。所以你在finally里写unlock时如果加锁了N次最后一定要解锁N次否则state不会归零。一个常用的排查方法在测试环境的锁方法里临时打印lock.getHoldCount()方法值看当前线程持有的锁次数是否异常累加这比肉眼检查代码快得多。注意在for循环里加锁多次再统一finally解锁这种操作不是没有但非常容易写错。我个人的习惯是加锁和解锁永远成对出现在同一个方法栈的相邻层级里避免隔山打牛式的解锁。2.3 lock()和tryLock()的选择差异Lock接口提供了三个获取锁的方法很多人分不清它们的使用时机lock()拿不到锁就死等直到拿到为止。和synchronized的等待行为最接近。tryLock()立即尝试获取锁拿不到就返回false绝不阻塞。tryLock(long timeout, TimeUnit unit)在指定时间内等待锁超时仍未拿到就返回false。我把它们的使用场景列了个表方便对比参考方法拿不到锁的行为可中断适用场景lock()一直等待不支持短临界区内严格互斥tryLock()立即放弃不能等待抢锁失败快速走其他分支tryLock(timeout)等待一段时间后放弃支持防止死锁、公平等待注意我表格里写的可中断lock()虽然在等待锁的时候不能被中断但如果获取到了锁在临界区内执行时响应线程中断信号是没有影响的。而tryLock(timeout)在等待锁期间是响应中断的等锁过程中被interrupt会直接抛出InterruptedException。tryLock()还有一个容易被忽略的细节它不遵守公平性设置无论这个锁是公平锁还是非公平锁tryLock()都会立即尝试获取一次锁凑热闹一样地往前挤。如果你依赖公平机制来保证线程执行顺序就别在关键路径上用无参tryLock()否则公平性会打折扣。3. 核心特性逐个拆解公平性、中断响应与超时控制3.1 公平锁和非公平锁性能和公平之间的博弈ReentrantLock有一个可选的构造参数专门控制公平性// 非公平锁默认 ReentrantLock lock new ReentrantLock(); // 公平锁 ReentrantLock fairLock new ReentrantLock(true);默认使用的是非公平锁。所谓非公平指的是当一个线程释放锁之后等待队列里有线程在排队但此时一个新来的线程可以直接抢锁它并没有排队却可能比排队的线程更早拿到锁。这个插队行为看起来不怎么正义但实际性能上往往更好。因为刚释放锁的线程还在热状态下新来的线程可能也是活跃的让其中一个立刻拿到锁执行可以减少线程切换和唤醒等待线程的开销。我能找到的很多性能测试也都表明在竞争中等或较低的场景下非公平锁的吞吐量要优于公平锁。公平锁的做法则是严格遵守FIFO原则谁排队最早谁先拿到锁。代价是线程频繁地阻塞和唤醒上下文切换开销大吞吐量相对低。什么时候必须用公平锁呢我的经验是当线程对持有锁的时长有强依赖且线程之间任务量差异特别大、怕小任务长年累月排不上号时才值得用公平锁去换一个执行顺序上的确定性。额外说一个细节公平锁虽然整体是FIFO但tryLock()方法是个例外它不排队直接试抢。如果某段逻辑依赖公平锁来防止饥饿结果又在同一段逻辑里调用了tryLock()这个公平性就形同虚设了。这点有必要牢记。3.2 用tryLock设计超时机制彻底摆脱死锁死锁最让人头疼的地方是它没有任何自愈手段系统一卡就是永远。synchronized时代我们只能靠人工干预重启应用来解困。ReentrantLock的tryLock(timeout)直接给了我们一套自救机制。来看一个经典的转账场景。线程A持有一把锁A尝试拿锁B线程B持有一把锁B尝试拿锁A。如果不加超时这就是教科书式的死锁。用tryLock(timeout)改写之后锁B拿不到时线程A会先释放已经持有的锁A然后退回重试死锁就不存在了。public boolean transferWithTimeout(Account from, Account to, int amount, long timeout, TimeUnit unit) { if (from.lock.tryLock(timeout, unit)) { try { if (to.lock.tryLock(timeout, unit)) { try { // 执行转账逻辑 from.balance - amount; to.balance amount; return true; } finally { to.lock.unlock(); } } } finally { from.lock.unlock(); } } return false; }这段代码有一个常见的坑使用tryLock时一定要把返回值判断放在if条件里只有返回true才说明拿锁成功也才需要在后面的finally里unlock。千万不要这样写from.lock.tryLock(timeout, unit); // 然后立刻操作共享资源不管tryLock是否成功代码都会往下走轻则逻辑出错重则在你根本没持有锁的情况下调用了unlock直接抛IllegalMonitorStateException。这种错误隐蔽性很强因为它的触发完全依赖竞争时序可能线上跑好几个月才出现一次。3.3 lockInterruptibly让等待中的线程听得见停止的指令如果说tryLock(timeout)是为了解决死锁那lockInterruptibly()就是为了让线程在等待锁的过程中能响应中断。这个方法在高频任务框架和线程池关闭流程里特别有用。想象一个场景线程池里有10个线程全部阻塞在lockInterruptibly()上等待一把锁。此时应用准备优雅停机调用了线程池的shutdownNow()方法这个方法会向所有线程发起中断请求。如果是synchronized或lock()等待方式这些线程根本不会反应但换成lockInterruptibly()等待它们就会抛出InterruptedException并退出等待。下面是标准的响应中断的写法public void run() { try { lock.lockInterruptibly(); } catch (InterruptedException e) { // 恢复中断状态通知上层调用者当前线程即将退出 Thread.currentThread().interrupt(); return; } try { // 执行受锁保护的代码 } finally { lock.unlock(); } }这里我特别想强调catch块里那行Thread.currentThread().interrupt()很多新手都会漏掉它。当线程被中断时Java会先把中断状态清除改成抛出异常。如果我们在catch块里什么都不做就return了中断信号就丢了上层调用方完全感知不到这个线程曾被打断。把interrupt状态原样恢复回去既是规范也是给上层代码一个记录和响应的机会。4. 源头看门道ReentrantLock的底层原理与实现4.1 AQS所有JUC锁的地基ReentrantLock能实现锁、条件队列、公平性这些能力底层依赖的既不是编译器特殊处理也不是什么黑魔法而是JUC包里的一个大管家——AbstractQueuedSynchronizer也就是常说的AQS。AQS可以类比成一个助手帮忙管理通行的闸门。闸门内部有一个int类型的state变量表示锁的大致状态还有一个FIFO等待队列来安排暂时没通过闸门的线程排队。ReentrantLock其实就是借用了AQS这套框架通过重写几个方法来实现专属的加锁和解锁逻辑。具体来说ReentrantLock内部定义了两个AQS的子类FairSync和NonfairSync分别对应公平锁和非公平锁的实现逻辑。两个类都重写了关键的方法来实现尝试获取锁和尝试释放锁的操作但获取锁时对待队列的先后顺序采取了不同的处理策略。state这个变量在ReentrantLock里就是持有锁的次数。有线程第1次获取锁时state从0变到1同一个线程再次获取锁state变成2解锁则每次减1。用这个整数来表示可重入的深度既直观又高效。4.2 非公平锁到底怎么插队CAS配合独占线程来分析一下非公平锁加锁的流程。当一个线程执行lock()时NonfairSync的目标很明确直接尝试通过CAS操作把state从0改成1。如果成功说明锁是空闲的这个线程直接拿走它当前没有任何排队线程参与竞争。如果CAS失败说明锁正在被别的线程持有那这个线程就不能硬闯了它得进入等待队列挂起。这里有一个容易误解的点非公平锁的非公平指的是锁恰好被释放的那一瞬间谁手快谁就能抢到新来的线程和排队的线程站在同一起跑线上没有先来后到之分。但如果锁没有释放新来的线程依然要老老实实排队不可能把已经持有锁的线程赶走。所谓插队其实就发生在锁从占用变为空闲的那个毫秒级窗口里。ReentrantLock底层用CAS这个无锁操作来更新state配合volatile变量保证多线程可见性非公平锁就这样以极小的开销实现了高频状态变更。也正因为如此非公平锁在低竞争场景下性能明显更好——恰恰是自身处于热状态的释放锁线程可能早就准备好了马上再次竞争与其让等待线程经历唤醒的黑盒延迟不如直接把锁给活跃线程。4.3 公平锁的排队检票机制公平锁的实现就差在获取锁之前多了一个条件判断只有当等待队列为空或者当前线程正好是排在队首的线程才允许它尝试用CAS获取锁。否则就不参与竞争直接去队尾排队。这个机制保证了线程获取锁的先后顺序与它们请求锁的时间顺序一致从逻辑上讲比非公平锁文明很多。但代价是每次获取锁前都要执行一次队列状态查询而且排队的线程被唤醒也需要时间。在高并发场景下活跃线程明明能立刻干活却因为要维护公平性而被迫等待队首线程被唤醒这白花花的性能就浪费掉了。这里有一个很实际的经验如果临界区代码足够短比如只有一次变量赋值用公平锁的代价会被无限放大。拿一个每秒执行几十万次的方法来说公平锁带来的排队检票开销和上下文切换会让吞吐量比非公平锁低一个量级。反过来如果临界区的核心逻辑要求严格的执行顺序就算非公平锁吞吐量高你也不能选它业务正确性永远排在性能前面。5. 实战中的坑与排查技巧5.1 锁泄漏是头号事故代码评审必查前面就反复提过ReentrantLock手动解锁遗忘unlock的后果非常严重。加锁后临界区快速执行完了不等于以后一定安全只要有一次异常路径漏掉了unlock锁就永久无法释放所有等待该锁的线程全部进入不间断阻塞状态。我在代码评审时习惯盯着每个lock()找对应的unlock()不是看它们是否存在而是看它们是否一定会被执行。规则很简单lock()后第一行就是tryfinally里只放unlock()中间不夹任何可能提前return的逻辑任何人都改不出问题。有些同事喜欢把unlock放在临界区内部的条件分支里能省一次无意义的调用但我真的不推荐这种优化完全没有收益反而是事故的温床。5.2 遇到锁失效先查是不是用了不同实例新手最容易踩的坑就是自以为加了锁实际加的是个寂寞。看一段典型的错误代码public class OrderService { public void createOrder() { ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 订单创建逻辑 } finally { lock.unlock(); } } }createOrder()方法里每次调用都new了一个全新的ReentrantLock对象。每个线程进来lock的都是自己刚new的锁根本不存在竞争所有线程都可以同时进入临界区。这种问题在静态方法、单例对象的非静态方法里都很容易出现一句话总结就是多个线程必须共享同一个锁对象实例。排查这种问题时我常常直接打印锁对象的identityHashCode来对比。不同线程下看到的是相同地址才有资格说是同一把锁如果hashCode各不相同赶紧去看实例创建方式。5.3 锁内代码扛不住异常甩锅给锁还有一种常见场景锁本身没问题但临界区里的代码抛了异常导致后续业务逻辑恶化。有一次线上系统突然出现大量线程阻塞排查日志发现某个接口的平均响应时间从50毫秒飙到30秒。最开始怀疑是锁竞争太激烈后来一看代码发现临界区里调用了一个外部HTTP接口这个接口的响应时间从100毫秒退化到了20秒锁就这样被外部服务的抖动拖垮了。这个教训催生了一条设计规则锁内代码必须短、快、纯。短是指临界区的代码行数尽量少快是指不要有耗时操作尤其是网络IO、磁盘IO、远程调用这一类纯是指锁内的逻辑不要依赖外部状态的稳定性否则异常一旦抛出锁释放是不可控的。如果有远程调用必须放在锁外可以先在锁内读取必要状态锁外执行调用再用锁内操作更新结果这就是常见的把IO移出锁的技巧。5.4 条件等待的假唤醒循环判断不能丢ReentrantLock搭配Condition使用await和signal时有一个Java规范一直在提醒的细节等待条件必须在循环里判断不能用if。核心原因有两条第一多线程竞争下可能有多个线程同时被唤醒如果唤醒后不重新检查条件状态就会在条件不满足时继续向下执行造成数据组装残缺或状态错乱。第二Java的条件等待存在假唤醒现象线程可能在没有收到任何signal的情况下自己醒过来。虽然实际遇到得少但规范层面它客观存在。正确姿势是把条件判断放进while循环lock.lock(); try { while (!conditionReady) { condition.await(); } // 条件满足时再执行后续 } finally { lock.unlock(); }这个while不是可写可不写的优化建议是必须遵守的硬性规则。不写while的条件等待在面试考到的时候是送命题在生产环境遇到诡异故障时是排查深渊。6. ReentrantLock与synchronized选型一个务实者的判断方法6.1 两者的核心差异一览很多Java学习者纠结的一个问题是既然synchronized自JDK 6以来做了大量优化引入了偏向锁、轻量级锁锁升级机制已经很成熟了那ReentrantLock还有必要学吗有必要用吗我的判断是必须学也必须会用但它未必是默认选项。两者在并发正确性上的作用相同——保证同一时刻只有一个线程执行临界区代码。真正的差异集中在灵活性上。我把关键区别整理成表特性synchronizedReentrantLock使用方式关键字自动加锁解锁显式API手动加锁解锁锁获取超时不支持tryLock(timeout)支持中断响应不支持lockInterruptibly()支持公平性非公平可选公平或非公平条件变量只有一个等待队列newCondition()可创建多个性能JVM自旋优化成熟高竞争场景更稳定这里面最容易被忽视的是条件变量的区别。synchronized配合wait/notify实际上只有一个等待队列一个notify随机唤醒任意一个线程而ReentrantLock可以new多个Condition把不同类型等待线程分开管理。典型场景是生产者-消费者模型一对Condition用于消费者的等待与唤醒另一对用于生产者的等待与唤醒分工明确唤醒精确不会出现只生产不出货之类的低效调度。6.2 我的选型倾向和理由每次做技术选型我都会把当前的业务场景往上面那张表里套一遍。如果在列出的需求里只要有一个和灵活性相关我就会用ReentrantLock。比如需要防止死锁希望加锁失败后能继续执行降级逻辑选ReentrantLock的tryLock。需要优雅停机希望等待锁的线程能响应中断并安全退出选ReentrantLock。需要多个等待队列或者说需要精确的按条件唤醒选ReentrantLock。代码里已经有大量JUC组件如ConcurrentHashMap、线程池全都是显式风格那引入ReentrantLock也很自然。反之如果项目里清一色synchronized且并发逻辑并不复杂为了保持整体代码风格统一我也会考虑继续用synchronized。关于性能如果竞争不激烈两者的差异基本可以忽略如果竞争非常激烈ReentrantLock通常能交出更稳定的成绩单特别是它提供了非公平锁的默认实现能在绝大多数高并发场景中保持低开销。但前提是你把它用对了手动lock/unlock的代码结构有问题的话性能再好也白搭。6.3 延伸一招tryLock中的优雅重试最后分享一个我在实际项目中反复用到的重试模式。当并发冲突较多时一次tryLock失败不代表任务失败可以退避一下再试public boolean doWithRetry(Runnable task, int maxAttempts, long waitMillis) { for (int attempt 0; attempt maxAttempts; attempt) { if (lock.tryLock(waitMillis, TimeUnit.MILLISECONDS)) { try { task.run(); return true; } finally { lock.unlock(); } } // 简单退避避免高频空转加重系统负担 LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(waitMillis / 2)); } return false; }注意退避时间不要设得太长否则任务延迟会显著增加。重试次数也要严格控制避免异常情况下线程长时间空转。这个模式的本质是把锁竞争当成一个暂时的、可重试的状态而不是致命的错误这比锁内重试或者死等的方案要健壮得多。这一套组合拳打下来ReentrantLock的核心知识基本就串起来了。从最常用的加锁模板到公平策略、中断响应、超时控制再到AQS底层的排队机制最后落到真实项目里的坑和选型思路我觉得能坚持看到这里的朋友应该都能做到心里有数了。自己在写代码时多留个心眼每一次lock都必须有unlock兜底每一个条件等待都必须用while包住每出现一次锁竞争都要多想一步能不能用tryLock给出路。并发编程的魅力从来不在于背熟多少API而在于你能预判代码在真实世界里的各种意外并提前给它们留好逃生通道。