Java并发系列之AbstractQueuedSynchronizer源码分析(概要分析)

学习Java并发编程不得不去了解一下java.util.concurrent这个包,这个包下面有许多我们经常用到的并发工具类,例如:ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore等。而这些类的底层实现都依赖于AbstractQueuedSynchronizer这个类,由此可见这个类的重要性。所以在Java并发系列文章中我首先对AbstractQueuedSynchronizer这个类进行分析,由于这个类比较重要,而且代码比较长,为了尽可能分析的透彻一些,我决定用四篇文章对该类进行一个比较完整的介绍。本篇文章作为概要介绍主要是让读者们对该类有个初步了解。为了叙述简单,后续有些地方会用AQS代表这个类。

1. AbstractQueuedSynchronizer这个类是干嘛的?

相信要许多读者使用过ReentrantLock,但是却不知道AbstractQueuedSynchronizer的存在。其实ReentrantLock实现了一个内部类Sync,该内部类继承了AbstractQueuedSynchronizer,所有锁机制的实现都是依赖于Sync内部类,也可以说ReentrantLock的实现就是依赖于AbstractQueuedSynchronizer类。于此类似,CountDownLatch, CyclicBarrier, Semaphore这些类也是采用同样的方式来实现自己对于锁的控制。可见,AbstractQueuedSynchronizer是这些类的基石。那么AQS内部到底实现了什么以至于所以这些类都要依赖于它呢?可以这样说,AQS为这些类提供了基础设施,也就是提供了一个密码锁,这些类拥有了密码锁之后可以自己来设置密码锁的密码。此外,AQS还提供了一个排队区,并且提供了一个线程训导员,我们知道线程就像一个原始的野蛮人,它不懂得讲礼貌,它只会横冲直撞,所以你得一步一步去教它,告诉它什么时候需要去排队了,要到哪里去排队,排队前要做些什么,排队后要做些什么。这些教化工作全部都由AQS帮你完成了,从它这里教化出来的线程都变的非常文明懂礼貌,不再是原始的野蛮人,所以以后我们只需要和这些文明的线程打交道就行了,千万不要和原始线程有过多的接触!

2. 为何说AbstractQueuedSynchronizer提供了一把密码锁?

//同步队列的头结点
private transient volatile Node head; 

//同步队列的尾结点
private transient volatile Node tail;

//同步状态
private volatile int state;

//获取同步状态
protected final int getState() {
 return state;
}

//设置同步状态
protected final void setState(int newState) {
 state = newState;
}

//以CAS方式设置同步状态
protected final boolean compareAndSetState(int expect, int update) {
 return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

上面的代码列出了AQS的所有成员变量,可以看到AQS的成员变量只有三个,分别是同步队列头结点引用,同步队列尾结点引用以及同步状态。注意,这三个成员变量都使用了volatile关键字进行修饰,这就确保了多个线程对它的修改都是内存可见的。整个类的核心就是这个同步状态,可以看到同步状态其实就是一个int型的变量,大家可以把这个同步状态看成一个密码锁,而且还是从房间里面锁起来的密码锁,state具体的值就相当于密码控制着密码锁的开合。当然这个锁的密码是多少就由各个子类来规定了,例如在ReentrantLock中,state等于0表示锁是开的,state大于0表示锁是锁着的,而在Semaphore中,state大于0表示锁是开的,state等于0表示锁是锁着的。

3. AbstractQueuedSynchronizer的排队区是怎样实现的?

AbstractQueuedSynchronizer内部其实有两个排队区,一个是同步队列,一个是条件队列。从上图可以看出,同步队列只有一条,而条件队列可以有多条。同步队列的结点分别持有前后结点的引用,而条件队列的结点只有一个指向后继结点的引用。图中T表示线程,每个结点包含一个线程,线程在获取锁失败后首先进入同步队列排队,而想要进入条件队列该线程必须持有锁才行。接下来我们看看队列中每个结点的结构。

//同步队列的结点
static final class Node {

 static final Node SHARED = new Node(); //表示当前线程以共享模式持有锁

 static final Node EXCLUSIVE = null; //表示当前线程以独占模式持有锁

 static final int CANCELLED = 1;  //表示当前结点已经取消获取锁

 static final int SIGNAL = -1;  //表示后继结点的线程需要运行

 static final int CONDITION = -2;  //表示当前结点在条件队列中排队

 static final int PROPAGATE = -3;  //表示后继结点可以直接获取锁

 volatile int waitStatus; //表示当前结点的等待状态

 volatile Node prev;  //表示同步队列中的前继结点

 volatile Node next;  //表示同步队列中的后继结点 

 volatile Thread thread; //当前结点持有的线程引用

 Node nextWaiter;   //表示条件队列中的后继结点

 //当前结点状态是否是共享模式
 final boolean isShared() {
  return nextWaiter == SHARED;
 }

 //返回当前结点的前继结点
 final Node predecessor() throws NullPointerException {
  Node p = prev;
  if (p == null) {
   throw new NullPointerException();
  } else {
   return p;
  }
 }

 //构造器1
 Node() {}

 //构造器2, 默认用这个构造器
 Node(Thread thread, Node mode) {
  //注意持有模式是赋值给nextWaiter
  this.nextWaiter = mode;
  this.thread = thread;
 }

 //构造器3, 只在条件队列中用到
 Node(Thread thread, int waitStatus) {
  this.waitStatus = waitStatus;
  this.thread = thread;
 }
}

Node代表同步队列和条件队列中的一个结点,它是AbstractQueuedSynchronizer的内部类。Node有很多属性,比如持有模式,等待状态,同步队列中的前继和后继,以及条件队列中的后继引用等等。可以把同步队列和条件队列看成是排队区,每个结点看成是排队区的座位,将线程看成是排队的客人。客人刚来时会先去敲敲门,看看锁有没有开,如果锁没开它就会去排队区领取一个号码牌,声明自己想要以什么样的方式来持有锁,最后再到队列的末尾进行排队。

4 怎样理解独占模式和共享模式?

前面讲到每个客人在排队前会领取一个号码牌,声明自己想要以什么样的方式来占有锁,占有锁的方式分为独占模式和共享模式,那么怎样来理解独占模式和共享模式呢?实在找不到什么好的比喻,大家可以联想一下公共厕所,独占模式的人比较霸道,老子要么就不进,进来了就不许别人再进了,自己一个人独自占用整个厕所。共享模式的人就没那么讲究了,当它发现这个厕所已经可以用了之后,它自己进来还不算,还得热心的问下后面的人介不介意一起用,如果后面的人不介意一起使用那就不用再排队了大家一起上就是了, 当然如果后面的人介意那就只好留在队列里继续排队了。

5 怎样理解结点的等待状态?

我们还看到每个结点都有一个等待状态,这个等待状态分为CANCELLED,SIGNAL,CONDITION,PROPAGATE四种状态。可以将这个等待状态看作是挂在座位旁边的牌子,标识当前座位上的人的等待状态。这个牌子的状态不仅自己可以修改,其他人也可以修改。例如当这个线程在排队过程中已经打算放弃了,它就会将自己座位上的牌子设置为CANCELLED,这样其他人看到了就可以将它清理出队列。还有一种情况是,当线程在座位上要睡着之前,它怕自己睡过了头,就会将前面位置上的牌子改为SIGNAL,因为每个人在离开队列前都会回到自己座位上看一眼,如果看到牌子上状态为SIGNAL,它就会去唤醒下一个人。只有保证前面位置上的牌子为SIGNAL,当前线程才会安心的睡去。CONDITION状态表示该线程在条件队列中排队,PROPAGATE状态提醒后面来的线程可以直接获取锁,这个状态只在共享模式用到,后面单独讲共享模式的时候会讲到。

6. 结点进入同步队列时会进行哪些操作?

//结点入队操作, 返回前一个结点
private Node enq(final Node node) {
 for (;;) {
  //获取同步队列尾结点引用
  Node t = tail;
  //如果尾结点为空说明同步队列还没有初始化
  if (t == null) {
   //初始化同步队列
   if (compareAndSetHead(new Node())) {
    tail = head;
   }
  } else {
   //1.指向当前尾结点
   node.prev = t;
   //2.设置当前结点为尾结点
   if (compareAndSetTail(t, node)) {
    //3.将旧的尾结点的后继指向新的尾结点
    t.next = node;
    //for循环唯一的出口
    return t;
   }
  }
 }
}

注意,入队操作使用一个死循环,只有成功将结点添加到同步队列尾部才会返回,返回结果是同步队列原先的尾结点。下图演示了整个操作过程。

读者需要注意添加尾结点的顺序,分为三步:指向尾结点,CAS更改尾结点,将旧尾结点的后继指向当前结点。在并发环境中这三步操作不一定能保证完成,所以在清空同步队列所有已取消的结点这一操作中,为了寻找非取消状态的结点,不是从前向后遍历而是从后向前遍历的。还有就是每个结点进入队列中时它的等待状态是为0,只有后继结点的线程需要挂起时才会将前面结点的等待状态改为SIGNAL。

注:以上全部分析基于JDK1.7,不同版本间会有差异,读者需要注意。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

您可能感兴趣的文章:

  • Java并发系列之Semaphore源码分析
  • Java并发系列之CountDownLatch源码分析
  • Java并发系列之CyclicBarrier源码分析
  • Java并发系列之ConcurrentHashMap源码分析
  • Java并发系列之AbstractQueuedSynchronizer源码分析(共享模式)
  • Java并发系列之AbstractQueuedSynchronizer源码分析(独占模式)
  • Java并发系列之ReentrantLock源码分析
  • Java并发系列之AbstractQueuedSynchronizer源码分析(条件队列)
  • Java并发系列之Semaphore源码分析
  • Java并发系列之ReentrantLock源码分析
(0)

相关推荐

  • Java并发系列之CountDownLatch源码分析

    CountDownLatch(闭锁)是一个很有用的工具类,利用它我们可以拦截一个或多个线程使其在某个条件成熟后再执行.它的内部提供了一个计数器,在构造闭锁时必须指定计数器的初始值,且计数器的初始值必须大于0.另外它还提供了一个countDown方法来操作计数器的值,每调用一次countDown方法计数器都会减1,直到计数器的值减为0时就代表条件已成熟,所有因调用await方法而阻塞的线程都会被唤醒.这就是CountDownLatch的内部机制,看起来很简单,无非就是阻塞一部分线程让其在达到某个条

  • Java并发系列之ConcurrentHashMap源码分析

    我们知道哈希表是一种非常高效的数据结构,设计优良的哈希函数可以使其上的增删改查操作达到O(1)级别.Java为我们提供了一个现成的哈希结构,那就是HashMap类,在前面的文章中我曾经介绍过HashMap类,知道它的所有方法都未进行同步,因此在多线程环境中是不安全的.为此,Java为我们提供了另外一个HashTable类,它对于多线程同步的处理非常简单粗暴,那就是在HashMap的基础上对其所有方法都使用synchronized关键字进行加锁.这种方法虽然简单,但导致了一个问题,那就是在同一时间

  • Java并发系列之AbstractQueuedSynchronizer源码分析(条件队列)

    通过前面三篇的分析,我们深入了解了AbstractQueuedSynchronizer的内部结构和一些设计理念,知道了AbstractQueuedSynchronizer内部维护了一个同步状态和两个排队区,这两个排队区分别是同步队列和条件队列.我们还是拿公共厕所做比喻,同步队列是主要的排队区,如果公共厕所没开放,所有想要进入厕所的人都得在这里排队.而条件队列主要是为条件等待设置的,我们想象一下如果一个人通过排队终于成功获取锁进入了厕所,但在方便之前发现自己没带手纸,碰到这种情况虽然很无奈,但是它

  • Java并发系列之Semaphore源码分析

    Semaphore(信号量)是JUC包中比较常用到的一个类,它是AQS共享模式的一个应用,可以允许多个线程同时对共享资源进行操作,并且可以有效的控制并发数,利用它可以很好的实现流量控制.Semaphore提供了一个许可证的概念,可以把这个许可证看作公共汽车车票,只有成功获取车票的人才能够上车,并且车票是有一定数量的,不可能毫无限制的发下去,这样就会导致公交车超载.所以当车票发完的时候(公交车以满载),其他人就只能等下一趟车了.如果中途有人下车,那么他的位置将会空闲出来,因此如果这时其他人想要上车

  • Java并发之ReentrantLock类源码解析

    ReentrantLock内部由Sync类实例实现. Sync类定义于ReentrantLock内部. Sync继承于AbstractQueuedSynchronizer. AbstractQueuedSynchronizer继承于AbstractOwnableSynchronizer. AbstractOwnableSynchronizer类中只定义了一个exclusiveOwnerThread变量,表示当前拥有的线程. 除了Sync类,ReentrantLock内部还定义了两个实现类. No

  • Java并发系列之AbstractQueuedSynchronizer源码分析(独占模式)

    在上一篇<Java并发系列[1]----AbstractQueuedSynchronizer源码分析之概要分析>中我们介绍了AbstractQueuedSynchronizer基本的一些概念,主要讲了AQS的排队区是怎样实现的,什么是独占模式和共享模式以及如何理解结点的等待状态.理解并掌握这些内容是后续阅读AQS源码的关键,所以建议读者先看完我的上一篇文章再回过头来看这篇就比较容易理解.在本篇中会介绍在独占模式下结点是怎样进入同步队列排队的,以及离开同步队列之前会进行哪些操作.AQS为在独占模

  • Java并发系列之ReentrantLock源码分析

    在Java5.0之前,协调对共享对象的访问可以使用的机制只有synchronized和volatile.我们知道synchronized关键字实现了内置锁,而volatile关键字保证了多线程的内存可见性.在大多数情况下,这些机制都能很好地完成工作,但却无法实现一些更高级的功能,例如,无法中断一个正在等待获取锁的线程,无法实现限定时间的获取锁机制,无法实现非阻塞结构的加锁规则等.而这些更灵活的加锁机制通常都能够提供更好的活跃性或性能.因此,在Java5.0中增加了一种新的机制:Reentrant

  • Java并发系列之AbstractQueuedSynchronizer源码分析(共享模式)

    通过上一篇的分析,我们知道了独占模式获取锁有三种方式,分别是不响应线程中断获取,响应线程中断获取,设置超时时间获取.在共享模式下获取锁的方式也是这三种,而且基本上都是大同小异,我们搞清楚了一种就能很快的理解其他的方式.虽然说AbstractQueuedSynchronizer源码有一千多行,但是重复的也比较多,所以读者不要刚开始的时候被吓到,只要耐着性子去看慢慢的自然能够渐渐领悟.就我个人经验来说,阅读AbstractQueuedSynchronizer源码有几个比较关键的地方需要弄明白,分别是

  • Java并发系列之CyclicBarrier源码分析

    现实生活中我们经常会遇到这样的情景,在进行某个活动前需要等待人全部都齐了才开始.例如吃饭时要等全家人都上座了才动筷子,旅游时要等全部人都到齐了才出发,比赛时要等运动员都上场后才开始.在JUC包中为我们提供了一个同步工具类能够很好的模拟这类场景,它就是CyclicBarrier类.利用CyclicBarrier类可以实现一组线程相互等待,当所有线程都到达某个屏障点后再进行后续的操作.下图演示了这一过程. 在CyclicBarrier类的内部有一个计数器,每个线程在到达屏障点的时候都会调用await

  • Java并发系列之AbstractQueuedSynchronizer源码分析(概要分析)

    学习Java并发编程不得不去了解一下java.util.concurrent这个包,这个包下面有许多我们经常用到的并发工具类,例如:ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore等.而这些类的底层实现都依赖于AbstractQueuedSynchronizer这个类,由此可见这个类的重要性.所以在Java并发系列文章中我首先对AbstractQueuedSynchronizer这个类进行分析,由于这个类比较重要,而且代码比较长,为了

  • Java并发编程之Condition源码分析(推荐)

    Condition介绍 上篇文章讲了ReentrantLock的加锁和释放锁的使用,这篇文章是对ReentrantLock的补充.ReentrantLock#newCondition()可以创建Condition,在ReentrantLock加锁过程中可以利用Condition阻塞当前线程并临时释放锁,待另外线程获取到锁并在逻辑后通知阻塞线程"激活".Condition常用在基于异步通信的同步机制实现中,比如dubbo中的请求和获取应答结果的实现. 常用方法 Condition中主要的

随机推荐