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

Java并发编程：从synchronized到ReentrantLock与Condition的进阶实践

news 2026/4/22 10:47:17

1. 为什么需要更强大的锁机制

在Java多线程开发中，synchronized关键字可能是大多数开发者最先接触的同步工具。记得我刚工作那会儿，处理线程安全问题就是无脑加synchronized，直到有次线上系统出现死锁，排查了整整两天才发现问题所在。synchronized确实简单易用，但在复杂的并发场景下就显得力不从心了。

举个例子，假设我们有个银行转账系统，用synchronized实现大概长这样：

public class BankAccount { private double balance; public synchronized void transfer(BankAccount to, double amount) { this.balance -= amount; to.balance += amount; } }

这种实现有个致命问题：当A给B转账的同时B也给A转账，就可能出现死锁。更麻烦的是，一旦发生死锁，synchronized既不能中断也不能设置超时，系统就直接卡死了。这就是为什么我们需要更强大的锁机制——ReentrantLock。

ReentrantLock提供了synchronized不具备的三大能力：

  1. 可中断锁：等待锁的线程可以被中断
  2. 超时机制：可以设置获取锁的等待时间
  3. 公平锁：可以按申请锁的顺序获取锁

在实际项目中，我曾经用ReentrantLock重构过一个订单处理系统。原先用synchronized时，高峰期经常出现线程堆积，改用ReentrantLock的tryLock(500, TimeUnit.MILLISECONDS)后，系统稳定性明显提升，超时订单能够自动放弃处理而不是一直阻塞。

2. ReentrantLock的核心特性解析

2.1 基础锁功能对比

先看一个最简单的计数器实现，我们用三种方式分别实现：

// 不加锁版本 public class NonLockCounter { private int count; public void add() { count++; // 非原子操作 } } // synchronized版本 public class SyncCounter { private int count; public synchronized void add() { count++; } } // ReentrantLock版本 public class LockCounter { private int count; private final Lock lock = new ReentrantLock(); public void add() { lock.lock(); try { count++; } finally { lock.unlock(); } } }

测试时，开100个线程各执行100次add操作，不加锁版本的结果每次都不一样，而synchronized和ReentrantLock版本都能稳定输出10000。看起来效果一样，但ReentrantLock的优势在于更灵活的控制。

2.2 可中断与超时机制

这是ReentrantLock最实用的特性之一。假设我们有个需要获取多个资源的操作：

public class ResourceManager { private final Lock lock1 = new ReentrantLock(); private final Lock lock2 = new ReentrantLock(); public boolean transferWithTimeout(long timeout, TimeUnit unit) throws InterruptedException { long stopTime = System.nanoTime() + unit.toNanos(timeout); // 尝试获取第一个锁 if (!lock1.tryLock(timeout, unit)) { return false; } try { // 计算剩余时间 long remaining = stopTime - System.nanoTime(); // 尝试获取第二个锁 if (!lock2.tryLock(remaining, TimeUnit.NANOSECONDS)) { lock1.unlock(); // 记得释放已获取的锁 return false; } try { // 执行业务逻辑 return doTransfer(); } finally { lock2.unlock(); } } finally { lock1.unlock(); } } }

这种写法完美避免了死锁风险，我在实际项目中处理分布式锁时经常使用这种模式。相比之下，synchronized一旦开始等待就只能死等，没有任何回旋余地。

2.3 公平锁与非公平锁

ReentrantLock的另一个强大之处是可以创建公平锁：

Lock fairLock = new ReentrantLock(true); // true表示公平锁

公平锁会按照线程请求锁的顺序来分配锁，避免了线程饥饿问题。不过要注意，公平锁的性能通常比非公平锁低，因为要维护请求队列。根据我的测试，在高并发场景下，非公平锁的吞吐量能比公平锁高出5-10倍。

3. Condition的精准线程控制

3.1 基本等待/通知机制

Condition可以理解为ReentrantLock的等待/通知机制，类似于Object的wait/notify，但更灵活。先看个生产者消费者例子：

public class MessageQueue { private final Lock lock = new ReentrantLock(); private final Condition notFull = lock.newCondition(); private final Condition notEmpty = lock.newCondition(); private final Object[] items = new Object[100]; private int putptr, takeptr, count; public void put(Object x) throws InterruptedException { lock.lock(); try { while (count == items.length) { notFull.await(); // 队列满时等待 } items[putptr] = x; if (++putptr == items.length) putptr = 0; count++; notEmpty.signal(); // 通知消费者 } finally { lock.unlock(); } } public Object take() throws InterruptedException { lock.lock(); try { while (count == 0) { notEmpty.await(); // 队列空时等待 } Object x = items[takeptr]; if (++takeptr == items.length) takeptr = 0; count--; notFull.signal(); // 通知生产者 return x; } finally { lock.unlock(); } } }

这个实现比用wait/notify更清晰，而且可以创建多个Condition实现更精细的控制。我在一个日志处理系统中就用过这种模式，不同的Condition分别处理不同优先级的日志。

3.2 多Condition应用场景

Condition最强大的地方在于一个Lock可以创建多个Condition。比如实现一个线程安全的连接池：

public class ConnectionPool { private final Lock lock = new ReentrantLock(); private final Condition hasAvailable = lock.newCondition(); private final Condition canReturn = lock.newCondition(); private final int maxSize; private final Set<Connection> pool = new HashSet<>(); private int activeCount = 0; public Connection get() throws InterruptedException { lock.lock(); try { while (activeCount >= maxSize) { hasAvailable.await(); } Connection conn = createConnection(); activeCount++; canReturn.signal(); return conn; } finally { lock.unlock(); } } public void release(Connection conn) { lock.lock(); try { while (!pool.contains(conn)) { canReturn.await(); } pool.remove(conn); activeCount--; hasAvailable.signal(); } finally { lock.unlock(); } } }

这种设计可以避免虚假唤醒问题，而且不同状态的等待可以分开处理，代码逻辑更清晰。

4. 实战中的选择与优化

4.1 何时选择ReentrantLock

根据我的经验，以下场景适合使用ReentrantLock：

  1. 需要可中断的锁获取操作
  2. 需要超时控制的锁获取
  3. 需要公平锁特性
  4. 需要多个条件变量(Condition)
  5. 需要尝试获取锁(tryLock)

而简单场景下，synchronized仍然是更好的选择，因为：

  1. 语法更简洁
  2. JVM会优化synchronized的性能
  3. 自动释放锁，不会忘记解锁

4.2 性能优化技巧

在使用ReentrantLock时，有几个性能优化点需要注意：

  1. 锁粒度：尽量减小锁的代码块范围
  2. 锁分离：读写锁分离(ReentrantReadWriteLock)
  3. 锁降级：写锁降级为读锁
  4. 避免锁嵌套：容易导致死锁

我曾经优化过一个商品库存系统，将原来的大锁拆分为多个细粒度锁后，QPS从200提升到了1500+。关键代码片段：

public class Inventory { private final Map<Long, Item> items = new HashMap<>(); private final Map<Long, ReentrantLock> locks = new ConcurrentHashMap<>(); public void updateStock(long itemId, int delta) { ReentrantLock lock = locks.computeIfAbsent(itemId, k -> new ReentrantLock()); lock.lock(); try { Item item = items.get(itemId); item.setStock(item.getStock() + delta); } finally { lock.unlock(); } } }

4.3 常见坑与解决方案

在使用ReentrantLock时，我踩过不少坑，这里分享几个典型问题：

坑1：忘记释放锁

lock.lock(); try { // 业务代码 if(someCondition) { return; // 这里直接return会导致锁未释放 } } finally { lock.unlock(); // 必须放在finally块 }

坑2：锁重入次数不匹配

public void methodA() { lock.lock(); try { methodB(); // 内部也调用了lock.lock() } finally { lock.unlock(); // 需要调用unlock()次数与lock()次数相同 } }

坑3：Condition使用不当

Condition condition = lock.newCondition(); // 错误！必须先获取锁才能调用await() condition.await(); // 正确用法 lock.lock(); try { condition.await(); } finally { lock.unlock(); }

这些坑我都真实踩过，特别是第一个问题，曾经导致我们线上系统出现严重的线程阻塞。后来我们制定了代码规范，要求所有锁操作必须用try-finally包裹，并在Code Review时重点检查。

http://www.jsqmd.com/news/681454/

相关文章：

  • 2026数电发票API接口技术解析：从合规到落地的全路径 - 速递信息
  • 【自动控制原理】Simulink仿真建模实战：从信号源到系统响应的完整流程
  • Fast-GitHub终极指南：三步解决GitHub下载慢的完整方案
  • 杰理之小度功能的功能配置项怎么查看？【篇】
  • 京东e卡回收真实行情来了！ - 圆圆收
  • 2026年长春好用的政府补贴项目申报机构有哪些，高企专精特新申报指南 - myqiye
  • 信号处理避坑指南：切比雪夫II型滤波器设计时，如何正确设置MATLAB中的Rp和Rs参数？
  • 基于GEC6818与LVGL的智能贩卖机系统：C语言、网络与数据库的嵌入式实践
  • 企业净水器服务商选型：从成本到售后的技术维度解析 - 速递信息
  • 2026数电发票API接口技术解析：企业税务数字化转型核心工具 - 速递信息
  • 手把手教你用阿里云ECS从零搭建VOS网络电话系统（含SIP线路对接与坐席配置避坑指南）
  • 2026年京津冀及东北口碑好的新中式家具品牌厂家推荐，专业制造商全解析 - mypinpai
  • 从应力应变到本构矩阵：Voigt符号在材料力学仿真中的核心应用避坑指南
  • MCP协议深度解析：让AI真正操控你的开发工具链（附5个实战案例）
  • 2026年4月盘点：气体分析系统哪个牌子好？生产企业全对比 - 品牌推荐大师
  • 优质美国专线机构推荐，深圳帕斯国际服务全国，费用怎么算？ - 工业品网
  • 宁夏知名防盗门生产厂家推荐丨首选宁夏创成索福门业，24年老品牌，防盗门/防火门/防爆门，源头工厂，支持各类个性化定制 - 宁夏壹山网络
  • 在Ubuntu 18.04虚拟机上，用一杯咖啡的时间搞定RK3588 NPU开发环境（附RKNN-Toolkit2避坑指南）
  • Adobe-GenP 3.0终极指南：如何快速免费激活Adobe全家桶的完整教程
  • WeChatPad：突破微信设备限制，实现手机平板同时在线登录
  • YOLO26镜像问题全解：CUDA内存不足、模块导入错误处理
  • 2026现阶段河南高强度双头螺栓服务商价值评估与选择指南 - 2026年企业推荐榜
  • 2026 江西 GEO 优化服务商深度测评：本土合规品牌冶希 GEO 实力实测 - 商业科技观察
  • 把键盘拆了！用Arduino Pro Micro + Keyboard库，5分钟自制一个物理宏按键
  • 从单反到无人机：实战解析‘跟焦’与‘变焦’在运动拍摄中的协同与陷阱
  • 别再折腾下载器了！用Proteus仿真STM32做项目原型，效率提升指南
  • 微信小程序saveFile报错？别慌，手把手教你排查‘tempFilePath file not exist’的三种常见原因
  • 2026 年湖州装修公司如何选？靠谱、口碑好、性价比高的湖州装修公司推荐 - GrowthUME
  • 2026专业做动物实验的公司有哪些？行业精选推荐 - 品牌排行榜
  • Unity项目中途想换HDRP？别慌，这份从内置管线平滑升级的保姆级避坑指南请收好