ReentrantLock与synchronized区别详解

ReentrantLock 并非 synchronized 的简单升级，而是一套需开发者严格自律的锁管理机制——它赋予你尝试获取、可中断等待、超时控制、多条件变量等强大能力，但也要求你亲手用 try-finally 确保 unlock() 永不遗漏，否则极易引发悄无声息的“假死”故障；它默认高性能的非公平策略更贴合真实负载，而公平锁虽看似合理却代价高昂；真正决定其价值的，不是功能多寡，而是你在每处 lock() 后是否真的写对了 finally 释放、是否为每个阻塞点配上了中断或超时逃生通道——用错不是少个功能，而是整条服务链路瞬间凝固。

ReentrantLock 为什么不是“升级版 synchronized”而是“另一套玩法”

它和 synchronized 解决的是同一类问题（线程互斥），但底层机制、使用契约和出错逻辑完全不同。不是“更好用的 synchronized”，而是“你得自己管锁的生命周期”。JVM 不会帮你兜底，写错就容易死锁、漏释放、IllegalMonitorStateException。

• synchronized 是语法糖，加锁/解锁由 JVM 自动完成，哪怕抛异常也一定释放
• ReentrantLock 是普通对象，lock() 和 unlock() 是纯方法调用，不配 finally 就大概率泄漏锁
• 它不绑定任何对象实例或类，锁的存在完全独立于被保护的数据结构

必须手写 finally 释放锁，否则其他线程永远卡住

这是最常踩的坑：只在 try 块里 lock()，没在 finally 里 unlock()。一旦临界区抛异常，锁就再也放不出来了——后续所有线程在 lock() 处无限阻塞，现象就是程序“假死”，CPU 低、无报错、线程 dump 显示一堆 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject。

• 正确姿势：try { lock.lock(); /* 业务 */ } finally { lock.unlock(); }
• 千万别写成 if (lock.tryLock()) { ... unlock(); } —— 没捕获异常时，unlock() 根本不会执行
• 更别在不同分支里分别 lock()/unlock()，极易失配

lockInterruptibly() 和 tryLock(long, TimeUnit) 是真能救命的功能

synchronized 在等锁时完全无法响应中断，而 ReentrantLock 提供了两个关键逃生通道：被中断时放弃等待，或超时后主动退出。这在 IO 等待、RPC 调用、定时任务等场景中直接决定服务是否可用。

• lockInterruptibly()：线程在阻塞等待锁时，收到 interrupt() 会抛 InterruptedException 并立即返回，不持有锁
• tryLock(3, TimeUnit.SECONDS)：最多等 3 秒，超时返回 false，你可以选择重试、降级或快速失败
• 注意：tryLock()（无参）是立即返回，适合做“乐观尝试”，但不能替代带超时的版本

公平锁不是“更正确”，而是“更慢”，默认非公平才是生产首选

构造 ReentrantLock 时传 true 可启用公平模式，但这会让锁获取性能下降 2–5 倍（实测 JDK 17+）。因为要维护 FIFO 队列、避免插队，每次唤醒都要查队列头，还容易引发 CPU 缓存行竞争。

• 公平锁只在极少数场景必要：比如你明确观察到某线程长期饥饿，且该线程优先级极高（如监控告警线程）
• 默认非公平锁反而更符合真实负载特征——新线程抢到锁的概率略高，整体吞吐更高
• 别为了“心理安慰”开公平锁，压测前后对比 Thread.getState() 分布和 RT 才是依据

实际用的时候，最麻烦的从来不是功能多，而是每一步都得自己判空、捕异常、保释放、选策略。一个 unlock() 忘在 finally 里，整条线程链就卡死；一个 tryLock() 没配超时，下游超时熔断就失效。这些细节不落在代码里，光看文档根本意识不到。

今天关于《ReentrantLock与synchronized区别详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！