Java并发编程：ReentrantLock-FairSync源码分析(hasQueuedPredecessors)

Posted 2022-12-09 黄智霖-blog

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Java并发编程：ReentrantLock-FairSync源码分析(hasQueuedPredecessors)相关的知识，希望对你有一定的参考价值。

前言

有了前面ReentrantLock-NonfairSync源码逐行深度分析的基础，理解公平锁FairSync的实现就很简单了。

一、公平的实现

ReentrantLock的默认构造函数创建的是非公平锁，同时提供了布尔类型的有参构造函数，true表示创建公平锁。

public ReentrantLock() 
	sync = new NonfairSync();


public ReentrantLock(boolean fair) 
	sync = fair ? new FairSync() : new NonfairSync();

在前文中我们已经分析过，使用ReentrantLock加锁其实是调用的内部sync.lock()方法，lock()方法在FairSync和NonfairSync中都有实现，本文主要看看FairSync，也就是公平锁中的lock方法：

static final class FairSync extends Sync 
        final void lock() 
            acquire(1);

这里已经看到和非公平锁不一样的地方了，非公平锁在lock的时候，会首先去竞争锁，竞争失败才会调用acquire方法。而在此处公平锁的实现中并没有直接就去获取锁，为了对比，这里再贴一下NonfairSync的lock方法：

static final class NonfairSync extends Sync 
        final void lock() 
			//首先尝试去或获取锁
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);

acquire方法定义在父类AQS中，首先是调用tryAcquire方法尝试获取锁，失败则调用addWaiter方法将线程包装为Node。然后自旋CAS入队，接着在acquireQueued方法中完成线程的阻塞：

public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer
    implements java.io.Serializable 
    
	public final void acquire(int arg) 
	        if (!tryAcquire(arg) &&
	            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
	            selfInterrupt();

其中的所有方法调用在前文已经详细分析过，这里就不再赘述，我们主要关注tryAcquire方法。tryAcquire方法在AQS中是一个空方法，由具体的子类重写实现逻辑，当然此处我们看FairSync中的实现：

static final class FairSync extends Sync 
	protected final boolean tryAcquire(int acquires) 
				//获取当前线程
	            final Thread current = Thread.currentThread();
	            //获取state
	            int c = getState();
	            if (c == 0) 
	            	//发现没有线程持有锁
	            	//调用hasQueuedPredecessors函数判断队列中是否有优先于此线程的排队线程
	            	//如果没有才去尝试竞争锁
	                if (!hasQueuedPredecessors() &&
	                    compareAndSetState(0, acquires)) 
	                    setExclusiveOwnerThread(current);
	                    return true;
	                
	            
	            else if (current == getExclusiveOwnerThread()) 
	            	//锁重入
	                int nextc = c + acquires;
	                if (nextc < 0)
	                    throw new Error("Maximum lock count exceeded");
	                setState(nextc);
	                return true;
	            
	            return false;

可以看到这里的逻辑和NonfairSync唯一的区别就是FairSync多了hasQueuedPredecessors函数的调用，在竞争锁之前需要先看队列中是否有优先于此线程的排队线程，如果有的话，那么FairSync不会去竞争锁，而是直接进入后面入队阻塞的逻辑。那么这里强调的优先于此线程的排队线程是什么意思呢？因为FairSync是公平锁的实现，获取锁总要有个先来后到。

二、hasQueuedPredecessors函数

接着我们来看看hasQueuedPredecessors函数的实现，该函数也定义在AQS中：

public final boolean hasQueuedPredecessors() 
        Node t = tail;
        Node h = head;
        Node s;
        return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());

虽然这个方法代码很少，但是细节点可一点儿不少，首先我们来关注最后一条返回语句：

return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());

可以看到，如果 h != t，那么会进入后面的条件判断，会调用h.next。这里考虑一个问题，在h != t的情况下，h可不可能为null？也就是h.next可不可能抛出空指针异常？
我们先从语法层面上分析一下，要在h != t 为true的情况下使得h为null，那么t就不能为null，也就是要考虑会不会出现head == null，但是tail != null的情况。
要从理论上看待这个问题，就需要回顾一下线程入队的逻辑，也就是enq方法：

private Node enq(final Node node) 
        for (;;) 
            Node t = tail;
            if (t == null) 
            	//初始化CLH队列
                if (compareAndSetHead(new Node()))
                    tail = head;
             else 
                node.prev = t;
                if (compareAndSetTail(t, node)) 
                    t.next = node;
                    return t;

这个方法在前文已经详细分析过，就不细说了，这里我们要关注在初始化CLH队列的时候是先通过CAS设置了head节点，然后将head赋值给tail，注意这是两步操作，也就是非原子的。有可能一个线程t0执行CAS设置了head节点，但是在设置tail节点之前时间片用完了，轮到执行hasQueuedPredecessors方法的线程t1，那么此时t1去获取head和tail节点，就可能得到head不为空，但是tail为空的情况。不过，由于t1线程在hasQueuedPredecessors方法中是先获取的tail，再获取的head，而t0线程在enq方法中是先设置head，再设置tail，所以不论t1线程在什么时候运行，只要获取的tail不为null，那么head一定不为null，也就是不可能出现head == null，但是tail != null的情况。
那现在回过头来试想一下，如果先获取head，再获取tail会不会有什么问题？贴个图就能明白了：

在上图的场景中，t1先获取head，此时为null，时间片耗尽，然后t0线程运行设置head和tail，然后t1线程恢复获取tail，此时不为null。这就出现了head == null，但是tail != null的情况，那么以下语句就会出现空指针异常：

return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());

所以基于这条判断语句，获取head和tail的顺序要和其初始化的顺序相反，才能保证不出异常，并且head和tail都被volatile修饰，即保证了可见性，也保证了不会被指令重排影响执行顺序。基于这样获取顺序，h(head)和t(tail)只可能是以下几种情况：

h == null and t == null
h != null and t != null
h !=null and t == null

然后我们再回过头来看这个条件判断语句，要表达的意思其实很简单：如果CLH队列中有排队线程，并且首个排队线程不是当前线程，那么方法需要返回true，表示有优先级比当前高的线程正在排队。
但是这里需要注意一个点，就是(s = h.next) == null这个条件判断是什么意思呢？既然CLH队列中有排队线程，那么h.next肯定是有节点才对啊？其实这个条件对应的就是我们前面提到的，由于线程穿插执行导致的，h != null，但是t == null的情况。如果出现这个情况，那么h.next就为null，因为前一个线程正在入队，但是还没有入队，当然也表示前面有线程优先级更高，只是还没有入队。也就是 h != t成立之后，有两种情况：

h !=null and t == null：此时h.next == null，表示已经有线程正在入队，但还未入队
h != null and t != null：此时表示CLH队列中已经有了排队线程，只需要判断h.next.thread是否为当前线程即可

所以这个hasQueuedPredecessors方法可以改写成：

public final boolean hasQueuedPredecessors() 
        //先获取tail，再获取head，可以避免得到 h ==null，但是t != null的情况
        Node t = tail;
        Node h = head;
        
        if(h != null && t == null)
        	//线程交叉执行，可能导致这个情况，但是此时表明前面已经有线程正在入队
        	return true;
        
        if(h != null && t != null)
        	//队列中已经有排队线程
        	return s.thread != Thread.currentThread();
        
        if(h == null && t == null)
        	//队列为空，当前线程可以尝试去竞争锁
        	return false;

2.1 返回值并不可靠

2.1.1 返回true不可靠

由于一个线程随时可能被中断唤醒或者超时唤醒，比如我们调用的lockInterruptibly方法获取锁（这个方法在前面的文章也详细介绍过了），阻塞线程一旦被中断，那么在醒来后会立即抛出异常，然后在finally代码块中的cancelAcquire方法中移除该节点，但是在这个方法逻辑还没有完成的时候（准确来说应该是被移除节点可能还没有真正被移除：队列中只有一个排队线程，移除的逻辑是通过CAS修改指针完成的，详情参考前面文章），那此时新来一个线程调用hasQueuedPredecessors返回的还是为true，表示前面有优先级更高的排队节点，虽然它已经是个无效节点。

2.1.2 返回false不可靠

现在考虑这样一种情况，两个线程同时准备竞争锁，都调用了hasQueuedPredecessors，此时CLH队列还没有初始化，连head节点都没有，所以都会得到head==null，并且tail==null的结果，返回false，那么它们都会尝试去通过CAS修改state，这个时候哪个线程获取到锁就是未知数了，即使两个线程有先后顺序。