Java并发锁详解：从synchronized到Lock实现类与AQS底层原理

面试里有一类问题特别能看出候选人对并发编程的理解深度那就是“你说说synchronized和Lock接口的区别顺便讲一下Lock有哪些实现类”说实话能把这个问题答得完整又准确的人真的不多。大多数人能蹦出一句“synchronized是关键字Lock是接口”后面就悬空了。但Lock接口java.util.concurrent.locks.Lock恰恰是JUC并发体系的基石之一它背后的实现类撑起了读写锁、乐观锁、锁降级这些高级特性无论是在面试还是在实际项目中都是绕不开的核心知识点。这是“面试必知必会”系列的第6篇我准备按面试官追问的思路从设计动机、核心方法、实现类源码、实操模板到高频坑位把Lock接口彻底盘一遍。这篇不是教科书式的方法罗列而是把每个考点背后的原理、取舍、踩坑全部掰开揉碎讲给你听。不管你是准备校招、社招还是项目里正纠结该用synchronized还是Lock又或者今天才第一次听说Lock接口这篇文章都能让你有收获而且读完就能用上。1. 从synchronized的短板说起1.1 synchronized真正管不了的事JDK 1.5之前Java内的同步手段基本只有synchronized。虽然JDK 1.6之后JVM对synchronized做了大量优化引入了偏向锁、轻量级锁、重量级锁的升级路径性能早就不是它最大的问题了。可它仍然有绕不过去的能力边界——synchronized把锁的获取和释放写死在了语言层面开发者只能“用锁”不能“操作锁”。我举几个实际场景你就明白了。比如你希望尝试获取锁拿不到就立刻走别的分支不傻等synchronized做不到。又比如你希望一个线程在等待锁的过程中能被其他线程中断从而有机会提前退出synchronized也做不到。再有你希望实现读读共享、读写互斥、写写互斥的锁让多个读线程同时进临界区只有写线程才独占synchronized更是根本没这个概念。这些需求在真实业务里太常见了所以Lock接口应运而生。这里要专门纠正一个流传很广的误解很多教程爱说“synchronized性能不如Lock”这是典型的以讹传讹。经过JVM这么多年的优化synchronized在其适用场景下性能并不差甚至低竞争场景下还可能更快。Lock的真正价值在于它把锁抽象成一个对象让获取、释放、尝试、超时、中断都变成可程序化控制的行为。这个“能力边界”层面的差异才是面试时真正要讲出来的点。1.2 锁从“关键字”到“对象”的思维转变synchronized是结构化锁进入代码块自动拿锁退出代码块自动释放简单可靠但灵活性约等于零。Lock则把一把锁当作普通的Java对象来用你可以持有它、传递它、尝试获取它、在指定时间内等待它甚至可以随时决定“不伺候了老子不等了”。这就是锁的“对象化”。对象化之后很多高级玩法才成为可能读写分离的ReadWriteLock乐观读的StampedLock还有配合Lock使用的Condition条件变量本质上都是把锁的能力细化、模块化之后衍生出来的。从面试角度说能解释清楚这一层设计动机的人就不多了。面试官问“为什么有了synchronized还要Lock”你如果只回答“Lock能超时能中断”说得对但不够你如果能补上“因为synchronized把锁固定死在语言层面而业务需要以对象方式控制锁”这个答案的含金量立马不一样。2. Lock接口核心方法与语义2.1 六个核心方法逐个拆Lock接口的源码非常简洁一共6个方法。但它们各自的语义差异恰恰是整个Lock体系里最容易被面试官做文章的地方。void lock()获取锁。获取不到就阻塞等待而且这个阻塞不响应中断跟synchronized的行为很接近。void lockInterruptibly() throws InterruptedException获取锁但优先响应中断。如果线程在等待中被interrupt()会立刻抛出InterruptedException不再继续等。boolean tryLock()尝试获取锁立即返回。成功返回true失败返回false绝对不阻塞。boolean tryLock(long time, TimeUnit unit) throws InterruptedException在给定时间内尝试获取锁超时返回false等待期间也能响应中断。void unlock()释放锁。Condition newCondition()返回绑定在当前Lock实例上的Condition对象用于实现比wait/notify更精细的条件等待。我见过不少候选人把lock()和lockInterruptibly()当成一回事这个要命。lock()是会傻等到底的即使线程被设置了中断标志它也不会醒直到拿到锁为止。而lockInterruptibly()是“可以被打断的等待”中断信号一到立刻抛弃抢锁行为。这两者的本质区别在5.3节我会结合场景详细说。2.2 从方法设计看锁的“边界意识”为什么Lock接口要设计成这几种方法这其实是在考察你对同步控制本质的理解。锁的本质是互斥但互斥只是最底层的需求。真实业务里我们往往需要在“互斥”之上叠加“让步、放弃、观察”这些策略。lock()回答的是“我就是死等不给我锁我就不干活”tryLock()回答的是“我能拿就拿拿不到我干别的”带超时的tryLock()回答的是“我愿意等但只能等到某个时刻”lockInterruptibly()回答的是“我一边等一边还对外界的中断保持敏感”。这四类需求对应四种不同的方法签名。理解了这层语义你就不会在面试时只背签名而是能顺着业务场景把每个方法的使用方式讲得头头是道。另外newCondition()也是一个高频考点。synchronized只能配合Object的wait/notify/notifyAll而Lock可以创建多个独立的Condition条件队列让不同的线程在不同的条件上等待。比如一个生产者消费者模型你可以让“缓冲满时等待的生产者”在fullCondition上等待让“缓冲空时等待的消费者”在emptyCondition上等待用signal()精确唤醒对应线程而不是用notifyAll把所有人都摇起来再各自检查。这种更细粒度的等待模型是synchronized完全给不了的。3. 面试高频Lock与synchronized的对比3.1 一张表看懂六个维度的差异面试官问“synchronized和Lock有啥区别”正确答案不是一个点而是一组点。我建议你心里先有一张六维对比表再逐条展开解释。对比维度synchronizedLock接口存在形式关键字JVM层面接口Java类层面锁的获取进入同步块时自动获取显式调用lock()或tryLock()锁的释放方法正常退出或异常时自动释放必须在finally中手动unlock()响应中断不支持等待锁时不可中断lockInterruptibly()可响应中断超时等待不支持tryLock(timeout, unit)支持公平性默认非公平无法设置实现类可指定公平或非公平你光把这个表背下来还不够得能展开说明。比如“自动释放”听起来是优点但反过来也意味着你完全没有控制权“显式释放”听起来麻烦但它给了你决定“什么时候释放”的自由这对实现复杂的同步协议至关重要。每个差异背后都有一组取舍面试官要的就是你能讲出这组取舍。3.2 为什么Lock还是取代不了synchronized面试官很爱在你说完差异之后追问一句“既然Lock这么强那为什么Java官方不干脆淘汰synchronized”这个问题答好了才算真的理解锁机制。首先synchronized是语言层面的强制约束它根本不存在“忘了释放”这种问题因为JVM替你兜底了。哪怕你的同步块里抛出异常锁也会自动释放绝不会因为异常导致死锁。而Lock必须手动unlock一旦漏了系统就会出现莫名其妙的阻塞排查起来非常痛苦。从工程安全性来说synchronized的容错率要高得多。其次JVM层面持续在给synchronized做优化。偏向锁、轻量级锁、重量级锁的升级路径加上JIT编译器的大量优化让它在竞争不激烈的场景下性能非常能打和Lock差距很小甚至反超。很多大型框架和公司的代码规范里仍然优先推荐synchronized原因不是技术落后而是它在简单场景下的代码简洁度、可靠性和性能都足够好。所以面试时千万别说“Lock是来替代synchronized的”。正确的说法是Lock是对synchronized能力边界的补充和扩展两者是共存关系。把这句话放在对比总结里考官对你的印象分一下就上来了。4. 实现类源码级拆解4.1 AQS所有Lock实现类的公共地基在揭晓各个实现类之前必须先讲AQSAbstractQueuedSynchronizer因为ReentrantLock、ReentrantReadWriteLock乃至Semaphore、CountDownLatch底层全部是建立在AQS之上的。面试题里凡是问到“Lock底层原理”九成绕不开AQS。AQS的核心就两块一个volatile int类型的state字段加上一个CLH变体队列实际上是一个双向链表。state的含义在不同实现类里完全不同。对ReentrantLock来说state表示锁的重入次数对ReentrantReadWriteLock来说state被拆成高16位和低16位分别代表读锁数量和写锁状态对Semaphore来说state表示剩余许可数量。这种设计非常精妙——AQS不关心state的具体含义它只负责在state变化时维护排队和唤醒的逻辑。自定义同步器时通常只需要重写tryAcquire、tryRelease或者tryAcquireShared、tryReleaseShared这几个方法然后在当前线程首次获取锁时把持有线程记录到一个ThreadLocal里以此支持可重入。面试时你只要能把“state状态字段 同步队列 独占/共享两种模式”讲清楚再配合ReentrantLock的例子说明state如何表示重入次数这个题基本就稳了。4.2 ReentrantLock可重入独占锁的教科书ReentrantLock是Lock接口最常用的实现不出意外的话你项目里手写的Lock代码九成都是它。它是独占锁同一时刻只有一个线程能持有锁。它的内部类Sync继承自AQSSync下又有两个子类NonfairSync和FairSync分别对非公平锁和公平锁。默认构造的ReentrantLock是非公平锁只有传true才是公平锁。两者核心区别就在获取锁的第一步非公平锁在lock()时先尝试用CAS直接抢一次state哪怕同步队列里已经有人排着队它也先抢为敬抢不到才乖乖进队列排队公平锁则严格遵守FIFO只有在队列为空或当前线程已经在队首时才去尝试获取锁。就这么几行代码的差异带来了吞吐量和公平性之间的巨大取舍。为什么JDK默认非公平因为线程的阻塞和唤醒开销远高于CAS抢锁。非公平锁允许新来的线程直接抢占避免了一次无意义的阻塞和唤醒因此在竞争激烈场景下整体吞吐量通常更高。代价是排队线程可能一直抢不到锁存在“饥饿”风险。但实际业务里配合超时机制这个风险多数场景可接受。这个“为什么会这样设计”的回答比单纯背书值钱得多。4.3 ReentrantReadWriteLock读写分离与锁降级ReentrantReadWriteLock是读写锁的实现类它同时提供readLock()和writeLock()两个Lock接口。规则是读读共享、读写互斥、写写互斥。也就是说多个线程可以同时持有读锁但读锁与写锁、写锁与写锁之间不能共存。为什么需要读写锁因为大量业务是“读多写少”。比如缓存组件、配置数据、热点数据加载多个读线程并发访问是安全的只有写线程才需要独占。如果全用独占锁读线程之间互相阻塞白白浪费并发能力。读写锁让读线程之间不再排队只在读与写之间建立互斥这就能把并发度拉高一个量级。面试官对读写锁问得最多的是“锁降级”。锁降级是指当前线程持有写锁不释放写锁的情况下再获取读锁然后释放写锁这样锁就由写锁降级为读锁。为什么要绕这么一圈因为在你持有写锁完成数据修改后后续还有读操作。如果先释放写锁再拿读锁中间可能插进另一个写线程修改数据导致本次读到脏数据。锁降级能保证“写后读”的整个区间内没有其他写线程能够介入。这里必须强调锁升级是绝对不行的——持有读锁的线程再获取写锁必然死锁因为写锁要求没有任何读者存在而你自己就是读者逻辑上自相矛盾。4.4 StampedLock乐观锁思路的新选手StampedLock是JDK 8引入的高级锁它提供三种模式写锁writeLock、悲观读锁readLock和乐观读tryOptimisticRead。乐观读是最有特色的模式它不加锁直接读取数据然后凭一个long类型的stamp版本号来校验读取期间有没有发生写操作。乐观读的典型流程是先调用tryOptimisticRead拿到stamp然后读共享数据最后调用validate(stamp)校验。如果validate返回true说明读取期间没有写操作这次读的是安全数据如果返回false再退化为悲观读锁重新读一遍。这就像你先按快照读发现版本没变就万事大吉版本变了再走重读流程。在并发不高、写操作少且短暂的场景下这种策略能大幅降低锁竞争带来的开销。但StampedLock也有明显短板它是不可重入的同一个线程不能反复拿锁它不支持Condition条件变量如果使用不当还容易死锁。面试里只要能说出“它无锁读取靠stamp校验、与ReadWriteLock关键差异在于乐观读支持”就已经是加分回答了。5. 实操模板与三个高频坑5.1 三个标准代码模板先抄走纸上谈兵再多最后都要落实到代码。用Lock有三个代码模板我建议你直接形成肌肉记忆。第一个是最基础的“获取并释放”模板。lock()必须放在try外面不能放在try里面Lock lock new ReentrantLock(); lock.lock(); try { // 业务代码 } finally { lock.unlock(); }为什么必须放try外面因为如果lock()本身抛了异常说明根本没拿到锁此时进finally执行unlock反而可能释放掉别的线程的锁。把这个细节写对面试官会觉得你写代码是有思考的。第二个是“条件尝试”模板。tryLock()要判断返回值拿到锁才进临界区拿不到走else分支if (lock.tryLock()) { try { // 获取成功执行业务 } finally { lock.unlock(); } } else { // 没拿到锁走降级或快速失败逻辑 }第三个是“带超时的尝试”模板我习惯配合System.currentTimeMillis()来计算剩余时间long deadline System.currentTimeMillis() 3000; boolean acquired false; while (!acquired) { long remaining deadline - System.currentTimeMillis(); if (remaining 0) { break; } if (lock.tryLock(remaining, TimeUnit.MILLISECONDS)) { acquired true; } } if (acquired) { try { // 业务代码 } finally { lock.unlock(); } } else { // 超时未获取做好降级处理 }tryLock(long, TimeUnit)在等待时间内是能够响应中断的因此会抛出InterruptedException。很多人在业务里直接catch吞掉中断异常这其实很不好。正确的做法是恢复中断状态调用Thread.currentThread().interrupt()让上层调用方知道该线程曾被中断过。5.2 坑一finally里漏掉unlock这恐怕是Lock使用中排名第一的生产事故来源。无论是lock()、tryLock()成功还是lockInterruptibly()只要是真正拿到了锁就必须确保执行路径能释放锁。最稳妥的写法就是把unlock放在finally块里而且这个习惯要在写第一行Lock代码时就养成。我自己就吃过这个亏。有一次写一个任务调度组件按模板写完lock和unlock后来改了中间一段业务逻辑提前return了一个结果正好把finally里的unlock绕过去了。当时线上测试CPU飙高后续任务全部卡在等待锁上排查了两个多小时才定位到是锁没释放。那次事故之后我在团队里立了一条规矩所有Lock的使用代码review时必须先看finally里有没有unlock没有的一律打回。5.3 坑二tryLock返回值没处理tryLock()返回false代表没拿到锁这时候如果你没加if判断直接往里走再等finally里unlock后果很可能就是释放了别人的锁或者把临界区代码在锁竞争失败时也执行了一遍。尤其是当你要用tryLock实现“拿不到锁就换一条路走”的策略时忘记判断返回值等于白写。所以用tryLock时我总是要求自己写完整两个分支拿到锁的分支里业务代码正常执行并在finally中unlock没拿到锁的分支里不管是否做业务降级都要有明确的处理逻辑。哪怕降级处理只是打印一行日志也不能空着否则很容易让人误以为这里的锁逻辑不完整。5.4 坑三持锁状态下再拿其他锁造成死锁Lock是可重入的只针对同一把锁不是针对所有锁。当线程持有锁A时去获取锁B而另一个线程恰好持有锁B在等锁A恭喜你死锁出现。尤其在多锁嵌套的业务里这种问题极其隐蔽。规避死锁有三个常用手段一是尽量缩小锁的范围能用一个锁就别用两个二是如果确实需要多把锁尽量固定获取锁的顺序比如始终先取A再取B避免交叉三是善用带超时的tryLock等待超时后立即放弃并释放已经持有的锁而不是无限阻塞下去。面试官问“如何避免死锁”你能答出这三点再加上“尽量使用超时获取锁”这一条基本就是满分答案了。6. 面试官追问清单6.1 高频追问与参考回答我把这些年面试中被反复追问的Lock相关问题整理成一个速查表你可以在面试前过一遍看看自己能不能每个都答出核心点。追问方向核心作答要点synchronized和Lock选哪个简单场景优先synchronized需要超时、中断、公平性、多条件时用Locklock()和lockInterruptibly()区别前者不响应中断后者等待中可被中断并抛出InterruptedExceptiontryLock和lock怎么选tryLock适合非阻塞快速失败lock适合必须获取才继续的场景ReentrantLock公平与非公平公平锁按FIFO排队非公平锁先抢一次再排队吞吐更高可重入原理state记录重入次数每次加1释放递减到0才真正释放读写锁的锁降级写锁持有中获取读锁再释放写锁保证写后读区间无写线程插入StampedLock与ReadWriteLock差异前者支持乐观读无锁校验版本但不可重入、不支持ConditionAQS是什么state状态字段同步队列锁语义由子类自定义6.2 个人体会与小建议最后聊聊我个人的观察。很多人准备并发编程面试喜欢疯狂背题把Lock的实现细节背得滚瓜烂熟可一到让写代码的环节就露馅。我建议你学Lock时换个方法不要从接口定义开始而是先从业务场景倒推。比如你在设计一个缓存工具要保证并发安全又要尽量提高读并发度你会想到用什么想明白这个问题你就自然理解了为什么有读写锁、为什么有乐观锁理解了一个工具存在的意义之后它的实现细节根本不需要死记。还有一个小技巧写项目代码时可以刻意在一两个模块里用tryLock(long, TimeUnit)代替lock()让代码在最恶劣的锁竞争情况下也不会无限卡死。这个习惯会在关键时候救你一命尤其是生产环境的故障排查里你能很快分清“业务本来就慢”和“线程卡在锁上出不来”之间的区别。最后再多啰嗦一句Lock虽然灵活但带来的责任也更大永远记得在finally里释放锁永远记得给tryLock配if判断这两条做到你的并发代码就成功了一大半。