Condition

在java.util.concurrent包中,有两个很特殊的工具类,Condition和ReentrantLock,使用过的人都知道,ReentrantLock(重入锁)是jdk的concurrent包提供的一种独占锁的实现。它继承自Dong Lea的 AbstractQueuedSynchronizer(同步器),确切的说是ReentrantLock的一个内部类继承了AbstractQueuedSynchronizer,ReentrantLock只不过是代理了该类的一些方法,可能有人会问为什么要使用内部类在包装一层? 我想是安全的关系,因为AbstractQueuedSynchronizer中有很多方法,还实现了共享锁,Condition(稍候再细说)等功能,如果直接使ReentrantLock继承它,则很容易出现AbstractQueuedSynchronizer中的API被误用的情况。

言归正传,今天,我们讨论下Condition工具类的实现。

ReentrantLock和Condition的使用方式通常是这样的:

C1

运行后,结果如下:

C2

可以看到,

Condition的执行方式,是当在线程1中调用await方法后,线程1将释放锁,并且将自己沉睡,等待唤醒,

线程2获取到锁后,开始做事,完毕后,调用Condition的signal方法,唤醒线程1,线程1恢复执行。

以上说明Condition是一个多线程间协调通信的工具类,使得某个,或者某些线程一起等待某个条件(Condition),只有当该条件具备( signal 或者 signalAll方法被带调用)时 ,这些等待线程才会被唤醒,从而重新争夺锁。

那,它是怎么实现的呢?

首先还是要明白,reentrantLock.newCondition() 返回的是Condition的一个实现,该类在AbstractQueuedSynchronizer中被实现,叫做newCondition()

C3

它可以访问AbstractQueuedSynchronizer中的方法和其余内部类( AbstractQueuedSynchronizer是个抽象类,至于他怎么能访问,这里有个很奇妙的点,后面我专门用demo说明 )

现在,我们一起来看下Condition类的实现,还是从上面的demo入手,

为了方便书写,我将AbstractQueuedSynchronizer缩写为AQS

当await被调用时,代码如下:

01 public final void await() throws InterruptedException {
02 if (Thread.interrupted())
03  throw new InterruptedException();
04  Node node = addConditionWaiter(); //将当前线程包装下后,
05                                    //添加到Condition自己维护的一个链表中。
06 int savedState = fullyRelease(node);//释放当前线程占有的锁,从demo中看到,
07                                        //调用await前,当前线程是占有锁的
08  
09 int interruptMode = 0;
10  while (!isOnSyncQueue(node)) {//释放完毕后,遍历AQS的队列,看当前节点是否在队列中,
11                            //不在 说明它还没有竞争锁的资格,所以继续将自己沉睡。
12                              //直到它被加入到队列中,聪明的你可能猜到了,
13                             //没有错,在singal的时候加入不就可以了?
14  LockSupport.park(this);
15  if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
16  break;
17  }
18 //被唤醒后,重新开始正式竞争锁,同样,如果竞争不到还是会将自己沉睡,等待唤醒重新开始竞争。
19 if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
20  interruptMode = REINTERRUPT;
21  if (node.nextWaiter != null)
22  unlinkCancelledWaiters();
23  if (interruptMode != 0)
24  reportInterruptAfterWait(interruptMode);
25  }

回到上面的demo,锁被释放后,线程1开始沉睡,这个时候线程因为线程1沉睡时,会唤醒AQS队列中的头结点,所所以线程2会开始竞争锁,并获取到,等待3秒后,线程2会调用signal方法,“发出”signal信号,signal方法如下:

1 public final void signal() {
2  if (!isHeldExclusively())
3  throw new IllegalMonitorStateException();
4  Node first = firstWaiter; //firstWaiter为condition自己维护的一个链表的头结点,
5                           //取出第一个节点后开始唤醒操作
6  if (first != null)
7  doSignal(first);
8  }

说明下,其实Condition内部维护了等待队列的头结点和尾节点,该队列的作用是存放等待signal信号的线程,该线程被封装为Node节点后存放于此。

C4

关键的就在于此,我们知道AQS自己维护的队列是当前等待资源的队列,AQS会在资源被释放后,依次唤醒队列中从前到后的所有节点,使他们对应的线程恢复执行。直到队列为空。

而Condition自己也维护了一个队列,该队列的作用是维护一个等待signal信号的队列,两个队列的作用是不同,事实上,每个线程也仅仅会同时存在以上两个队列中的一个,流程是这样的:

1. 线程1调用reentrantLock.lock时,线程被加入到AQS的等待队列中。

2. 线程1调用await方法被调用时,该线程从AQS中移除,对应操作是锁的释放。

3. 接着马上被加入到Condition的等待队列中,以为着该线程需要signal信号。

4. 线程2,因为线程1释放锁的关系,被唤醒,并判断可以获取锁,于是线程2获取锁,并被加入到AQS的等待队列中。

5.  线程2调用signal方法,这个时候Condition的等待队列中只有线程1一个节点,于是它被取出来,并被加入到AQS的等待队列中。  注意,这个时候,线程1 并没有被唤醒

6. signal方法执行完毕,线程2调用reentrantLock.unLock()方法,释放锁。这个时候因为AQS中只有线程1,于是,AQS释放锁后按从头到尾的顺序唤醒线程时,线程1被唤醒,于是线程1回复执行。

7. 直到释放所整个过程执行完毕。

可以看到,整个协作过程是靠结点在AQS的等待队列和Condition的等待队列中来回移动实现的,Condition作为一个条件类,很好的自己维护了一个等待信号的队列,并在适时的时候将结点加入到AQS的等待队列中来实现的唤醒操作。

看到这里,signal方法的代码应该不难理解了。

取出头结点,然后doSignal

C5

01 private void doSignal(Node first) {
02  do {
03  if ( (firstWaiter = first.nextWaiter) == null//修改头结点,完成旧头结点的移出工作
04  lastWaiter = null;
05  first.nextWaiter = null;
06  while (!transferForSignal(first) &&//将老的头结点,加入到AQS的等待队列中
07  (first = firstWaiter) != null);
08  }
09  
10 final boolean transferForSignal(Node node) {
11  /*
12  * If cannot change waitStatus, the node has been cancelled.
13  */
14  if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
15  return false;
16  
17 /*
18  * Splice onto queue and try to set waitStatus of predecessor to
19  * indicate that thread is (probably) waiting. If cancelled or
20  * attempt to set waitStatus fails, wake up to resync (in which
21  * case the waitStatus can be transiently and harmlessly wrong).
22  */
23  Node p = enq(node);
24  int ws = p.waitStatus;
25 //如果该结点的状态为cancel 或者修改waitStatus失败,则直接唤醒。
26  if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
27  LockSupport.unpark(node.thread);
28  return true;
29  }

可以看到,正常情况 ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL) 这个判断是不会为true的,所以,不会在这个时候唤醒该线程。

只有到发送signal信号的线程调用reentrantLock.unlock()后因为它已经被加到AQS的等待队列中,所以才会被唤醒

<think>好的,用户想了解JavaCondition接口的用法相关编程问题。首先,我需要回忆一下Condition接口的基本概念它在Java并发编程中的作用。Condition接口通常与Lock配合使用,用于实现线程间的协调,类似于Object类的wait()、notify()notifyAll()方法,但提供了更灵活的功能。 接下来,我应该整理Condition的主要方法,比如await()、signal()signalAll(),并说明它们与传统wait/notify的区别。用户可能需要知道为什么使用Condition而不是内置的监视器方法,所以需要强调Condition的优点,比如多个等待集、更细粒度的控制等。 然后,考虑一个实际的使用示例。例如,实现一个简单的有界队列,当队列满时,生产者线程等待;当队列空时,消费者线程等待。这可以展示如何用Condition的awaitsignal来管理线程的等待唤醒。编写代码时要注意锁的正确获取释放,以及处理InterruptedException的情况。 同时,用户可能对Condition的使用场景最佳实践感兴趣,需要解释什么时候应该选择Condition,比如在复杂的同步结构中,或者需要多个条件谓词时。此外,可能还需要提到常见的陷阱,比如忘记在finally块中释放锁,或者错误地使用signal而不是signalAll导致信号丢失。 还需要检查是否有相关的引用内容可以支持回答。查看提供的引用,引用[1]提到类的成员括方法,引用[2]展示了线程持有对象的情况,可能与线程协调有关,引用[3]讨论了联合类型的参数判别,这可能与条件判断有关联。不过,这些引用可能与Condition接口的直接关联不大,但可以适当引用其中关于类成员或线程示例的部分来增强回答的可信度。 最后,生成相关问题,帮助用户进一步学习,比如Condition与wait/notify的区别,如何避免死锁,或者Condition在生产者-消费者模式中的应用。确保问题覆盖用户可能感兴趣的扩展话题,并引导他们深入理解。</think>### JavaCondition接口的用法详解 #### 1. Condition接口基础 Condition接口是`java.util.concurrent.locks`中的核心组件,需配合`Lock`实现线程协调。与传统的`Object.wait()`/`notify()`相比,它支持**多个等待队列**,提供更细粒度的线程控制[^1]。 主要方法: - `await()`: 使当前线程等待并释放锁,可响应中断 - `signal()`: 唤醒一个等待线程 - `signalAll()`: 唤醒所有等待线程 #### 2. 标准使用模板 ```java Lock lock = new ReentrantLock(); Condition condition = lock.newCondition(); lock.lock(); try { while (条件不满足) { condition.await(); // 释放锁并等待 } // 执行操作 } finally { lock.unlock(); } ``` #### 3. 生产者-消费者案例 实现线程安全的阻塞队列: ```java class BoundedBuffer { final Lock lock = new ReentrantLock(); final Condition notFull = lock.newCondition(); final Condition notEmpty = lock.newCondition(); Object[] items = new Object[100]; 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(); } } } ``` 此实现特点: 1. 使用两个独立Condition分别管理空/满状态 2. 避免虚假唤醒的`while`循环检查 3. 遵循`lock.unlock()`放在finally块的规范 #### 4. 关键优势 - **多条件谓词**:可为不同等待条件创建独立Condition对象 - **公平锁支持**:配合`ReentrantLock(true)`实现公平调度 - **超时机制**:提供`awaitNanos()`/`awaitUntil()`等超时方法 #### 5. 典型应用场景 - 线程池任务调度 - 阻塞队列实现 - 复杂状态机同步 - 资源访问控制(如数据库连接池) #### 6. 注意事项 - 始终在`lock()``unlock()`之间使用Condition - 调用signal时需持有对应的锁 - 推荐使用signalAll()避免信号丢失 - 处理InterruptedException时应维护线程中断状态
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值