1. 从 synchronized 到 Lock为什么需要另一把锁刚接触 JUC 并发包那会儿我脑子里一直有个疑问既然synchronized已经能解决线程安全问题为什么还要搞出一个Lock接口后来在一个订单扣减库存的模拟场景里踩了坑才真正理解这俩不是替代关系而是互补关系。Lock是java.util.concurrent.locks包下的核心接口最常用的实现是ReentrantLock。它解决的问题很具体synchronized是隐式锁加锁释放锁全由 JVM 自动完成灵活度低而Lock把锁的控制权交到开发者手里可以手动加锁、手动释放还能实现可中断、可超时、公平锁这些synchronized做不到的事情。这篇文章适合已经会写多线程、用过synchronized但想进一步掌握Lock体系的人。我会从设计思路讲到实操代码把ReentrantLock、ReentrantReadWriteLock、Condition这几个核心组件拆开揉碎再补上我实际调试中遇到的坑。看完你应该能判断什么场景该用Lock什么场景老老实实用synchronized就行。2. Lock 接口的整体设计与选型逻辑2.1 为什么 Lock 要设计成接口而不是类很多人第一次看Lock源码会疑惑它就定义了几个方法为什么不做成抽象类这背后是 Java 集合框架一贯的设计哲学——面向接口编程把锁的行为和锁的实现彻底解耦。Lock接口只规定了能加锁、能解锁、能尝试加锁、能中断加锁这几件事至于底层是用 AQSAbstractQueuedSynchronizer队列实现还是用别的机制接口不关心。这样一来ReentrantLock、ReentrantReadWriteLock.ReadLock、ReentrantReadWriteLock.WriteLock都能实现同一套接口上层代码调用方式统一。我个人的理解是synchronized像是家里的防盗门锁上就锁上你没法中途改主意Lock像是带遥控的智能锁你可以设定等 3 秒没人开门就放弃、有人按门铃就中断等待、优先让排队最久的人进。灵活性的代价就是你必须记得手动关门忘了就是灾难。2.2 Lock 与 synchronized 的核心差异对照选型之前先把两者的差异摆清楚。我整理了一张表这些点在实际开发中都会直接影响你的决策对比维度synchronizedLock以 ReentrantLock 为例锁的获取释放隐式JVM 自动管理显式必须手动 unlock是否可中断不可中断lockInterruptibly 可中断是否可超时不支持tryLock(timeout) 支持是否公平锁只能非公平可选公平/非公平条件变量单一 wait/notify多个 Condition 精准唤醒锁信息获取无法查询可查询持有线程、等待队列代码简洁度简洁不易出错繁琐易漏 unlock从表里能看出来synchronized的优势是简单安全Lock的优势是灵活可控。我的一般原则是能用synchronized解决的就别上Lock只有当确实需要超时、中断、公平性或者多条件唤醒时才切换到Lock。2.3 ReentrantLock 的可重入性到底意味着什么可重入这个词初学者容易懵。说白了就是同一个线程已经拿到了锁再进一次被同一把锁保护的代码还能直接拿到不会被自己卡死。举个生活化的例子你拿着自家钥匙进了门进门后想进卧室不需要再掏一次钥匙重新开大门。如果锁不可重入线程第二次请求自己已持有的锁时就会死等直接把自己锁死。ReentrantLock内部维护了一个持有计数每重入一次计数加一每 unlock 一次计数减一减到零才真正释放锁。这一点和synchronized行为一致但Lock要求你 unlock 的次数必须和 lock 次数严格匹配多一次少一次都会出问题。注意可重入计数是ReentrantLock内部状态你无法直接读取但可以通过getHoldCount()方法查看当前线程的重入次数调试死锁时很有用。3. ReentrantLock 核心方法逐个拆解3.1 lock 与 unlock 的标准写法最基础的用法就是lock()加锁、unlock()释放。但这里有个铁律unlock()必须放在finally块里。我见过太多新手把 unlock 写在业务代码后面一旦中间抛异常锁永远释放不了整个系统就卡死了。标准模板长这样ReentrantLock lock new ReentrantLock(); public void doSomething() { lock.lock(); try { // 临界区业务逻辑 processData(); } finally { lock.unlock(); } }为什么lock()要放在 try 外面因为如果lock()本身抛异常虽然极少你还没拿到锁这时候去 unlock 会抛IllegalMonitorStateException。所以正确顺序是先 lock再进 tryfinally 里 unlock。3.2 tryLock 的两种形态与实战价值tryLock()是Lock相比synchronized最实用的能力之一。它有两个重载tryLock()立即返回拿到锁返回 true拿不到返回 false不等待。tryLock(long timeout, TimeUnit unit)在指定时间内尝试超时返回 false期间可被中断。这个能力在什么场景下救命比如秒杀系统里多个线程抢同一件商品的库存锁如果用lock()抢不到的线程会一直排队阻塞线程池很快被占满。用tryLock()就能让抢不到的线程立刻返回系统繁忙把资源让给其他请求。if (lock.tryLock(500, TimeUnit.MILLISECONDS)) { try { // 抢到锁处理库存扣减 deductStock(); } finally { lock.unlock(); } } else { // 500ms 没抢到直接降级返回 return 当前请求过多请稍后重试; }实测下来这种快速失败策略在高并发下比无脑阻塞的吞吐量高出一大截因为它避免了大量线程堆积在锁队列里空耗 CPU。3.3 lockInterruptibly 与线程中断的配合lockInterruptibly()和lock()的区别在于等待锁的过程中如果线程被interrupt()它会抛InterruptedException并放弃等待。而lock()是忽略中断的会一直等到拿到锁为止。这个特性在需要优雅关闭线程池的场景里特别重要。比如你有一个后台任务线程在等锁主线程要关闭它调用interrupt()后如果用的是lockInterruptibly()任务能立刻响应中断退出如果用的是lock()它可能还在傻等导致关闭流程卡住。public void taskWithInterrupt() throws InterruptedException { lock.lockInterruptibly(); try { // 业务逻辑 } finally { lock.unlock(); } }提示lockInterruptibly()抛出的InterruptedException必须处理要么往上抛要么捕获后恢复中断状态Thread.currentThread().interrupt()别默默吞掉。3.4 公平锁与非公平锁的选择ReentrantLock构造时可以传一个 boolean 参数true 表示公平锁false默认表示非公平锁。公平锁的意思是线程按请求锁的先后顺序排队获取先到先得。非公平锁则允许插队——新来的线程如果刚好赶上锁释放可以直接抢不用管队列里有没有人在等。那是不是公平锁更好不是。公平锁虽然公平但吞吐量明显低于非公平锁因为每次唤醒排队线程都有上下文切换开销而且严格排队会让 CPU 利用率下降。非公平锁虽然可能让某些线程饿死但实际中概率很低性能却好得多。我的经验是绝大多数场景用默认的非公平锁就够了。只有当你明确需要避免线程饥饿比如某些任务对响应顺序有严格要求时才考虑公平锁。// 非公平锁默认推荐 ReentrantLock unfairLock new ReentrantLock(); // 公平锁按需使用 ReentrantLock fairLock new ReentrantLock(true);4. Condition 条件变量精准唤醒的艺术4.1 为什么需要多个 Conditionsynchronized配合wait/notify有个硬伤一个锁对象只有一个等待队列notify()唤醒的是随机一个等待线程你没法指定唤醒生产者还是消费者。这在生产者-消费者模型里会导致唤醒错人的问题——生产者唤醒了另一个生产者结果大家都空转。Condition就是来解决这个问题的。一个ReentrantLock可以创建多个Condition每个 Condition 维护自己的等待队列。生产者等在一个 Condition 上消费者等在另一个上唤醒时各叫各的精准高效。4.2 await 与 signal 的正确使用姿势Condition的核心方法就三个await()让当前线程等待并释放锁signal()唤醒一个等待线程signalAll()唤醒全部。关键点在于await()会释放锁被唤醒后会重新竞争锁拿到锁才从 await 返回。所以调用 await/signal 之前必须持有对应的锁否则抛IllegalMonitorStateException。ReentrantLock lock new ReentrantLock(); Condition notFull lock.newCondition(); Condition notEmpty lock.newCondition(); QueueString queue new LinkedList(); int capacity 10; public void produce(String item) throws InterruptedException { lock.lock(); try { while (queue.size() capacity) { notFull.await(); // 队列满生产者等待 } queue.add(item); notEmpty.signal(); // 唤醒一个消费者 } finally { lock.unlock(); } } public String consume() throws InterruptedException { lock.lock(); try { while (queue.isEmpty()) { notEmpty.await(); // 队列空消费者等待 } String item queue.poll(); notFull.signal(); // 唤醒一个生产者 return item; } finally { lock.unlock(); } }4.3 为什么 await 必须放在 while 循环里这是并发编程里最经典的坑之一。很多人写成if (条件不满足) await();结果出现虚假唤醒spurious wakeup时逻辑就崩了。虚假唤醒是指线程在没有被 signal 的情况下也可能从 await 返回这是操作系统层面的正常现象。用 while 循环重新检查条件被唤醒后如果条件还是不满足就继续等才能保证正确性。// 错误写法 if (queue.isEmpty()) { notEmpty.await(); } // 正确写法 while (queue.isEmpty()) { notEmpty.await(); }注意这个 while 规则和synchronized里的wait()完全一致是并发编程的铁律别偷懒用 if。5. 读写锁 ReentrantReadWriteLock 的适用场景5.1 读读不互斥的设计初衷ReentrantLock是排他锁同一时刻只允许一个线程访问。但现实中很多场景是读多写少比如缓存、配置中心。如果读操作也互斥性能浪费严重。ReentrantReadWriteLock把锁拆成读锁和写锁读锁之间共享多个线程可以同时读写锁排他写的时候不允许任何其他读写。这样在读多写少的场景下并发度能大幅提升。锁组合是否互斥读锁 读锁不互斥可并发读锁 写锁互斥写锁 写锁互斥5.2 读写锁的降级与升级规则读写锁有个容易搞混的点锁降级可以锁升级不行。锁降级是指持有写锁的线程可以再获取读锁然后释放写锁最后持有读锁。这个过程是允许的用于保证数据可见性。锁升级是指持有读锁的线程去获取写锁。这个会直接死锁因为读锁还没释放写锁永远等不到。所以千万别在持有读锁时去申请写锁。// 锁降级示例 readWriteLock.writeLock().lock(); try { // 修改数据 updateData(); readWriteLock.readLock().lock(); // 获取读锁 } finally { readWriteLock.writeLock().unlock(); // 释放写锁此时仍持有读锁 } try { // 读取数据保证看到自己刚写的 readData(); } finally { readWriteLock.readLock().unlock(); }5.3 读写锁的实战选型建议读写锁不是万能的。如果写操作占比很高读写锁反而比普通排他锁慢因为它内部维护了更复杂的状态。我一般这样判断读操作占比超过 70% 且读操作耗时较长时才考虑读写锁否则直接用ReentrantLock或synchronized更省心。另外ReentrantReadWriteLock也支持公平和非公平模式默认非公平。非公平模式下读锁可能被后来的写锁插队导致读线程饥饿这点在高并发读场景下要留意。6. 实操中踩过的坑与排查技巧6.1 unlock 漏写导致的死锁排查我遇到过一次线上事故某个接口偶尔超时重启后恢复过一阵又出现。用jstack抓线程栈发现大量线程卡在WAITING状态持有锁的线程却已经执行完了业务逻辑。排查后发现代码里有个分支提前 return 了而 unlock 写在 return 之后导致这条路径锁没释放。这就是典型的unlock 没放 finally问题。排查这类问题的套路用jstack pid导出线程栈搜索waiting to lock关键字。找到持有锁的线程看它在干什么。如果持有锁的线程已经消失或卡在别处基本就是漏 unlock。提示ReentrantLock提供了getOwner()、getQueuedThreads()、isLocked()等方法可以在监控代码里定期打印锁状态提前发现异常。6.2 锁粒度过大引发的性能问题另一个常见坑是锁粒度过大。比如把整个方法都用锁包起来里面还包含数据库查询、远程调用这些耗时操作结果所有线程都堵在锁上QPS 上不去。解决办法是缩小临界区只把真正需要互斥的代码放进锁里耗时操作挪到锁外面。比如先查数据库拿到数据再进锁更新内存状态。// 优化前锁包住整个方法 lock.lock(); try { Data data queryFromDb(); // 耗时 updateCache(data); } finally { lock.unlock(); } // 优化后只锁关键部分 Data data queryFromDb(); // 锁外执行 lock.lock(); try { updateCache(data); } finally { lock.unlock(); }6.3 常见问题速查表问题现象可能原因排查方向线程一直 WAITING漏 unlock 或死锁jstack 看锁持有者抛 IllegalMonitorStateException未持锁调用 await/unlock检查 lock 与 unlock 配对性能突然下降锁粒度过大或公平锁缩小临界区改非公平读线程饥饿非公平读写锁写优先考虑公平模式或调整策略虚假唤醒导致逻辑错乱await 用了 if 而非 while改为 while 循环检查6.4 几个容易被忽略的细节第一ReentrantLock的newCondition()可以调用多次每次返回新的 Condition 对象别重复用同一个 Condition 去管不同条件。第二tryLock()不带超时的版本即使当前线程已经持有锁也会返回 true可重入这点和lock()一致。第三读写锁的读锁不支持 Condition只有写锁能创建 Condition因为读锁是共享的没法做排他等待。第四Lock的锁信息查询方法如getQueueLength()返回的是估计值不保证精确用于监控可以用于业务判断不行。7. 我的实操体会与选型建议用了几年Lock之后我总结出一条朴素的原则默认用 synchronized需要高级特性时才上 Lock。这不是保守而是因为synchronized在 JDK 后续版本里做了大量优化偏向锁、轻量级锁、锁消除性能已经不比ReentrantLock差多少而且它不会因为漏 unlock 出事故。真正让我切换到Lock的场景就那么几类需要tryLock做快速失败降级、需要lockInterruptibly支持任务取消、需要多个Condition做精准唤醒、需要读写分离提升并发。除此之外synchronized足够。最后分享一个小技巧如果你在调试并发问题可以在关键锁的 lock 和 unlock 前后加上线程名和时间的日志配合jstack一起看定位死锁和锁竞争的效率会高很多。日志别打太密否则本身就成了性能瓶颈。这个度需要根据实际压测结果来调我一般只在排查阶段临时开启问题定位后立刻关掉。