实现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上的实现。