深入浅出Synchronized 与 ReentrantLock 全解析 —— 从使用到原理Java 并发编程绕不开的两把锁一个关键字、一个类一个 JVM 原生、一个 AQS 加持。它们到底有什么区别生产环境该用哪个一文讲透。目录一、什么是 Java 锁二、两种基本使用三、核心特性对比四、底层原理剖析五、性能对比与误区六、如何选型七、总结一、什么是 Java 锁1.1 从线程安全说起多线程并发访问共享变量时会引发数据不一致的问题这就是竞态条件。锁Lock就是用来保证同一时刻只有一个线程访问共享资源的机制。// ❌ 无锁并发下 count 结果不确定publicclassCounter{privateintcount0;publicvoidincrement(){count;}// 非原子操作可能丢更新}1.2 两大主角登场维度synchronizedReentrantLock形态关键字语言层面类JDK 提供原理JVM 内置监视器锁AQS 抽象队列同步器出现JDK 1.0JDK 1.5定位简单、自动灵活、强大核心观点synchronized是傻瓜式的编译器帮你加锁解锁ReentrantLock是手工式的能力更强但需要自己释放。二、两种基本使用2.1 synchronized 的三种用法用法锁的对象适用修饰实例方法当前实例this保护实例状态修饰静态方法当前 Class 对象保护类级状态代码块手动指定对象精细控制锁范围// ① 实例方法锁 thispublicsynchronizedvoidincr(){count;}// ② 静态方法锁 Class 对象publicstaticsynchronizedvoidincrStatic(){count;}// ③ 代码块锁指定对象范围可控推荐publicvoidincr(){synchronized(this){// 锁粒度更小count;}}2.2 ReentrantLock 的使用privatefinalLocklocknewReentrantLock();// 默认非公平锁publicvoidincr(){lock.lock();// 加锁try{count;}finally{lock.unlock();// 必须手动释放放 finally 里}}⚠️大坑ReentrantLock忘记unlock()会死锁而synchronized由 JVM 自动释放不会犯这个错。三、核心特性对比3.1 可重入性两者都支持可重入指同一线程在持有锁的情况下可以再次获取同一把锁。// 可重入外层方法持锁还能进入内层同步方法publicsynchronizedvoidouter(){inner();}// 没问题publicsynchronizedvoidinner(){}3.2 ReentrantLock 独有能力按等待顺序获取锁响应中断❌✅lockInterruptibly()等待锁时可被中断超时获取❌✅tryLock(3, SECONDS)拿不到锁就放弃条件变量❌ 仅一个等待集✅ 可创建多个Condition精确唤醒指定线程非阻塞尝试❌✅tryLock()拿不到立即返回// 超时获取拿不到锁不傻等if(lock.tryLock(3,TimeUnit.SECONDS)){try{/* 业务 */}finally{lock.unlock();}}else{System.out.println(抢锁失败先干别的);}核心观点synchronized只会死等ReentrantLock会见机行事——能中断、能超时、能非阻塞这是它最大的价值。四、底层原理剖析4.1 synchronized锁升级路线JDK 6 之后synchronized不是一上来就用重量级锁而是按竞争激烈程度逐级升级无锁 - 偏向锁 - 轻量级锁 - 重量级锁 只有升级不降级锁状态适用场景实现偏向锁单线程反复访问记录线程 ID无竞争开销极小轻量级锁多线程交替访问CAS 抢锁自旋等待重量级锁多线程激烈竞争依赖操作系统互斥量阻塞挂起一句话竞争越激烈synchronized花销越大但锁升级机制让它在低竞争时几乎零成本。4.2 ReentrantLockAQS 队列同步器ReentrantLock底层依赖AQSAbstractQueuedSynchronizer线程抢锁失败 ──▶ 进入 CLH 等待队列 ──▶ 前驱释放锁 ──▶ 唤醒后继 ┌──────────┐ │ 队列节点 │ 基于 CAS volatile state └──────────┘AQS 要素作用volatile state记录锁状态0空闲0重入次数CLH 队列等待线程排成 FIFO 队列CAS 操作原子修改状态保证并发安全一句话AQS 就是用volatile CAS 队列实现的排队叫号机制ReentrantLock只是它的一个应用。五、性能对比与误区5.1 性能演进差距已不明显版本现状JDK 1.5ReentrantLock性能明显优于synchronizedJDK 1.6synchronized引入锁升级两者性能基本持平现在简单场景推荐synchronized无需为性能选ReentrantLock❌误区以为ReentrantLock永远更快。实际锁升级后synchronized低竞争下性能不输选型看功能需求不是看性能。5.2 常见的几个坑坑说明忘释放锁ReentrantLock忘unlock()直接死锁锁对象用错synchronized锁字符串字面量/包装类导致全局互斥粗粒度锁锁了过多代码并发度骤降锁顺序不一致多把锁嵌套顺序不同引发死锁六、如何选型6.1 选型决策树需要超时 / 中断 / 公平 / 多条件变量 ├─ 是 ────▶ ReentrantLock └─ 否 ── 只是想保证线程安全 ├─ 是 ────▶ synchronized简单省心 └─ 否 ──▶ 考虑更高层并发工具6.2 最佳实践建议场景推荐理由简单互斥synchronized代码简洁自动释放读多写少ReentrantReadWriteLock读写分离并发更高需要超时/中断ReentrantLock唯一选择等待-通知synchronizedwait/notify单条件够用// ✅ 最佳实践范围最小化 finally 释放lock.lock();try{// 只锁必要的代码}finally{lock.unlock();}七、总结7.1 核心要点synchronizedJVM 关键字自动加锁解锁有锁升级优化简单场景首选ReentrantLockAQS 实现支持公平锁、超时、中断、多条件变量功能最全共同点都可重入都保证互斥选型关键需要见机行事的能力 →ReentrantLock否则 →synchronized性能JDK 6 后两者差距已不大不必为此纠结7.2 最后的话核心观点锁是并发安全的基石而会释放比能加锁更重要。理解两者的原理差异才能在复杂的并发场景中做出正确选择。记住synchronized忘不了释放ReentrantLock忘不得释放面试常考锁升级、AQS、公平与非公平必背进阶方向LockSupport、Condition、StampedLock、Java 21 虚拟线程参考资料《Java 并发编程的艺术》方腾飞《Java 并发编程实战》Brian GoetzJDK 源码ReentrantLock、AbstractQueuedSynchronizerJVM 规范monitor 指令与对象头 Mark Word标签Java, 并发编程, Synchronized, ReentrantLock, AQS, 锁升级, 面试题