synchronized与Lock吞吐量无绝对快慢，低竞争时二者接近，高竞争下ReentrantLock通常更高；公平锁吞吐下降20%–40%，synchronized天然非公平更稳定；Lock灵活性利于细粒度优化。
在吞吐量模型上，synchronized 和 Lock（特别是 ReentrantLock）的表现差异主要取决于线程竞争强度、锁获取方式及调度机制，而非绝对的“谁快谁慢”。
低竞争场景下吞吐量接近
JDK 6 起，synchronized 经过偏向锁、轻量级锁、自旋锁等多层优化，锁获取开销大幅降低。当临界区短、线程冲突少时，JVM 的内置锁机制与 Lock 的 AQS 实现吞吐量基本持平，甚至因更少的 Java 层调用而略优。
高竞争场景下 Lock 吞吐量通常更高
当多个线程频繁争抢同一把锁时，ReentrantLock 基于 AQS 的 FIFO 队列 + CAS 自旋 + 精细唤醒策略，能更高效地管理等待线程：
- AQS 使用 volatile state + UNSAFE 原子操作，避免了 monitor 进入/退出时的部分 JVM 重量级操作
- 非公平模式（默认）允许新线程“插队”尝试获取锁，减少上下文切换次数
- 可中断获取（lockInterruptibly()）和超时获取（tryLock(long, TimeUnit)）能快速释放无效等待，降低无效线程堆积
公平性对吞吐量有显著影响
公平锁虽能避免饥饿，但强制排队导致大量线程阻塞+唤醒，CPU 开销上升，实测吞吐量常下降 20%–40%。synchronized 无公平选项，天然走非公平路径，因此在同等高竞争压力下，其吞吐稳定性反而更接近 ReentrantLock 的非公平模式。
立即学习“Java免费学习笔记（深入）”；
锁粒度与使用方式间接影响吞吐
Lock 支持分段加锁、读写分离（如 ReentrantReadWriteLock）、多 Condition 等，便于设计更细粒度的并发控制；而 synchronized 只能绑定对象或类，容易造成过度串行化。合理利用 Lock 的灵活性，可在业务层面提升整体吞吐——这不是锁本身更快，而是架构更适配。
不复杂但容易忽略：吞吐量差异本质是调度策略与使用边界的差异，不是性能代差。选型应优先看是否需要中断、超时、条件变量等能力，再结合压测数据判断实际收益。
