《Java并发编程的艺术》读书笔记

目的

并发编程的目的是为了让程序运行得更快，但是，并不是启动更多的线程就能让程序最大限度地并发执行。在进行并发编程时，如果希望通过多线程执行任务让程序运行得更快，会面临非常多的挑战，比如上下文切换的问题、死锁的问题，以及受限于硬件和软件的资源限制问题。

单核处理器是不是不支持并发？

即使是单核处理器也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程是同时执行的，时间片一般是几十毫秒。

什么是上下文切换？

CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。

这就像我们同时读两本书，当我们在读一本英文的技术书时，发现某个单词不认识，于是便打开中英文字典，但是在放下英文技术书之前，大脑必须先记住这本书读到了多少页的第多少行，等查完单词之后，能够继续读这本书。这样的切换是会影响读书效率的，同样上下文切换也会影响多线程的执行速度。

多线程一定会让代码更快吗？

不一定，当并发执行累加操作不超过百万次时，速度会比串行执行累加操作要慢。因为线程有创建和上下文切换的开销。

如何减少上下文切换？

• 无锁并发编程

多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash算法取模分段，不同的线程处理不同段的数据。

• CAS算法

Java的Atomic包使用CAS算法来更新数据，而不需要加锁。

• 使用最少线程

使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这 样会造成大量线程都处于等待状态。

• 使用协程

在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

死锁和避免方法

如果两个线程互相等待对方释放锁就会造成死锁。

避免死锁的几个常见方法：

• 避免一个线程同时获取多个锁
• 避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源
• 尝试使用定时锁，使用lock.tryLock(timeout)来替代使用内部锁机制
• 对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况

volatile关键字

定义：Java允许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保通过排他锁单独获得这个变量。如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。

volatile是如何保证可见性的？

有volatile变量修饰的共享变量进行写操作的时候会多出Lock前缀的汇编代码，Lock前缀的指令在多核处理器下会引发了两件事情

• 将当前处理器缓存行的数据写回到系统内存。
• 这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存后再进行操作，但操作完不知道何时会写到内存。如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

synchronized关键字

synchronized实现同步的基础是Java中的每一个对象都可以作为锁。具体表现为以下3种形式。

• 对于普通同步方法，锁是当前实例对象
• 对于静态同步方法，锁是当前类的Class对象
• 对于同步方法块，锁是Synchonized括号里配置的对象

当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。

原理

JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter 和monitorexit指令实现的，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明。但是，方法的同步同样可以使用这两个指令来实现。

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter 指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。

synchronized用的锁是存在Java对象头里的。如果对象是数组类型，则虚拟机用3个字宽存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit。

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

在运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据。

锁的升级与比对

为了减少获得锁和释放锁带来的性能损耗，JDK1.6之后引入了偏向锁和轻量级锁，在JDK1.6中锁一共有4种状态，级别从低到高依次是：无锁、偏向锁、轻量级锁、重量级锁。这几个状态会随着竞争情况逐渐升级，而且不能降级，目的是为了提高获得锁和释放锁的效率。

偏向锁

大多数情况下，锁不仅不存在多线程竞争，反而总是有同一个线程获得，为了让线程获得锁代价更低，所以引入了偏向锁。

当一个线程访问同步块并获取锁的时候，会在对象头和栈帧中的锁记录里面存储锁偏向的线程ID，以后该线程在进入和退出同步块的时候不需要进行CAS操作来加锁和解锁，只需要简单地测试一下对象头的MarkWord里面是否存储指向当前线程的偏向锁即可。

如果失败了则需要在测试一下MarkWord中偏向锁的标识是否设置成1(表示当前是偏向锁)，如果没有设置，则使用CAS竞争锁，如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销

偏向锁使用了一种等到竞争出现才释放锁的机制，当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。

偏向锁的撤销需要等待全局安全点(时间点上没有正在执行的字节码)，它会首先暂停拥有偏向锁的线程然后检查持有偏向锁的线程是否或者，如果线程不处于活动状态则将对象头设置成无锁状态。如果线程活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，然后唤醒暂停的线程。

偏向锁的关闭

偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0

如果确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:- UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

轻量级锁

加锁

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。

然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁

轻量级锁解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。

因为自旋会消耗CPU，为了避免无用的自旋(比如获得锁的线程被阻塞住了)，一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。

当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的竞争。

原子操作的实现原理

定义：原子操作意思是不可被中断的一个或一些列操作。下图是解释原子操作相关的CPU术语。

处理器如何实现原子操作

32位处理器基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。

首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。

最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位 的操作是原子的，但是复杂的内存操作处理器是不能自动保证其原子性的，比如跨总线宽度、跨多个缓存行和跨页表的访问。但是，处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。

总线锁

如果多个处理器同时对共享变量进行读改写操作 (i++就是经典的读改写操作)，那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致。

举个例子，如果i=1，进行两次i++操作，期望的结果是3，但是有可能结果是2。因为多个处理器同时从各自的缓存中读取变量i，分别进行加1操作，然后分别写入系统内存中。想要保证改写共享变量的操作是原子的，就必须保证CPU1读改写共享变量的时候CPU2不能操作。

处理器使用总线锁就是来解决这个问题的。总线锁就是使用处理器提供的一个 LOCK#信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住，那么该处理器可以独占共享内存。

缓存锁

总线锁定把CPU和内存之间的通信锁住了，锁定期间其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大。在某些场景下，可以使用缓存锁定代替总线锁定来进行优化。因为只要保证在同一时刻对某个内存地址的操作是原子性的就可以。

频繁使用的内存会缓存在处理器的L1、L2和L3高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，

可以使用“缓存锁定”的方式来实现复杂的原子性。“缓存锁定”是指内存区域如果被缓存在处理器的缓存中，并且在Lock操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声明LOCK#信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处 理器回写已被锁定的缓存行的数据时，会使缓存行无效。上图中当CPU1修改缓存行中的 i 时使用了缓存锁定，那么CPU2就不能同时缓存 i 的缓存行。

但是，有两种情况下处理器不会使用缓存锁定。

1、当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行时，处理器会调用总线锁定。

2、有些处理器不支持缓存锁定。对于Intel 486和Pentium处理器，就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。

Java如何实现原子操作

循环CAS实现原子操作

JVM中的CAS操作利用了处理器提供的CMPXCHG指令实现的。自旋CAS实现的基本思路就是循环进行CAS操作直到成功为止。

从Java 1.5开始，JDK的并发包里提供了一些类来支持原子操作，如AtomicBoolean(用原子方式更新的boolean值)、AtomicInteger(用原子方式更新的int值)和AtomicLong(用原子方式更新的long值)。这些原子包装类还提供了有用的工具方法，比如以原子的方式将当前值自增1和自减1。

CAS存在的问题

• ABA问题

CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新。

如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。

从 Java 1.5开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法的作用是首先检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

• 循环时间长开销大

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令，那么效率会有一定的提升。

pause指令有两个作用，一个是它可以延迟流水线执行指令，使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零；第二点是它可以避免在退出循环的时候因内存顺序冲突引起CPU流水线被清空，从而提高CPU的执行效率。

• 只能保证一个共享变量的原子操作

对多个共享变量操作时，循环CAS就无法保证操作的原子性。

解决办法是改用锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i=2，j=a，合并一下ij=2a，然后用CAS来操作ij。

从Java 1.5开始， JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

使用锁实现原子操作

锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。JVM内部实现了很多种锁机制，有偏向锁、轻量级锁和互斥锁。除了偏向锁，JVM实现锁的方式都用了循环 CAS，当一个线程想进入同步块的时候使用循环CAS的方式来获取锁，当它退出同步块的时候使用循环CAS释放锁。

Java内存模型

Java内存模型的抽象结构

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

Java线程之间的通信由Java内存模型(JMM)控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

JMM定义了线程和主内存之间的抽象关系，线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程以读/写共享变量的副本。

本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

从上图来看线程A和线程B要通信必须要经历下面2个步骤

1、线程A把本地内存A中更新过的共享变量刷新到主内存中去。

2、线程B到主内存中去读取线程A之前已更新过的共享变量。

本地内存A和本地内存B由主内存中共享变量x的副本。假设初始时，3个内存中的x值都为0。线程A在执行时，把更新后的x值1临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。

这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为程序员提供内存可见性保证。

重排序

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。重排序分3种类型。

• 编译器优化的重排序。

编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

• 指令级并行的重排序。

现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

• 内存系统的重排序。

由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从Java源代码到最终实际执行的指令序列，会分别经历下面3种重排序

这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排 序。

对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序。

线程

定义：操作系统调度的最小单元是线程，也叫轻量级进程，在一个进程里可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，并且能够访问共享的内存变量。

为什么要使用多线程？

• 更多的处理器核心

处理器上的核心数量越来越多，现在大多数计算机都比以往更加擅长并行计算，而处理器性能的提升方式，也从更高的主频向更多的核心发展。如果程序使用多线程技术，将计算逻辑分配到多个处理器核心上，就会显著减少程序的处理时间，并且随着更多处理器核心的加入而变得更有效率。

• 更快的响应时间
• 更好的编程模型

线程的状态

线程创建之后，调用start()方法开始运行。当线程执行wait()方法之后，线程进入等待状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态，而超时等待状态相当于在等待状态的基础上增加了超时限制，也就是超时时间到达时将 会返回到运行状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到阻塞状态。线程在执行Runnable的run()方法之后将会进入到终止状态。

Daemon线程

Daemon线程是一种支持型线程，它主要被用作程序中后台调度以及支持性工作。当一个Java虚拟机中不存在非Daemon线程的时候，Java虚拟机将会退出。可以通过调用Thread.setDaemon(true)将线程设置为Daemon线程。

启动线程

线程对象在初始化完成之后，调用start()方法就可以启动这个线程。

线程start()方法的含义是：当前线程同步告知Java虚拟机，只要线程规划器空闲，应立即启动调用 start()方法的线程。

中断

中断可以理解为线程的一个标识位属性，它表示一个运行中的线程是否被其他线程进行了中断操作。中断好比其他线程对该线程打了个招呼，其他线程通过调用该线程的interrupt()方法对其进行中断操作

线程通过检查自身是否被中断来进行响应，线程通过方法isInterrupted()来进行判断是否被中断，也可以调用静态方法Thread.interrupted()对当前线程的中断标识位进行复位。如果该线程已经处于终结状态，即使该线程被中断过，在调用该线程对象的isInterrupted()时依旧会返 回false。

等待/通知机制

等待/通知机制，是指一个线程A调用了对象O的wait()方法进入等待状态，而另一个线程B调用了对象O的notify()或者notifyAll()方法，线程A收到通知后从对象O的wait()方法返回，进而执行后续操作。上述两个线程通过对象O来完成交互，而对象上的wait()和notify/notifyAll()的 关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。

WaitThread首先获取了对象的锁，然后调用对象的wait()方法，从而放弃了锁并进入了对象的等待队列WaitQueue中，进入等待状态。由于WaitThread释放了对象的锁NotifyThread随后获取了对象的锁，并调用对象的notify()方法，将WaitThread从WaitQueue移到 SynchronizedQueue中，此时WaitThread的状态变为阻塞状态。NotifyThread释放了锁之后， WaitThread再次获取到锁并从wait()方法返回继续执行。

等待/通知的范式

等待方遵循如下原则。

1、获取对象的锁。

2、如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。

3、条件满足则执行对应的逻辑。

java synchronized(对象) {    while(条件不满足) { 对象.wait();   }    对应的处理逻辑 }

通知方遵循如下原则。

1、获得对象的锁。

2、改变条件。

3、通知所有等待在对象上的线程。

java synchronized(对象) {    改变条件    对象.notifyAll(); }

管道输入/输出流

管道输入/输出流主要包括了如下4种具体实现

• PipedOutputStream
• PipedInputStream
• PipedReader
• PipedWriter

前两种面向字节，而后两种面向字符。

Thread.join()的使用

如果一个线程A执行了thread.join()语句，其含义是：当前线程A等待thread线程终止之后才从thread.join()返回。

线程Thread除了提供join()方法之外，还提供了join(long millis)和join(long millis,int nanos)两个具备超时特性的方法。这两个超时方法表示，如果线程thread在给定的超时时间里没有终止，那么将会从该超时方法中返回。

ThreadLocal的使用

ThreadLocal，即线程变量，是一个以ThreadLocal对象为键、任意对象为值的存储结构。这个结构被附带在线程上，也就是说一个线程可以根据一个ThreadLocal对象查询到绑定在这个线程上的一个值。

可以通过set(T)方法来设置一个值，在当前线程下再通过get()方法获取到原先设置的值。

Java中的锁

Lock接口

在Lock接口出现之前，Java程序是靠synchronized关键字实现锁功能的。

Java 5之后，并发包中新增了Lock接口用来实现锁功能，它提供了与synchronized关键字类似的同步功能，只是在使用时需要显式地获取和释放锁。虽然它缺少了隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以 及超时获取锁等多种synchronized关键字所不具备的同步特性。

使用synchronized关键字将会隐式地获取锁，但是它将锁的获取和释放固化了，也就是先获取再释放。这种方式简化了同步的管理，可是扩展性没有显示的锁获取和释放来的好。例如，针对一个场景，手把手进行锁获取和释放，先获得锁A，然后再获取锁B，当锁B获得后，释放锁A同时获取锁C，当锁C获得后，再释放B同时获取锁D，以此类推。这种场景下， synchronized关键字就不那么容易实现了，而使用Lock却容易许多。

Lock lock = new ReentrantLock(); lock.lock(); try { } finally { lock.unlock(); }

在finally块中释放锁，目的是保证在获取到锁之后，最终能够被释放。不能将获取锁的过程写在try块中，因为如果在获取锁(自定义锁的实现)时发生了异常， 异常抛出的同时，也会导致锁无故释放。

以下是Lock接口提供的特性，

Lock接口定义了锁获取和释放的基本操作

队列同步器

队列同步器AbstractQueuedSynchronizer，是用来构建锁或者其他同步组件的基础框架。

它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。

同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法getState()、setState(int newState)和compareAndSetState(int expect,int update)来进行操作，因为它们能够保证状态的改变是安全的。

子类推荐被定义为自定义同步组件的静态内部类，同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件(ReentrantLock、 ReentrantReadWriteLock和CountDownLatch等)。

同步器是实现锁(也可以是任意同步组件)的关键，在锁的实现中聚合同步器，利用同步器实现锁的语义。锁是面向使用者的，同步器定义了使用者与锁交互的接口(比如可以允许两个线程并行访问)，隐藏了实现细节。同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。

实现分析

• \ 同步队列

同步器依赖内部的同步队列(一个FIFO双向队列)来完成同步状态的管理，当前线程获取同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点(Node)并将其加入同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再次尝试获取同步状态。

同步队列中的节点(Node)用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点。

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

通过调用同步器的acquire(int arg)方法可以获取同步状态，该方法对中断不敏感，也就是由于线程获取同步状态失败后进入同步队列中，后续对线程进行中断操作时，线程不会从同步队列中移出

java public final void acquire(int arg) {  if (!tryAcquire(arg) &&  acquireQueued(addWaiter(Node.EXCLUSIVE), arg)){       selfInterrupt(); } }

首先调用自定义同步器实现的tryAcquire(int arg)方法，该方法保证线程安全地获取同步状态，如果同步状态获取失败，则构造同步节点并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部，最后调用acquireQueued(Node node,int arg)方法，使得该节点以“死循环”的方式获取同步状态。如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞线程被中断来实现。

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

共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。以文件的读写为例，如果一个程序在对文件进行读操作，那么这一时刻对于该文件的写操作均被阻塞，而读操作能够同时进行。写操作要求对资源的独占式访问，而读操作可以是共享式访问。

• 独占式超时获取同步状态

通过调用同步器的doAcquireNanos(int arg,long nanosTimeout)方法可以超时获取同步状态，即在指定的时间段内获取同步状态，如果获取到同步状态则返回true，否则，返回false。该方法提供了传统Java同步操作(比如synchronized关键字)所不具备的特性。

重入锁

重入锁ReentrantLock，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。

ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

重入的实现

• 线程再次获取锁

锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。

• 线程的最终释放

线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

公平锁和非公平锁的区别

如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO

读写锁

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

读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构，它大部分时间提供读服务 (例如查询和搜索)，而写操作占有的时间很少，但是写操作完成之后的更新需要对后续的读服务可见。在没有读写锁支持的时候，要使用Java的等待通知机制，当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后，所有等待的读操作才能继续执行。改用读写锁实现上述功能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，相对于使用等待通知机制的实现方式而言，变得简单明了。

一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是 ReentrantReadWriteLock，它的特性如下所示。

Condition接口

任意一个Java对象，都拥有一组监视器方法(定义在java.lang.Object上)，主要包括wait()、 wait(long timeout)、notify()以及notifyAll()方法，这些方法与synchronized同步关键字配合，可以实现等待/通知模式。

Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的。

Java并发容器和框架

ConcurrentHashMap

在并发编程中使用HashMap可能导致程序死循环。而使用线程安全的HashTable效率又非常低下，基于两个原因，便有了ConcurrentHashMap。

• 线程不安全的HashMap

在多线程环境下，使用HashMap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。例如，执行以下代码会引起死循环。因为多线程会导致HashMap的Entry链表形成环形数据结构，一旦形成环形数据结构，Entry的next节点永远不为空，就会产生死循环获取Entry。

java final HashMap<String, String> map = new HashMap<String, String>(2);           Thread t = new Thread(new Runnable() {               @Override               public void run() {                   for (int i = 0; i < 10000; i++) {                       new Thread(new Runnable() {                           @Override                           public void run() {                               map.put(UUID.randomUUID().toString(), "");                           }                       }, "ftf" + i).start();                   } } }, "ftf");           t.start();           t.join();

• 效率低下的HashTable

HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法，其他线程也访问HashTable的同步方法时，会进入阻塞或轮询状态。如线程1使用put进行元素添加，线程2不但不能使用put方法添加元素，也不能使用get方法来获取元素，所以竞争越激烈效率越低。

• ConcurrentHashMap的锁分段技术提高并发率

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因是所有访问HashTable的线程都必须竞争同一把锁，假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术。

首先将数据分成一段一段地存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

结构

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

Segment是一种可重入锁(ReentrantLock)，在ConcurrentHashMap里扮演锁的角色。

HashEntry则用于存储键值对数据。

一个ConcurrentHashMap里包含一个Segment数组。Segment的结构和HashMap类似，是一种数组和链表结构。一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护着一个HashEntry数组里的元素，当对HashEntry数组的数据进行修改时，必须首先获得与它对应的Segment锁，如下图所示。

初始化

ConcurrentHashMap初始化方法是通过initialCapacity、loadFactor和concurrencyLevel等几个参数来初始化segment数组、段偏移量segmentShift、段掩码segmentMask和每个segment里的HashEntry数组来实现的。

1、初始化segments数组

下面是初始化segments数组的源代码

java if (concurrencyLevel > MAX_SEGMENTS)               concurrencyLevel = MAX_SEGMENTS;           int sshift = 0;           int ssize = 1;           while (ssize < concurrencyLevel) { ++sshift; ssize <<= 1;           }           segmentShift = 32 - sshift;           segmentMask = ssize - 1;           this.segments = Segment.newArray(ssize);

segments数组的长度ssize是通过concurrencyLevel计算得出的。为了能通过按位与的散列算法来定位segments数组的索引，必须保证segments数组的长度是2的N次方 (power-of-two size)，所以必须计算出一个大于或等于concurrencyLevel的最小的2的N次方值来作为segments数组的长度。

假如concurrencyLevel等于14、15或16，ssize都会等于16，即容器里锁的个数也是16。

2、初始化segmentShift和segmentMask

这两个全局变量需要在定位segment时的散列算法里使用，sshift等于ssize从1向左移位的次数，在默认情况下concurrencyLevel等于16，1需要向左移位移动4次，所以sshift等于4。 segmentShift用于定位参与散列运算的位数，segmentShift等于32减sshift，所以等于28，这里之所以用32是因为ConcurrentHashMap里的hash()方法输出的最大数是32位的。segmentMask是散列运算的掩码，等于ssize减1，即15，掩码的二进制各个位的值都是1。因为ssize的最大长度是65536，所以segmentShift最大值是16，segmentMask最大值是 65535，对应的二进制是16位，每个位都是1。

3、初始化每个segment

输入参数initialCapacity是ConcurrentHashMap的初始化容量，loadfactor是每个segment的负载因子，在构造方法里需要通过这两个参数来初始化数组中的每个segment。

java if (initialCapacity > MAXIMUM_CAPACITY)               initialCapacity = MAXIMUM_CAPACITY;           int c = initialCapacity / ssize;           if (c * ssize < initialCapacity)               ++c;           int cap = 1;           while (cap < c)               cap <<= 1;           for (int i = 0; i < this.segments.length; ++i)               this.segments[i] = new Segment<K,V>(cap, loadFactor);

代码中的变量cap就是segment里HashEntry数组的长度，它等于initialCapacity除以ssize 的倍数c，如果c大于1，就会取大于等于c的2的N次方值，所以cap不是1，就是2的N次方。 segment的容量threshold=(int)cap*loadFactor，默认情况下initialCapacity等于16，loadfactor等于 0.75，通过运算cap等于1，threshold等于零。

操作

1、get

get操作先经过一次再散列，然后使用这个散列值通过散列运算定位到Segment，再通过散列算法定位到元素，代码如下。

java  public V get(Object key) {           int hash = hash(key.hashCode());           return segmentFor(hash).get(key, hash); }

get操作的高效之处在于整个get过程不需要加锁，除非读到的值是空才会加锁重读。

ConcurrentHashMap的get操作之所以能做到不加锁，是因为它的get方法里将要使用的共享变量都定义成volatile类型，如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写，在get操作里只需要读不需要写共享变量count和value，所以可以不用加锁。之所以不会读到过期的值，是因为根据Java内存模型的happen before原则，对volatile字段的写入操作先于读操作，即使两个线程同时修改和获取 volatile变量，get操作也能拿到最新的值，这是用volatile替换锁的经典应用场景。

java transient volatile int count; volatile V value;

2、put

由于put方法里需要对共享变量进行写入操作，在操作共享变量时必须加锁。

put方法首先定位到Segment，然后在Segment里进行插入操作。插入操作需要经历两个步骤，第一步判断是否需要对Segment里的HashEntry数组进行扩容，第二步定位添加元素的位置，然后将其放在HashEntry数组里。

• 是否需要扩容

在插入元素前会先判断Segment里的HashEntry数组是否超过容量，如果超过阈值，则对数组进行扩容。

Segment的扩容判断比HashMap更恰当，因为HashMap是在插入元素后判断元素是否已经到达容量的，如果到达了就进行扩容，但是很有可能扩容之后没有新元素插入，这时HashMap就进行了一次无效的扩容。

• 如何扩容

在扩容的时候，首先会创建一个容量是原来容量两倍的数组，然后将原数组里的元素进行再散列后插入到新的数组里。为了高效，ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容。

3、size操作

要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量，在多线程场景下虽然相加时可以获取每个Segment的count的最新值，但是可能累加前使用的count发生了变化，统计结果就不准了。所以，最安全的做法是在统计size的时候把所有Segment的put、remove和clean方法全部锁住，但是这种做法显然非常低效。

在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以 ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。

ConcurrentHashMap使用modCount 变量判断在统计的时候容器是否发生了变化，在put、remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。

阻塞队列

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

1、支持阻塞的插入方法

意思是当队列满时，队列会阻塞插入元素的线程，直到队列不满。

2、支持阻塞的移除方法

意思是在队列为空时，获取元素的线程会等待队列变为非空。

阻塞队列常用于生产者和消费者的场景，生产者是向队列里添加元素的线程，消费者是从队列里取元素的线程。阻塞队列就是生产者用来存放元素、消费者用来获取元素的容器。

在阻塞队列不可用时，这两个附加操作提供了4种处理方式。

JDK7提供了7个阻塞队列。

• ArrayBlockingQueue

由数组结构组成的有界阻塞队列，此队列按照先进先出(FIFO)的原则对元素进行排序。

• LinkedBlockingQueue

一个由链表结构组成的有界阻塞队列，此队列的默认和最大长度为 Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。

• PriorityBlockingQueue

一个支持优先级排序的无界阻塞队列。默认情况下元素采取自然顺序升序排列。也可以自定义类实现compareTo()方法来指定元素排序规则，或者初始化 PriorityBlockingQueue时，指定构造参数Comparator来对元素进行排序。需要注意的是不能保证同优先级元素的顺序。

• DelayQueue

一个使用优先级队列实现的无界阻塞队列。队列使用PriorityQueue来实现。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。 只有在延迟期满时才能从队列中提取元素。

大多运用于缓存系统设计或者定时任务调度。 可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询 DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。也可以使用DelayQueue保存当天将会执行的任务和执行时间，一旦从 DelayQueue中获取到任务就开始执行，比如TimerQueue就是使用DelayQueue实现的。

• SynchronousQueue

一个不存储元素的阻塞队列。SynchronousQueue是一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作， 否则不能继续添加元素。

SynchronousQueue可以看成是一个传球手，负责把生产者线程处理的数据直接传递给消费者线程。队列本身并不存储任何元素，非常适合传递性场景。SynchronousQueue的吞吐量高于 LinkedBlockingQueue和ArrayBlockingQueue。

• LinkedTransferQueue

一个由链表结构组成的无界阻塞队列。LinkedTransferQueue是一个由链表结构组成的无界阻塞TransferQueue队列。相对于其他阻塞队列，LinkedTransferQueue多了tryTransfer和transfer方法。

transfer方法可以把生产者传入的元素立刻transfer(传输)给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。

tryTransfer方法是用来试探生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回，而transfer方法是必须等到消费者消费了才返回。

• LinkedBlockingDeque

LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列。所谓双向队列指的是可以从队列的两端插入和移出元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。相比其他的阻塞队列，LinkedBlockingDeque多了addFirst、 addLast、offerFirst、offerLast、peekFirst和peekLast等方法，以First单词结尾的方法，表示插入、 获取(peek)或移除双端队列的第一个元素。以Last单词结尾的方法，表示插入、获取或移除双 端队列的最后一个元素。另外，插入方法add等同于addLast，移除方法remove等效于 removeFirst。但是take方法却等同于takeFirst，不知道是不是JDK的bug，使用时还是用带有First 和Last后缀的方法更清楚。

Fork/Join框架

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

Java并发工具类

CountDownLatch

CountDownLatch允许一个或多个线程等待其他线程完成操作。

CountDownLatch的构造函数接收一个int类型的参数作为计数器，如果想等待N个点完成，就传入N。

当调用CountDownLatch的countDown方法时，N就会减1，CountDownLatch的await方法会阻塞当前线程，直到N变成零。由于countDown方法可以用在任何地方，所以这里说的N个点，可以是N个线程，也可以是1个线程里的N个执行步骤。用在多个线程时，只需要把这个 CountDownLatch的引用传递到线程里即可。

CyclicBarrier

CyclicBarrier是可循环使用的屏障。它让一组线程到达一个屏障(也可以叫同步点)时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。

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

CyclicBarrier可以用于多线程计算数据，最后合并计算结果的场景。

\

CountDownLatch和CyclicBarrier的区别

CountDownLatch的计数器只能使用一次，而CyclicBarrier的计数器可以使用reset()方法重置。

所以CyclicBarrier能处理更为复杂的业务场景。例如，如果计算发生错误，可以重置计数器，并让线程重新执行一次。

CyclicBarrier还提供其他有用的方法，比如getNumberWaiting方法可以获得CyclicBarrier阻塞的线程数量。isBroken()方法用来了解阻塞的线程是否被中断。

Semaphore

Semaphore(信号量)是用来控制同时访问特定资源的线程数量，它通过协调各个线程，以保证合理的使用公共资源。

Semaphore可以用于做流量控制，特别是公用资源有限的应用场景，比如数据库连接。

举例来说，在代码中有30个线程在执行，但是只允许10个并发执行。Semaphore的构造方法 Semaphore(int permits)可以用Semaphore(10)表示最大并发数是10。

Semaphore的用法很简单，首先线程使用 Semaphore的acquire()方法获取一个许可证，使用完之后调用release()方法归还许可证。还可以用tryAcquire()方法尝试获取许可证。

Semaphore还提供一些其他方法，

• intavailablePermits()

返回此信号量中当前可用的许可证数。

• intgetQueueLength()

返回正在等待获取许可证的线程数。

• booleanhasQueuedThreads()

是否有线程正在等待获取许可证。

• void reducePermits(int reduction)

减少reduction个许可证，是个protected方法。

• Collection getQueuedThreads()

返回所有等待获取许可证的线程集合，是个protected方法。

Exchanger

Exchanger(交换者)是一个用于线程间协作的工具类。

Exchanger用于进行线程间的数据交换。它提供一个同步点，在这个同步点，两个线程可以交换彼此的数据。

这两个线程通过 exchange方法交换数据，如果第一个线程先执行exchange()方法，它会一直等待第二个线程也执行exchange方法，当两个线程都到达同步点时，这两个线程就可以交换数据，将本线程生产出来的数据传递给对方。

线程池

实现原理

当提交一个新任务到线程池时，线程池的处理流程：

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

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

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

ThreadPoolExecutor执行execute()方法的示意图

可以用银行办业务来理解

ThreadPoolExecutor执行execute方法分下面4种情况。

1、如果当前运行的线程少于corePoolSize，则创建新线程来执行任务(执行这一步骤需要获取全局锁)。

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

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

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

线程池的使用

创建一个线程池时需要输入几个参数

java new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime,   milliseconds,runnableTaskQueue, handler);

1、corePoolSize(线程池的基本大小)

当提交一个任务到线程池时，线程池会创建一个线程来执行任务，即使其他空闲的基本线程能够执行新任务也会创建线程，等到需要执行的任务数大于线程池基本大小时就不再创建。如果调用了线程池的prestartAllCoreThreads()方法， 线程池会提前创建并启动所有基本线程。

2、runnableTaskQueue(任务队列)

用于保存等待执行的任务的阻塞队列。可以选择以下几个阻塞队列。

• ArrayBlockingQueue

是一个基于数组结构的有界阻塞队列，此队列按FIFO原则对元素进行排序。

• LinkedBlockingQueue

一个基于链表结构的阻塞队列，此队列按FIFO排序元素，吞吐量通常要高于ArrayBlockingQueue。

• SynchronousQueue

一个不存储元素的阻塞队列。每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于Linked-BlockingQueue。

• PriorityBlockingQueue

一个具有优先级的无限阻塞队列。

3、maximumPoolSize(线程池最大数量)

线程池允许创建的最大线程数。如果队列满了，并且已创建的线程数小于最大线程数，则线程池会再创建新的线程执行任务。值得注意的是，如果使用了无界的任务队列这个参数就没什么效果。

4、ThreadFactory

用于设置创建线程的工厂，可以通过线程工厂给每个创建出来的线程设置更有意义的名字。使用开源框架guava提供的ThreadFactoryBuilder可以快速给线程池里的线程设置有意义的名字

5、RejectedExecutionHandler(饱和策略)

当队列和线程池都满了，说明线程池处于饱和状态，那么必须采取一种策略处理提交的新任务。

这个策略默认情况下是AbortPolicy，表示无法处理新任务时抛出异常。

在JDK 1.5中Java线程池框架提供了以下4种策略。

• AbortPolicy

直接抛出异常。

• CallerRunsPolicy

只用调用者所在线程来运行任务。

• DiscardOldestPolicy

丢弃队列里最近的一个任务，并执行当前任务。

• DiscardPolicy

不处理，丢弃掉。

向线程池提交任务

可以使用两个方法向线程池提交任务，分别为execute()和submit()方法。

execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。

submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用get(long timeout，TimeUnit unit)方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

关闭线程池

可以通过调用线程池的shutdown或shutdownNow方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的interrupt方法来中断线程，所以无法响应中断的任务可能永远无法终止。但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表，而 shutdown只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程。

只要调用了这两个关闭方法中的任意一个，isShutdown方法就会返回true。当所有的任务都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用shutdown方法来关闭线程池，如果任务不一定要执行完，则可以调用shutdownNow方法。

合理配置

要想合理地配置线程池，就必须首先分析任务特性，可以从以下几个角度来分析。

1、任务的性质

CPU密集型任务、IO密集型任务和混合型任务。

2、任务的优先级

高、中和低。

3、任务的执行时间

长、中和短。

4、任务的依赖性

是否依赖其他系统资源，如数据库连接。

性质不同的任务可以用不同规模的线程池分开处理。

• CPU密集型任务应配置尽可能小的线程，如配置Ncpu+1个线程的线程池。
• IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如2*Ncpu。
• 混合型的任务，如果可以拆分，将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐量将高于串行执行的吞吐量。如果这两个任务执行时间相差太大，则没必要进行分解。

可以通过 Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数。

Executor框架

在Java中，使用线程来异步执行任务。Java的线程既是工作单元，也是执行机制。从JDK 5开始，把工作单元与执行机制分离开来。工作单元包括Runnable和Callable，而执行机制由Executor框架提供。下图是Executor的任务两级调度模型

Executor框架主要由3大部分组成如下。

1、任务

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

2、任务的执行

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

3、异步计算的结果

包括接口Future和实现Future接口的FutureTask类。

Executor的成员包括ThreadPoolExecutor、ScheduledThreadPoolExecutor、 Future接口、Runnable接口、Callable接口和Executors。

1、ThreadPoolExecutor

ThreadPoolExecutor通常使用工厂类Executors来创建。Executors可以创建3种类型的

SingleThreadExecutor、FixedThreadPool和CachedThreadPool。

FixedThreadPool创建使用固定线程数，适用于为了满足资源管理的需求，而需要限制当前线程数量的应用场景，它适用于负载比较重的服务器。

SingleThreadExecutor使用单个线程。适用于需要保证顺序地执行各个任务，并且在任意时间点，不会有多个线程是活动的应用场景。

CachedThreadPool是大小无界的线程池，适用于执行很多的短期异步任务的小程序，或者是负载较轻的服务器。

2、ScheduledThreadPoolExecutor

Executors可以创建2种类型的ScheduledThreadPoolExecutor，包含若干个线程的ScheduledThreadPoolExecutor和只包含一个线程的ScheduledThreadPoolExecutor。