ReentrantLock不是synchronized的升级版，而是需手动管理锁生命周期的另一套机制：必须用try-finally确保unlock()执行，支持lockInterruptibly()和带超时的tryLock()，默认非公平锁性能更优。
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() 没配超时，下游超时熔断就失效。这些细节不落在代码里，光看文档根本意识不到。
