java - 求对ArrayBlockingQueue中一段源码的解释
阿神
阿神 2017-05-27 17:41:19
0
2
883

为什么take()方法在判断队列中元素个数是否为0的时候使用了while循环,而不是if;

我认为,如果notEmpty.await()方法既然苏醒返回了 ,那么此线程肯定拿到了lock。

而苏醒的原因也是因为put()方法放入了新的元素,而其他线程无法拿到锁,自然无法取走元素,那么此时对于拿到锁的线程来说count肯定不为0了,应该放心的执行 dequeue()获取元素就可以了。
不知道作者使用了while是何意呢?

阿神
阿神

闭关修行中......

全部回复(2)
漂亮男人

“notEmpty.await()方法既然苏醒返回了 ,那么此线程肯定拿到了 lock” 这句话是正确的。

假设你写的代码是:

if (count == 0)
    notEmpty.await();

可以明确的一点就是我们需要保证在 return dequeue() 之前需要满足的一个条件是 count != 0。我们假设 线程A 此时拿到了 lock,那么 线程A 的 notEmpty.await() 此时便会停止阻塞,准备向下执行 return dequeue()。但是假设在竞争激烈的条件下,线程A 拿到 lock 之后,准备执行下一条 JVM 指令的时候,线程B 此时抢占了 lock,然后继续向下执行 return dequeue(),刚好使得 count 变为了 0;而此时因为写的只是 if(count == 0),那么线程 A 在拿到 lock 之后,还是会继续向下执行 return dequeue(),从而导致了错误。

关于为什么wait()await() 这样当条件不满足时就阻塞的方法一定要在 while 循环中使用,可以参考《Effective Java》第二版第 69 条(244 页)。

黄舟
public ArrayBlockingQueue(int capacity, boolean fair) {
    if (capacity <= 0)
        throw new IllegalArgumentException();
    this.items = new Object[capacity];
    lock = new ReentrantLock(fair);
    notEmpty = lock.newCondition();    //notEmpty 就是这个锁的条件
    notFull =  lock.newCondition();
}

所以在你这段代码里当前队列为空时(count==0),调用了notEmpty.await(),这段代码对锁是有影响的,实际上底层上已经释放了锁,只是这个方法保证了被唤醒时一定又能够拿回锁(当有元素放入队列会调用notEmpty.signal()进行唤醒),那为什么需要使用while呢?因为insert后lock.unlock,未必notEmpty.await()立即被唤醒,可能之前插入一个线程运行remove方法

热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板