synchronized具备JVM内置锁升级机制（无锁→偏向锁→轻量级锁→重量级锁），ReentrantLock始终基于AQS的CAS与park/unpark，无锁升级；低竞争时synchronized更轻量，高竞争时ReentrantLock更可控稳定；现代JVM下二者性能差距已大幅收窄。
synchronized 具备 JVM 内置的锁升级机制，ReentrantLock 完全没有锁升级概念——这是二者在性能表现上最根本的差异来源。
锁升级机制只属于 synchronized
synchronized 的锁状态会随竞争程度动态变化：从无锁 → 偏向锁（单线程场景）→ 轻量级锁（短时自旋）→ 重量级锁（系统级阻塞）。整个过程由 JVM 自动完成，开发者不可干预。
ReentrantLock 始终基于 AQS 的 volatile state + CAS + park/unpark 运行。无论是否发生竞争、竞争激烈程度如何，它都走同一套逻辑路径：获取失败即入队、等待唤醒，不尝试自旋优化，也不降级或升级锁状态。
低竞争下 synchronized 明显更轻量
当只有一个线程反复进入同步块时：
立即学习“Java免费学习笔记（深入）”；
- synchronized 在开启偏向锁（JDK 15 前默认启用）的情况下，后续加锁几乎零开销——仅比普通指令多一次线程 ID 比较；
- ReentrantLock 即便无竞争，每次 lock()/unlock() 都需执行 CAS 更新 state、检查中断、维护 AQS 队列节点等完整流程，开销稳定但更高。
高竞争时 ReentrantLock 更可控、更稳定
当多个线程频繁争抢锁时：
- synchronized 可能快速升级为重量级锁，依赖操作系统互斥量，带来内核态切换开销；
- ReentrantLock 虽然也走阻塞路径，但其队列管理、线程调度、唤醒策略均由 Java 层控制，避免了部分 OS 调度不确定性；
- 它支持 tryLock(timeout)、lockInterruptibly() 等机制，可主动规避长时间等待，而 synchronized 一旦阻塞就只能死等。
现代 JVM 下性能差距已大幅收窄
JDK 6 以后，synchronized 经过持续优化：
- 偏向锁虽在 JDK 17+ 默认禁用，但轻量级锁的自旋策略已更智能（如自适应自旋）；
- 实测表明，在典型业务负载下，二者吞吐量差异通常在 20%–30% 范围内，远非早期数量级差距；
- 真正影响性能的往往不是锁类型本身，而是临界区大小、锁粒度、是否发生虚假共享等工程细节。
