一、什么是CAS

CAS(Compare And Swap),即比较并交换。是解决多线程并行情况下使用锁造成性能损耗的一种机制,CAS操作包含三个操作数——内存位置(V)、预期原值(A)和新值(B)。如果内存位置的值与预期原值相匹配,那么处理器会自动将该位置值更新为新值。否则,处理器不做任何操作。无论哪种情况,它都会在CAS指令之前返回该位置的值。CAS有效地说明了“我认为位置V应该包含值A;如果包含该值,则将B放到这个位置;否则,不要更改该位置,只告诉我这个位置现在的值即可。

在JAVA中,sun.misc.Unsafe 类提供了硬件级别的原子操作来实现这个CAS。 java.util.concurrent 包下的大量类都使用了这个 Unsafe.java 类的CAS操作。

二、CAS典型应用

java.util.concurrent.atomic 包下的类大多是使用CAS操作来实现的(eg. AtomicInteger.java,AtomicBoolean,AtomicLong)。下面以 AtomicInteger.java 的部分实现来大致讲解下这些原子类的实现。

  1. public class AtomicInteger extends Number implements java.io.Serializable {
  2. private static final long serialVersionUID = 6214790243416807050L;
  3.  
  4. // setup to use Unsafe.compareAndSwapInt for updates
  5. private static final Unsafe unsafe = Unsafe.getUnsafe();
  6.  
  7. private volatile int value;// 初始int大小
  8. // 省略了部分代码...
  9.  
  10. // 带参数构造函数,可设置初始int大小
  11. public AtomicInteger(int initialValue) {
  12. value = initialValue;
  13. }
  14. // 不带参数构造函数,初始int大小为0
  15. public AtomicInteger() {
  16. }
  17.  
  18. // 获取当前值
  19. public final int get() {
  20. return value;
  21. }
  22.  
  23. // 设置值为 newValue
  24. public final void set(int newValue) {
  25. value = newValue;
  26. }
  27.  
  28. //返回旧值,并设置新值为 newValue
  29. public final int getAndSet(int newValue) {
  30. /**
  31. * 这里使用for循环不断通过CAS操作来设置新值
  32. * CAS实现和加锁实现的关系有点类似乐观锁和悲观锁的关系
  33. * */
  34. for (;;) {
  35. int current = get();
  36. if (compareAndSet(current, newValue))
  37. return current;
  38. }
  39. }
  40.  
  41. // 原子的设置新值为update, expect为期望的当前的值
  42. public final boolean compareAndSet(int expect, int update) {
  43. return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
  44. }
  45.  
  46. // 获取当前值current,并设置新值为current+1
  47. public final int getAndIncrement() {
  48. for (;;) {
  49. int current = get();
  50. int next = current + 1;
  51. if (compareAndSet(current, next))
  52. return current;
  53. }
  54. }
  55.  
  56. // 此处省略部分代码,余下的代码大致实现原理都是类似的
  57. }

一般来说在竞争不是特别激烈的时候,使用该包下的原子操作性能比使用 synchronized 关键字的方式高效的多(查看getAndSet(),可知如果资源竞争十分激烈的话,这个for循环可能换持续很久都不能成功跳出。不过这种情况可能需要考虑降低资源竞争才是)。 
在较多的场景我们都可能会使用到这些原子类操作。一个典型应用就是计数了,在多线程的情况下需要考虑线程安全问题。通常第一映像可能就是:

  1. public class Counter {
  2. private int count;
  3. public Counter(){}
  4. public int getCount(){
  5. return count;
  6. }
  7. public void increase(){
  8. count++;
  9. }
  10. }

上面这个类在多线程环境下会有线程安全问题,要解决这个问题最简单的方式可能就是通过加锁的方式,调整如下:

  1.  
  1. public class Counter {
  2. private int count;
  3. public Counter(){}
  4. public synchronized int getCount(){
  5. return count;
  6. }
  7. public synchronized void increase(){
  8. count++;
  9. }
  10. }

这类似于悲观锁的实现,我需要获取这个资源,那么我就给他加锁,别的线程都无法访问该资源,直到我操作完后释放对该资源的锁。我们知道,悲观锁的效率是不如乐观锁的,上面说了Atomic下的原子类的实现是类似乐观锁的,效率会比使用 synchronized 关系字高,推荐使用这种方式,实现如下:

  1. public class Counter {
  2. private AtomicInteger count = new AtomicInteger();
  3. public Counter(){}
  4. public int getCount(){
  5. return count.get();
  6. }
  7. public void increase(){
  8. count.getAndIncrement();
  9. }
  10. }  

三、什么是AQS

AQS(AbstractQueuedSynchronizer),AQS是JDK下提供的一套用于实现基于FIFO等待队列的阻塞锁和相关的同步器的一个同步框架。它使用了一个原子的int value status来作为同步器的状态(如:独占锁,1代表已占有,0代表未占有),通过该类提供的原子修改status方法(getState setState and compareAnsSetState),我们可以把它作为同步器的基础框架类来实现各种同步器。AQS还定义了一个实现了Condition接口的ConditionObject内部类。Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象,以便通过将这些对象与任意 Lock 实现组合使用,为每个对象提供多个等待 set (wait-set)。其中,Lock 替代了 synchronized 方法和语句的使用,Condition 替代了 Object 监视器方法的使用。 
简单来说,就是Condition提供类似于Object的wait、notify的功能signal和await,都是可以使一个正在执行的线程挂起(推迟执行),直到被其他线程唤醒。但是Condition更加强大,如支持多个条件谓词、保证线程唤醒的顺序和在挂起时不需要拥有锁。这个抽象类被设计为作为一些可用原子int值来表示状态的同步器的基类。如果你有看过类似 CountDownLatch 类的源码实现,会发现其内部有一个继承了 AbstractQueuedSynchronizer 的内部类 Sync。可见 CountDownLatch 是基于AQS框架来实现的一个同步器.类似的同步器在JUC下还有不少。(eg. Semaphore)

四、AQS用法

如上所述,AQS管理一个关于状态信息的单一整数,该整数可以表现任何状态。比如, Semaphore 用它来表现剩余的许可数,ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁;FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)

  1. To use this class as the basis of a synchronizer, redefine the
  2. * following methods, as applicable, by inspecting and/or modifying
  3. * the synchronization state using {@link #getState}, {@link
  4. * #setState} and/or {@link #compareAndSetState}:
  5. *
  6. * <ul>
  7. * <li> {@link #tryAcquire}
  8. * <li> {@link #tryRelease}
  9. * <li> {@link #tryAcquireShared}
  10. * <li> {@link #tryReleaseShared}
  11. * <li> {@link #isHeldExclusively}
  12. * </ul>

如JDK的文档中所说,使用AQS来实现一个同步器需要覆盖实现如下几个方法,并且使用getState,setState,compareAndSetState这几个方法来设置获取状态 
1. boolean tryAcquire(int arg) 
2. boolean tryRelease(int arg) 
3. int tryAcquireShared(int arg) 
4. boolean tryReleaseShared(int arg) 
5. boolean isHeldExclusively()

以上方法不需要全部实现,根据获取的锁的种类可以选择实现不同的方法,支持独占(排他)获取锁的同步器应该实现tryAcquire、 tryReleaseisHeldExclusively而支持共享获取的同步器应该实现tryAcquireSharedtryReleaseSharedisHeldExclusively。下面以 CountDownLatch 举例说明基于AQS实现同步器, CountDownLatch 用同步状态持有当前计数,countDown方法调用 release从而导致计数器递减;当计数器为0时,解除所有线程的等待;await调用acquire,如果计数器为0,acquire 会立即返回,否则阻塞。通常用于某任务需要等待其他任务都完成后才能继续执行的情景。源码如下:

  1. public class CountDownLatch {
  2. /**
  3. * 基于AQS的内部Sync
  4. * 使用AQS的state来表示计数count.
  5. */
  6. private static final class Sync extends AbstractQueuedSynchronizer {
  7. private static final long serialVersionUID = 4982264981922014374L;
  8.  
  9. Sync(int count) {
  10. // 使用AQS的getState()方法设置状态
  11. setState(count);
  12. }
  13.  
  14. int getCount() {
  15. // 使用AQS的getState()方法获取状态
  16. return getState();
  17. }
  18.  
  19. // 覆盖在共享模式下尝试获取锁
  20. protected int tryAcquireShared(int acquires) {
  21. // 这里用状态state是否为0来表示是否成功,为0的时候可以获取到返回1,否则不可以返回-1
  22. return (getState() == 0) ? 1 : -1;
  23. }
  24.  
  25. // 覆盖在共享模式下尝试释放锁
  26. protected boolean tryReleaseShared(int releases) {
  27. // 在for循环中Decrement count直至成功;
  28. // 当状态值即count为0的时候,返回false表示 signal when transition to zero
  29. for (;;) {
  30. int c = getState();
  31. if (c == 0)
  32. return false;
  33. int nextc = c-1;
  34. if (compareAndSetState(c, nextc))
  35. return nextc == 0;
  36. }
  37. }
  38. }
  39.  
  40. private final Sync sync;
  41.  
  42. // 使用给定计数值构造CountDownLatch
  43. public CountDownLatch(int count) {
  44. if (count < 0) throw new IllegalArgumentException("count < 0");
  45. this.sync = new Sync(count);
  46. }
  47.  
  48. // 让当前线程阻塞直到计数count变为0,或者线程被中断
  49. public void await() throws InterruptedException {
  50. sync.acquireSharedInterruptibly(1);
  51. }
  52.  
  53. // 阻塞当前线程,除非count变为0或者等待了timeout的时间。当count变为0时,返回true
  54. public boolean await(long timeout, TimeUnit unit)
  55. throws InterruptedException {
  56. return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
  57. }
  58.  
  59. // count递减
  60. public void countDown() {
  61. sync.releaseShared(1);
  62. }
  63.  
  64. // 获取当前count值
  65. public long getCount() {
  66. return sync.getCount();
  67. }
  68.  
  69. public String toString() {
  70. return super.toString() + "[Count = " + sync.getCount() + "]";
  71. }
  72. }  

  

五、AQS独占锁官方例子(1代表锁被占用,0代表未被占)

  1. class Mutex implements Lock, java.io.Serializable {
  2.  
  3. // 定义一个内部帮助类
  4. private static class Sync extends AbstractQueuedSynchronizer {
  5. // 判断当前独占锁是否被持有
  6. protected boolean isHeldExclusively() {
  7. return getState() == 1;
  8. }
  9.  
  10. // 重写AQS独占锁获取锁方法:如果当前AQS的state状态为0,则获取锁成功
  11. public boolean tryAcquire(int acquires) {
  12. assert acquires == 1; // Otherwise unused
  13. //CAS (Compare and Set)调用CPU指令原子更新AQS的state值
  14. if (compareAndSetState(0, 1)) {
  15. setExclusiveOwnerThread(Thread.currentThread());
  16. //返回获取成功
  17. return true;
  18. }
  19. return false;
  20. }
  21.  
  22. // 重写AQS独占锁释放方法
  23. protected boolean tryRelease(int releases) {
  24. assert releases == 1; // Otherwise unused
  25. if (getState() == 0) throw new IllegalMonitorStateException();
  26. setExclusiveOwnerThread(null);
  27. //可以看到这里并没有使用CAS原子更新state的值,不够严谨
  28. setState(0);
  29. return true;
  30. }
  31.  
  32. // 提供条件队列功能
  33. Condition newCondition() { return new ConditionObject(); }
  34.  
  35. // Deserialize properly
  36. private void readObject(ObjectInputStream s)
  37. throws IOException, ClassNotFoundException {
  38. s.defaultReadObject();
  39. setState(0); // reset to unlocked state
  40. }
  41. }
  42.  
  43. // 下面Mutex提供的功能,实际上仅仅只是委托了AQS的独占锁实现类Sync
  44. private final Sync sync = new Sync();
  45.  
  46. public void lock() { sync.acquire(1); }
  47. public boolean tryLock() { return sync.tryAcquire(1); }
  48. public void unlock() { sync.release(1); }
  49. public Condition newCondition() { return sync.newCondition(); }
  50. public boolean isLocked() { return sync.isHeldExclusively(); }
  51. public boolean hasQueuedThreads() { return sync.hasQueuedThreads(); }
  52. public void lockInterruptibly() throws InterruptedException {
  53. sync.acquireInterruptibly(1);
  54. }
  55. public boolean tryLock(long timeout, TimeUnit unit)
  56. throws InterruptedException {
  57. return sync.tryAcquireNanos(1, unit.toNanos(timeout));
  58. }
  59. }
  60.  
  61. /*
  62. 看完了上面AQS的独占锁实现,再来看下AQS的共享锁实现。下面这个是AQS的共享锁实现类,它类似于JDK提供的闭锁CountDownLatch
  63. BooleanLatch 顾名思义,是个类似于布尔型的闭锁。即如果该锁为真时候则能获取,为假时候则等待直到另外线程修改该锁状态为真。
  64. */
  65. class BooleanLatch {
  66.  
  67. private static class Sync extends AbstractQueuedSynchronizer {
  68. boolean isSignalled() { return getState() != 0; }
  69. //重写AQS的共享锁获取方法,只要返回的值大于0则可以获取锁,否则AQS会调用unsafe的park挂起线程,后面我们会分析这块源码
  70. protected int tryAcquireShared(int ignore) {
  71. return isSignalled() ? 1 : -1;
  72. }
  73. //重写AQS的共享锁释放方法,这里仅仅只是设置AQS的state值为1,和参数ignore没有任何关系。设置完毕后,AQS会调用unsafe的unpark唤醒线程,则之前被挂起的线程会重新执行tryAcquireShared
  74. //方法。而此时的state大于0,则可以获取锁
  75. protected boolean tryReleaseShared(int ignore) {
  76. setState(1);
  77. return true;
  78. }
  79. }
  80.  
  81. private final Sync sync = new Sync();
  82. public boolean isSignalled() { return sync.isSignalled(); }
  83. public void signal() { sync.releaseShared(1); }
  84. public void await() throws InterruptedException {
  85. sync.acquireSharedInterruptibly(1);
  86. }
  87. }

AQS就是一个阻塞锁和相关同步器的实现类的底层框架!它封装了线程、挂起唤醒的内部运作,我们只需要通过设置AQS的state值来控制他的线程挂起和唤醒的运作路径,就可以实现我们的同步器类了。  

六、LoclSupport源码分析

LockSupport是用来创建锁和其他同步类的基本线程阻塞基本体(primitives)。通过调用LockSupport的park方法可以申请一个许可,如果当前许可可用的话,那么则立即返回,否则则阻塞等待许可。直到另外一个线程调用unpark方法对被阻塞的线程的许可进行释放。(默认许可阻塞)

park方法还支持Blocker对象参数,在调用park方法对当前线程进行阻塞时候,可以把Blocker对象参数传递过来,LockSupport的park方法里会调用setBlocker方法把该对象参数存入到Thread里的parkBlocker变量里。我们可以通过getBlocker获取线程的parkBlocker变量,从而得知该线程正在被阻塞的原因。

  1. public class LockSupport {
  2. private LockSupport() {} // 禁止创建对象
  3.  
  4. // Unsafe实际上调用的都是本地方法native
  5. private static final Unsafe unsafe = Unsafe.getUnsafe();
  6. private static final long parkBlockerOffset;
  7.  
  8. static {
  9. try {
  10. //获取Thread的成员变量parkBlocker的偏移量
  11. parkBlockerOffset = unsafe.objectFieldOffset
  12. (java.lang.Thread.class.getDeclaredField("parkBlocker"));
  13. } catch (Exception ex) { throw new Error(ex); }
  14. }
  15. //设置Blocker对象到Thread对象里面
  16. private static void setBlocker(Thread t, Object arg) {
  17. // Even though volatile, hotspot doesn't need a write barrier here.
  18. unsafe.putObject(t, parkBlockerOffset, arg);
  19. }
  20.  
  21. //获取先前park时候存入的线程的Blocker,如果未存入或者当前线程并不在park里,则为null
  22. public static Object getBlocker(Thread t) {
  23. if (t == null)
  24. throw new NullPointerException();
  25. return unsafe.getObjectVolatile(t, parkBlockerOffset);
  26. }
  27.  
  28. //对于给定的Thread释放它所占有的许可。如果当前线程已经占有许可,则释放。如果为占有也释放,那么下次调用该线程的unpark方法时候
  29. //会导致park直接获取了。因为上次已经释放了
  30. public static void unpark(Thread thread) {
  31. if (thread != null)
  32. unsafe.unpark(thread);
  33. }
  34.  
  35. //挂起当前线程,且把Blocker存到线程中
  36. public static void park(Object blocker) {
  37. Thread t = Thread.currentThread();
  38. setBlocker(t, blocker);
  39. //false代表非绝对时间(即相对时间)
  40. unsafe.park(false, 0L);
  41. setBlocker(t, null);
  42. }
  43. }

 

七、LockSupport使用例子

  1. class FIFOMutex {
  2. private final AtomicBoolean locked = new AtomicBoolean(false);
  3. private final Queue waiters = new ConcurrentLinkedQueue();
  4.  
  5. public void lock() {
  6. boolean wasInterrupted = false;
  7. //首先获取当前线程,然后存入waiters 队列头部
  8. Thread current = Thread.currentThread();
  9. waiters.add(current);
  10.  
  11. // 先循环判断是否满足线程挂起条件
  12. while (waiters.peek() != current ||
  13. !locked.compareAndSet(false, true)) {
  14. //把当前的FIFOMutex 对象传递到 LockSupport.park(this),LockSupport会把this给赋值到当前Thread的变量里
  15. LockSupport.park(this);
  16. if (Thread.interrupted()) // ignore interrupts while waiting
  17. wasInterrupted = true;
  18. }
  19. //上面那段while循环主要是负责阻塞挂起线程。当挂起条件不满足后则跳出循环
  20. //删除队列头部已被阻塞完成的线程
  21. waiters.remove();
  22. if (wasInterrupted) // reassert interrupt status on exit
  23. current.interrupt();
  24. }
  25. //释放线程
  26. public void unlock() {
  27. locked.set(false);
  28. LockSupport.unpark(waiters.peek());
  29. }
  30. }}
  31.  
  32. //TestFIFOMutex是FIFOMutex的测试例子
  33. import java.util.Date;
  34.  
  35. public class TestFIFOMutex {
  36.  
  37. private static FIFOMutex mutex = new FIFOMutex();
  38.  
  39. public static void main(String[] args) {
  40. new Thread(new Runnable(){
  41. @Override
  42. public void run() {
  43. sleep(1000 * 2);
  44. System.out.println(new Date().toGMTString()+" :t1 准备lock");
  45. mutex.lock();
  46. System.out.println(new Date().toGMTString()+" :t1 完成lock");
  47. }
  48. }).start();
  49.  
  50. new Thread(new Runnable(){
  51. @Override
  52. public void run() {
  53. sleep(1000 * 3);
  54. System.out.println(new Date().toGMTString()+" :t2 准备lock");
  55. mutex.lock();
  56. System.out.println(new Date().toGMTString()+" :t2 完成lock");
  57. }
  58. }).start();
  59.  
  60. new Thread(new Runnable(){
  61. @Override
  62. public void run() {
  63. sleep(1000 * 5);
  64. System.out.println(new Date().toGMTString()+" :t3 准备 unlock释放");
  65. mutex.unlock();
  66. System.out.println(new Date().toGMTString()+" :t3 释放完毕unlock");
  67. }
  68. }).start();
  69. }
  70.  
  71. public static void sleep(long num){
  72. try {
  73. Thread.sleep(num);
  74. } catch (InterruptedException e) {
  75. e.printStackTrace();
  76. }
  77. }
  78.  
  79. }
  80.  
  81. //TestFIFOMutex执行结果
  82. 24 Nov 2017 14:33:46 GMT :t1 准备lock
  83. 24 Nov 2017 14:33:46 GMT :t1 完成lock
  84. 24 Nov 2017 14:33:47 GMT :t2 准备lock
  85. 24 Nov 2017 14:33:49 GMT :t3 准备 unlock释放
  86. 24 Nov 2017 14:33:49 GMT :t2 完成lock
  87. 24 Nov 2017 14:33:49 GMT :t3 释放完毕unlock  

 

可以发现t2完成lock必须等到t3进行unlock,因为t2线程已经给part挂起了,必须等待unpart唤醒。

八、AQS链表队列结构

AQS内部维护了一个以Node为节点实现的链表的队列。

  1. /**
  2. +------+ prev +-----+ +-----+
  3. head | | <---- | | <---- | | tail
  4. +------+ +-----+ +-----+
  5. /**
  6. static final class Node {
  7. //SHARED作为共享模式下的常量
  8. static final Node SHARED = new Node();
  9. //EXCLUSIVE作为独占模式下的常量
  10. static final Node EXCLUSIVE = null;
  11. //常量:表示节点的线程是已被取消的
  12. static final int CANCELLED = 1;
  13. //常量:表示当前节点的后继节点的线程需要被唤醒
  14. static final int SIGNAL = -1;
  15. //常量:表示线程正在等待某个条件
  16. static final int CONDITION = -2;
  17. //常量:表示下一个共享模式的节点应该无条件的传播下去
  18. static final int PROPAGATE = -3;
  19. /**
  20. * 状态字段:只具有以下值
  21. * SIGNAL: 当前节点的后继节点已经 (或即将)被阻塞(通过park) , 所以当 当前节点释放或则被取消时候
  22. * ,一定要unpark它的后继节点。为了避免竞争,获取方法一定要首先设置node为signal,然后再次重
  23. * 新调用获取方法,如果失败,则阻塞
  24. * CANCELLED: 当前节点由于超时或者被中断而被取消。一旦节点被取消后,那么它的状态值不在会被改变,且当前节点的线程不会再次被阻塞
  25. * CONDITION: 表示当前节点正在条件队列(AQS下的ConditionObject里也维护了个队列)中,
  26. * 在从conditionObject队列转移到同步队列前,它不会在同步队列(AQS下的队列)中被使用。
  27. * 当成功转移后,该节点的状态值将由CONDITION设置为0
  28. * PROPAGATE: 共享模式下的释放操作应该被传播到其他节点。该状态值在doReleaseShared方法中被设置的,
  29. *
  30. * 0: 以上都不是
  31. *
  32. * 该状态值为了简便使用,所以使用了数值类型。非负数值意味着该节点不需要被唤醒。所以,大多数代码中不需要检查该状态值的确定值,
  33. * 只需要根据正负值来判断即可对于一个正常的Node,他的waitStatus初始化值时0.
  34. 对于一个condition队列中的Node,他的初始化值时CONDITION
  35. 如果想要修改这个值,可以使用AQS提供CAS进行修改
  36. */
  37. volatile int waitStatus;
  38. /**
  39. * 指向当前节点的前驱节点,当前节点依赖前驱节点来检测waitStatus,前驱节点是在当前节点入队时候被设置的。
  40. * 为了提高GC效率,在当前节点出队时候会把前驱节点设置为null。而且,在取消前驱节点中,则会循环直到找到一个非取消的节点,
  41. * 由于头节点永远不会是取消状态,所以一定能找到。
  42. */
  43. volatile Node prev;
  44. /**
  45. * 指向当前节点的后继节点,在当前节点释放时候会唤醒后继节点。该后继节点也是在入队时候被分配的。
  46. * 当前驱节点被取消时候,会重新调整链表的节点链接指向关系。如:前驱节点的前驱节点指向当前节点。
  47. * 且把前驱节点设置为null。节点入队操作过程完成前,入队操作并还未设置前驱节点的后继节点。所以
  48. * 会看到前驱节点的后继节点为null,但是这并不意味着前驱节点就是队列的尾节点!如果后继节点为null,
  49. * 我们可以通过从尾节点向前扫描来做双重检测。一个被取消的节点的后继节点被设置为自身。即node.next=node。
  50. * 这样设置会帮助isOnSyncQueue的执行效率更高(即执行时间更短。注意该方法的if (node.next != null))
  51. */
  52. volatile Node next;
  53. /**
  54. * 当前节点的线程。在构造Node时候被初始化,在节点使用完毕后设置为null
  55. * construction and nulled out after use.
  56. */
  57. volatile Thread thread;
  58. /**
  59. * ConditionObject链表的后继节点或者代表共享模式的节点SHARED。Condition条件队列:因为Condition队列只能在独占模式下被能被访问,
  60. * 我们只需要简单的使用链表队列来链接正在等待条件的节点。再然后它们会被转移到同步队列(AQS队列)再次重新获取。
  61. * 由于条件队列只能在独占模式下使用,所以我们要表示共享模式的节点的话只要使用特殊值SHARED来标明即可。
  62. */
  63. Node nextWaiter;
  64. /**
  65. * 如果节点是属于共享模式节点则返回true
  66. */
  67. final boolean isShared() {
  68. return nextWaiter == SHARED;
  69. }
  70. /**
  71. * Returns previous node, or throws NullPointerException if null.
  72. * Use when predecessor cannot be null. The null check could
  73. * be elided, but is present to help the VM.
  74. *
  75. * @return the predecessor of this node
  76. */
  77. final Node predecessor() throws NullPointerException {
  78. Node p = prev;
  79. if (p == null)
  80. throw new NullPointerException();
  81. else
  82. return p;
  83. }
  84. Node() { // Used to establish initial head or SHARED marker
  85. }
  86. Node(Thread thread, Node mode) { // Used by addWaiter
  87. this.nextWaiter = mode;
  88. this.thread = thread;
  89. }
  90. Node(Thread thread, int waitStatus) { // Used by Condition
  91. this.waitStatus = waitStatus;
  92. this.thread = thread;
  93. }
  94. }

公共辅助方法 
在node获取失败时,node入队后,检测和更新node的状态值。

  1. private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
  2. int ws = pred.waitStatus;
  3. //该节点如果状态如果为SIGNAL。则返回true,然后park挂起线程
  4. if (ws == Node.SIGNAL)
  5. return true;
  6. //表明该节点已经被取消,向前循环重新调整链表节点
  7. if (ws > 0) {
  8. /*
  9. * Predecessor was cancelled. Skip over predecessors and
  10. * indicate retry.
  11. */
  12. do {
  13. node.prev = pred = pred.prev;
  14. } while (pred.waitStatus > 0);
  15. pred.next = node;
  16. } else {
  17.  
  18. //执行到这里代表节点是0或者PROPAGATE,然后标记他们为SIGNAL,但是
  19. //还不能park挂起线程。需要重试是否能获取,如果不能则挂起
  20. compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
  21. }
  22. return false;
  23. }

挂起当前线程,且返回线程的中断状态

  1. private final boolean parkAndCheckInterrupt() {
  2. LockSupport.park(this);
  3. return Thread.interrupted();
  4. }

取消节点

  1. private void cancelAcquire(Node node) {
  2. // Ignore if node doesn't exist
  3. if (node == null)
  4. return;
  5. node.thread = null;
  6. // Skip cancelled predecessors
  7. Node pred = node.prev;
  8. //迭代剔除已被取消的节点
  9. while (pred.waitStatus > 0)
  10. node.prev = pred = pred.prev;
  11. // predNext is the apparent node to unsplice. CASes below will
  12. // fail if not, in which case, we lost race vs another cancel
  13. // or signal, so no further action is necessary.
  14. Node predNext = pred.next;
  15. // Can use unconditional write instead of CAS here.
  16. // After this atomic step, other Nodes can skip past us.
  17. // Before, we are free of interference from other threads.
  18. node.waitStatus = Node.CANCELLED;
  19. // If we are the tail, remove ourselves.
  20. if (node == tail && compareAndSetTail(node, pred)) {
  21. compareAndSetNext(pred, predNext, null);
  22. } else {
  23. // If successor needs signal, try to set pred's next-link
  24. // so it will get one. Otherwise wake it up to propagate.
  25. int ws;
  26.  
  27. if (pred != head &&
  28. ((ws = pred.waitStatus) == Node.SIGNAL ||
  29. (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
  30. pred.thread != null) {
  31. Node next = node.next;
  32. if (next != null && next.waitStatus <= 0)
  33. compareAndSetNext(pred, predNext, next);
  34. } else {
  35. /**
  36. 1.头部head
  37. 2.当前节点的前驱节点状态为SIGNAL + 前驱节点线程不为null
  38. 3.如果前驱节点不是取消状态且修改前驱节点状态为SIGNAL成功 + 前驱节点线程不为null
  39.  
  40. 以上三总情况则会释放当前取消的节点的后继节点的线程(注意仅仅只是释放线程,并不代表能成功出队列。还需要在for(;;)重试truAcquire*)。
  41.  
  42. **/
  43. unparkSuccessor(node);
  44. }
  45. node.next = node; // help GC
  46. }
  47. }  

九、独占模式public final void acquire(int arg) 和public final boolean release(int arg)

获取方法

  1. /**
  2. * 忽略中断的(即不手动抛出InterruptedException异常)独占模式下的获取方法。该方法在成功返回前至少
  3. * 会调用一次tryAcquire()方法(该方法是子类重写的方法,如果返回true则代表能成功获取).否则当前线程会进入
  4. * 队列排队,重复的阻塞和唤醒等待再次成功获取后返回, 该方法可以用来实现Lock.lock
  5. *
  6. * @param arg 这个值被传递给tryAcquire使用,主要是用来作为state值处理的参数。可以根据需要灵活使用该值
  7. */
  8. public final void acquire(int arg) {
  9. //首先调用tryAcquire(arg)值尝试获取,如果成功则返回true。!true则等于false不需要进入 acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  10. //进行排队等待再次成功获取
  11. if (!tryAcquire(arg) &&
  12. acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  13. selfInterrupt();
  14. }
  15.  
  16. /**
  17. * 尝试在独占模式下获取.这个方法应该查下该对象的状态是否被允许在独占模式下获取,如果是才获取
  18. * 这个方法通常由线程执行获取时调用,如果该方法返回false,且该线程还未进入队列,则该线程会进去AQS队列排队然后挂起线程,
  19. * 直到其他线程调用release进行通知已被的线程释放。该方法可以备用来实现Lock.tryLock
  20. *
  21. *默认抛出UnsupportedOperationException异常
  22. *
  23. */
  24. protected boolean tryAcquire(int arg) {
  25. throw new UnsupportedOperationException();
  26. }

根据参数mode(Node.EXCLUSIVE或者Node.SHARED)和Thread.currentThread()创建一个节点Node,然后加到AQS链表队列. 
只有在tryAcquire获取失败时候,才进入AQS链表队列等待再次成功获取。 
打个比方:我们去医院看医生,挂号在某个特定教授。如果当前该教授没有任何病人在看病(相等于tryAcquired),那么我们不需要排队就能 
进去看病。否则的话,我们要在门口排队(相当于addWaiter),等待当前在看病的病人出来,出来一个(相当于release)则正在队列 
头部的病人可以进去看病了(大概相当于acquireQueued)。

  1. private Node addWaiter(Node mode) {
  2. Node node = new Node(Thread.currentThread(), mode);
  3. // 尝试快速入队,即无竞争条件下肯定成功。如果失败,则进入enq自旋重试入队
  4. Node pred = tail;
  5. if (pred != null) {
  6. node.prev = pred;
  7. //CAS替换当前尾部。成功则返回
  8. if (compareAndSetTail(pred, node)) {
  9. pred.next = node;
  10. return node;
  11. }
  12. }
  13. enq(node);
  14. return node;
  15. }

插入节点到队列中,如果队列未初始化则初始化。然后再插入

  1. private Node enq(final Node node) {
  2. for (;;) {
  3. Node t = tail;
  4. if (t == null) { // Must initialize
  5. if (compareAndSetHead(new Node()))
  6. tail = head;
  7. } else {
  8. node.prev = t;
  9. if (compareAndSetTail(t, node)) {
  10. t.next = node;
  11. return t;
  12. }
  13. }
  14. }
  15. }

acquireQueued主要是处理正在排队等待的线程。自旋、阻塞重试获取。如果获取成功则替换当前节点为链表头,然后返回。

  1. final boolean acquireQueued(final Node node, int arg) {
  2. boolean failed = true;
  3. try {
  4. boolean interrupted = false;
  5. for (;;) {
  6. //获取当前节点的前驱节点。
  7. final Node p = node.predecessor();
  8. //如果前驱节点是头节点且尝试获取成功,则替换当前节点会链表的头结点,然后返回
  9. //问题:为什么是前驱节点而不是当前节点?因为我们队列在初始化时候生成了个虚拟头节点,相当于多出来了个节点。
  10. if (p == head && tryAcquire(arg)) {
  11. setHead(node);
  12. //设置前驱节点的后继节点为null。使前驱节点成为不可达。方便GC回收
  13. p.next = null; // help GC
  14. failed = false;
  15. return interrupted;
  16. }
  17. //判断当前节点的线程是否应该被挂起,如果应该被挂起则挂起。等待release唤醒释放
  18. //问题:为什么要挂起当前线程?因为如果不挂起的话,线程会一直抢占着CPU
  19. if (shouldParkAfterFailedAcquire(p, node) &&
  20. parkAndCheckInterrupt())
  21. interrupted = true;
  22. }
  23. } finally {
  24. if (failed)
  25. //在队列中取消当前节点
  26. cancelAcquire(node);
  27. }
  28. }

独占模式下的释放,如果方法返回true,可释放1个或者多个线程。该方法可以用来实现Lock.unlock方法

  1.  
  1. public final boolean release(int arg) {
  2. if (tryRelease(arg)) {
  3. Node h = head;
  4. if (h != null && h.waitStatus != 0)
  5. unparkSuccessor(h);
  6. return true;
  7. }
  8. return false;
  9. }

十.共享模式:public final void acquireShared(int arg)和public final boolean releaseShared(int arg)

共享模式的典型例子就是信号量和闭锁了。

共享模式下忽略中断的获取,该方法至少会调用一次子类重写的tryAcquireShared方法,如果首次获取结果大于等于0.则完成获取 
否则进入AQS同步队列阻塞等待机会再次重新尝试获取,直到获取成功。

  1. public final void acquireShared(int arg) {
  2. if (tryAcquireShared(arg) < 0)
  3. doAcquireShared(arg);
  4. }
  5.  
  6. /**
  7. * 共享模式下尝试获取。该方法应该确定在共享模式下,Object的状态值是否允许被获取。
  8. * 如果该方法返回结果被认为失败(值<0),则当前线程会进入AQS的同步队列阻塞等待
  9. * 知道其他线程调用release释放。
  10. *
  11. *
  12. * 默认抛出 UnsupportedOperationException异常
  13. *
  14. * @param arg the acquire argument. This value is always the one
  15. * passed to an acquire method, or is the value saved on entry
  16. * to a condition wait. The value is otherwise uninterpreted
  17. * and can represent anything you like.
  18. * @return a negative value on failure; zero if acquisition in shared
  19. * mode succeeded but no subsequent shared-mode acquire can
  20. * succeed; and a positive value if acquisition in shared
  21. * mode succeeded and subsequent shared-mode acquires might
  22. * also succeed, in which case a subsequent waiting thread
  23. * must check availability. (Support for three different
  24. * return values enables this method to be used in contexts
  25. * where acquires only sometimes act exclusively.) Upon
  26. * success, this object has been acquired.
  27. * @throws IllegalMonitorStateException if acquiring would place this
  28. * synchronizer in an illegal state. This exception must be
  29. * thrown in a consistent fashion for synchronization to work
  30. * correctly.
  31. * @throws UnsupportedOperationException if shared mode is not supported
  32. */
  33. protected int tryAcquireShared(int arg) {
  34. throw new UnsupportedOperationException();
  35. }

共享模式获取的核心公共方法

  1. private void doAcquireShared(int arg) {
  2. //添加当前线程为一个共享模式的节点
  3. final Node node = addWaiter(Node.SHARED);
  4. boolean failed = true;
  5. try {
  6. boolean interrupted = false;
  7. for (;;) {
  8. final Node p = node.predecessor();
  9. if (p == head) {
  10. int r = tryAcquireShared(arg);
  11. //如果当前节点的前驱节点==head 且 state值大于0则认为获取成功
  12. if (r >= 0) {
  13. setHeadAndPropagate(node, r);
  14. p.next = null; // help GC
  15. if (interrupted)
  16. selfInterrupt();
  17. failed = false;
  18. return;
  19. }
  20. }
  21. //判断当前节点是否应该被阻塞,是则阻塞等待其他线程release
  22. if (shouldParkAfterFailedAcquire(p, node) &&
  23. parkAndCheckInterrupt())
  24. interrupted = true;
  25. }
  26. } finally {
  27. //如果出异常,没有完成当前节点的出队,则取消当前节点
  28. if (failed)
  29. cancelAcquire(node);
  30. }
  31. }

设置节点node为AQS同步队列的头结点。如果后继节点为共享模式且参数propagate是否大于0或者PROPAGATE是否已被设置,则唤醒后继节点

  1. private void setHeadAndPropagate(Node node, int propagate) {
  2. Node h = head; // Record old head for check below
  3. //首先设置node为头节点
  4. setHead(node);
  5. /*
  6. * Try to signal next queued node if:
  7. * Propagation was indicated by caller,
  8. * or was recorded (as h.waitStatus) by a previous operation
  9. * (note: this uses sign-check of waitStatus because
  10. * PROPAGATE status may transition to SIGNAL.)
  11. * and
  12. * The next node is waiting in shared mode,
  13. * or we don't know, because it appears null
  14. *
  15. * The conservatism in both of these checks may cause
  16. * unnecessary wake-ups, but only when there are multiple
  17. * racing acquires/releases, so most need signals now or soon
  18. * anyway.
  19. */
  20.  
  21. if (propagate > 0 || h == null || h.waitStatus < 0) {
  22. Node s = node.next;
  23. if (s == null || s.isShared())
  24. doReleaseShared();
  25. }
  26. }

共享模式下的释放,唤醒后继节点并且保证传播。 
注意:在独占模式下,如果需要唤醒,仅仅相当于调用头节点的unparkSuccessor动作。  

  1. private void doReleaseShared() {
  2. /*
  3. * 确保释放的传播性, 即使在并发情况下,多个线程在获取、释放。
  4. * 如果需要唤醒,则通常尝试头节点的unparkSuccessor 动作。
  5. * 但是如果他不符合唤醒的条件,为了确保能正确release,那么则把头节点的state设置为
  6. * 的state设置为PROPAGATE。此外,在执行该行为时,为了以防万一有新
  7. * 节点的加入我们的行为必须在循环中,而且如果在修改状态中,如果修改失败,那么
  8. * 也需要重新尝试修改。
  9. */
  10. for (;;) {
  11. Node h = head;
  12. if (h != null && h != tail) {
  13. int ws = h.waitStatus;
  14. if (ws == Node.SIGNAL) {
  15. if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
  16. continue; // loop to recheck cases
  17. unparkSuccessor(h);
  18. }
  19. /**
  20. 为什么这里要把state状态修改为Node.PROPAGATE?可以想象一下在什么情况下节点的状态会被修改为0,。
  21. 线程1调用doReleaseShared的方法释放头节点,此时头节点的状态被设置为0,compareAndSetWaitStatus(h, Node.SIGNAL, 0)
  22. 然后unparkSuccessor(h); AQS的头节点则被唤醒重试尝试出队。注意:此时的头节点状态为0!!
  23. 线程2调用且成功进入到doReleaseShared方法,此时获取头节点状态为0(新的头节点还未被setHead),既然能进入到这里,总不能释放失败吧?
  24. 然后则把头节点由0修改为Node.PROPAGATE,这样我们在关注下setHeadAndPropagate方法
  25. if (propagate > 0 || h == null || h.waitStatus < 0) {
  26. Node s = node.next;
  27. if (s == null || s.isShared())
  28. doReleaseShared();
  29. }
  30. 可以看到这时候h.waitStatus是小于0的。则保证了并发情况下线程2的释放成功!
  31. **/
  32. else if (ws == 0 &&
  33. !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
  34. continue; // loop on failed CAS
  35. }
  36. /**
  37. 为什么这里要加个h == head?
  38. 思考什么情况下这里的头部会被改变。上面也说了:Additionally, we must loop in case a new node is addedwhile we are doing this
  39. 假设当前AQS队列没有任何等待的节点,即head==tail。这时候上面的if判断不成立,执行到这里适合再次判断h==head,如果有新节点添加
  40. 进来,则h!=head,会重新尝试释放。我结论:应该是为了保证在多线程情况下的尽可能成功性。
  41. **/
  42. if (h == head) // loop if head changed
  43. break;
  44. }
  45. }

十一.区别 Shard(共享模式) 和非Shard(独占模式)

虽然AQS的共享模式和独占模式写的有点复杂。但是要知道无非就两种情况: 
独占模式:即state值在0和1之前来回切换,保证同一时间只能有一个线程是处于活动的,其他线程都被阻塞, 参考:ReentranLock.. 
共享模式:state值在整数区间内,如果state值<0则阻塞,否则则不阻塞。可以参考:Semphore、CountDownLautch..

十二.ConditionObject

Condition内部类是作为锁实现的一种基础服务。 Condition内部类实现类Condition接口。 
Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象,以便通过将这些对象与任意 Lock 实现组合使用,为每个对象提供多个等待 set (wait-set)。其中,Lock 替代了 synchronized 方法和语句的使用,Condition 替代了 Object 监视器方法的使用。

  1. public class ConditionObject implements Condition, java.io.Serializable {
  2. private static final long serialVersionUID = 1173984872572414699L;
  3. //条件队列的头节点
  4. private transient Node firstWaiter;
  5. //条件队列的尾节点
  6. private transient Node lastWaiter;
  7. /**
  8. * Creates a new <tt>ConditionObject</tt> instance.
  9. */
  10. public ConditionObject() { }
  11. // Internal methods
  12.  
  13. /**
  14. 添加一个新节点到条件队列
  15. 可以看到,在修改队列节点结构时候并没有使用CAS,这是因为通常使用condition的前提必须是在独占模式的lock下。
  16. **/
  17. private Node addConditionWaiter() {
  18. Node t = lastWaiter;
  19. //如果条件队列的尾节点已被取消,则调用unlinkCancelledWaiters重新调整队列结构
  20. if (t != null && t.waitStatus != Node.CONDITION) {
  21. unlinkCancelledWaiters();
  22. t = lastWaiter;
  23. }
  24. Node node = new Node(Thread.currentThread(), Node.CONDITION);
  25. if (t == null)
  26. firstWaiter = node;
  27. else
  28. t.nextWaiter = node;
  29. lastWaiter = node;
  30. return node;
  31. }
  32.  
  33. /**
  34. 删除condition等待队列中的节点first,且把节点first转移到condition所属的AQS等待队列中,
  35. 直到成功。
  36.  
  37. **/
  38. private void doSignal(Node first) {
  39. do {
  40. if ( (firstWaiter = first.nextWaiter) == null)
  41. lastWaiter = null;
  42. first.nextWaiter = null;
  43. } while (!transferForSignal(first) &&
  44. (first = firstWaiter) != null);
  45. }
  46.  
  47. /**
  48. 转移且删除所有的节点
  49. **/
  50. private void doSignalAll(Node first) {
  51. lastWaiter = firstWaiter = null;
  52. do {
  53. Node next = first.nextWaiter;
  54. first.nextWaiter = null;
  55. transferForSignal(first);
  56. first = next;
  57. } while (first != null);
  58. }
  59.  
  60. /**
  61. 持有锁的情况下,从condition等待队列中分离已被取消的节点。
  62. 该方法只有在条件队列中发生节点取消或者添加一个新的节点的时候发现尾节点已被取消时调用。
  63. 该方法需要避免垃圾滞留(没有signal时候),所以即使它需要完整遍历,但也只有在在由于没有signal
  64. 而导致的超时或者取消时才起作用。 It traverses all nodes rather than stopping at a
  65. particular target to unlink all pointers to garbage nodes without requiring many re-traversals
  66. during cancellation storms.
  67. **/
  68. private void unlinkCancelledWaiters() {
  69. Node t = firstWaiter;
  70. Node trail = null;
  71. while (t != null) {
  72. Node next = t.nextWaiter;
  73. if (t.waitStatus != Node.CONDITION) {
  74. t.nextWaiter = null;
  75. if (trail == null)
  76. firstWaiter = next;
  77. else
  78. trail.nextWaiter = next;
  79. if (next == null)
  80. lastWaiter = trail;
  81. }
  82. else
  83. trail = t;
  84. t = next;
  85. }
  86. }
  87. // public methods
  88.  
  89. /**
  90. 在独占锁模式下,删除当前Condition中的等待队列的头节点.
  91. **/
  92. public final void signal() {
  93. if (!isHeldExclusively())
  94. throw new IllegalMonitorStateException();
  95. Node first = firstWaiter;
  96. if (first != null)
  97. /**
  98. 删除当前Condition中的等待队列的头节点,且转移头节点到AQS的同步等待队列中
  99. 注意:仅仅只是删除头节点,并没有唤醒任何节点!
  100. 那么疑问来了,为什么signal不唤醒节点却能达到Object的signal一样的效果呢?(头)
  101. 单纯的从这一步解释的通,因为signal代表着唤醒线程。AQS利用signal必须得持有独占锁,
  102. 在unlock时候实际上就是唤醒await节点。而这里的signal仅仅只是移除等待队列的头部
  103. **/
  104. doSignal(first);
  105. }
  106.  
  107. /**
  108. 在当前线程拥有独占锁的情况下,删除当前condition 中等待队列的所有线程
  109. **/
  110. public final void signalAll() {
  111. //判断是否拥有独占锁
  112. if (!isHeldExclusively())
  113. throw new IllegalMonitorStateException();
  114. Node first = firstWaiter;
  115. if (first != null)
  116. doSignalAll(first);
  117. }
  118. /**
  119. 不抛出线程中断异常的的条件等待的实现.
  120. 保存getState方法返回的状态值,且调用release释放getState方法返回的状态值。
  121. 为什么要释放所有的getState的状态值?
  122. 试下Condition的await方法功能是类似于Object的await方法,Object的await方法
  123. 在调用时候需要进行该Object的同步(Synchronized)。所以Condition的await在
  124. 被调用时候也需要拥有独占锁(Lock.lock)。
  125. 如果 线程1 await后不释放AQS的state,那么 线程2 在signal时候无法获取锁。
  126.  
  127. 如果release失败,则抛出异常 IllegalMonitorStateException
  128.  
  129. 接着会调用LockSupport.park(this);阻塞当前线程,直到该线程被唤醒
  130.  
  131. **/
  132. public final void awaitUninterruptibly() {
  133. Node node = addConditionWaiter();
  134. int savedState = fullyRelease(node);
  135. boolean interrupted = false;
  136. //线程被唤醒后需要判断当前节点是否在同步队列(因为调用signal唤醒,会把头节点从等待队列转移到AQS的同步队列 )
  137. while (!isOnSyncQueue(node)) {
  138. LockSupport.park(this);
  139. if (Thread.interrupted())
  140. interrupted = true;
  141. }
  142. //这里注意acquireQueued带有一个形参savedState。至于为什么要把这个savedState传入,
  143. //想想之前释放掉的savedState就明白了
  144. if (acquireQueued(node, savedState) || interrupted)
  145. selfInterrupt();
  146. }
  147. /*
  148. * For interruptible waits, we need to track whether to throw
  149. * InterruptedException, if interrupted while blocked on
  150. * condition, versus reinterrupt current thread, if
  151. * interrupted while blocked waiting to re-acquire.
  152. */
  153. /** Mode meaning to reinterrupt on exit from wait */
  154. private static final int REINTERRUPT = 1;
  155. /** Mode meaning to throw InterruptedException on exit from wait */
  156. private static final int THROW_IE = -1;
  157. /**
  158. * Checks for interrupt, returning THROW_IE if interrupted
  159. * before signalled, REINTERRUPT if after signalled, or
  160. * 0 if not interrupted.
  161. */
  162. /**
  163.  
  164. **/
  165. private int checkInterruptWhileWaiting(Node node) {
  166. return Thread.interrupted() ?
  167. (transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
  168. 0;
  169. }
  170.  
  171. /**
  172. 根据mode来决定是否抛出InterruptedException异常或者,或者不执行任何动作。
  173. **/
  174. private void reportInterruptAfterWait(int interruptMode)
  175. throws InterruptedException {
  176. if (interruptMode == THROW_IE)
  177. throw new InterruptedException();
  178. else if (interruptMode == REINTERRUPT)
  179. selfInterrupt();
  180. }
  181. /**
  182. * Implements interruptible condition wait.
  183. * <ol>
  184. * <li> If current thread is interrupted, throw Interrupte dException.
  185. * <li> Save lock state returned by {@link #getState}.
  186. * <li> Invoke {@link #release} with
  187. * saved state as argument, throwing
  188. * IllegalMonitorStateException if it fails.
  189. * <li> Block until signalled or interrupted.
  190. * <li> Reacquire by invoking specialized version of
  191. * {@link #acquire} with saved state as argument.
  192. * <li> If interrupted while blocked in step 4, throw InterruptedException.
  193. * </ol>
  194. */
  195. public final void await() throws InterruptedException {
  196. if (Thread.interrupted())
  197. throw new InterruptedException();
  198. // 添加一个新节点到等待队列
  199. Node node = addConditionWaiter();
  200. //释放当前所有state。因为其他线程需要lock,后面还会恢复
  201. int savedState = fullyRelease(node);
  202. int interruptMode = 0;
  203. //判断当前节点是否已被释放(从等待队列转移到同步队列)
  204. while (!isOnSyncQueue(node)) {
  205. LockSupport.park(this);
  206. if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
  207. break;
  208. }
  209. //调用acquireQueued使节点node从AQS同步队列出队
  210. if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
  211. interruptMode = REINTERRUPT;
  212. // 如果存在后继节点,则检查且清理取消节点。
  213. if (node.nextWaiter != null) // clean up if cancelled
  214. unlinkCancelledWaiters();
  215. if (interruptMode != 0)
  216. reportInterruptAfterWait(interruptMode);
  217. }
  218. //指定一个相对时间,如果在相对时间内被唤醒且检查是否满足不再阻塞线程条件,否知阻塞直至到达过期时间,
  219. //释放当前线程
  220. public final long awaitNanos(long nanosTimeout)
  221. throws InterruptedException {
  222. if (Thread.interrupted())
  223. throw new InterruptedException();
  224. Node node = addConditionWaiter();
  225. int savedState = fullyRelease(node);
  226. long lastTime = System.nanoTime();
  227. int interruptMode = 0;
  228. while (!isOnSyncQueue(node)) {
  229. if (nanosTimeout <= 0L) {
  230. transferAfterCancelledWait(node);
  231. break;
  232. }
  233. //这里和上面普通。只挂起线程nanosTimeout纳秒
  234. LockSupport.parkNanos(this, nanosTimeout);
  235. if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
  236. break;
  237. long now = System.nanoTime();
  238. //注意这里运算符德优先级关系
  239. nanosTimeout -= now - lastTime;
  240. lastTime = now;
  241. }
  242. if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
  243. interruptMode = REINTERRUPT;
  244. if (node.nextWaiter != null)
  245. unlinkCancelledWaiters();
  246. if (interruptMode != 0)
  247. reportInterruptAfterWait(interruptMode);
  248. return nanosTimeout - (System.nanoTime() - lastTime);
  249. }
  250. //指定一个绝对时间,如果在绝对时间之前被唤醒,则线程检查是否满足完成阻塞,是则推出阻塞。
  251. //否则继续阻塞直至到达绝对时间,然后才中断阻塞
  252. public final boolean awaitUntil(Date deadline)
  253. throws InterruptedException {
  254. if (deadline == null)
  255. throw new NullPointerException();
  256. long abstime = deadline.getTime();
  257. if (Thread.interrupted())
  258. throw new InterruptedException();
  259. Node node = addConditionWaiter();
  260. int savedState = fullyRelease(node);
  261. boolean timedout = false;
  262. int interruptMode = 0;
  263. while (!isOnSyncQueue(node)) {
  264. if (System.currentTimeMillis() > abstime) {
  265. timedout = transferAfterCancelledWait(node);
  266. break;
  267. }
  268. LockSupport.parkUntil(this, abstime);
  269. if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
  270. break;
  271. }
  272. if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
  273. interruptMode = REINTERRUPT;
  274. if (node.nextWaiter != null)
  275. unlinkCancelledWaiters();
  276. if (interruptMode != 0)
  277. reportInterruptAfterWait(interruptMode);
  278. return !timedout;
  279. }
  280.  
  281. public final boolean await(long time, TimeUnit unit)
  282. throws InterruptedException {
  283. if (unit == null)
  284. throw new NullPointerException();
  285. long nanosTimeout = unit.toNanos(time);
  286. if (Thread.interrupted())
  287. throw new InterruptedException();
  288. Node node = addConditionWaiter();
  289. int savedState = fullyRelease(node);
  290. long lastTime = System.nanoTime();
  291. boolean timedout = false;
  292. int interruptMode = 0;
  293. while (!isOnSyncQueue(node)) {
  294. if (nanosTimeout <= 0L) {
  295. timedout = transferAfterCancelledWait(node);
  296. break;
  297. }
  298. if (nanosTimeout >= spinForTimeoutThreshold)
  299. LockSupport.parkNanos(this, nanosTimeout);
  300. if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
  301. break;
  302. long now = System.nanoTime();
  303. nanosTimeout -= now - lastTime;
  304. lastTime = now;
  305. }
  306. if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
  307. interruptMode = REINTERRUPT;
  308. if (node.nextWaiter != null)
  309. unlinkCancelledWaiters();
  310. if (interruptMode != 0)
  311. reportInterruptAfterWait(interruptMode);
  312. return !timedout;
  313. }
  314. // support for instrumentation
  315. //判断sync是否和和当前的调用的this是同一个。追踪下AQS的owns(ConditionObject condition)就明白了
  316. final boolean isOwnedBy(AbstractQueuedSynchronizer sync) {
  317. return sync == AbstractQueuedSynchronizer.this;
  318. }
  319.  
  320. //查询当前等待队列是否存在 有效等待(waitStatus 值为CONDITION)的线程
  321. protected final boolean hasWaiters() {
  322. if (!isHeldExclusively())
  323. throw new IllegalMonitorStateException();
  324. for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
  325. if (w.waitStatus == Node.CONDITION)
  326. return true;
  327. }
  328. return false;
  329. }
  330.  
  331. //获取当前等待队列里节点数的估计值
  332. protected final int getWaitQueueLength() {
  333. if (!isHeldExclusively())
  334. throw new IllegalMonitorStateException();
  335. int n = 0;
  336. for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
  337. if (w.waitStatus == Node.CONDITION)
  338. ++n;
  339. }
  340. return n;
  341. }
  342. //获取当前等待队列里节点里的处于有效等待唤醒状态的线程的集合
  343. protected final Collection<Thread> getWaitingThreads() {
  344. if (!isHeldExclusively())
  345. throw new IllegalMonitorStateException();
  346. ArrayList<Thread> list = new ArrayList<Thread>();
  347. for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
  348. if (w.waitStatus == Node.CONDITION) {
  349. Thread t = w.thread;
  350. if (t != null)
  351. list.add(t);
  352. }
  353. }
  354. return list;
  355. }
  356. }

注:

特别鸣谢:https://blog.csdn.net/wojiaolinaaa/article/details/50070031

https://blog.csdn.net/zcw4237256/article/details/78552741  

  

  1.  

【多线程系列】AQS CAS简单介绍的更多相关文章

  1. Java多线程系列--AQS之 LockSupport

    concurrent包是基于AQS (AbstractQueuedSynchronizer)框架的,AQS(JAVA CAS原理.unsafe.AQS)框架借助于两个类: Unsafe(提供CAS操作 ...

  2. Docker系列之原理简单介绍

    目录 1.1.Docker架构简介 1.2.Docker 两个主要部件 1.3.虚拟机和Docker对比: 1.4.Docker内部结构 Docker系列之原理简单介绍 @ Docker是一个开源的应 ...

  3. openresty开发系列10--openresty的简单介绍及安装

    openresty开发系列10--openresty的简单介绍及安装 一.Nginx优点 十几年前,互联网没有这么火,软件外包开发,信息化建设,帮助企业做无纸化办公,收银系统,工厂erp,c/s架构偏 ...

  4. iOS开发多线程篇 09 —NSOperation简单介绍

    iOS开发多线程篇—NSOperation简单介绍 一.NSOperation简介 1.简单说明 NSOperation的作⽤:配合使用NSOperation和NSOperationQueue也能实现 ...

  5. AJ学IOS(50)多线程网络之GCD简单介绍(任务,队列)

    AJ分享,必须精品 GCD简单介绍 1.什么是GCD? 全称是Grand Central Dispatch,可译为“牛逼的中枢调度器” 纯C语言,提供了非常多强大的函数 2.GCD的优势 GCD是苹果 ...

  6. 初学HTML5系列一:简单介绍

    最近很闲,就想着学点东西,然后就瞄中了html5,以前只看过很简单的一些,这次是系统的学下,顺便也记录下.废话不多说,开始正题. 稍微介绍下html5,html5是W3C和WHATWG 合作的结果. ...

  7. iOS:多线程同步加锁的简单介绍

    多线程同步加锁主要方式有3种:NSLock(普通锁).NSCondition(状态锁).synchronized同步代码块 还有少用的NSRecursiveLock(递归锁).NSConditionL ...

  8. iOS多线程篇:NSThread简单介绍和使用

    一.什么是NSThread NSThread是基于线程使用,轻量级的多线程编程方法(相对GCD和NSOperation),一个NSThread对象代表一个线程, 需要手动管理线程的生命周期,处理线程同 ...

  9. 【Zookeeper系列】Zookeeper简单介绍(转)

    原文链接:https://www.cnblogs.com/sunddenly/p/4033574.html 一.分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技 ...

随机推荐

  1. linq join 左连接 leftjoin 多个on条件 where 条件

    var haveChange = from newScore in newScoreList join oldScore in oldScoreList on new{newScore.ExamId, ...

  2. .net framework 4.0上跑webapi 1.0

    public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web AP ...

  3. JAVA构造方法与方法是啥意思,方法重载方法覆盖俗谈

    构造函数跟构造方法是一样的,只是称呼不同; C语言里叫函数,Java里叫方法. 成员方法必须有返回类型即使是没有返回,也要写上void 构造方法没有返回类型,而且和类名一样!一个类里面,一看就知道了譬 ...

  4. cordova ios and ios8

    ios8发布后,一些用cordova编写的app会碰到问题,总的来说,cordova官方称是完全支持ios8的,而且由于ios8推出的WKWebView存在问题并没能很好的解决(看原文),仍旧用了UI ...

  5. vue v-if与v-show使用注意问题

    在使用中发现v-show和v-if用哪个都不可以控制元素块的显示隐藏, 之前v-show和v-if都是这样写的: <span v-if="{loadingComplete:false} ...

  6. pyqt与拉勾网爬虫的结合

    人力部需要做互联网金融行业的从业人员薪酬分析,起初说的是写脚本,然后他们自己改.但这样不太好,让人事部来修改py脚本不太好,这需要安装py环境和一些第三方包,万一脚本改来改去弄错了,就运行不起来了. ...

  7. 【hadoop】 hadoop 单机伪分布式安装

    准备: 虚拟机(CentOS 6.9) JDK1.8 hadoop2.8.0 一.JDK安装及配置 rpm -ivh jdkxxxx 安装 配置环境变量 vim /etc/profile export ...

  8. vs2010,vs2012如何连接vss2005,vss2008

    打开vs2010.依次打开[工具]-[选项]-[源代码管理] 这个时候可以看到管理插件中有Microsoft Visual SourceSafe选项(若没有该选项,重新安装VSS即可). 连接上项目后 ...

  9. 【Nodejs】npm cnpm 淘宝镜像

    一.通过命令配置 1. 命令 npm config set registry https://registry.npm.taobao.org 2. 验证命令 npm config get regist ...

  10. 3dmax osg格式导出插件 osgExp OpenSceneGraph Max Exporter

    https://sourceforge.net/projects/osgmaxexp/files/OpenSceneGraph%20Max%20Exporter/