背景
最近在啃《多处理器编程的艺术》，书中的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上的实现。