当前位置：首页 > article >正文

面试基础----ReentrantLock vs Synchronized

article 2025/2/26 15:03:40

ReentrantLock vs Synchronized：源码级解析与高并发场景下的锁博弈

引言：多线程编程中的锁为何重要？

业务背景：北京互联网大厂的高并发场景（如电商秒杀、支付交易、实时推荐系统）对线程安全和性能的极致要求。
锁的核心作用：解决竞态条件（Race Condition）、保证可见性（Visibility）和有序性（Ordering）。
痛点直击：错误选锁可能引发性能瓶颈（如线程阻塞、上下文切换）、死锁风险，甚至系统雪崩。

一、Synchronized 的底层实现：JVM 的锁优化艺术

1.1 对象头与 Mark Word（源码级解析）

对象内存布局：以 HotSpot JVM 为例，对象头中的 Mark Word（32/64位）存储锁状态、GC 分代年龄等信息。
锁状态标志位：通过 markOop.hpp（C++ 源码）中的 mark bit 区分无锁、偏向锁、轻量级锁、重量级锁。

代码示例：

// 对象头示例（简化）
class ObjectHeader {
    MarkWord mark;  // 锁状态存储
    // ...
}

1.2 锁升级过程：偏向锁 → 轻量级锁 → 重量级锁

偏向锁（Biased Locking）：
- 目标：减少无竞争场景下的锁开销。
- 实现：通过 BiasedLocking::revoke_and_rebias（HotSpot 源码）处理线程 ID 偏向。
- 适用场景：单线程重复进入同步块（如订单状态机）。
轻量级锁（Lightweight Locking）：
- CAS 自旋：通过 Atomic::cmpxchg_ptr（JVM 原子操作）尝试获取锁。
- 栈帧锁记录（Lock Record）：存储对象头的拷贝，用于锁释放时的恢复。
重量级锁（Heavyweight Locking）：
- 操作系统互斥量（Mutex）：通过 ObjectMonitor（objectMonitor.hpp）实现，涉及线程阻塞和唤醒。
- 性能代价：上下文切换开销（约 1-10μs）。

1.3 锁粗化与锁消除（JIT 优化）

锁粗化（Lock Coarsening）：合并相邻同步块（如循环内的同步操作）。
锁消除（Lock Elimination）：逃逸分析（Escape Analysis）确定锁对象无竞争时直接移除锁。

二、ReentrantLock 的底层实现：AQS 的队列化控制

2.1 AQS（AbstractQueuedSynchronizer）核心机制

CLH 队列（Craig, Landin, Hagersten）：双向链表实现线程排队，源码见 AbstractQueuedSynchronizer.Node。
状态变量（state）：通过 volatile int state 控制锁的获取与释放。
关键方法：
- acquire(int arg)：尝试获取锁，失败则加入队列阻塞。
- release(int arg)：释放锁并唤醒后继节点。

2.2 公平锁 vs 非公平锁（源码对比）

公平锁（FairSync）：

protected final boolean tryAcquire(int acquires) {
    if (hasQueuedPredecessors())  // 检查队列中是否有等待线程
        return false;
    // ... CAS 操作获取锁
}

非公平锁（NonfairSync）：

final void lock() {
    if (compareAndSetState(0, 1))  // 直接尝试插队
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

业务场景选择：
- 公平锁：避免线程饥饿（如金融交易订单处理）。
- 非公平锁：提高吞吐量（如日志异步写入）。

2.3 Condition 的精准控制

等待/通知机制：通过 ConditionObject 实现（对比 Object.wait()/notify()）。

典型应用：生产者-消费者模型中的精准唤醒。

ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition();
Condition notEmpty = lock.newCondition();

三、性能对比：JMH 基准测试与业务场景适配

3.1 吞吐量对比（JMH 基准测试）

低竞争场景：synchronized 因偏向锁优化表现更优。
高竞争场景：ReentrantLock 的非公平锁模式吞吐量更高（减少线程切换）。

3.2 响应时间对比

ReentrantLock 的优势：
- tryLock()：支持超时等待，避免死锁。
- lockInterruptibly()：响应线程中断。

3.3 适用场景总结

场景	推荐锁	理由
低竞争、简单同步	synchronized	JVM 自动优化，代码简洁
高并发、需要超时/中断	ReentrantLock	灵活控制，避免线程阻塞
分布式锁本地降级	synchronized	减少外部依赖，降低复杂度

四、实际应用中的选择建议与避坑指南

4.1 大厂业务场景实战

场景 1：秒杀系统库存扣减
- 选择：ReentrantLock + tryLock(10ms)
- 原因：防止线程长时间阻塞导致请求堆积。
场景 2：配置中心热更新
- 选择：synchronized
- 原因：更新频率低，偏向锁优化足够高效。

4.2 常见坑与解决方案

坑 1：锁粒度过粗
- 现象：全局锁导致性能瓶颈。
- 解决：细粒度锁（如 ConcurrentHashMap 分段锁）。
坑 2：死锁
- 诊断：jstack 分析线程栈，检查锁依赖链。
- 预防：统一锁获取顺序，使用 tryLock 超时机制。

4.3 优化建议

监控：通过 APM 工具（如 Arthas）监控锁竞争（monitor 命令）。
代码规范：避免在锁内执行耗时操作（如 IO 操作）。

五、总结：最佳实践与未来展望

synchronized 优势：简单、自动优化、JVM 原生支持。
ReentrantLock 优势：灵活、可中断、支持公平性。
终极选择：
- 80% 场景：优先使用 synchronized（KISS 原则）。
- 20% 复杂场景：选择 ReentrantLock（灵活控制）。
未来趋势：无锁编程（CAS、LongAdder）、协程（虚拟线程）的崛起。