高并发编程的艺术

因为线程创建和上下文切换的开销，所以多线程不一定比单线程快

无锁并发编程

CAS算法

使用最少线程

协程

避免一个线程同时获取多个锁

避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源

尝试使用定时锁

对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况

资源限制是指在进行并发编程时，程序的执行速度受限于计算机硬件资源或软件资源

受于资源限制，并发执行可能仍然保持串行执行，这时候因为增加了上下文切换和资源调度的时间，程序将不仅不会执行得更快，反而变得更慢

硬件资源限制：使用集群

软件资源限制：使用资源池

如果一个字段被声明称volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的

volatile的实现主要依靠JVM给处理器发送的Lock前缀指令

将变量追加到64字节

Java对象头里的Mark Word里默认储存对象的HashCode、分代年龄和锁标记位

偏向锁

轻量级锁

锁的优缺点对比

缓存行：缓存的最小单位

比较并交换：也就是CAS。CAS操作需要输入两个数值，一个旧值（期望操作前的值）和一个新值，在操作期间先比较旧值有没有发现变化，如果没有发生变化，才交换成新值，发生了变化则不交换。

CPU流水线：CPU流水线的工作方式就像工业生产上的装配流水线，在CPU中由5~6个不同功能的电路单元组成一条指令处理流水线，然后将一条X86指令分成5~6步后再由这些电路单元分别执行，这样就能实现在一个CPU时钟周期完成一条指令，因此提高CPU的运算速度

内存顺序冲突：内存顺序冲突一般是由假共享引起的，假共享是指多个CPU同时修改同一个缓存航的不同部分而引起其中一个CPU的操作无效，当出现这个内存顺序冲突时，CPU必须清空流水线

两种锁定方式：

使用循环CAS实现原子操作

使用锁机制实现原子操作

线程之间如何通信：线程之间以何种机制来交换信息

线程之间如何同步：程序中用于控制不同线程间操作发生相对顺序的机制

在Java中，所有实例域、静态域和数组元素都存储在堆内存中，堆内存在线程之间共享（“共享变量”这个术语代指这三个东西）。局部变量，方法定义参数和异常处理器参数不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

Java线程之间的通信由Java内存模型（JMM）控制。JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了共享变量的副本。注意：本地内存是JMM的一个抽象概念，并不真实存在。

编译器优化的重排序

指令级并行的重排序【处理器】

内存系统的重排序【处理器】

ps：JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序(通过内存屏障指令)，提供一致的内存可见性保证。

与程序员密切相关的happens-before规则

写后读

写后写

读后写

不管怎么重排序，（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守。遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序。

只要重排序和顺序执行的结果一致，JMM会允许对于程序顺序的重排序

在单线程程序中，对存在控制依赖的操作重排序不会改变执行结果（这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，则可能会改变程序的执行结果。

两大特性

在JMM中，临界区内的代码可以重排序，但绝不可以逸出到临界区之外

对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，Null，False），JMM保证线程读操作读取的值不会是无中生有的冒出来。

未同步程序在JMM和顺序一致性内存模型的几个差异

可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

假设线程A执行writer()方法之后，线程B执行reader()方法。根据happens-before规则，这个立的happens-before关系可以分为3类：
1）根据程序次序规则，1 happens-before 2;3 happens-before 4。
2）根据volatile规则，2 happens-before 3。
3）根据happens-before的传递性规则，1 happens-before 4。
因为1 happens-before4，所以保证了flag变量的内存可见性。

volatile写的内存语义：当写一个volatile变量时，JMM会把该线程对应本地内存中的共享变量值刷新到主内存。

volatile读的内存语义：当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。

为了实现volatile内存语义，JMM会限制编译器重排序和处理器重排序

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

旧的Java内存模型允许volatile变量与普通变量重排序

根据程序顺序规则：1 happens-before 2，2happens-before 3；4 happens-before 5，5 happens-before 6。

根据监视器锁规则：3 happens-before 4。

根据happens-before的传递性：2 happens-before 5。

因为2 happens-before 5，因此，线程A在释放锁之前所有的可见的共享变量，在线程B同一个锁后，将立刻变得对线程B可见。

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量。

利用volatile变量的写-读所具有的内存语义。

利用CAS所附带的volatile读和volatile写的内存语义。

通用的实现模式

对于final域，编译器和处理器要遵守两个重拍规则

JMM禁止编译器把final域的写重排序到构造函数之外。

编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。

在一个线程中，初次读对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读final域操作的前面插入一个LoadLoad屏障。

对于引用类型，写final域的重排序规则对编译器和处理器增加如下约束：在构造函数内对一个final引用的对象的成员域的写入，与随后在构造函数外把这个被构造函数对象的引用赋值給一个引用变量，这两个操作之间不能重排序。

在构造函数内部，不能让这个被构造对象的引用为其他线程所见，也就是对象引用不能在构造函数中“溢出”

在x86处理器中：由于X86处理器不会对写-写操作做重排序，所以在X86处理器中，写final域需要的StoreStore障屏会被省略掉。同样，由于X86处理器不会对存在间接依赖关系的操作做重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说，在X86处理器中，final域的读/写不会插入任何内存屏障！

问题：在旧的Java内存模型中，一个最严重的缺陷就是线程可能看到final域的值会改变。比如，一个线程当前看到一个整型final域的值为0（还未初始化之前的默认值），过一段时间之后这个线程再去读这个final域的值时，却发现值变为1（被某个线程初始化之后的值）。最常见的例子就是在旧的Java内存模型中，String的值可能会改变。

解决：为了修补这个漏洞，JSR-133专家组增强了final的语义。通过为final域增加写和读重排序规则，可以为Java程序员提供初始化安全保证：只要对象是正确构造的（被构造对象的引用在构造函数中没有“逸出”），那么不需要使用同步（指lock和volatile的使用）就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。

JMM向程序员提供的happens-before规则能满足程序员的需求。JMM的happens-before规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证。

JMM对编译器和处理器的束缚已经尽可能少。从上面的分析可以看出，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。

as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同
步的多线程程序的执行结果不被改变。

as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺
序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正
确同步的多线程程序是按happens-before指定的顺序来执行的。

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。

监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。

volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的
读。

传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。

start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。

join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

非线程安全的延迟初始化对象

对象的初始化可能被重排序

volatile保证共享变量的读/写具有原子性

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。

类初始化情况

注意，因为处理器要遵守as-if-serial语义，处理器不会对存在数据依赖性的两个内存操作做重排序。

JMM是一个语言级的内存模型，处理器内存模型是硬件级的内存模型，顺序一致性内存模型是一个理论参考模型。

处理器内存模型比语言内存模型要弱，处理器内存模型和语言内存模型都比顺序一致性内存模型要弱。同处理器内存模型一样，越是追求执行性能的语言，内存模型设计得会越弱。

单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。

正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。

未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0、null、false）。

增强volatile的内存语义。旧内存模型允许volatile变量与普通变量重排序。JSR-133严格限制volatile变量与普通变量的重排序，使volatile的写-读和锁的释放-获取具有相同的内存语义。

增强final的内存语义。在旧内存模型中，多次读取同一个final变量的值可能会不相同。为此，JSR-133为final增加了两个重排序规则。在保证final引用不会从构造函数内逸出的情况下，final具有了初始化安全性。

更多的处理器核心

更快的响应时间

更好的编程模型

在运行线程之前首先要构造一个线程对象，线程对象在构造的时候需要提供线程所需要的属性，如线程所属的线程组、线程优先级、是否是Daemon线程等信息。

中断状态是线程的一个标识位，而中断操作是一种简便的线程间交互方式，而这种交互方式最适合用来取消或停止任务。除了中断以外，还可以利用一个boolean变量来控制是否需要停止任务并终止该线程。

关键字volatile可以用来修饰字段（成员变量），就是告知程序任何对该变量的访问均需要从共享内存中获取，而对它的改变必须同步刷新回共享内存，它能保证所有线程对变量访问的可见性。

关键字synchronized可以修饰方法或者以同步块的形式来进行使用，它主要确保多个线程在同一个时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性。

等待/通知的相关方法是任意Java对象都具备的，因为这些方法被定义在所有对象的超类java.lang.Object上

等待方遵循规则

通知方遵循规则

看源码我们可知，join()是利用Object的等待/通知方法

其实ThreadLoca操作的就是当前线程的TreadLocalMap成员变量。

等待超时模式就是在等待/通知范式基础上增加了超时控制，这使得该模式相比原有范式更具有灵活性，因为即使方法执行时间过长，也不会“永久”阻塞调用者，而是会按照调用者的要求“按时”返回。

TODO 使用等待超时模式来构造一个简单的数据库连接池

尝试非阻塞的获取锁：当前线程尝试获取锁，如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁

能被中断的获取锁：与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁会被释放

超时获取锁：在指定的截止时间之前获取锁，如果截止时间到了仍旧无法获取锁，则返回

void lock()：获取锁时，调用该方法当前线程将会获取锁，当获得锁后，从该方法返回

void lockInterruptibly() throws InterruptedException：可中断地获取锁，和lock()方法的不同之处在于该方法会响应中断，即在锁的获取中可以中断该线程

boolean tryLock()：尝试非阻塞的获取锁，调用该方法后立刻返回，如果能获取则返回true，否则返回false。

boolean tryLock(long time,TimeUint unit) throws InterruotedException：超时的获取锁，当线程在以下3种情况下会返回：①当线程在超时时间内获得了锁②当前线程在超时时间内被中断③超时时间结束，返回false

vold unlock()：释放锁

Condition newCondition()：获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的awit()方法，而调用后，当前线程将释放锁。

同步器提供的3个方法来访问后修改同步状态

同步器可重写的方法

同步器提供的模版方法

同步队列

独占式同步状态获取与释放

共享式同步状态获取与释放

独占式超时获取同步状态

自定义同步组件-TwinsLock

线程再次获取锁

锁的最终释放

源码（非公平锁）

非公平获取锁：只要CAS设置同步状态成功即可

公平锁获取锁：会加多一个判断，当前线程节点是否有前驱节点

之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。

公平性选择

重进入

锁降级

int getReadLockCount()

int getReadHoldCount()

boolean isWriteLocked()

int getWriteHoldCount()

使用读写锁来保证作为本地缓存的HashMap具有线程安全性

读写状态的设计

写锁的获取与释放

读锁的获取与释放

锁降级

当需要阻塞或唤醒一个线程的时候，都会使用LockSupport工具类来完成相应工作。LockSupport定义了一组的公共静态方法，这些方法提供了最基本的线程阻塞和唤醒功能，而LockSupport也成为构建同步组件的基础工具。

void park()：阻塞当前线程，如果调用unpark(Thread thread)方法或者当前线程被终端，才能从park()方法返回

void parkNanos(long nanos)：阻塞当前线程，最长不超过nanos纳秒，返回条件再park()的基础上增加了超时返回

void parkUntil(long deadline)：阻塞当前线程，知道deadline时间（从1970年开始到deadline时间的毫秒数）

void unpark(Thread thread)：唤醒处于阻塞状态的线程thread

LockSupport增加了park(Object blocker)、parkNanos(Object blocker,long nanos)和parkUntil(Object blocker,long deadline)3个方法，用于实现阻塞当前线程的功能，其中参数blocker是用来标识当前线程在等待的对象（以下称为阻塞对象），该对象主要用于问题排查和系统监控。

任意一个Java对象，都拥有一组监视器方法（定义在java.lang.Object上），主要包括wait()、wait(long timeout)、notify()以及notifyAll()方法，这些方法与synchronized同步关键字配合，可以实现等待/通知模式。Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的。

void await() throws InterruptedException

void awaitUninterruptibly()

long awaitNanos(long nanosTimeout) throws InterruptedException

boolean awaitUntil(Date deadline) throws InterruptedException

void signal()

void signalAll()

有界队列是一种特殊的队列，当队列为空时，队列的获取操作将会阻塞获取线程，直到队列中有新增元素，当队列已满时，队列的插入操作将会阻塞插入线程，直到队列出现“空位”

等待队列

等待

通知

线程不安全的HashMap

效率低下的HashTable

ConcurrentHashMap的锁分段技术可有效提升并发访问率

ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成

初始化segment数组

初始化segmentShift和segmentMask

初始化每个segment

使用Wang/Jenkins hash的变种算法对元素的hashCode进行一次再散列

get操作

put操作

size操作

ConcurrentLinkedQueue由head节点和tail节点组成，每个节点（Node）由节点元素（item）和指向下一个节点（next）的引用组成，节点与节点之间就是通过这个next关联起来，从而组成一张链表结构的队列。

第一是定位出尾节点；第二是使用CAS算法将入队节点设置成尾节点的next节点，如不成功则重试。

一个支持两个附加操作的队列。这两个附加的操作支持阻塞的插入和移除方法。

ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列

LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列

PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列

DelayQueue：一个支持延时获取元素的无界阻塞队列

SynchronousQueue：一个不存储元素的阻塞队列

LinkedTransferQueue：一个由链表结构组成的无界阻塞队列

LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列

使用通知模式实现（Condition）

Java 7提供的一个用于并行执行任务的框架，是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架

窃取（work-stealing）算法是指某个线程从其他队列里窃取任务来执行

为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务的线程永远从双端队列的尾部拿任务执行。

步骤

两个类完成上面的两个步骤

在compute()方法里，首先需要判断任务是否足够小，如果足够小就直接执行任务。如果不足够小，就必须分割成两个子任务，每个子任务在调用fork方法时，又会进入compute方法，看看当前子任务是否需要继续分割成子任务，如果不需要继续分割，则执行当前子任务并返回结果。使用join方法会等待子任务执行完并得到其结果

isCompletedAbnormally()

getException()

ForkJoinPool由ForkJoinTask数组和ForkJoinWorkerThread数组组成，ForkJoinTask数组负责将存放程序提交给ForkJoinPool的任务，而ForkJoinWorkerThread数组负责执行这些任务

ForkJoinTask的fork方法实现原理

ForkJoinTask的join方法实现原理

AtomicBoolean：原子更新布尔类型

AtomicInteger：原子更新整型

AtomicLong：原子更新长整型

int addAndGet（int delta）：以原子方式将输入的数值与实例中的值（AtomicInteger里的
value）相加，并返回结果

boolean compareAndSet（int expect，int update）：如果输入的数值等于预期值，则以原子方
式将该值设置为输入的值

int getAndIncrement()：以原子方式将当前值加1，注意，这里返回的是自增前的值

void lazySet（int newValue）：最终会设置成newValue，使用lazySet设置值后，可能导致其他线程在之后的一小段时间内还是可以读到旧的值

int getAndSet（int newValue）：以原子方式设置为newValue的值，并返回旧值

死循环+CAS

利用Unsafe类(CAS算法)

AtomicIntegerArray：原子更新整型数组里的元素

AtomicLongArray：原子更新长整型数组里的元素

AtomicReferenceArray：原子更新引用类型数组里的元素

int addAndGet（int i，int delta）：以原子方式将输入值与数组中索引i的元素相加

boolean compareAndSet（int i，int expect，int update）：如果当前值等于预期值，则以原子
方式将数组位置i的元素设置成update值

AtomicReference：原子更新引用类型

AtomicReferenceFieldUpdater：原子更新引用类型里的字段

AtomicMarkableReference：原子更新带有标记位的引用类型

AtomicIntegerFieldUpdater：原子更新整型的字段的更新器

AtomicLongFieldUpdater：原子更新长整型字段的更新器

AtomicStampedReference：原子更新带有版本号的引用类型

每次使用的时候必须使用静态方法newUpdater()创建一个更新器，并且需要设置想要更新的类和属性

更新类的字段（属性）必须使用public volatile修饰符

CyclicBarrier默认的构造方法是CyclicBarrier（int parties），其参数表示屏障拦截的线程数量，每个线程调用await方法告诉CyclicBarrier我已经到达了屏障，然后当前线程被阻塞

CyclicBarrier还提供一个更高级的构造函数CyclicBarrier（int parties，Runnable barrier-Action），用于在线程到达屏障时，优先执行barrierAction，方便处理更复杂的业务场景

多线程计算数据，最后合并计算结果

CountDownLatch的计数器只能使用一次

CyclicBarrier的计数器可以使用reset()方法重置

intavailablePermits()：返回此信号量中当前可用的许可证数

intgetQueueLength()：返回正在等待获取许可证的线程数

booleanhasQueuedThreads()：是否有线程正在等待获取许可证

void reducePermits（int reduction）：减少reduction个许可证，是个protected方法

Collection getQueuedThreads()：返回所有等待获取许可证的线程集合，是个protected方
法

线程池判断核心线程池里的线程是否都在执行任务。如果不是，则创建一个新的工作线程来执行任务。如果核心线程池里的线程都在执行任务，则进入下个流程

线程池判断工作队列是否已经满。如果工作队列没有满，则将新提交的任务存储在这个工作队列里。如果工作队列满了，则进入下个流程

线程池判断线程池的线程是否都处于工作状态。如果没有，则创建一个新的工作线程来执行任务。如果已经满了，则交给饱和策略来处理这个任务

如果当前运行的线程少于corePoolSize，则创建新线程来执行任务（注意，执行这一步骤需要获取全局锁）

如果运行的线程等于或多于corePoolSize，则将任务加入BlockingQueue

如果无法将任务加入BlockingQueue（队列已满），则创建新的线程来处理任务（注意，执行这一步骤需要获取全局锁）

如果创建新线程将使当前运行的线程超出maximumPoolSize，任务将被拒绝，并调用RejectedExecutionHandler.rejectedExecution()方法

创建代码

核心参数

execute()

submit()

shutdown()

shutdownNow()

CPU密集型任务应配置尽可能小的线程，如配置Ncpu+1个线程的线程池

IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如2*Ncpu

优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理

建议使用有界队列

taskCount：线程池需要执行的任务数量

completedTaskCount：线程池在运行过程中已完成的任务数量，小于或等于taskCount

largestPoolSize：线程池里曾经创建过的最大线程数量。通过这个数据可以知道线程池是否曾经满过。如该数值等于线程池的最大大小，则表示线程池曾经满过

getPoolSize：线程池的线程数量。如果线程池不销毁的话，线程池里的线程不会自动销毁，所以这个大小只增不减

getActiveCount：获取活动的线程数

通过扩展线程池进行监控。可以通过继承线程池来自定义线程池，重写线程池的beforeExecute、afterExecute和terminated方法，也可以在任务执行前、执行后和线程池关闭前执行一些代码来进行监控。例如，监控任务的平均执行时间、最大执行时间和最小执行时间等。这几个方法在线程池里是空方法

在上层，Java多线程程序通常把应用分解为若干个任务，然后使用用户级的调度器（Executor框架）将这些任务映射为固定数量的线程

在底层，操作系统内核将这些线程映射到硬件处理器上

任务。包括被执行任务需要实现的接口：Runnable接口或Callable接口

任务的执行。包括任务执行机制的核心接口Executor，以及继承自Executor的ExecutorService接口。Executor框架有两个关键类实现了ExecutorService接口（ThreadPoolExecutor和ScheduledThreadPoolExecutor）

异步计算的结果。包括接口Future和实现Future接口的FutureTask类

FixedThreadPool被称为可重用固定线程数的线程池

public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue());
}

execute()方法

SingleThreadExecutor是使用单个worker线程的Executor

public static ExecutorService newSingleThreadExecutor() {
       return new FinalizableDelegatedExecutorService(new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue()));
}

execute()方法

CachedThreadPool是一个会根据需要创建新线程的线程池

public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,60L, TimeUnit.SECONDS,new SynchronousQueue());
}

execute()方法

当调用ScheduledThreadPoolExecutor的scheduleAtFixedRate()方法或者scheduleWithFixedDelay()方法时，会向ScheduledThreadPoolExecutor的DelayQueue添加一个实现了RunnableScheduledFutur接口的ScheduledFutureTask

线程池中的线程从DelayQueue中获取ScheduledFutureTask，然后执行任务

ScheduledThreadPoolExecutor为了实现周期性的执行任务，对ThreadPoolExecutor做了如下
的修改

ScheduledFutureTask

任务执行步骤

DelayQueue.take()

DelayQueue.add()

FutureTask除了实现Future接口外，还实现了Runnable接口。因此，FutureTask可以交给Executor执行，也可以由调用线程直接执行（FutureTask.run()）

三种状态

get()

cancel()

直接调用FutureTask的run()方法

可以通过ExecutorService.submit()提交任务

每个FutureTask任务最多只能被执行一次

FutureTask的实现基于AbstractQueuedSynchronizer（以下简称为AQS）

基于“复合优先于继承”的原则，FutureTask声明了一个内部私有的继承于AQS的子类，对FutureTask所有公有方法的调用都会委托给这个内部子类

AQS被作为“模板方法模式”的基础类提供给FutureTask的内部子类Sync，这个内部子类只需要实现状态检查和状态更新的方法即可，这些方法将控制FutureTask的获取和释放操作。具体来说，Sync实现了AQS的tryAcquireShared（int）方法和tryReleaseShared（int）方法，Sync通过这两个方法来检查和更新同步状态