菜鸟的jdk源码学习

2018-11-11 本文已影响0人 wittycat

java源码学习，(基于java version 1.8.0_60)

1.基础部分（原理，运用熟练掌握）

1.1java.util

   这个包主要以集合为主，这是数据结构的最佳实践。

集合罗列

集合	查询时间复杂度	继承前列	线程安全	支持排序
Map	HashMap	LinkedHashMap	HashTable	TreeMap
Set	HashSet	LinkedHashSet		TreeSet
~	无	无	线程安全	继承前列线程安全
List	ArrayList	LinkedList	Vector	Stack

相似比较

Name	同作用	不同作用
Iterator	支持遍历	支持fail-fast[ConcurrentModificationException]机制，通过迭代器可以对集合删除;可以对集合进行增强for循环遍历【Iterable和Iterator一起使用，Iterable像管理者，产生Iterator，Iterator负责执行】
Enumeration	支持遍历
Map	支持key-value	功能强（官方建议使用map）
Dictionary	支持key-value	和map比较功能弱
Comparable	支持比较	实体直接实现
Comparator	支持比较	更灵活，实体可以实现多个

1.1.1Map相关

这是集合中个人认为是最关键最复杂的类，搞清楚map的常用实现类是非常关键的对于认识集合总体的实现。
每个key，value键值对封装为Map.Entry<K, V> 实体bean。

1.1.1.1HashMap

数据结构：Node实体数组（又叫Hash表或散列表，hash函数又叫散列函数）+ 单向链表+红黑树（又叫自平衡二叉查找树）。
Node实体基本结构：hash,key,value,next(链表的下一个实体);Map.Entry<K, V> 实现类。
TreeNode实体基本结构：parent,left,right,prev;TreeNode继承LinkedHashMap.Entry继承HashMap.Node<K,V>。
数组上的元素为链表（或红黑树）的头节点（或根节点）。
对于hash冲突解决办法使用链表（或红黑树），当链表长度大于等于8时转化为红黑树。之所以转化为红黑树是当数量大时红黑树的查询效率更高。
操作红黑树，增加删除后为了自平衡进行的左右旋和重新着色。

几种时间复杂度

结构	查询时间复杂度	说明
hash表	O（1）
链表	O（n）	遍历链表去查找
红黑树	O（log n）

多线程下当共享变量使用时，扩容链表造成的问题

版本	元素是否倒置	元素是否丢失	复杂程度
1.7	倒置(易形成闭合回路)	没验证	代码量约1000行
1.8	不倒置(99%的认为不会形成，1%再验证)	会丢失	代码量约2000行
解决办法	不当共享变量使用（在局部变量中 new创建是没问题的，在栈中操作，属于私有的）或使用Collections.synchronizedMap(Map<K, V>)包装或使用ConcurrentHashMap

1.1.1.2HashTable

数据结构：数组+单向链表。
Entry实体基本结构：hash,key,value,next与HsahMap的Node实体结构一致;Map.Entry<K, V> 实现类。
扩容时元素顺序不变。
由于HashTable是同步的，多数方法添加了synchronized关键字同步。

1.1.1.3TreeMap

数据结构：红黑树（天然排序）。
Entry结构：key，value， left，right，parent，color
由于这是排序的hash表，必须在构造函数传递比较器Comparator实现类或添加的实体实现Comparable接口
- Comparator和Comparable区别：Comparable，方便，实体直接继承，不灵活。Comparator，灵活，根据业务多维度实现比较
实现结果基本和HashMap的红黑树实现部分一致

1.1.1.4LinkedHashMap

数据结构：双向链表（输入的顺序和添加顺序一致）
Entry结构，继承自HashMap.Node ,新添加before, after属性
继承自HashMap
新添加的元素放置到链表的尾部，遍历时从头节点开始，保证了输入的顺序和添加顺序一致

几种map总结：
    1、在存储上基本与value没有关系，主要依赖K和K的hash值来放置到合适位置。
    2、内部实现上基本以循环操作为主。

1.1.2Set相关

1.1.2.1HashSet

实现依赖于HashMap

1.1.2.3LinkedHashSet

实现依赖于LinkedHashMap（通过构造函数调用HashSet的LinkedHashMap构造函数实现）

1.1.2.2TreeSet

支持排序，间接实现SortedSet接口
实现依赖于NavigableMap

1.1.3List相关

1.1.2.1ArrayList

数据结构：数组
扩容依赖Arrays.copyOf()，它又依赖于 System.arraycopy（）
通过索引访问遍历效率最高，而使用迭代器的效率最低（还可以通过增强for循环遍历）

1.1.2.2LinkedList

数据结构：双向链表
Node实体：item,next, prev(当前，下一个，上一个)
LinkedList可以作为FIFO(先进先出)的队列
LinkedList可以作为LIFO(后进先出)的栈

1.1.2.3Vector

数据结构：数组
支持同步

1.1.2.3Stack

数据结构：数组
继承自Vector，支持同步，先进后出

1.1.4工具类

Arrays：提供一系列静态方法，对数组排序，搜索等
Collections ：提供一系列静态方法，对集合排序，搜索，包装集合为安全类型等。包装基本实现思路为，传入之后赋值给局部变量，通过synchronized关键字同步对于传入集合的原有方法加以限制。

1.2java.io

理解类提供的功能,才能更准确的使用。要理解io必须先了解一些基本的概念和区别。

装饰模式和适配器模式
字符流和字节流
流的基本介质和区别

io字节输入流（不是所有的输入输出都一一对应）

io字节输入流

io字节输出流

io字符输入流

io字符输出流

1.3java.lang

java的base包，唯一一个只使用不用导包的包。
主要类的类型有：基本类型的包装类型，异常类，进程类，Thread的相关类，字符（串）的系列类。

Object：主要提供hashcode，equals ，getClass，以及线程之间通信的方式：等待和唤醒。
System
- 主要是native方法
- 集成一些其他类像IO流，
- 集成RunTime的方法
- nanoTime（）：获取微妙值，主要用于线程阻塞时间的计算。
- arraycopy（）：高效数组的拷贝，(包括Arrays.copyOf) 都是拷贝引用
RunTime：exit，gc，exec，获取os运行核数。
Class：对象字节码对象，反射的重点

1.4java.util除过集合的其他类

Formatter：公式 %[argument_index$][flags][width][.precision]conversion

2.高级部分（深刻理解）

2.1java.lang.reflect

2.1.1反射

反射类的主要关系

获取对象字节对象的3种方式
- this.getClass()
- 对象.class
- Class.forName() 获取对象字节码对象
Class 对象可以获取字段数组，方法数组，构造函数（通过方法可以创建实例），所涉及的权限修饰符，参数，参数类型，方法的返回值类等一切基本都可以获取到。

2.1.2动态代理

动态代理执行逻辑

代理模式的应用
创建过程类似于“高级装饰者模式”+“高级继承（非继承实现类，继承的是接口）”
生成代理类过程：生成代理对象的字节码数组->生成字节码对象->通过构造函数创建实例
代理对象和被代理对象的区别：代理对象由于是Proxy的子类，所以持有起桥梁作用的InvocationHandler子类（简称h），h又持有被代理对，通过代理对象给h传入Method对象和参数在加上h持有的被代理对象就可以对代理对象通过Method的invoke执行。其实就是代理对象持有自己实现的InvocationHandler对象，而被代理对象是没有的。（Method的invoke传入的对象一定不能是h的invoke方法传入的proxy对象，proxy对象是代理对象传入的自己本身，如果传入Proxy，将会发生代理对象和h对象之间的递归调用，直到栈溢出，正确应该传入h持有的被代理对象。h的invoke方法传入的proxy对象也没有什么实际作用）
代理对象里面的基本方法有equals，toString，hashCode和接口的方法。所有方法里面没有额外的逻辑，都是通过h.invoke(this, method, 参数)去调用真是对象的。通过 ProxyGenerator.generateProxyClass("$Proxy11", 接口字节码数组); 可以写入生成代理对象到文件进行查看。
h对象里面的invoke是对被代理对象的所有方法的代理，想要定制化代理可以在里面通过传入的Method对象获取方法名进行判断处理。

2.2java.util.concurrent.*

并发包主要内容：原子类，锁，容器，线程池，框架，工具类

并发主要内容

2.2.1原子类

关于Unsafe的并发性。compareAndSwap*方法是原子的，并且可用来实现高性能的、无锁（free-lock）的数据结构。

可能存在ABA问题、指令重排序等问题
获取Unsafe实例的2种方法：反射获取字段的方法或反射获取构造函数获取
自定义实现Integer的原子操作类：CAtomicInteger
原子类主要提供：3类（int，long，Reference），每类3种（本身，数组，字段）的更新
外加Boolean（底层转化为int）,具体实现对应于Unsafe类的方法
unsafe.compareAndSwapInt(arg0, arg1, arg2, arg3)
unsafe.compareAndSwapLong(arg0, arg1, arg2, arg3)
unsafe.compareAndSwapObject(arg0, arg1, arg2, arg3)

数组的原子更新是通过索引号更新的具体数值的

若想要实现其他基本类型，可以通过转化为int 或long类型转化去操作
实现原理大致过程如下：
有一些状态
创建它的副本
修改它
执行CAS
如果失败，重复尝试直到成功

无锁编程（lock free）

常见的lock free编程一般是基于CAS(Compare And Swap)操作：CAS(void ptr, Any oldValue, Any newValue);即查看内存地址ptr处的值，如果为oldValue则将其改为 newValue，并返回true，否则返回false。 X86平台上的CAS操作一般是通过CPU的CMPXCHG指令来完成的。CPU在执行此指令时会首先锁住CPU总线，禁止其它核心对内存的访问，然后再查看或修改ptr的值。简单的说CAS利用了CPU的硬件锁来实现对共享资源的串行使用。

优点：
a、开销较小：不需要进入内核，不需要切换线程；
b、没有死锁：总线锁最长持续为一次read+write的时间；
c、只有写操作需要使用CAS，读操作与串行代码完全相同，可实现读写不互斥。

缺点：
a、编程非常复杂，两行代码之间可能发生任何事，很多常识性的假设都不成立。
b、CAS模型覆盖的情况非常少，无法用CAS实现原子的复数操作。

2.2.2锁

主要类关系：

Lock包主要类关系

2.2.2.1AQS

锁是面向用户的，同步器是面向锁的（就是锁的内部实现），AQS支持互斥锁，共享锁的实现。
AQS实现一个FIFO等待队列。
通过对state的原子修改来实现获取锁和释放锁；
互斥锁：state为1时可以实现互斥锁（TCustomSyncExclusiveLock），大于1可以实现重入锁；
共享锁：state大于1时可以实现共享锁（TCustomSyncShareLock），此时state的值即表示并发的线程数，此时不便实现重入锁。

2.2.2.1.1关键词理解

模板方法，互斥锁(排它锁)，共享锁，同步队列，阻塞队列（条件队列），LockSupport，ConditionObject

AQS：提供一组模板方法用于具体业务实现互斥锁或者共享锁
同步队列：保存等待获取锁的线程节点
阻塞队列：保存执行了await的线程节点
LockSupport：用于阻塞或者唤醒线程，属于工具类，不和锁关联（Condition和synchronized阻止线程必须和锁关联）
ConditionObject：AQS的监视器

（注意：Object的监视器只有一个同步队列和一个阻塞队列；而AQS却有一个同步队列和多个阻塞队列，对应多个ConditionObject）

2.2.2.1.2同步队列和阻塞队列的节点互相转化（结合ReentrantLock说明）

TReentrantLock3运行示例
同步队列：双向链表；阻塞队列：单向链表
基本流程：首先所有节点会被加入同步队列，在执行await后会加入阻塞队列，唤醒时又会被转化回同步队列
2个队列独立存在，都使用Node作为基本节点

（注意使线程节点进入阻塞队列的不适合AQS实现的共享锁操作，因为newCondition.await()其中会调用tryRelease(long arg),而共享锁不会实现这个）

2.2.2.1.3lock ,unLock,await,signal(signalAll:相当于循环操作signal)的逻辑分析（结合ReentrantLock说明）

lock:获取不到锁阻塞该线程，加入同步队列
unLock:释放锁唤醒后继节点
await:主要干三件事:1.阻塞该线程 2.添加到等待队列3. 唤醒后继线程
signal:主要干1件事:加入同步队列

2.2.2.2ReentrantLock

ReentrantLock内部关系

主要理解公平锁和非公平锁的在获取锁时的不同之处（二者都使用同步队列，非公平锁再获取时存在插队现象，这样对于队列其他的节点线程就是不公平的）
ReentrantLock,属于互斥锁，重入锁（释放必须和获取执行次数一样）
ReentrantLock的方法在调用时如果抛出 IllegalMonitorStateException - 则该方法必须在锁的区域内调用
不管是公平锁或者非公平锁都使用的AQS的同步队列
性能问题：（TReentrantLock2测试）
- 前提:把不同线程获取锁的一次定义为一次上下文切换
- 获取同等锁次数情况下，非公平锁相对用时更少，原因是减少了cpu的上下文切换
- 公平锁执行较多上下文切换次数，而非公平锁执行上下文切换次数较少（原因是当一个线程获取释放锁后，下一次如果它再需要锁，相对比其他线程获取锁的概率更大，此时就不需要切换就相对省时）

2.2.2.3ReentrantReadWriteLock

ReentrantReadWriteLock内部关系

出现读写锁的缘由：当多读少写时，使用读写锁比使用互斥锁具有更高的并发性
特点：（读锁可以并发访问，写锁时其他的读锁和其他的写锁都被阻塞）
主要依据32位的int类型的state的低16位的值表示写锁（为互斥锁）；高16位的值表示读锁（为共享锁）
通过位运算把state值拆分为2个值：假设当前状态为s
写状态：s & (1 << 16) - 1 即：s&65535，也就是s与16个1（2进制的），这样就把高16位抹去了；当写状态+1时，即为s+1，只给低位加。
读状态：s>>>16 ,表示无符号补0右移16位；当读状态+1时，等于s+（1<<16）,结果就是只给高位加
（锁降级）流程：先获取写锁，在获取读锁，在释放写锁，在释放读锁（不支持锁升级）

2.2.3容器

主要并发容器

并发容器

2.2.3.1队列

阻塞队列主要方法说明：
[add:remove]没有值或队列满时，操作报异常；属于Queue接口的规范
[offer:poll]返回特殊值（null或波尔值），队列满时添加失败，造成丢失元素；属于Queue接口的规范
[put:take]空或满时操作阻塞，但是不会丢失元素；属于BlockingQueue接口的规范

ArrayBlockingQueue：数组实现的有节阻塞队列，此队列按 FIFO（先进先出）原则。

自定义CArrayBlockingQueue注意：
- putIndex和takeIndex，当到达数组末端时，必须从0开始。
- while和if的选择？
- 必须使用while，因为在signal()take1线程时，只会从阻塞队列转移到同步队列（不见得会获取锁真正唤醒），此时可能已经有其他take2线程获取到了锁，把队列中仅有的元素移除了，此时take2线程执行完后是释放锁，唤醒后继节点也就是take1线程。此时take1线程应该再次判断，条件不满足继续阻塞。
- 能否通过公平锁或不公平锁避免这个问题？不能，因为上面的take2线程可以认为是不公平锁的插队线程。加入是公平锁呢？上面 take1线程顺利获取到了锁，取走了唯一的元素。而新线程在获取不到锁时，加入同步队列。当线程 take1 线程执行完后释放锁，take2线程被唤醒，也必须再次检测while条件。否则将返回null元素，不符合阻塞队列。
- 区别：while比if执行完后多一次检测
- if：只会进行一次判断，执行if代码块完后就会执行if之后的代码
- while：符合while条件后，执行完while代码块里面的代码，执行完后会再次检查while条件，符合继续执行；不符合跳过，while：多使用于多线程唤醒后的再次检查条件
- signal和signalAll:使用这俩个都可以，只不过只会有一个线程获取锁得到元素，所以使用signal比signalAll更恰当
LinkedBlockingQueue：一个单向链表实现的有界（可指定大小，默认Integer.MAX_VALUE）阻塞队列，此队列按 FIFO（先进先出）原则。链接队列的吞吐量通常要高于基于数组的队列，但是在大多数并发应用程序中，其可预知的性能要低。
PriorityBlockingQueue：一个无界阻塞队列，虽然此队列逻辑上是无界的，但是资源被耗尽时试图执行 add 操作也将失败，导致 OutOfMemoryError。不支持先进先出原则
由于队列是无界的，所以put方法不会由于满了（始终不会满）而导致阻塞。
不保证具有同等优先级的元素的顺序
入队（通过比较找到合适位置入队）相同（值相等）元素不会覆盖，出对从队列头出队
DelayQueue：一个无界阻塞队列，内部根据PriorityQueue（无界线程不安全队列）存储元素，适用场景：定时执行（获取），缓存失效等
LinkedBlockingDeque：链表实现的有界阻塞双端队列，支持同端存取(FILO)和异端存取（FIFO）。如果未指定容量，那么容量将等于 Integer.MAX_VALUE
LinkedTransferQueue：一个链表实现的无界阻塞队列
- tryTransfer()尝试传递给消费者 ,没有消费者放入队列
- transfer()尝试传递给消费者 ,没有消费者自己处于阻塞状态，这种模式类似与SynchronousQueue
- 无论是transfer还是tryTransfer方法，在>=1个消费者线程等待获取元素时（此时队列为空），都会立刻转交，这属于线程之间的元素交换。注意，这时，元素并没有进入队列。
- 在队列中已有数据情况下，transfer将需要等待前面数据被消费掉，直到传递的元素e被消费线程取走为止。
SynchronousQueue：一个不存储元素的阻塞队列
- 其中每个插入操作必须等待另一个线程的对应移除操作，如果没被消费则一直处于阻塞
- 此同步队列没有任何内部容量，甚至连一个队列的容量都没有,适合传递性的应用场景

2.2.3.2Copy-On-Write简称COW，仅2个类Set和List

Copy-On-Write简称COW，是一种用于程序设计中的优化策略，采用数组存储。
使用场景：多读少写（读不加锁，写会加锁，防止多个线程多多个拷贝同时造成数据混乱，所以会加锁防止此问题）
写时采用复制新的容器，进行修改；新容器为原容器中对象的引用，使用完把新容器赋值给类的原有容器引用。复制新的容器时，这是一个比较耗费性能的操作
CopyOnWriteArraySet 采用CopyOnWriteArrayList 作为存储。基本差不多
CopyOnWrite的缺点
- 内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象
  
  （注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。
- 数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果若希望写入的的数据，马上能读到，不建议使用CopyOnWrite容器。
java1.8 下CopyOnWriteArrayList 和 Collections.synchronizedList(new ArrayList<String>()) 性能测试结论：
- 1.6下 CopyOnWriteArrayList 优于 synchronizedList网上结论;
- 1.8下基本差不多,可能是jvm对synchronized 不断的优化

2.2.3.3Concurrent*集合

均为安全的集合ConcurrentHashMap采用加锁，其他几个采用CAS无锁更新

ConcurrentHashMap
1.代码体积约6000行
2.java1.8 ConcurrentHashMap 和 HashMap 结构一样，在put操作时，当数组索引位置大于1时进行加锁操作
3.size()(或 mappingCount()) 使用无锁操作，返回并非准确值, 因为此时可能有线程对集合进行删除或增加操作
4.比较：
- java1.7
  - 1.版本采用Segment<K,V>[] segments数组，Segment继承ReentrantLock，实现锁分段，进行安全操作
  - 2.每个Segment相当于一个老版本的hashMap(数据结构为：table数组＋单向链表的数据结构)
  - 3.get时取不到值最后在加锁取一次
- java1.8
  - 1.取消segments字段，直接采用 HashEntry<K,V>[] table保存数据
  - 2.数据结构改为：变更为table数组＋单向链表(或红黑树)
  - 3.get() 使用无锁操作，取不到直接返回空
5.1.8中的锁力度更小，数据结构更简单
6.CounterCell何时使用没有理解透彻？
ConcurrentLinkedDeque
- 1.代码体积约1500行
- 2.一个无界线程安全双向链表
- 3.使用unsafe 保证原子性
ConcurrentLinkedQueue
- 一个无界线程安全FIFO队列
ConcurrentSkipListMap
- 是TreeMap的多线的安全版本
- 数据结构使用跳表保存数据，实质为一种链表

Key-Value数据结构

目前常用的key-value数据结构有三种：Hash表、红黑树、SkipList

名称	描述
hash表	即数组：例如：Hashmap（Hash表+链表+红黑树），HashTbale（Hash表+链表）插入、查找最快，为O(1)；如使用链表实现则可实现无锁；数据有序化需要显式的排序操作。
红黑树	例如：TreeMap 插入、查找为O(logn)，但常数项较小；无锁实现的复杂性很高，一般需要加锁；数据天然有序。
Skip表	例如：ConcurrentSkipListMap,插入、查找为O(logn)，但常数项比红黑树要大；底层结构为链表，可无锁实现；数据天然有序。

2.2.4线程池

线程池常用类关系

2.2.4.1Executor`CompletionService`

CompletionService实现了生产者提交任务和消费者获取结果的解耦，消费者一定是按照任务完成的先后顺序来获取执行结果,注意不是提交顺序。（自定义的实现为按照提交顺序）
基本实现：Executor+阻塞队列实现
一组任务获取结果的场景

2.2.4.2FutureTask

仅在计算完成时才能获取结果；如果计算尚未完成，则阻塞 get 方法。
单个任务获取结果的场景
可使用 FutureTask 包装 Callable 或 Runnable 对象。因为 FutureTask 实现了 Runnable，所以可将 FutureTask 提交给 Executor 执行。
FutureTask和Callable的关系？
- 由于线程池(AbstractExecutorService)只执行Callable类型的任务 ,提交的 Runnable 也会转化为Callable。
- 从类型上讲：FutureTask = Runnable+Future ;FutureTask内部又维护一个Callable，所以实际上又是一个 Callable
- 总之：FutureTask既是Runnable 又是Callable ，还有Future的特性。

2.2.4.3两种线程池

ThreadPoolExecutor

ThreadPoolExecutor调节线程的原则是：先调整到最小线程，最小线程用完后，它会优先将任务放入缓存队列(offer(task)),等缓冲队列用完了，才会向最大线程数调节。
线程池线程参数设置原则
- 无界队列：大小线程数建议设置成一致，如果使用无界队列，就不可能使用最大线程数
- 有界队列：大小线程数可以不一致（当有界队列特别大时，也没有必要把core和max设置的不一样，因为可能很难达到有界的最值，也就更难达到max的值了）
继承关系:
Executor->ExecutorService->AbstractExecutorService->ThreadPoolExecutor
理解线程复用？（难点）

ScheduledThreadPoolExecutor

ScheduledExecutorService的实现类ScheduledThreadPoolExecutor是继承线程池类ThreadPoolExecutor的，因此它拥有线程池的全部特性。但是同时又是一种特殊的线程池，这个
线程池的线程数大小最大Integer最大值，任务队列是基于DelayQueue的无限任务队列。
主要提供定时执行功能，通过延时队列实现
继承关系:
Executor->ExecutorService->AbstractExecutorService->ThreadPoolExecutor->ScheduledExecutorService
scheduleAtFixedRate【不关注上次线程执行完成】和scheduleWithFixedDelay【关注上次线程执行完成】
功能效果和Timer类似

2.2.4.4拒绝策略

拒绝策略4个类属于ThreadPoolExecutor的内部类
具体使用区别
- AbortPolicy：当提交的不能立即执行且阻塞队列无法容纳时，抛出异常，后续生产线程不能再正常提交到线程池
- CallerRunsPolicy：当提交的不能立即执行且阻塞队列无法容纳时，则立即执行,后续正常提交到线程池
- DiscardOldestPolicy：当提交的不能立即执行且阻塞队列无法容纳时，移除调队列中最早的任务,后续正常提交到线程池
- DiscardPolicy：当提交的不能立即执行且阻塞队列无法容纳时，丢弃提交的任务,后续正常提交到线程池

2.2.5框架

Executors
- 也可以认为是创建线程池的一个工具类
- 提供创建线程池的一些静态方法
Fork/Join
Fork/Join实现了“工作窃取算法”，ForkJoinTask需要通过ForkJoinPool来执行，任务分割出的子任务会添加到当前工作线程所维护的双端队列中，进入队列的头部。当一个工作线程的队列里暂时没有任务时，它会随机从其他工作线程的队列的尾部获取一个任务。
Fork/Join框架的设计主要2步任务
- 第一步分割任务。首先我们需要有一个fork类来把大任务分割成子任务，有可能子任务还是很大，所以还需要不停的分割，直到分割出的子任务足够小。
- 第二步执行任务并合并结果。分割的子任务分别放在双端队列里，然后几个启动线程分别从双端队列里获取任务执行。子任务执行完的结果都统一放在一个队列里，启动一个线程从队列里拿数据，然后合并这些数据。
应用
- 第一步：创建任务job，继承ForkJoinTask的子类:
  
  -----RecursiveAction：用于没有返回结果的任务。
  
  -----RecursiveTask ：用于有返回结果的任务。
- 第二步：提交job到ForkJoinPool(获取结果如果有)

2.2.6工具类

CountDownLatch : 基于AQS共享锁的实现，当state为0时唤醒等待的一个或一组线程
CyclicBarrier : 内部维护一个count 当count为0时，等待的线程开始运行，恢复CyclicBarrier的count为原初始值parties，所以相比CountDownLatch是可以重复使用的
Exchanger:线程互换数据
每个线程既可以充当消费者，也可以充当生产者
当生产大于消费时，如果一直没有被消费完，线程将处于阻塞状态
Semaphore:
- 基于AQS共享锁的实现
- Semaphore可以应用于流量控制，比如对数据库的连接数控制