smart_an的专栏

本章和上一章——Fork/Join框架（1） 原理，从思想、使用、实现等方面较完整地分析了Fork/Join框架，Fork/Join框架的使用需要根据实际情况划分子任务的大小。理解F/J框架需要先从整体上了解框架调度任务的流程（参考本章开头的调度图），可以自己通过示例模拟一个任务的调度过程，然后根据实际运用过程中遇到的问题，再去调试及在相应的源码中查看实现原理。

本章简要概述了Fork/Join框架的思想、主要组件及基本使用，Fork/Join框架的核心包含四大组件：任务类、线程池、工作线程、WorkQueue任务队列。每个Worker线程利用它自己的任务队列维护可执行任务；任务队列是一种双端队列，支持LIFO的push和pop操作，也支持FIFO的take操作；任务fork的子任务，只会push到它所在线程（调用fork方法的线程）的队列；

Future模式是Java多线程设计模式中的一种常见模式，它的主要作用就是异步地执行任务，并在需要的时候获取结果。我们知道，一般调用一个函数，需要等待函数执行完成，调用线程才会继续往下执行，如果是一些计算密集型任务，需要等待的时间可能就会比较长。笔者在读书期间曾参与过一个国家电网的复杂水电系统的联合优化调度项目，需要在工业上可接受的时间内计算出整个云南地区近40座大型水电站的日发电计划。

在executors框架概述一节中，我们曾经提到过一种可对任务进行延迟/周期性调度的执行器（Executor），这类Executor一般实现了这个接口。ScheduledExecutorService在普通执行器接口（ExecutorService）的基础上引入了Future模式，使得可以限时或周期性地调度任务。

在juc-executors框架概述的章节中，我们已经简要介绍过了，通过Executors工厂，用户可以创建自己需要的执行器对象。ThreadPoolExecutor，它是J.U.C在JDK1.5时提供的一种实现了ExecutorService接口的执行器，或者说线程池。ThreadPoolExecutor并没有自己直接实现ExecutorService接口，因为它只是其中一种Executor的实现而已，所以Doug Lea把一些通用部分封装成一个抽象父类——，供J.U.C中的其它执行器继承。

框架是整个J.U.C包中类/接口关系最复杂的框架，真正理解executors框架的前提是理清楚各个模块之间的关系，高屋建瓴，从整体到局部才能透彻理解其中各个模块的功能和背后的设计思路。网上有太多文章讲executors框架，要么泛泛而谈，要么一叶障目不见泰山，缺乏整体视角，很多根本没有理解整个框架的设计思想和模块关系。本文将对整个executors框架做综述，介绍各个模块的功能和联系，后续再深入探讨每个模块，包括模块中的各个工具类。

是在JDK1.7时，J.U.C包新增的一种比较特殊的阻塞队列，它除了具备阻塞队列的常用功能外，还有一个比较特殊的transfer方法。我们知道，在普通阻塞队列中，当队列为空时，消费者线程（调用take或poll方法的线程）一般会阻塞等待生产者线程往队列中存入元素。而的transfer当有消费者线程阻塞等待时，调用transfer方法的生产者线程不会将元素存入队列，而是直接将元素传递给消费者；

和类似，都是一种双端队列的结构，只不过LinkedBlockingDeque同时也是一种阻塞队列，它是在JDK1.5时随着J.U.C包引入的，实现了接口，底层基于双链表LinkedBlockingDeque底层利用ReentrantLock实现同步，并不像ConcurrentLinkedDeque那样采用无锁算法。另外，LinkedBlockingDeque是一种近似有界阻塞队列，为什么说近似？

DelayQueue是JDK1.5时，随着J.U.C包一起引入的一种阻塞队列，它实现了BlockingQueue接口，底层基于已有的实现：DelayQueue也是一种比较特殊的阻塞队列，从类声明也可以看出，DelayQueue中的所有元素必须实现Delayed/*** 一种混合风格的接口，用来标记那些应该在给定延迟时间之后执行的对象。* * 此接口的实现必须定义一个 compareTo 方法，该方法提供与此接口的 getDelay 方法一致的排序。*//**

是JDK1.5时，随着J.U.C包一起引入的一种阻塞队列，它实现了BlockingQueue接口，底层基于栈和队列实现：没有看错，SynchronousQueue的底层实现包含两种数据结构——栈和队列。入队线程和出队线程必须一一匹配，否则任意先到达的线程会阻塞。比如ThreadA进行入队操作，在有其它线程执行出队操作之前，ThreadA会一直等待，反之亦然；SynchronousQueue内部不保存任何元素，也就是说它的容量为0，数据直接在配对的生产者和消费者线程之间传递，不会将数据缓冲到队列中。

是在JDK1.5时，随着J.U.C包引入的一种阻塞队列，它实现了接口，底层基于堆实现：PriorityBlockingQueue是一种无界阻塞队列，在构造的时候可以指定队列的初始容量。PriorityBlockingQueue与之前介绍的阻塞队列最大的不同之处就是：它是一种优先级队列，也就是说元素并不是以FIFO的方式出/入队，而是以按照权重大小的顺序出队；

是在JDK1.5时，随着J.U.C包引入的一种阻塞队列，它实现了BlockingQueue接口，底层基于单链表实现：LinkedBlockingQueue是一种近似有界阻塞队列，为什么说近似？因为LinkedBlockingQueue既可以在初始构造时就指定队列的容量，也可以不指定，如果不指定，那么它的容量大小默认为。LinkedBlockingQueue除了底层数据结构（单链表）与ArrayBlockingQueue不同外，另外一个特点就是：它维护了两把锁——takeLock和putLock。

是在JDK1.5时，随着J.U.C包引入的一种阻塞队列，它实现了接口，底层基于数组实现：ArrayBlockingQueue是一种有界阻塞队列，在初始构造的时候需要指定队列的容量。队列的容量一旦在构造时指定，后续不能改变；插入元素时，在队尾进行；删除元素时，在队首进行；队列满时，调用特定方法插入元素会阻塞线程；队列空时，删除元素也会阻塞线程；支持公平/非公平策略，默认为非公平策略。这里的公平策略，是指当线程从阻塞到唤醒后，以最初请求的顺序（FIFO）来添加或删除元素；

是在JDK1.5时，随着J.U.C引入的一个接口：当线程向队列中插入元素时，如果队列已满，则阻塞线程，直到队列有空闲位置（非满）；当线程从队列中取元素（删除队列元素）时，如果队列未空，则阻塞线程，直到队列有元素；既然BlockingQueue是一种队列，所以也具备队列的三种基本方法：插入删除读取操作类型抛出异常返回特殊值阻塞线程超时插入add(e)offer(e)put(e)删除remove()poll()take()读取element()peek()

Queue的接口非常简单，一共只有三种类型的操作：入队、出队、读取。操作类型抛出异常返回特殊值入队add(e)offer(e)出队remove()poll()读取element()peek()每种操作类型，都给出了两种方法，区别就是其中一种操作在队列的状态不满足某些要求时，会抛出异常；另一种，则直接返回特殊值（如null）。操作类型抛出异常返回特殊值队首入队队首出队队首读取getFirst()队尾入队addLast(e)队尾出队pollLast()队尾读取。

是JDK1.5时随着J.U.C一起引入的一个支持并发环境的队列。从名字就可以看出来，ConcurrentLinkedQueue底层是基于链表实现的。Doug Lea在实现ConcurrentLinkedQueue时，并没有利用锁或底层同步原语，而是完全基于自旋+CAS的方式实现了该队列。回想一下AQS，AQS内部的CLH等待队列也是利用了这种方式。

是另一类适合并发环境的SET工具类，也是在JDK1.5时，随着J.U.C包一起引入的。我们之前已经介绍过了ConcurrentSkipListSet，ConcurrentSkipListSet底层基于Skip List（跳表）实现，其操作平均时间复杂度均为O(logn)。CopyOnWriteArraySet，从名字上可以看出，也是基于“写时复制”的思想。事实上，CopyOnWriteArraySet内部引用了一个。

ArrayList是一种“列表”数据机构，其底层是通过数组来实现元素的随机访问。使用Vector类使用返回一个同步代理类；自己实现ArrayList的子类，并进行同步/加锁。前两种方式都相当于加了一把“全局锁”，访问任何方法都需要首先获取锁。第3种方式，需要自己实现，复杂度较高。JDK1.5时，随着J.U.C引入了一个新的集合工具类——大多数业务场景都是一种“读多写少”的情形，就是为适应这种场景而诞生的。CopyOnWriteArrayList，运用了一种“写时复制”的思想。

是JDK1.6时J.U.C新增的一个集合工具类，顾名思义，它是一种SET类型。SET类型，在数学上称为“集合”，具有互异性、无序性的特点，也就是说SET中的任意两个元素均不相同（即不包含重复元素），且元素是无序的。是不是感觉和HashMap有点类似？HashMap中的Key也是不能重复，且是无序的。事实上，JDK提供的默认SET实现——HashSet，其实就是采用“组合”的方式——内部引用了一个HashMap对象，以此实现SET的功能。

在正式讲ConcurrentSkipListMap之前，我们先来看下ConcurrentSkipListMap的类继承图：我们知道，一般的Map都是无序的，也就是只能通过键的hash值进行定位。JDK为了实现有序的Map，提供了一个SortedMap接口，SortedMap提供了一些根据键范围进行查找的功能，比如返回整个Map中 key最小/大的键、返回某个范围内的子Map视图等等。为了进一步对有序Map进行增强，JDK又引入了。

我们刚才说了，调用transfer的线程会自动领用某个区段的桶，进行数据迁移操作，当区段的初始索引i变成负数的时候，说明当前线程处理的其实就是最后剩下的桶，并且处理完了。所以首先会更新sizeCtl变量，将扩容线程数减1，然后会做一些收尾工作：设置table指向扩容后的新数组，遍历一遍旧数组，确保每个桶的数据都迁移完成——被ForwardingNode占用。另外，可能在扩容过程中，出现扩容冲突的情况，比如多个线程领用了同一区段的桶，这时任何一个线程都不能进行数据迁移。

是在JDK1.5时，J.U.C引入的一个同步集合工具类，顾名思义，这是一个线程安全的HashMap。不同版本的ConcurrentHashMap，内部实现机制千差万别，本节所有的讨论基于JDK1.8。的类继承关系并不复杂：可以看到ConcurrentHashMap继承了，这是一个java.util包下的抽象类，提供Map接口的骨干实现，以最大限度地减少实现Map这类数据结构时所需的工作量，一般来讲，如果需要重复造轮子——自己来实现一个Map，那一般就是继承AbstractMap。另外，实现了方法签名。

Phaser是JDK1.7开始引入的一个同步工具类，适用于一些需要分阶段的任务的处理。它的功能与和同步器作用倒数计数器，初始时设定计数器值，线程可以在计数器上等待，当计数器值归0后，所有等待的线程继续执行循环栅栏，初始时设定参与线程数，当线程到达栅栏后，会等待其它线程的到达，当到达栅栏的总数满足指定数后，所有等待的线程继续执行Phaser多阶段栅栏，可以在初始时设定参与线程数，也可以中途注册/注销参与者，当到达的参与者数量满足栅栏设定的数量后，会进行阶段升级（advance）Phaser。

Exchanger——交换器，是JDK1.5时引入的一个同步器，从字面上就可以看出，这个类的主要作用是交换数据。Exchanger有点类似于，我们知道CyclicBarrier是一个栅栏，到达栅栏的线程需要等待其它一定数量的线程到达后，才能通过栅栏。

Semaphore，又名信号量，这个类的作用有点类似于“许可证”。有时，我们因为一些原因需要控制同时访问共享资源的最大线程数量，比如出于系统性能的考虑需要限流，或者共享资源是稀缺资源，我们需要有一种办法能够协调各个线程，以保证合理的使用公共资源。Semaphore维护了一个许可集，其实就是一定数量的“许可证”。当有线程想要访问共享资源时，需要先获取(acquire)的许可；如果许可不够了，线程需要一直等待，直到许可可用。当线程使用完共享资源后，可以归还(release)许可，以供其它需要的线程使用。

是一个辅助同步器类，在JDK1.5时随着J.U.C一起引入。这个类的功能和我们之前介绍的CountDownLatch有些类似。我们知道，是一个倒数计数器，在计数器不为0时，所有调用await的线程都会等待，当计数器降为0，线程才会继续执行，且计数器一旦变为0，就不能再重置了。可以认为是一个栅栏，栅栏的作用是什么？就是阻挡前行。

是一个辅助同步器类，用来作计数使用，它的作用有点类似于生活中的倒数计数器，先设定一个计数初始值，当计数降到0时，将会触发一些事件，如火箭的倒数计时。初始计数值在构造CountDownLatch对象时传入，每调用一次方法，计数值就会减1。线程可以调用CountDownLatch的await方法进入阻塞，当计数值降到0时，所有之前调用await阻塞的线程都会释放。CountDownLatch的初始计数值一旦降到0，无法重置。如果需要重置，可以考虑使用CyclicBarrier。

JDK1.8时，LongAdder。根据Oracle官方文档的介绍，LongAdder在高并发的场景下会比它的前辈————AtomicLong 具有更好的性能，代价是消耗更多的内存空间：为什么要引入LongAdder？AtomicLong在高并发的场景下有什么问题吗？如果低并发环境下，LongAdder和AtomicLong性能差不多，那LongAdder是否就可以替代AtomicLong了？

在。通过名称可以看到，这几类的功能大致相同，只是针对的类型有所不同。所谓，就是可以以一种线程安全的方式操作非线程安全对象的某些字段。光这么说有点难理解，我们通过一个例子来看下。假设有一个公司账户Account，100个人同时往里面存钱1块钱，那么正常情况下，最终账户的总金额应该是100。money++;// 初始金额0i < 100;

Atomic数组，顾名思义，就是能以原子的方式，操作数组中的元素。。对应对应AtomicLong对应其实阅读源码也可以发现，这些数组原子类与对应的普通原子类相比，只是多了通过索引找到内存中元素地址的操作而已。注意：原子数组并不是说可以让线程以原子方式一次性地操作数组中所有元素的数组。而是指对于数组中的每个元素，可以以原子方式进行操作。说得简单点，原子数组类型其实可以看成原子类型组成的数组。// 将第0个元素原子地增加1等同于// 将第0个元素原子地增加1。

AtomicReference，顾名思义，就是以原子方式更新对象引用。可以看到，AtomicReference持有一个对象的引用——value为什么需要AtomicReference？难道多个线程同时对一个引用变量赋值也会出现并发问题？引用变量的赋值本身没有并发问题，也就是说对于引用变量var ，类似下面的赋值操作本身就是原子操作:AtomicReference的引入是为了可以用一种类似乐观锁的方式操作共享资源，在某些情景下以提升性能。try{// 操作共享资源sharedValue。

AtomicInteger，应该是atomic框架中用得最多的原子类了。顾名思义，AtomicInteger是Integer类型的线程安全原子类，可以在应用程序中以原子的方式更新int值。

在正式的开讲 juc-atomic框架系列之前，有必要先来了解下Java中的Unsafe类。Unsafe类，来源于sun.misc包。该类封装了许多类似指针操作，可以直接进行内存管理、操纵对象、阻塞/唤醒线程等操作。Java本身不直接支持指针的操作，所以这也是该类命名为Unsafe的原因之一。J.U.C中的许多CAS方法，内部其实都是Unsafe类在操作。比如的方法是个native方法。（如果对象中的字段值与期望值相等，则将字段值修改为x，然后返回true；否则返回false)：参数名称含义。

StampedLock类，在JDK1.8时引入，是对读写锁ReentrantReadWriteLock的增强，该类提供了一些功能，优化了读锁、写锁的访问，同时使读写锁之间可以互相转换，更细粒度控制并发。首先明确下，该类的设计初衷是作为一个内部工具类，用于辅助开发其它线程安全组件，用得好，该类可以提升系统性能，用不好，容易产生死锁和其它莫名其妙的问题。当入队一个线程时，如果队尾是读结点，不会直接链接到队尾，而是链接到该读结点的cowait链中，cowait链本质是一个栈；

AQS系列的前四个章节，已经分析了AQS的原理，本章将会从出发，给出其内部利用AQS框架的实现原理。ReentrantReadWriteLock（以下简称RRW），也就是读写锁，是一个比较特殊的同步器，特殊之处在于其对同步状态State的定义与ReentrantLock、CountDownLatch都很不同。通过RRW的分析，我们可以更深刻的了解AQS框架的设计思想。Java多线程进阶（3）—— juc-locks锁框架：ReentrantReadWriteLock。

AQS系列的前三个章节，我们通过ReentrantLock的示例，分析了AQS的独占功能。本章将以为例，分析AQS的共享功能。CountDownLatch，是J.U.C中的一个同步器类，可作为倒数计数器使用。CountDownLatch示例假设现在有3个线程，ThreadA、ThreadB、mainThread，CountDownLatch初始计数为1：// ThreadA调用await()方法等待// ThreadB调用await()方法等待。

本章将继续以ReentrantLock的调用为例，说明AbstractQueuedSynchronizer提供的Conditon等待功能。关于Conditon接口的介绍，可以参见：Java多线程进阶（二）—— juc-locks锁框架：接口。本章以ReentrantLock的公平锁为例，分析了AbstractQueuedSynchronizer的Condition功能。通过分析，可以看到，当线程在指定Condition对象上等待的时候，其实就是将线程包装成结点，加入了条件队列，然后阻塞。

本章以ReentrantLock的调用为例，说明AbstractQueuedSynchronizer提供的独占功能。以ReentrantLock的公平策略为例，分析AbstractQueuedSynchronizer的独占功能以ReentrantLock的非公平策略为例，分析AbstractQueuedSynchronizer的独占功能分析AbstractQueuedSynchronizer的锁中断、限时等待等功能本章从ReentrantLock入手，分析AQS的独占功能的内部实现细节。

AbstractQueuedSynchronizer抽象类（以下简称AQS）是整个包的核心。在JDK1.5时，Doug Lea引入了J.U.C包，该包中的大多数同步器都是基于AQS来构建的。AQS框架提供了一套通用的机制来管理同步状态（synchronization state）、阻塞/唤醒线程、管理等待队列。我们所熟知的ReentrantLock、CountDownLatch、CyclicBarrier等同步器，其实都是通过内部类实现了AQS框架暴露的API，以此实现各类同步器功能。

LockSupport类，是JUC包中的一个工具类，是用来创建锁和其他同步类的基本线程阻塞原语。park()和unark()，其中park()方法用来阻塞当前调用线程，unpark()方法用于唤醒指定线程。这其实和Object类的wait()和signial()方法有些类似，但是LockSupport的这两种方法从语意上讲比Object类的方法更清晰，而且可以针对指定线程进行阻塞和唤醒。