实现TOLock过程中的一处多线程bug

背景

最近在啃《多处理器编程的艺术》,书中的7.6节介绍了时限锁——实现了tryLock方法的队列锁。

书中重点讲解了tryLock的实现,也就是如何实现在等待超时后退出队列,放弃锁请求,并且能让后继线程感知到。

在实现的过程中,我为TOLock补充了lock方法的实现。代码如下所示:

public class TOLock implements Lock {

    private static final QNode AVAILABLE = new QNode();

    private AtomicReference<QNode> tail;

    private ThreadLocal<QNode> myNode;

    public TOLock() {
        this.tail = new AtomicReference<>(null);
        this.myNode = new ThreadLocal<>();
    }

    @Override
    public void lock() {
        QNode qNode = new QNode();
        qNode.pred = null;
        myNode.set(qNode);

        QNode myPred = tail.getAndSet(qNode);
        if (myPred == null) {
            return;
        }

        while (myPred.pred != AVAILABLE) {
            if (myPred.pred != null) {
                myPred = myPred.pred;
            }
        }
    }

    @Override
    public void unlock() {
        QNode qNode = myNode.get();
        if (!tail.compareAndSet(qNode, null)) {
            qNode.pred = AVAILABLE;
        }
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        long startTime = System.currentTimeMillis();
        long patience = TimeUnit.MILLISECONDS.convert(time, unit);

        QNode qNode = new QNode();
        myNode.set(qNode);
        qNode.pred = null;

        QNode myPred = tail.getAndSet(qNode);
        if (myPred == null || myPred.pred == AVAILABLE) {
            return true;
        }

        while (System.currentTimeMillis() - startTime < patience) {
            QNode predPred = myPred.pred;
            if (predPred == AVAILABLE) {
                return true;
            } else if (predPred != null) {
                myPred = predPred;
            }
        }

        if (!tail.compareAndSet(qNode, myPred)) {
            qNode.pred = myPred;
        }
        return false;
    }

    private static class QNode {
        volatile QNode pred;
    }
}

问题

在编写lock方法的单元测试的时候发现,TOLock偶现卡死,当加大线程池中线程数量,几乎是稳定复现卡死。遂debug,发现lock方法卡死是因为

while (myPred.pred != AVAILABLE) {
    if (myPred.pred != null) {
        myPred = myPred.pred;
    }
}

这段代码中的myPred.pred为null,所以就一直走不出去。myPred.pred为什么会是null,再定睛一看,myPred居然就是AVAILABLE。这怎么会呢?
myPred的取值路径只有两种,一种是从tail通过GAS操作拿到tail之前的值,另一种就是走循环拿到myPred.pred。
原子引用tail一开始为null,每次都是吸一个new出来的QNode进队列,绝对不可能会有AVAILABLE的情况。

排除了所有不可能的情况,剩下的即使在不可能,也都是真相了。

事实上就是如此,myPred变为AVAILABLE是通过循环的if分支拿到的。

 if (myPred.pred != null) {
    myPred = myPred.pred;
}

这段while循环在多线程的情况下是有bug的,在并发环境下,在后继争用线程读取while条件的时候,有可能前驱线程还没有释放锁,所以此时的myPred.pred应该为null,接下去前驱线程释放了锁,此时myPred.pred为AVAILABLE,这时当前线程理应具备进入临界区的条件,但是因为内存循环的判断导致myPred被赋值为AVAILABLE,此后myPred.pred永远为null,线程无限时原地旋转,后继线程也无法进入临界区。

我随后将此处代码改为如下:

QNode predPred;
while ((predPred = myPred.pred) != AVAILABLE) {
    if (predPred != null) {
        myPred = predPred;
    }
}

其实就和tryLock中的写法是类似的,将myPred.pred赋值到局部变量,封闭在栈上即可。

后记

后来仔细想了想,其实类似的写法在我以前读源码的时候我有注意到过,例如BufferedInputStream里面也有很多类似的将变量封闭在栈上保证线程安全的做法。可以参考这篇帖子

在FilterInputStream里面定义的in是
protected volatile InputStream in可以被子类访问到,或者BufferedInputStream本身的byte[] buf也是protected volatile的并且还被volatile修饰,本身就是为多线程环境设计的,所以我们可以看到

 private InputStream getInIfOpen() throws IOException {
    InputStream input = in;
    if (input == null)
        throw new IOException("Stream closed");
    return input;
}

JDK中getInIfOpen是这样写的,虽然看上去挺丑的,像是冗余了一个input变量,但还真就是改不得。
否则就会出现在读取input的时候还不是null,return出去就已经是null的情况了。

看过类似代码,积累过知识,自己真正操刀练习的时候还是犯错,只说明了一句话:纸上得来终觉浅,绝知此事要躬行。


完整源码实现

关于TOLock的完整代码实现,可以参考我的github上的实现

posted @ 2017-04-22 11:00  活在夢裡  阅读(408)  评论(0编辑  收藏  举报