ReentrantLock在低竞争下与synchronized性能相近，高竞争时非公平锁吞吐量高20%–30%、延迟更稳，公平锁易现长尾；线程阻塞率超15%即提示锁瓶颈。

评估 ReentrantLock 在高竞争与低竞争下的性能表现，关键不是只看“锁快不快”，而是看它在不同并发压力下，对吞吐量、延迟、线程调度开销的实际影响。真实系统中，竞争程度会动态变化，所以需要结合可量化的指标和典型场景来判断。

看三个核心指标：吞吐量、平均延迟、线程阻塞率

这三项能直接反映锁在不同竞争强度下的行为差异：

• 吞吐量：单位时间完成的临界区操作次数。高竞争时，非公平 ReentrantLock 通常比公平锁高 20%–30%，因为减少了线程排队唤醒的开销
• 平均延迟：从调用 lock() 到成功进入临界区的时间。低竞争（如单线程或两线程）下，ReentrantLock 和 synchronized 差距极小；但高竞争（比如 100+ 线程争同一把锁）时，公平锁延迟可能飙升数倍
• 线程阻塞率：通过 JVM ThreadMXBean 或 JFR（Java Flight Recorder）观察 BLOCKED 状态线程占比。若持续 >15%，说明锁已成为瓶颈，需考虑降粒度或换读写锁

用简化模型粗估竞争程度

不必每次都压测，可先用轻量级公式快速判断是否大概率进入高竞争：

竞争系数 ≈ （并发线程数 × 锁持有纳秒数） ÷ （临界区执行纳秒数 + 1）

例如：50 个线程、临界区平均耗时 1000ns、每次持锁 5000ns → 系数 ≈ (50 × 5000) / 1001 ≈ 249 → 属于高竞争区间。此时非公平锁更稳，公平锁易出现长尾延迟。

对比测试要控制变量，避开常见干扰

实测时容易忽略 JVM 自身优化带来的偏差：

• 关闭偏向锁（-XX:-UseBiasedLocking），避免低竞争下 biased lock 掩盖真实行为
• 预热充分（至少 5 秒 JIT 编译+GC 稳定），否则初期数据波动大
• 固定 CPU 核心数（如 taskset -c 0-3 java ...），排除调度抖动影响
• 对比基线必须包含 synchronized，因 JDK 17+ 后二者差距已大幅收窄，尤其在低竞争下

典型场景参考值（基于 JDK 17–21 实测）

以下为 10 万次临界区操作的代表性结果（单核，无 GC 干扰）：

• 低竞争（2 线程）：ReentrantLock 非公平 vs synchronized —— 吞吐量相差
• 中竞争（16 线程）：非公平 ReentrantLock 吞吐量比公平锁高约 25%，比 synchronized 高约 8%
• 高竞争（64 线程）：公平锁平均延迟跳至 120μs，非公平锁维持在 45μs 左右；synchronized 延迟升至 60μs，但无公平性选项