jdk中cocurrent下的AbstractQueuedSynchronizer理解记录

   以前虽然看过一次AQS的源码实现，但在过一段时间后与同学交流时，发觉自己理解并不够深，印像太浅。需要做一个记录整理，帮助自己消化。

 

AQS中Node的设计： 

 

几个点：

1. Node实现作者： "CLH" (Craig, Landin, and * Hagersten) ，有名的CLH queue

2. 是一个FIFO的链表的实现，对于队列的控制经常要做double-check。

3. Node节点通过一个int waiteStatus代表一些不同意义的状态。

 

• SIGNAL=-1，代表是需要当前Node节点需要唤起后一个Node节点。在Node节点enqueue时，会设置前一个节点的状态。这样链式的唤醒，完成这样的一个交接棒。
• CONDITION = -2 ， 

4. nextWaiter一个标志位，就是用于表明是采用的共享锁还是排他锁。同时也是其对应condition队列的引用节点。

来看一下Node操作的一个double-check设计

node的equeue操作： 

private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {  // 位置1
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) { // Must initialize    // 位置3
                Node h = new Node(); // Dummy header
                h.next = node;
                node.prev = h;
                if (compareAndSetHead(h)) {   // 位置4
                    tail = node;
                    return h;
                }
            }
            else {
                node.prev = t;
                if (compareAndSetTail(t, node)) {   // 位置2
                    t.next = node;
                    return t;
                }
            }
        }
    }

 

代码中标记了4个位置：

1.  node默认的equeue操作都是接在tail节点之后，prev节点指定完成后，进行一个cas设置操作，将当前加入的节点做为tail。 因为会有并发操作，原先的tail节点会有所变化，位置1处会出现失败。这样就进入第2步的check机制

2.  位置2，每次都取一次当前的tail节点，尝试通过cas设置操作，将当前节点做为tail，有并发变化/竞争导致处理失败，继续重复这一动作，直到完成为之。 

3.  在位置1和2处理的一种异常情况，就是tail节点为空，有可能该节点是第一个进行enqueue，也有可能是node节点被所有唤醒。这时需要重新创建队列，创建一个空的Head node节点，将自己做为tail节点。

4.  同样考虑并发因素，位置3在处理时，可能已有线程创建了Head节点，这样就又回到位置2上的处理，将node节点添加在tail节点之后。

位置2,3,4都是基于一种发展的锁机制实现，尝试N次竞争后，总能成功。

node的dequeue操作： 

一个比较巧妙的设计，需要细细品味。

出库分为两个动作： 

动作1： 

private void setHead(Node node) {
        head = node;
        node.thread = null;
        node.prev = null;
    }

轮到自己出库后，进行head节点的gc处理，断开自己node节点和链表的一些应用。同时将自己添加为head。 

说明：刚开始对出库时将自己node设置为head，一直想不明白。后来仔细看了下是否轮到出库时的判断就可以明白了。

final Node p = node.predecessor();   // 位置1
   if (p == head && tryAcquire(arg)) {
   setHead(node);
   p.next = null; // help GC
   return interrupted;
}

轮到出库时的判断：

   在位置1上，每次判断都是获取当前节点的prev节点，判断==head节点。最后就可以这么理解，head节点其实是一个“傀儡”，代表的是上一个出库的节点，因为是一个FIFO队列，如果当前的上一个节点已经出库，那就可以轮到自己

动作2： 

private void unparkSuccessor(Node node) {
        /*
         * Try to clear status in anticipation of signalling.  It is
         * OK if this fails or if status is changed by waiting thread.
         */
        compareAndSetWaitStatus(node, Node.SIGNAL, 0);

        /*
         * Thread to unpark is held in successor, which is normally
         * just the next node.  But if cancelled or apparently null,
         * traverse backwards from tail to find the actual
         * non-cancelled successor.
         */
        Node s = node.next;
        if (s == null || s.waitStatus > 0) { //位置1
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }

这里没啥特殊的，就是在位置1上，当一个节点需要出库后，唤醒下一个非cancel的节点。这里的LockSupport的代码设计也有一点取巧，后续可以再写点。

acquire , release , cancel三个动作设计

按照原先作者的设计： 

 

  Acquire:
      while (!tryAcquire(arg)) {
          enqueue thread if it is not already queued;
          possibly block current thread;
      }
 
  Release:
      if (tryRelease(arg))
         unblock the first queued thread;

 

 预留了5个protected方法，用于client自己实现相关的处理，进行业务行为控制，因为cocurrent很多Lock,Future的实现都是基于此扩展，定义了自己的处理。

• tryAcquire
• tryRelease
• tryAcquireShared
• tryReleaseShared
• isHeldExclusively

具体的一些方法使用，后续再补。

 

acquire动作:

独占锁：

 

1. public final void acquire(int arg)
2. public final void acquireInterruptibly(int arg) throws InterruptedException
3. public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException 

public final void acquire(int arg)

public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

说明：

1. tryAcquire自定义的扩展，一般用value值进行控制，类似P/V原语的控制。

2.  addWaiter是一个入库的动作，前面已经介绍。

3. 来看一下accquireQueued方法

final boolean acquireQueued(final Node node, int arg) {
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();   // 位置1
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&  // 位置2
                    parkAndCheckInterrupt())  // 位置3
                    interrupted = true;
            }
        } catch (RuntimeException ex) {
            cancelAcquire(node);  // 位置4
            throw ex;
        }
    }

位置1： 前面已经介绍过，就是对比一下我的上一个节点是否已经出队列，如果已经出队列，就认为当前轮到自己出队列，返回 interrupted的标志。

位置2： 执行了一个动作，就是设置一下当前节点的上一个节点的waitStatus状态为SINGLE，让其在出队列的时候能唤醒自己进行处理。

位置3： 在设置了上一个节点为SINGLE后，当前线程就可以进行park，转到阻塞状态，直到等到被唤醒。 (唤醒条件有2个： 前一个节点的唤醒和 Thread.interupte事件)

位置4： 就是一个cancel动作。

public final void acquireInterruptibly(int arg) throws InterruptedException

和accquire方法的区别，就是针对Thread.interrupt会响应一个InterruptedException异常，立马返回。而accquire会一直等待直到自己可以出队列。

 

看一下其核心方法：

private void doAcquireInterruptibly(int arg)
        throws InterruptedException {
        final Node node = addWaiter(Node.EXCLUSIVE);
        try {
            for (;;) {
                final Node p = node.predecessor();  // 位置1
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&  // 位置2
                    parkAndCheckInterrupt())
                    break;   // 位置3
            }
        } catch (RuntimeException ex) {
            cancelAcquire(node);
            throw ex;
        }
        // Arrive here only if interrupted
        cancelAcquire(node);
        throw new InterruptedException();   // 位置4
    }

 位置1，2和accquire一样，唯一的区别小点就在 位置3上直接进行了break，跳出响应位置4了 InterruptedException。

public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException

和accquire, accquireInterruptibly方法的区别，就在于在支持 Interrupted响应的基础上，还支持了Timeout超时的控制，在指定时间内无法获取对应锁，抛出对应的TimeoutException

来看一下核心方法：

private boolean doAcquireNanos(int arg, long nanosTimeout)
        throws InterruptedException {
        long lastTime = System.nanoTime();
        final Node node = addWaiter(Node.EXCLUSIVE);
        try {
            for (;;) {
                final Node p = node.predecessor();   // 位置1
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return true;
                }
                if (nanosTimeout <= 0) {   // 位置2
                    cancelAcquire(node);
                    return false;
                }
                if (nanosTimeout > spinForTimeoutThreshold &&  // 位置3
                    shouldParkAfterFailedAcquire(p, node))   // 位置4
                    LockSupport.parkNanos(this, nanosTimeout);  // 位置5
                long now = System.nanoTime();   // 位置6
                nanosTimeout -= now - lastTime;
                lastTime = now;
                if (Thread.interrupted())   // 位置7
                    break;
            }
        } catch (RuntimeException ex) {
            cancelAcquire(node);
            throw ex;
        }
        // Arrive here only if interrupted
        cancelAcquire(node);
        throw new InterruptedException();  // 位置8
    }

位置1： 和先前的accquire一样

位置2：6都是对超时时间的处理，nanosTimeout为当前还需要等待的时间，每次检查一下nanosTimeout时间，并在循环过程中减去对应的处理时间。

位置3：一个自旋锁的优化判断

位置4：和先前的accquire一样，设置上一个Node节点的waitStatus状态。

位置5：和先前accquire有点不同，使用 LockSupport指定时间的park方法，完成对应的时间控制。

共享锁：

1. public final void acquireShared(int arg)
2. public final void acquireSharedInterruptibly(int arg) throws InterruptedException
3. public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException

 

public final void acquireShared(int arg)

和独占锁处理方式基本类似，来看一下核心代码：

 

private void doAcquireShared(int arg) {
        final Node node = addWaiter(Node.SHARED);
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor(); 
                if (p == head) {
                    int r = tryAcquireShared(arg); 
                    if (r >= 0) {
                        setHeadAndPropagate(node, r);   // 位置1
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        return;
                    }
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } catch (RuntimeException ex) {
            cancelAcquire(node);
            throw ex;
        }
    }

这里设计上有点小技巧，原先思考一个共享锁的典型场景：读写锁。 一旦写锁释放，应该是唤起所有的读锁。而原先在看setHeadAndPropagate，并没有一个循环释放锁的过程。后来思考了下，采用的是一个链式释放的过程，前一个shared的锁对象释放下一个，在释放的时候继续进行tryAccquireShared控制。

 

一点感悟：在写并发程序时，一些传统编程的思路要有所改变。

 

public final void acquireSharedInterruptibly(int arg) throws InterruptedException

public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException

这两个实现上和独占锁类似，也就是setHeadAndPropagate处理上的不同点而已。

 

 

release动作:

public final boolean release(int arg)

 

 

 

 

if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;

没啥特别好将的，一看基本也就明白了，出队列的时候，同时唤醒下一个Node。

 

cancel动作:

private void cancelAcquire(Node node) 

 

 

代码就不贴了，几个处理：

1. 从链表上删除cancel节点

2. 如果cancel节点是head，则尝试唤醒cancel节点的下一个节点。

 

 

ConditionObject的理解

几个主要方法：

 

• public final void await() throws InterruptedException
• public final void awaitUninterruptibly()
• public final long awaitNanos(long nanosTimeout) throws InterruptedException
• public final boolean awaitUntil(Date deadline) throws InterruptedException
• public final boolean await(long time, TimeUnit unit) throws InterruptedException
• public final void signal()
• public final void signalAll()

先理解一下ConditionObject的应用场景，和Objectd的wait,single方法使用场景的区别。

就拿生产者/消费者程序看，假想用object.wait和single实现： 

伪代码如下：

Array queue;
Object empty = new Object();
Object full = new Object();

// 生产者
if(queue 是否满了)
   full.wait() //阻塞等待
else 
   put(queue , data) //放入数据
   empty.single(); // 已经放了一个，通知一下


// 消费者
if(queue 是否空了)
  empty.wait() // 阻塞等待
else 
  data = get(queue);
  full.single() //  已经消费了，通知一下

 

存在的问题： 

1. 如何保证put和get数据是满足是线程安全的？ CAS设计 or 使用同步原语？ 

很明显，CAS的设计满足不了 queue的两个操作，第一数据入库，第二下标+1，存在安全隐患。所以需要使用对queue进行同步控制。但这样会引出思索的问题，拿到queue的锁后，一直在等待empty或者full通知。

这里ConditionObject就能很好的解决这个问题，不存在死的问题。它的执行一个条件的await操作时，会首先释放当前所持有的Lock，让其他的线程可以进行生产/消费处理。说白了2个object是基于同一个Node等待队列链表。

 

整体概念

在整个AQS存在两种链表。 一个链表就是整个Sync Node链表，横向链表。另一种链表就是Condition的wait Node链表，相对于Sync node，它属于node节点的一个纵向链表。当纵向列表被single通知后，会进入对应的Sync Node进行排队处理。

 

通过这样的纵横队列，实现了ConditionObject共享lock锁数据。