参考资料地址：https://pan.baidu.com/s/1r0d-WyGqvV8VOyUdrf4uRA?pwd=k5en
并发编程实战：从synchronized到ReentrantLock，破解高并发下的线程安全迷局
在Java并发编程的浩瀚海洋中，线程安全始终是那座必须翻越的“珠穆朗玛峰”。对于许多开发者而言，synchronized关键字曾是我们在多线程迷雾中唯一的灯塔，它简单、隐式且由JVM自动兜底。然而，随着高并发场景的日益复杂化，这座灯塔的光芒逐渐显得力不从心。从synchronized到ReentrantLock的演进，不仅仅是API的更替，更是一场关于控制权、灵活性与性能极致追求的思维跃迁。
synchronized的优雅在于它的“无脑”使用——进入代码块自动加锁，退出自动释放。在JDK 1.6之后，JVM对其进行了大量的优化，如偏向锁、轻量级锁的引入，使得它在低竞争场景下的性能已经非常出色。对于大多数基础的业务逻辑，它依然是首选，因为它将开发者从繁琐的锁释放逻辑中解放出来，避免了因忘记释放锁而导致的死锁风险。然而，它的局限性也恰恰在于这种“自动化”。它像是一个只有“开”和“关”的简单开关，一旦进入阻塞状态，线程只能无限期地等待，无法响应中断，也无法尝试在非阻塞的情况下获取锁。在复杂的业务场景中，这种“死板”往往成为系统稳定性的隐患。
ReentrantLock的出现，则是为了解决这些“死板”的问题。它代表了显式锁的崛起，将锁的控制权完全交还给了开发者。这种控制权的转移，带来了synchronized无法比拟的灵活性。首先是“可中断”特性，在ReentrantLock的世界里，一个正在等待锁的线程可以被其他线程中断，从而优雅地退出等待，避免了资源的无谓消耗。其次是“超时尝试”，通过tryLock方法，线程可以尝试获取锁，如果在规定时间内获取不到，便可以选择放弃或执行降级策略，这对于防止系统雪崩至关重要。
更为核心的差异在于公平性的选择。synchronized永远是非公平的，这意味着后到的线程可能“插队”成功，导致先到的线程长期处于饥饿状态。而在ReentrantLock中，我们可以通过构造函数指定是否为公平锁。虽然公平锁会带来一定的性能损耗，但在某些对顺序有严格要求的业务场景下（如FIFO的任务队列），它是保证业务逻辑正确性的唯一选择。此外，ReentrantLock配合Condition接口，能够实现比wait/notify更精准的线程通信，支持多路通知，让多线程协作变得如同指挥交响乐般精准。
然而，能力的增强往往伴随着责任的加重。ReentrantLock要求开发者必须在finally块中手动释放锁，任何疏忽都可能导致灾难性的后果。这不仅是编码规范的考验，更是对开发者心智模型的挑战。在高并发的实战中，选择synchronized还是ReentrantLock，本质上是在“易用性”与“控制力”之间做权衡。对于简单的同步需求，synchronized依然是简洁高效的王者；而对于那些需要响应中断、超时控制或公平调度的复杂战场，ReentrantLock则是我们手中不可或缺的利剑。只有深刻理解两者的底层逻辑与适用边界，我们才能在并发编程的迷局中游刃有余，构建出既安全又高效的系统。