Java并发编程：Condition机制详解与实战应用

1. Condition机制在Java并发中的核心地位

Java并发编程中的Condition接口，本质上是对传统Object监视器方法（wait/notify）的现代化升级。我在实际项目中处理生产者-消费者问题时，发现原生wait/notify存在三个致命缺陷：无法区分等待条件、唤醒操作缺乏精确控制、容易产生嵌套监视器锁死。而Condition通过将单个监视器的等待集拆分为多个条件队列，完美解决了这些问题。

关键区别：一个Lock可以绑定多个Condition对象，而每个Object只能有一个等待队列

在JDK源码层面，Condition的实现类ConditionObject是AQS（AbstractQueuedSynchronizer）的内部类。当调用await()时，线程会被包装成Node加入条件队列；调用signal()时则将节点转移到同步队列参与锁竞争。这种设计使得：

• 条件谓词检查与等待成为原子操作
• 线程唤醒可以精确控制（signal vs signalAll）
• 避免了"虚假唤醒"问题

2. Condition标准使用范式与底层原理

2.1 模板代码结构

以下是经过多个线上项目验证的最佳实践模板：

java复制Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
boolean conditionPredicate = false; // 条件谓词

// 等待方
lock.lock();
try {
    while (!conditionPredicate) {  // 必须用while循环检查条件
        condition.await();
    }
    // 条件满足后的处理逻辑
} finally {
    lock.unlock();
}

// 通知方
lock.lock();
try {
    conditionPredicate = true;
    condition.signal();  // 或signalAll()
} finally {
    lock.unlock();
}

2.2 为什么必须使用while循环

在电商订单系统中，我曾遇到一个典型bug：用if判断库存数量导致超卖。这是因为：

1. await()返回时，线程需要重新获取锁
2. 在此期间其他线程可能修改了共享状态
3. while循环能确保线程被唤醒后再次验证条件

2.3 选择signal还是signalAll

在IM消息推送场景中，经过压测发现：

• signal()：唤醒一个线程，吞吐量高但可能产生"信号丢失"
• signalAll()：唤醒所有线程，更安全但上下文切换开销大

经验法则：当满足以下条件时用signal()

1. 所有等待线程是可互换的
2. 每次条件满足只需要一个线程处理
3. 能确保至少一个线程会被唤醒

3. 高级应用：实现可超时的阻塞队列

3.1 带时间限制的await

java复制public boolean awaitUntil(Date deadline) throws InterruptedException {
    long nanos = deadline.getTime() * 1000_000;
    return condition.awaitNanos(nanos) > 0;
}

在风控系统中，我们用它实现了：

• 订单支付超时自动取消
• 异步任务执行时限控制
• 分布式锁的本地超时降级

3.2 中断处理策略

在微服务架构下，正确处理中断异常至关重要：

java复制try {
    while (!conditionPredicate) {
        condition.await();
    }
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // 恢复中断状态
    throw new ServiceException("Operation interrupted", e);
}

致命错误：吞掉InterruptedException会导致线程池无法正常关闭

4. 性能优化与避坑指南

4.1 条件队列长度监控

通过反射获取AQS内部状态：

java复制Field field = AbstractQueuedSynchronizer.class
    .getDeclaredField("conditionQueues");
field.setAccessible(true);
Collection<Thread> threads = (Collection<Thread>) field.get(lock);
int queueSize = threads.size();

4.2 常见死锁场景

1. 嵌套锁问题：

java复制lock1.lock();
lock2.lock();
// 线程A持有lock1等待lock2
// 线程B持有lock2等待lock1

2. 信号丢失：

java复制// 错误示范
if (count == 0) {  // 应该用while
    notEmpty.await();
}

4.3 与synchronized的对比测试

在8核服务器上的基准测试结果（ops/ms）：

5. 真实案例：分布式任务调度系统

在某金融级系统中，我们基于Condition实现了：

1. 任务优先级队列（不同Condition对应不同优先级）
2. 资源限制器（await直到有可用资源）
3. 批量触发机制（积累足够任务量后signalAll）

关键配置参数：

java复制// 优化点：根据业务特点调整这些参数
Lock lock = new ReentrantLock(true); // 公平锁
Condition highPriority = lock.newCondition();
Condition normalPriority = lock.newCondition();
int batchSize = Runtime.getRuntime().availableProcessors() * 2;

踩坑记录：最初没有区分IO密集和CPU密集任务，导致线程饥饿。最终解决方案是为不同类型任务分配独立的Condition和线程池。