synchronized 是 Java 关键字，属于 JVM 层面的内置隐式锁；ReentrantLock 是 java.util.concurrent.locks 包下的类，属于 API 层面的显式锁。它们的主要区别体现在使用方式、功能性、灵活性和底层实现上。
一句话概括：synchronized 简洁、自动，ReentrantLock 强大、灵活。在无需高级功能的场景下，优先推荐使用 synchronized；当需要可中断锁、超时获取、公平锁、多个条件变量等高级功能时，则必须使用 ReentrantLock。
深度解析
使用方式与灵活性
synchronized： 无需手动释放锁。它的作用域是 代码块（需指定锁对象）或 实例方法/静态方法（锁对象分别是当前实例和 Class 对象）。锁的获取和释放由编译器生成的字节码指令（monitorenter/monitorexit）隐式管理。
// synchronized 代码块
public void syncMethod() {synchronized (this) { // 手动指定锁对象// 临界区}
}
// synchronized 方法
public synchronized void syncMethod() { // 锁是当前实例 this// 临界区
}ReentrantLock： 必须 显式地调用lock()和unlock()方法，并且通常将unlock()置于finally块中以确保锁必然释放，防止死锁。这赋予了它更大的灵活性，但也增加了代码的复杂性。
ReentrantLock lock = new ReentrantLock();
public void reentrantLockMethod() {lock.lock(); // 必须显式获取try {// 临界区} finally {lock.unlock(); // 必须显式释放，且在finally中}
}功能性对比
这是 ReentrantLock 优势最集中的地方。
| 特性 | synchronized | ReentrantLock |
|---|---|---|
| 公平性 | 非公平锁（无法指定） | 可指定为公平或非公平锁（构造方法传入 true）。公平锁能减少线程饥饿，但吞吐量通常较低。 |
| 尝试非阻塞获取 | 不支持 | 支持 tryLock()，可立即返回是否成功。 |
| 可中断等待 | 等待锁时不可中断，会一直阻塞。 | 支持 lockInterruptibly()，等待锁的线程可被其他线程中断。 |
| 超时获取 | 不支持 | 支持 tryLock(long timeout, TimeUnit unit)，可避免无限期等待。 |
| 条件变量 | 仅有一个隐式的等待/通知机制（Object.wait()/notify()）。 |
可以创建多个 Condition 对象，实现更精细的线程间通信（如“生产者-消费者”模型）。 |
底层实现与性能
synchronized： 依赖 JVM 的ObjectMonitor（对象监视器）实现。在 JDK 6 之后，JVM 团队对其进行了大量优化，如偏向锁、轻量级锁、锁消除、锁粗化、适应性自旋等。在低至中度竞争的场景下，其性能已经非常优秀，甚至与ReentrantLock相差无几。ReentrantLock： 基于 AQS（AbstractQueuedSynchronizer） 实现。AQS 内部维护了一个 CLH 变体的双向队列来管理等待线程。其高级功能（如条件变量）正是基于 AQS 的灵活架构实现的。
最佳实践与常见误区
- 优先使用
synchronized： 由于其简洁性和 JVM 的持续优化，在大多数通用并发场景下，synchronized是首选。它能减少代码错误（如忘记解锁），且性能足够好。 - 需要高级功能时再用
ReentrantLock： 当你的业务确实需要上述表格中的某个高级特性时，再选择ReentrantLock。切忌为了用而用。 - 必须解锁在
finally中： 使用ReentrantLock时，这是铁律，否则一旦临界区代码抛出异常，锁将永远无法释放。 - 避免误解性能： 不要再说“
ReentrantLock性能远高于synchronized”，这个结论在 JDK 6 之后已经过时。性能差异高度依赖于具体场景（竞争激烈程度、锁持有时间等）。在极高竞争下，ReentrantLock的可预测性可能更好。