【详解】依赖状态的并发程序之等待方式

引言:

  有时候我们执行一个操作,需要一个前提条件,只有在条件满足的情况下,才能继续执行。在单线程程序中,如果某个状态变量不满足条件,则基本上可以直接返回。但是,在并发程序中,基于状态的条件可能会由于其他线程的操作而改变。而且存在这种需要,即某个操作一定要完成,如果当前条件不满足,没关系,我可以等,等到条件满足的时候再执行。今天,我们就来聊一聊等待的几种方式。

  • 忙等待 / 自旋等待。
  • 让权等待 / 轮询与休眠
  • 条件队列

 

情景条件

  我们要实现一个有界缓存,其中用不同的等待方式处理前提条件失败的问题。在每种实现中都扩展了BaseBoundedBuffer,这个类中实现了一个基于数组的循环缓存,其中各个缓存状态变量(buf、head、tail和count)均由缓存的内置锁来保护。它还提供了同步的doPut和doTake方法,并在子类中通过这些方法来实现put和take操作,底层的状态将对子类隐藏。

此段代码来自《Java Concurrency in Practice》

public abstract class BaseBoundedBuffer<V> {
    private final V[] buf;   //缓冲数组
    private int tail;        //缓冲数据尾部索引
    private int head;        //头部索引
    private int count;       //存储的数据量

    public BaseBoundedBuffer(int capacity) {
        this.buf = (V[]) new Object[capacity];
    }

    protected synchronized final void doPut(V v) {
        buf[tail] = v;
        if (++tail == buf.length)
            tail = 0;
        ++count;
    }

    protected synchronized final V doTake() {
        V v = buf[head];
        buf[head] = null;
        if (++head == buf.length)
            head = 0;
        --count;
        return v;
    }
    
    public synchronized final boolean isFull() {
        return count == buf.length;
    }
    
    public synchronized final boolean isEmpty() {
        return count == 0;
    }
}

一、忙等待

反复检查条件是否为真,直到条件达到,继而完成后续任务。

优点:响应性好,只要条件符合,马上就能做出响应。

缺点:这样做,虽然在逻辑上实现了功能要求,但是在性能上却可能消耗过多的CPU时间。

我们来看看,忙等待的实现方式:

public class BusyWaitBoundedBuffer<V> extends BaseBoundedBuffer<V> {

    public BusyWaitBoundedBuffer(int size) {
        super(size);
    }
    
    public void put(V v) throws InterruptedException {
        while(true) {
            synchronized (this) {
                if(!isFull()) {
                    doPut(v);
                    return;
                }
            }
        }
    }
    
    public V take() throws InterruptedException {
        while(true) {
            synchronized (this) {
                if(!isEmpty())
                    return doTake();
            }
        }
    }
}

这里的两个方法在访问缓存时都采用”先检查,再运行“的逻辑策略,非线程安全,因为条件可能在”检查之后,运行之前“的中间时刻,被其他线程修改,以至于,在运行的时候,前提条件已经不满足了,故需要对put和take两个方法都进行同步,共用同一个锁以确保实现对缓冲状态的独占访问,即某一时刻只能有一个线程可以访问操作缓冲数组。也就是说,在put方法执行的一次尝试中,take方法不能被调用,不能改变缓冲数组状态。

还有一点,值得注意的是,while循环并不在同步块内,而是同步块在while循环内,也就是每执行一次条件检查,如果不满足,需要释放掉锁。不然另一个方法就拿不到锁,也就不能改变状态,条件就永远不能发生改变,这个方法就变成了死等待

 

“尚未解决的疑惑”:线程等待锁的时候是否会被JVM挂起,调出CPU?如果是这样的话,那么上下文切换的开销也会很大,因为每检查一次条件,需要进出CPU两次。

 

二、让权等待 / 轮询与休眠

类似忙等待,但是在每次检查条件后,若不合符条件,将进入休眠状态,避免消耗过多的CPU时间。而不是马上进入下一次检查。

优点:避免消耗过多的CPU时间

缺点:响应性差

实现代码:

public class SleepyBoundedBuffer<V> extends BaseBoundedBuffer<V> {
    private static final long SLEEP_GRANULARITY = 3000L;

    public SleepyBoundedBuffer(int size) {
        super(size);
    }

    public void put(V v) throws InterruptedException {
        while (true) {
            synchronized (this) {
                if (!isFull()) {
                    doPut(v);
                    return;
                }
            }
            Thread.sleep(SLEEP_GRANULARITY); //休眠固定时间
        }
    }
    
    public V take() throws InterruptedException {
        while(true) {
            synchronized (this) {
                if(!isEmpty()) {
                    return doTake();
                }
            }
            Thread.sleep(SLEEP_GRANULARITY);
        }
    }

}

需要强调的是,sleep方法不会释放当前线程拥有的锁,所以不能在同步块内调用,如果在同步块内调用的话,虽然不会马上进行下一次条件检查,但是在这期间,锁没有被释放,其他线程无法获取到这个对象的锁,故无法改变状态,此操作也会变成死等待。依据如下(monitor指的就是锁)。

 

避免消耗过多的CPU时间是怎么回事?

  这里,我们需要先了解一下线程调度机制,和时间片轮转算法。

我们知道,线程并非至始至终占用CPU,而是每运行一段时间便退出CPU,让其他线程继续执行。来回切换,以实现程序的并发执行。

线程调度机制如图所示:(此图来自汤小丹《计算机操作系统》)

再来说一说,时间片轮转算法,看到这个,我想当然的以为,时间片的分配类似于内存空间的分配,也就是说,给你分配多少空间,那这个空间就归属你了,用多用少看你自己情况,多出来的空间其他人不能用。但是,认真看了轮转调度算法后,就明白了,原来时间片并不是那么回事,而是相当于一个定时器。即,假如时间片划分为30ms,那么从每个线程进入CPU,就开始倒计时,如果时间片用完,即倒计时为0,或者线程任务执行完毕,就调出线程。调入新线程后,定时器重新从30ms开始倒计时。

 

基于时间片轮转的解释

  对于忙等待来说,如果条件长时间没有达到,则可能耗尽其本次分配的时间片,甚至在等待过程中会消耗多个时间片。在这段时间内,此线程占据着此CPU,却只是等待,不做计算,其他线程不能获得此CPU,计算资源就算是浪费了。

  而对于让步等待来说,如果此次检查条件没有达到的话,会休眠一段时间,这时候,会退出CPU,让出当前时间片多余的部分,而且休眠的这段时间内也不会参与调度。

 

为什么说,让步等待响应性差?

   因为,可能出现这种情况,即线程刚进入休眠或者进入休眠状态没多久,条件就成立了,但是线程已进入休眠,只能等到休眠结束,才能继续执行。也就不能够及时响应了。

如图所示:(此图来自《Java Concurrency in Practice》,L、U不太清楚是何意思)

 

三、条件队列

未完待续…