作为JVM内置锁，synchronized通过隐式加锁/释放简化了代码，但功能相对固定；而ReentrantLock作为API层面的显式锁，支持可中断获取、超时等待、公平锁设置等灵活特性，却需手动管理锁的释放。文章将对比两者在锁获取方式、释放机制、性能表现上的关键差异，比如synchronized的自动释放如何避免死锁风险，ReentrantLock的Condition对象如何实现更精细的线程协作。
更重要的是，我们会结合实际业务场景给出选型指南：简单同步场景下，synchronized的简洁性为何更具优势？高并发且需灵活控制锁时，ReentrantLock的超时机制和中断能力如何提升系统稳定性？通过真实案例分析，助你掌握“何时用内置锁、何时选手动锁”的判断逻辑，让并发代码既安全又高效。
你有没有遇到过这种情况：写多线程代码时，明明用了锁却还是出问题——要么是synchronized写起来简单但功能不够用，要么是ReentrantLock灵活却总担心忘了释放锁导致死锁？其实这两种锁就像螺丝刀和瑞士军刀，各有各的拿手活，用对了能让并发代码既安全又高效。今天我就结合自己这些年做Java后端的踩坑经验，帮你彻底搞懂它们的核心差异，以后选锁再也不用纠结。
从底层到功能，彻底搞懂两种锁的核心差异
很多人用了几年Java，还是分不清synchronized和ReentrantLock到底哪里不一样，总觉得“不都是加锁吗？能锁住不就行了？”但去年我带团队做电商秒杀系统时，就因为一个实习生混用了这两种锁，导致线上出现间歇性死锁——他用ReentrantLock加了锁，却没在finally里释放，结果某个异常分支跳过了unlock()，锁就永远没释放，最后不得不紧急回滚。这事儿让我意识到，搞懂两者的底层逻辑和功能边界，比死记API重要多了。
底层实现：一个“隐式自动门”，一个“显式手动门”
先说说最本质的区别：synchronized是JVM内置的锁机制，就像你家小区的自动门——进门时不用你动手（隐式加锁），出门时门会自动关上（自动释放锁），哪怕你在门内摔倒了（抛异常），门也会照样关。这种“全自动”的特性来自JVM的底层支持：当你用synchronized修饰方法或代码块时，JVM会在编译后的字节码里自动插入monitorenter（加锁）和monitorexit（释放锁）指令，而且会确保每个monitorenter对应多个monitorexit（比如正常执行和异常退出的情况），所以基本不会出现锁泄漏。
而ReentrantLock是Java代码层面实现的锁（基于AQS框架），相当于你办公室的手动门——进门要自己掏钥匙（显式调用lock()），出门必须记得锁门（调用unlock()），要是忘了锁门（没在finally里释放），别人就进不来了（死锁风险）。你可以把AQS理解成一个“排队叫号系统”：所有想进门的线程先取号排队，AQS根据规则（公平或非公平）叫号，叫到号的线程才能拿到钥匙进门。这种显式控制虽然麻烦，但也带来了更多灵活性，比如你可以问“还要等多久能轮到我？”（tryLock超时等待），或者“不想等了能走吗？”（可中断获取锁）。
这里有个冷知识：很多人觉得synchronized性能不如ReentrantLock，其实这是JDK 6以前的老黄历了。现在JVM对synchronized做了“三级优化”——偏向锁（只给第一个线程“VIP通行证”，减少竞争）、轻量级锁（用CAS尝试抢锁，避免内核态切换）、重量级锁（真正互斥，需要操作系统介入），就像你开车过收费站：平时没人时直接ETC通行（偏向锁），偶尔有车抢道就快速变道（轻量级锁），堵车了就走人工通道（重量级锁）。根据美团技术团队的测试，在低并发场景下，synchronized甚至比ReentrantLock性能更好，因为AQS的排队机制本身也有开销（美团技术团队《Java并发编程的艺术》相关分析）。
功能特性：简洁性和灵活性的“取舍之道”
除了底层实现，两者的功能差异更影响日常开发。我整理了一张对比表，你可以直观看到它们的“技能点”：
| 特性 | synchronized | ReentrantLock |
|---|---|---|
| 锁获取方式 | 隐式获取（代码块/方法修饰） | 显式获取（lock()/tryLock()） |
| 锁释放机制 | JVM自动释放（异常也会释放） | 必须手动调用unlock()（ 在finally中） |
| 可中断性 | 不可中断（一旦阻塞无法被中断） | 可中断（lockInterruptibly()支持中断） |
| 超时等待 | 不支持（获取不到锁会一直阻塞） | 支持（tryLock(long timeout, TimeUnit unit)） |
| 公平锁 | 仅支持非公平锁 | 支持公平锁（构造函数传true） |
| 条件变量 | 仅支持一个（wait()/notify()） | 支持多个（newCondition()创建多个Condition） |
举个我踩过的坑：之前做一个订单处理系统，需要让“订单创建线程”和“订单取消线程”协作——创建线程把订单加入队列后通知取消线程，取消线程超时未收到新订单就自动退出。一开始用synchronized+wait()/notify()实现，结果发现notify()会随机唤醒一个线程，要是队列里有多个条件（比如“订单创建”和“订单超时”），就可能唤醒错线程，导致逻辑混乱。后来换成ReentrantLock的Condition，创建两个Condition：createCondition和cancelCondition，分别调用signal()，精准唤醒对应线程，问题一下就解决了。这就是ReentrantLock多条件变量的优势——就像你家有多个房间，每个房间有独立的门铃，你可以按指定门铃叫醒特定的人，而不是大喊一声不知道谁会醒。
实战场景落地：什么情况用synchronized，什么情况选ReentrantLock
讲了这么多理论，你可能还是想问：“我到底该怎么选？”其实没有绝对的“谁更好”，只有“谁更适合”。结合我带项目的经验，你可以按这几个场景对号入座。
简单同步场景：synchronized的“懒人优势”
如果你的需求只是“让某个方法/代码块同一时间只有一个线程执行”，没有超时、中断、多条件这些高级需求，那优先选synchronized。比如单例模式的懒汉式实现：
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {}
public static synchronized LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}
这段代码够简单吧？就一个synchronized修饰方法，不用管锁的释放，JVM自动搞定。之前有个同事非要“炫技”，用ReentrantLock实现单例，结果写了一堆lock()/unlock()，还忘了在finally里释放，上线后直接死锁，排查半天才发现是少了finally。这种场景下，简洁就是最大的优势，而且synchronized的“自动释放”特性几乎能杜绝锁泄漏风险。
还有一种情况是“锁粒度小且竞争不激烈”，比如工具类里的静态方法同步。我之前维护过一个日期格式化工具类，SimpleDateFormat不是线程安全的，所以给format()方法加了synchronized，线上跑了三年没出过问题——因为调用量不大，锁竞争很少，synchronized的性能完全够用，代码还清晰。
复杂并发控制：ReentrantLock的“灵活工具箱”
当你需要超时等待、中断、公平锁或多条件变量时，ReentrantLock就是更好的选择。我印象最深的是做秒杀系统的库存锁定功能：用户下单后锁定库存15分钟，超时未支付自动释放。这种场景用synchronized根本搞不定，因为它拿不到锁就会一直阻塞，没法设置15分钟超时。
后来我们用ReentrantLock的tryLock()解决了问题：
ReentrantLock lock = new ReentrantLock();
// 尝试锁定库存，最多等15分钟
if (lock.tryLock(15, TimeUnit.MINUTES)) {
try {
// 扣减库存、创建订单
} finally {
lock.unlock(); // 确保释放锁
}
} else {
// 锁定超时，返回“系统繁忙，请重试”
}
这个逻辑上线后，不仅解决了库存长期锁定的问题，还通过“超时快速失败”机制，避免了高并发下线程大量阻塞导致的系统雪崩。这就是ReentrantLock超时机制的价值——就像你打电话，等了10秒没人接就挂掉，总比一直占线浪费时间强。
再比如“公平锁”场景。有次做一个抢票系统，用户投诉“明明我先点的抢票，后点的人反而抢到了”。排查发现是用了非公平锁（默认都是非公平锁，因为性能更好），导致后到的线程可能“插队”抢到锁。后来把ReentrantLock的构造函数改成new ReentrantLock(true)（公平锁），按线程请求顺序分配锁，虽然性能略有下降（排队需要额外开销），但用户体验明显改善。这时候公平锁的“排队机制”就比性能更重要。
还有个高级用法是“可中断锁”。之前做一个实时数据分析系统，需要定期中断过时的计算任务。如果用synchronized，任务线程一旦阻塞在锁上，调用interrupt()根本没用，线程会一直卡在那里。换成ReentrantLock的lockInterruptibly()，在主线程调用interrupt()后，阻塞的线程会抛出InterruptedException并退出，顺利终止过时任务。这就像你排队买票时突然接到紧急电话，可以随时离开队伍，而不是必须等到买到票才能走。
最后再提醒一句：用ReentrantLock一定要记得在finally里释放锁！我见过太多新手把unlock()写在try块里，结果方法抛异常时unlock()根本没执行，导致锁永远被占用。正确的写法永远是：
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// 业务逻辑
} finally {
lock.unlock(); // 必须放finally！必须放finally！必须放finally！
}
你最近的项目中用过哪种锁？有没有遇到过锁竞争导致的性能问题？或者用对锁后系统稳定性提升的案例？欢迎在评论区分享，我们一起看看能不能挖出更多实战技巧！
我见过太多人用ReentrantLock踩的第一个坑，就是锁释放的位置没放对。你想啊，ReentrantLock跟synchronized不一样，它不是JVM自动管的，得你自己动手调unlock()才能放锁，这就跟你借了朋友的工具箱，用完得记得还，不然下次朋友要用就找不着了。最容易出错的就是把unlock()直接写在try块里，觉得“业务逻辑跑完就释放，多顺啊”——可万一try块里的代码突然抛个异常呢？比如你正在处理订单，突然来个NullPointerException，后面的unlock()根本执行不到，锁就像你家大门开着没关，后面的线程全堵在门口进不来，这不就死锁了嘛。
正确的打开方式其实特简单，就像你进门后先把钥匙插在锁孔里（调用lock()），然后赶紧把“锁门步骤”写在手机备忘录里（finally块里的unlock()），不管你在屋里是看电视还是做家务（业务逻辑），哪怕不小心把水杯碰倒了（抛异常），最后出门前都得按备忘录步骤把门锁好。我一般写代码时，lock()完马上就跟try，finally里必写unlock()，形成肌肉记忆：lock() → try { … } finally { lock.unlock(); }。去年带实习生做支付系统，他就觉得“我这逻辑写得这么严谨，肯定不会抛异常”，嫌finally麻烦，把unlock()直接放try块末尾了。结果上线第三天，一个订单金额传了null，触发空指针异常，unlock()直接被跳过，整个支付通道卡住半小时，最后只能紧急重启服务。那一次故障后，他写ReentrantLock时，finally块比谁都写得勤快，这教训可比我讲十遍理论都管用。
synchronized和ReentrantLock最核心的区别是什么？
最核心的区别在于底层实现和控制方式：synchronized是JVM内置锁，通过隐式加锁/释放（JVM自动插入monitorenter/monitorexit指令），无需手动管理锁释放，适合简单场景；ReentrantLock是API层面的显式锁（基于AQS框架），需手动调用lock()/unlock()，但支持超时等待、可中断获取、公平锁、多条件变量等灵活特性，适合复杂并发控制。简单说，前者是“全自动门”，后者是“手动门+工具箱”。
日常开发中，什么场景优先用synchronized？
当你只需要基础的线程同步（比如保证代码块/方法同一时间单线程执行），且没有超时、中断、多条件协作等高级需求时，优先选synchronized。比如单例模式的懒汉式实现、简单工具类的静态方法同步等场景，它的“自动释放锁”特性能避免锁泄漏，代码更简洁，维护成本低。我之前做的日期格式化工具类，就用synchronized修饰format()方法，三年没出过锁相关问题。
使用ReentrantLock时，手动释放锁有什么必须注意的？
最关键的是必须在finally块中释放锁！因为ReentrantLock需要显式调用unlock()，如果放在try块里，一旦业务逻辑抛异常，unlock()可能被跳过，导致锁永远无法释放（锁泄漏）。正确写法是：lock()后立即try，finally中调用unlock()，就像“进门后必须随手锁门”。去年我团队的实习生就因漏写finally释放锁，导致线上死锁，这个教训一定要记牢。
两种锁在性能上有差异吗？该怎么选？
JDK 6后synchronized做了“三级优化”（偏向锁、轻量级锁、重量级锁），性能已大幅提升。根据美团技术团队测试，低并发场景下synchronized甚至比ReentrantLock更优（AQS排队机制有额外开销）；高并发且需灵活控制（如超时、中断）时，ReentrantLock的性能优势更明显。简单说：无特殊需求用synchronized，需超时/中断/多条件时选手动锁。
如何用ReentrantLock实现公平锁？公平锁适合什么场景？
ReentrantLock的公平锁通过构造函数参数实现：new ReentrantLock(true)即可创建公平锁，此时线程会按请求顺序获取锁（类似“排队叫号”）。公平锁适合对“顺序公平性”要求高的场景，比如抢票系统、任务调度系统，避免后请求的线程“插队”。但要注意：公平锁会因排队机制增加性能开销，非特殊场景 用默认的非公平锁（new ReentrantLock()，性能更优）。
