Java并发编程

控制单元是整个CPU的指挥控制中心，由指令寄存器IR（Instruction Register）、指
令译码器ID（Instruction Decoder）和 操作控制器OC（Operation Controller） 等组
成，对协调整个电脑有序工作极为重要。它根据用户预先编好的程序，依次从存储器中取出
各条指令，放在指令寄存器IR中，通过指令译码（分析）确定应该进行什么操作，然后通过
操作控制器OC，按确定的时序，向相应的部件发出微操作控制信号。操作控制器OC中主要
包括：节拍脉冲发生器、控制矩阵、时钟脉冲发生器、复位电路和启停电路等控制逻辑。

运算单元是运算器的核心。可以执行算术运算（包括加减乘数等基本运算及其附加运
算）和逻辑运算（包括移位、逻辑测试或两个值比较）。相对控制单元而言，运算器接受控
制单元的命令而进行动作，即运算单元所进行的全部操作都是由控制单元发出的控制信号来
指挥的，所以它是执行部件。

存储单元包括 CPU 片内缓存Cache和寄存器组，是 CPU 中暂时存放数据的地方，里
面保存着那些等待处理的数据，或已经处理过的数据，CPU 访问寄存器所用的时间要比访
问内存的时间短。 寄存器是CPU内部的元件，寄存器拥有非常高的读写速度，所以在寄存
器之间的数据传送非常快。采用寄存器，可以减少 CPU 访问内存的次数，从而提高了 CPU
的工作速度。寄存器组可分为专用寄存器和通用寄存器。专用寄存器的作用是固定的，分别
寄存相应的数据；而通用寄存器用途广泛并可由程序员规定其用途。

L1 Cache，分为数据缓存和指令缓存，逻辑核独占

L2 Cache，物理核独占，逻辑核共享

L3 Cache，所有物理核共享

存储器存储空间大小：内存>L3>L2>L1>寄存器；

存储器速度快慢排序：寄存器>L1>L2>L3>内存；

缓存是由最小的存储区块-缓存行(cacheline)组成，缓存行大小通
常为64byte。

缓存行是什么意思呢？

现代操作系统在运行一个程序时，会为其创建一个进程；例如，启动一个Java程序，操作系
统就会创建一个Java进程。进程是OS(操作系统)资源分配的最小单位。

线程是OS(操作系统)调度CPU的最小单元，也叫轻量级进程（Light Weight Process），
在一个进程里可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，
并且能够访问共享的内存变量。CPU在这些线程上高速切换，让使用者感觉到这些线程在同
时执行，即并发的概念，相似的概念还有并行！

1、用户级线程(User-Level Thread)

2、内核线线程(Kernel-Level Thread)

继承Thread

实现Runnable接口

使用ExecutorService

Callable

Future实现带返回结果的多线程

一共有 6 种状态

interupt（线程终止）

通过指令的方式

线程之间相互配合，完成某项工作，比如：一个线程修改了一个对象的值，而另一个线程感知到了变化，然后进行相应的操作，整个过程开始于一个线程，而最终执行又是另一个线程。前者是生产者，后者就是消费者，这种模式隔离了“做什么”（what）和“怎么做”（How），简单的办法是让消费者线程不断地循环检查变量是否符合预期在while循环中设置不满足的条件，如果条件满足则退出while循环，从而完成消费者的工作。却存在如下问题：
1） 难以确保及时性。
2）难以降低开销。如果降低睡眠的时间，比如休眠1毫秒，这样消费者能更加迅速地发现条件变化，但是却可能消耗更多的处理器资源，造成了无端的浪费。

等待/通知机制

实现方式

区别

总结

导致原因

开销

如何减少上下文 切换

1.打开终端或者命令提示符，键入“jps”，（JDK1.5 提供的一个显示当前所有 java进程 pid 的命令），可以获得相应进程的 pid

2.根据上一步骤获得的 pid，继续输入 jstack pid（jstack 是 java 虚拟机自带的一种堆栈跟踪工具。jstack 用于打印出给定的 java 进程 ID 或 core file 或远程调试服务的 Java 堆栈信息）

线程之间共享程序的 公共状态，通过写-读内存中的公共状态进行隐式通信

线程之间通过发送消息 来显示进行通信

CAS 的全称是 Compare And Swap 即比较交换，其算法核心思想如下
函数：CAS(V,E,N) 参数：V 表示要更新的变量 E 预期值 N 新值


如果 V 值等于 E 值，则将 V 的值设为 N。若 V 值和 E 值不同，则说明已经有其他线程做了
更新，则当前线程什么都不做。通俗的理解就是 CAS 操作需要我们提供一个期望值，当期
望值与当前线程的变量值相同时，说明还没线程修改该值，当前线程可以进行修改，也就是
执行 CAS 操作，但如果期望值与当前线程不符，则说明该值已被其他线程修改，此时不执
行更新操作，但可以选择重新读取该变量再尝试再次修改该变量，也可以放弃操作

ABA

循环时间长 开销大

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

阻塞等待队列

共享/独占

公平/非公平

可重入

允许中断

一般通过定义内部类Sync继承AQS

将同步器所有调用都映射到Sync对应的方法

state表示资源的可用状态

State三种访问方式

对于ReentrantLock的实现来说，state可以用来表示当前线程获取锁的可重入的次数

对于读写锁ReentrantReadWriteLock来说，state的高16位表示读状态，也就是获取该读锁的次数；低16位表示获取到写锁的线程的可重入次数；

对于semphore来说，state用来表示当前可用信号的个数；

对于CountDownlatch来说，state用来表示计数器当前的值

Exclusive-独占，只有一个线程能执行，如ReentrantLock

Share-共享，多个线程可以同时执行，如Semaphore/CountDownLatch

同步等待队列

条件等待队列

AQS源码分析

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。

tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。

tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。

tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。

tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

独占、共享

可中断、不可中断

待超时时间的

模板方法模式

首先，确定访问模式。TrinityLock能够在同一时刻支持多个线程的访问，这显然是共享式访问，因此，需要使用同步器提供的acquireShared(int args)方法等和Shared相关的方法，这就要求TwinsLock必须重写tryAcquireShared(int args)方法和tryReleaseShared(int args)方法，这样才能保证同步器的共享式同步状态的获取与释放方法得以执行。

其次，定义资源数。TrinityLock在同一时刻允许至多三个线程的同时访问，表明同步资源数为3，这样可以设置初始状态status为3，当一个线程进行获取，status减1，该线程释放，则status加1，状态的合法范围为0、1和2,3，其中0表示当前已经有3个线程获取了同步资源，此时再有其他线程对同步状态进行获取，该线程只能被阻塞。在同步状态变更时，需要使用compareAndSet(int expect,int update)方法做原子性保障。

最后，组合自定义同步器。前面的章节提到，自定义同步组件通过组合自定义同步器来完成同步功能，一般情况下自定义同步器会被定义为自定义同步组件的内部类。

synchronized 同时只能与一个共享变量的notify或wait方法实现同步，而AQS的一个锁可以对应多个条件变量。

Unsafe提供的API大致可分为内存操作、CAS、Class相关、对象操作、线程调度、系统信息获取、内存屏障、数组操作等几类

内存操作

CAS

Class相关

对象操作

数组相关

内存屏障

系统相关

线程调度

阻塞线程

解除阻塞线程

LockSupport 主要是针对 Thread 进进行阻塞处理，可以指定阻塞队列的目标对象，每次可以指定具体的线程唤醒

Object.wait() 是以对象为纬度，阻塞当前的线程和唤醒单个（随机）或者所有线程。

LockSupport 阻塞和解除阻塞线程直接操作的是 Thread。而 Object 的 wait/notify 并不是直接对线程操作，是被动的方法，需要一个 Object 来进行线程的挂起或唤醒。

Thead 在调用 wait 之前，当前线程必须先获得该对象的监视器（syschronized），被唤醒之后需要重新获取到监视器才能继续执行。而 LockSupport 可以随意进行 park 或者 unpark。 

主要存储的是Java实例对象，所有线程创建的 实例对象都存放在主存中，不管该实例对象时成员边浪还是方法中的本地变量，当然还包含共享的类信息、常量、静态 变量。由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。

主要存储当前方法的所有本地变量(工作内存中存储着主内存中的变量副本拷贝),每个线程只能访问自己的工作内存，即线程中的本地变量对其他线程是不可见的，就算是两个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。

由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。

根据JVM 虚拟机规范主内存与工作内存的数据存储类型以及操作方式，对于一个实例对象中的成员方法而言，如果方法中包含本地变量是基本类型，将直接存储在工作内存的栈帧结构中，但倘若本地变量是引用类型，那么该变量的引用会存储在工作内存的栈帧中，而对象实例将存储在主内存(共享内存区域，堆中)。

但对于实例对象的成员变量，不管它是基本数据类型或者包装类型还是引用类型，都会存储在堆中

至于static变量以及类本身相关信息将会存储在主内存中。

在主内存中的实例对象可以被多线程共享，倘若两个线程同时调用了同一对象的同一方法，那么两条线程会将要操作的数据拷贝一份到自己的工作内存中，执行完成操作后才刷新到主内存中。

假设主内存中存在一个共享变量X，现在有A和B两条线程分别对该变量x=1进行操作，A和B线程各自在自己的工作内存中存在共享变量副本X.

假设现在A线程想要修改x的值 为2，而B线程却想要读取X的值，那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢？答案是不确定，即B线程 有可能读取到A线程更新前的值1，也有可能读取到A 线程更新后的值2，这是因为工作内存是每个线程私有的数据区域，而线程A变量x时，首先是讲变量从主内存拷贝到A线程的工作内存中，然后对变量进行操作，操作完成 后再将变量X写回主内存中，而对于B线程也是类似，这样就有可能造成主内存与工作内存间数据存在不一致性问题。

假设A线程修改完成后正在将数据写回主内存，而B线程此时正在读取主内存，即将x=1拷贝到自己的工作呢次云中，这样B线程读取的值就是x=1,但如果A线程已将x=2写回主内存后，B线程才开始读取的话，那么此时B线程读取的就是x=2，但到底是哪种情况先发生呢？

read(读取），从主内存读取数据

load(载入）：将主内存读取到的数据写入到工作内存

use(使用）： 从工作内存读取数据来计算

assign（赋值）：将计算好的值重新赋值到工作内存中

store(存储）：将工作内存数据写入主内存

write(写入):将store过去的变量值赋值给主内存中的变量

lock(锁定）：将主内存变量加锁，标识为线程 独占状态

unlock(解锁）:将主内存变量解锁，解锁后其他线程可以锁定该变量

CPU在摩尔定律的指导下以每18个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及CPU。这就造成了高性能能的内存和硬盘价格及其昂贵。然而CPU的高度运算需要高速的数据。为了解决这个问题，CPU厂商在CPU中内置了少量的高速缓存以解决I\O速度和CPU运算速度之间的不匹配问题。
在CPU访问存储设备时，无论是存取数据抑或存取指令，都趋于聚集在一片连续的区域中，这就被称为局部性原理。

时间局部 性

空间局部性

由于CPU的运算速度超越了1级缓存的数据I\O能力，CPU厂商又引入了多级的缓存结构。

MESI协议缓存状态

MESI状态转换

多核缓存协同操作

缓存行伪共享

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说
如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能
是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可

可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。

但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。

有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象

除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。

volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。

synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。

通过volatile可以保证有序性

可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性

JVM能根据处理器特征适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器特性。

initFlag加上volatile关键字

initFlag不加volatile关键字

Intel硬件提供了一系列的内存屏障

LoadLoad

StoreStore

LoadStore

StoreLoad

是一个CPU指令，作用有两个

由于编译器和处理器都能执行指令重排序，如果在指令间插入一条Memory barrier则会告诉编译器和CPU，不管什么指令都不能和 这条Memory  Barrier指令重排序 ，也就是说通过插入内存屏障禁止再内存屏障前后的指令执行重排序优化。

Memory Barrier的另外一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能 读取到 这些数据 的 最新版本。

双重加锁单例模式代码

重排序对多线程的影响

volatile重排序的规则表

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略。

volatile写插入内存屏障后生成的指令序列示意图

volatile读插入内存屏障

示例

支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁

实现重进入需要解决的2个问题

悲观锁

乐观锁

公平锁

非公平锁

独占锁

共享锁

实现缓存

实现分析

•  synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，，内置锁的并发性能已经基本与Lock持平。

    synchronized关键字被编译成字节码后会被翻译成monitorenter 和 monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。

每个同步对象都有一个自己的Monitor(监视器锁)，加锁过程如下图所示：

Monitor监视器锁

对象的内存布局 分为三块区域

普通方法，锁的是当前实例对象

静态同步方法，锁的 是当前类的class对象

同步方法块，锁的是括号里的 对象

锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁

随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级到重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。

从JDK1.6中默认是开启偏向锁和轻量级锁的，可以通过-XX:-UseBiasedLocking来禁用偏向锁

偏向锁

轻量级锁

自旋锁

锁消除

使用逃逸分析，编译器可以对代码做如下优化：

是不是所有的对象和数组都会在堆内存分配空间？

wait和notify 为什么需要在synchronized里面

oop.hpp，每个 Java Object 在 JVM 内部都有一个 native 的 C++ 对象 oop/oopDesc 与之对应。先在oop.hpp中看
oopDesc的定义

_mark 被声明在 oopDesc 类的顶部，所以这个 _mark 可以认为是一个 头部, 前面我们讲过头部保存了一些重要的
状态和标识信息，在markOop.hpp文件中有一些注释说明markOop的内存布局

ReentrantLock是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于synchronized是一种互斥锁，可以保证线程安全。而且它具有比synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。

ReentrantLock如何实现synchronized不具备的公平与非公平性呢？

实现重进入

公平锁

非公平锁

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

除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构，它大部分时间提供读服务（例如查询和搜索），而写操作占有的时间很少，但是写操作完成之后的更新需要对后续的读服务可见。

在没有读写锁支持的（Java 5之前）时候，如果需要完成上述工作就要使用Java的等待通知机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后，所有等待的读操作才能继续执行（写操作之间依靠synchronized关键进行同步），这样做的目的是使读操作能读取到正确的数据，不会出现脏读。改用读写锁实现上述功能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续（非当前写操作线程）的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，编程方式相对于使用等待通知机制的实现方式而言，变得简单明了。

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

使用ReentrantReadWriteLock实现缓存

源代码分析

Condition接口提供了类似Object的 监视器方法，与Lock配合可以实现等待/通知模式

理解Condition 和 条件变量

Condition使用范式

实现

数组+锁实现

链表+锁实现

堆 + 锁

PriorityQueue + 锁

ReentrantLock

Condition

在线程池中有比较多的应用，生产者消费者场景

基于ReentrantLock保证线程安全，根据Condition实现队列满时的阻塞

构造方法

blockingQueue 的容量将设置为 Integer.MAX_VALUE 。

ReentrantLock + Condition

二叉堆 

BlockingQueue<String> blockingQueue = new DelayQueue();

入队的对象必须要实现Delayed接口,而Delayed集成自Comparable接口

对缓存超时的数据进行移除

任务超时处理（例如订单超时，
饿了么订餐：下单后60s之后给用户发送短信通知））

空闲连接的关闭

1.使用阻塞算法

2.使用非阻塞算法

入队列

出队列

cyclicBarrier.await();

多线程结果的合并的操作，用于多线程计算数据，最后合并计算结果的应用场景

可以用于多线程计算数据，最后合并计算结果的场景。例如，用一个Excel保存了用户所有银行流水，每个Sheet保存一个账户近一年的每笔银行流水，现在需要统计用户的日均银行流水，先用多线程处理每个sheet里的银行流水，都执行完之后，得到每个sheet的日均银行流水，最后，再用barrierAction用这些线程的计算结果，计算出整个Excel的日均银行流水。

CountDownLatch 的作用是允许1或者N个线程等待其他线程 完成执行；而CyclicBarrier则是允许N个线程相互等待。

CountDownLatch的计数器无法重置；CyclicBarrier的计数器可以被重置后使用，因此它被 称为是循环的barrier。

CountDownLatch.countDown()

CountDownLatch.await();

Zookeeper分布式锁,Jmeter模拟高并发等

实现最大的并行性：有时我们想同时启动多个线程，实现最大程度的并行性。例如，我们想测试一个单例类。如果我们创建一个初始计数为1的CountDownLatch，并让所有线程都在这个锁上等待，那么我们可以很轻松地完成测试。我们只需调用 一次countDown()方法就可以让所有的等待线程同时恢复执行。

确保某个计算在其需要的所有资源都被初始化之后才执行

确保某个服务在其依赖的所有其他服务都已经启动之后才启动

等待直到每个操作的所有参与者都就绪再执行（比如打麻将时需要等待四个玩家就绪） 

主线程中启动多个线程去执行任务，
并且主线程需要等待所有子线程执行完毕后去汇总

调用子线程的join方法后，该线程会一直被阻塞直到子线程运行完毕，而CountDownLatch则使用计数器来允许子线程运行完毕或者在运行中递减计数，也就是CountDownLatch可以在子线程运行的 任何 时候让await方法返回而不一定必须等到线程结束，

使用线程池来管理线程时一般都是直接添加Runable线程池，这时候就没有办法再调用线程的join方法了，就是说countDownLatch相比join方法让我们对线程同步有更灵活的控制。

构造方法

重要方法

资源访问，服务限流(Hystrix里限流就有基于信号量方式)。

流量控制

一个数据库连接池的实现

挂起和唤醒线程

是一个简单的代理类，里面的代码都是使用Unsafe类里面的方法

阻塞线程

解除阻塞线程

LockSupport 主要是针对 Thread 进进行阻塞处理，可以指定阻塞队列的目标对象，每次可以指定具体的线程唤醒

Object.wait() 是以对象为纬度，阻塞当前的线程和唤醒单个（随机）或者所有线程。

LockSupport 阻塞和解除阻塞线程直接操作的是 Thread。而 Object 的 wait/notify 并不是直接对线程操作，是被动的方法，需要一个 Object 来进行线程的挂起或唤醒。

Thead 在调用 wait 之前，当前线程必须先获得该对象的监视器（syschronized），被唤醒之后需要重新获取到监视器才能继续执行。而 LockSupport 可以随意进行 park 或者 unpark。

Executor是一个接口，它是Executor框架的基础，它将任务的提交与任务的执行分离开来。

ExecutorService接口继承了Executor，在其上做了一些shutdown()、submit()的扩展，可以说是真正的线程池接口；

AbstractExecutorService抽象类实现了ExecutorService接口中的大部分方法；

ThreadPoolExecutor是线程池的核心实现类，用来执行被提交的任务。

ScheduledExecutorService接口继承了ExecutorService接口，提供了带"周期执行"功能ExecutorService；

ScheduledThreadPoolExecutor是一个实现类，可以在给定的延迟后运行命令，或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活，功能更强大。

execute（Runnable command）：履行Ruannable类型的任务

submit（task）：可用来提交Callable或Runnable任务，并返回代表此任务的Future
对象

shutdown（）：在完成已提交的任务后封闭办事，不再接管新任务,

shutdownNow（）：停止所有正在履行的任务并封闭办事

isTerminated（）：测试是否所有任务都履行完毕了。

isShutdown（）：测试是否该ExecutorService已被关闭

任务

任务的执行

异步计算的结果

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

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

3、如果无法将任务将入BlockingQueue（队列已满），则创建新的线程来处理任务(需获取全局锁)

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

public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) 

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

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

corePoolSize

maximumPoolSize

keepAliveTime

unit

workQueue

threadFactory

handler

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

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

可以监控以下属性

监控的代码示例

public ScheduledFuture schedule(Runnable command, long delay, TimeUnit unit)

//向定时任务线程池提交一个延时Runnable任务（仅执行一次）
public ScheduledFuture schedule(Callable callable, long delay, TimeUnit unit);

//向定时任务线程池提交一个延时的Callable任务（仅执行一次）
public ScheduledFuture scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit)

//向定时任务线程池提交一个固定时间间隔执行的任务
public ScheduledFuture scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit);

//向定时任务线程池提交一个固定延时间隔执行的任务

固定时间间隔的任务不论每次任务花费多少时间，下次任务开始执行时间从理论上讲是确定的，当然执行任务的时间不能超过执行周期。

固定延时间隔的任务是指每次执行完任务以后都延时一个固定的时间。由于操作系统调度以及每次任务执行的语句可能不同，所以每次任务执行所花费的时间是不确定的，也就导致了每次任务的执行周期存在一定的波动。

scheduleAtFixedRate中，若任务处理时长超出设置的定时频率时长，本次任务执行完才开始下次任务，下次任务已经处于超时状态，会马上开始执行。

若任务处理时长小于定时频率时长，任务执行完后，定时器等待，下次任务会在定时器等待频率时长后执行。

设置定时任务每60s执行一次，那么从理论上应该第一次任务在第0s开始,第二次任务在第60s开始，第三次任务在120s开始，但实际运行时第一次任务时长80s，第二次任务时长30s，第三次任务时长50s，则实际运行结果为：

任务的性质

任务的优先级

任务的时间执行长短

任务的依赖性

获取CPU个数

创建使用固定线程数的FixedThreadPool的API。适用于为了满足资源管理的需求，而需要限制当前线程数量的应用场景，它适用于负载比较重的服务器。FixedThreadPool的corePoolSize和maximumPoolSize都被设置为创建FixedThreadPool时指定的参数nThreads。

当线程池中的线程数大于corePoolSize时，keepAliveTime为多余的空闲线程等待新任务的

最长时间，超过这个时间后多余的线程将被终止。这里把keepAliveTime设置为0L，意味着多余的空闲线程会被立即终止。

FixedThreadPool使用有界队列LinkedBlockingQueue作为线程池的工作队列（队列的容量为Integer.MAX_VALUE）。

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

corePoolSize和maximumPoolSize被设置为1。其他参数与FixedThreadPool相同。SingleThreadExecutor使用有界队列LinkedBlockingQueue作为线程池的工作队列（队列的容量为Integer.MAX_VALUE）。

创建一个会根据需要创建新线程的CachedThreadPool的API。大小无界的线程池，适用于执行很多的短期异步任务的小程序，或者是负载较轻的服务器。

corePoolSize被设置为0，即corePool为空；maximumPoolSize被设置为Integer.MAX_VALUE。这里把keepAliveTime设置为60L，意味着CachedThreadPool中的空闲线程等待新任务的最长时间为60秒，空闲线程超过60秒后将会被终止。

FixedThreadPool和SingleThreadExecutor使用有界队列LinkedBlockingQueue作为线程池的工作队列。CachedThreadPool使用没有容量的SynchronousQueue作为线程池的工作队列，但CachedThreadPool的maximumPool是无界的。这意味着，如果主线程提交任务的速度高于maximumPool中线程处理任务的速度时，CachedThreadPool会不断创建新线程。极端情况下，CachedThreadPool会因为创建过多线程而耗尽CPU和内存资源。

使用工厂类Executors来创建。Executors可以创建2种类型的ScheduledThreadPoolExecutor，如下。

ScheduledThreadPoolExecutor适用于需要多个后台线程执行周期任务，同时为了满足资源管理的需求而需要限制后台线程的数量的应用场景。

SingleThreadScheduledExecutor适用于需要单个后台线程执行周期任务，同时需要保证顺序地执行各个任务的应用场景。

使用方法一，自己创建一个集合来保存Future存根并循环调用其返回结果的时候，主线程并不能保证首先获得的是最先完成任务的线程返回值。它只是按加入线程池的顺序返回。因为take方法是阻塞方法，后面的任务完成了，前面的任务却没有完成，主程序就那样等待在那儿，只到前面的完成了，它才知道原来后面的也完成了。

使用方法二，使用CompletionService来维护处理线程不的返回结果时，主线程总是能够拿到最先完成的任务的返回值，而不管它们加入线程池的顺序。

Future模式实现方式

未启动

已启动

已完成

当一个线程需要等待另外一个线程把某个任务执行完后它才能继续被执行，此时可以使用FutureTask。

假设有多个线程执行 若干任务，每个任务最多只能被执行一次。当多个线程试图同时执行同一个任务时，只允许一个线程执行任务，其他线程需要等待这个任务执行完后才能继续执行。

Cache line

Compare and Swap

CPU pipeline

Memory order violation

首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的，但是复杂的内存操作处理器不能自动保证其原子性，比如跨总线宽度，跨多个缓存行，跨页表的访问。但是处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。

第一个机制是通过总线锁保证原子性。如果多个处理器同时对共享变量进行读改写（i++就是经典的读改写操作）操作，那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致，举个例子：如果i=1,我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2。如下图

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

第二个机制是通过缓存锁定保证原子性。在同一时刻我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把CPU和内存之间通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。

频繁使用的内存会缓存在处理器的L1，L2和L3高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，在奔腾6和最近的处理器中可以使用“缓存锁定”的方式来实现复杂的原子性。所谓“缓存锁定”就是如果缓存在处理器缓存行中内存区域在LOCK操作期间被锁定，当它执行锁操作回写内存时，处理器不在总线上声言LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时会起缓存行无效，在例1中，当CPU1修改缓存行中的i时使用缓存锁定，那么CPU2就不能同时缓存了i的缓存行。

但是有两种情况下处理器不会使用缓存锁定。第一种情况是：当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line），则处理器会调用总线锁定。第二种情况是：有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。

以上两个机制我们可以通过Inter处理器提供了很多LOCK前缀的指令来实现。比如位测试和修改指令BTS，BTR，BTC，交换指令XADD，CMPXCHG和其他一些操作数和逻辑指令，比如ADD（加），OR（或）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。

基本类：AtomicInteger、AtomicLong、AtomicBoolean；

引用类型：AtomicReference、AtomicReference的ABA实例、AtomicStampedRerence、AtomicMarkableReference；

数组类型：AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

属性原子修改器（Updater）：AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater

用于通过原子的方式更新基本类型，Atomic包提供了以下三个类

AtomicInteger的常用方法如下

Atomic包提供了三种基本类型的原子更新，但是Java的基本类型里还有char，float和double等。那么问题来了，如何原子的更新其他的基本类型呢？Atomic包里的类基本都是使用Unsafe实现的，Unsafe只提供了三种CAS方法，compareAndSwapObject，compareAndSwapInt和compareAndSwapLong，再看AtomicBoolean源码，发现其是先把Boolean转换成整型，再使用compareAndSwapInt进行CAS，所以原子更新double也可以用类似的思路来实现。

通过原子的方式更新数组里的某个元素，Atomic包提供了以下三个类

其常用方法如下

原子更新基本类型的AtomicInteger，只能更新一个变量，如果要原子的更新多个变量，就需要使用这个原子更新引用类型提供的类。

Atomic包提供了以下三个类：

如果我们只需要某个类里的某个字段，那么就需要使用原子更新字段类

Atomic包提供了以下三个类

原子更新字段类都是抽象类，每次使用都时候必须使用静态方法newUpdater创建一个更新器。原子更新类的字段的必须使用public volatile修饰符

数组+链表+(红黑树jdk>=8)

基于ReentrantLock实现分段锁

分段锁+CAS保证线程安全

在1.7下的实现

在1.8下的实现

读写分离，空间换时间，避免为保证并发安全导致的激烈的锁竞争。

1、CopyOnWrite适用于读多写少的情况，最大程度的提高读的效率；

2、CopyOnWrite是最终一致性，在写的过程中，原有的读的数据是不会发生更新的，只有新的读才能读到最新数据；

3、如何使其他线程能够及时读到新的数据，需要使用volatile变量；

4、写的时候不能并发写，需要对写操作进行加锁；

CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，假如我们有一个搜索网站，用户在这个网站的搜索框中，输入关键字搜索内容，但是某些关键字不允许被搜索。这些不能被搜索的关键字会被放在一个黑名单当中，黑名单每天晚上更新一次。当用户搜索时，会检查当前关键字在不在黑名单当中，如果在，则提示不能搜索。实现代码如下：

内存占用问题

数据一致性问题

JDK中并没有提供CopyOnWriteMap，我们可以参考CopyOnWriteArrayList来实现一个

二分查找和AVL树查找

什么是跳表

ConcurrentSkipListMap和TreeMap的不同

ConcurrentSkipListMap 和 ConcurrentHashMap 不不同

void set(Object value)

public Object get()

public void remove()

protected Object initialValue()

代码

存储结构

ThreadLocal的核心机制

ThreadLocalMap

set方法

get方法

remove()方法

ThreadLocal 在 ThreadLocalMap 中是以一个弱引用身份被Entry中的Key引用的，因此如果ThreadLocal没有外部强引用来引用它，那么ThreadLocal会在下次JVM垃圾收集时被回收。这个时候就会出现Entry中Key已经被回收，出现一个null Key的情况，外部读取ThreadLocalMap中的元素是无法通过null Key来找到Value的。因此如果当前线程的生命周期很长，一直存在，那么其内部的ThreadLocalMap对象也一直生存下来，这些null key就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，这条强引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。

但是JVM团队已经考虑到这样的情况，并做了一些措施来保证ThreadLocal尽量不会内存泄漏：在ThreadLocal的get()、set()、remove()方法调用的时候会清除掉线程ThreadLocalMap中所有Entry中Key为null的Value，并将整个Entry设置为null，利于下次内存
由于ThreadLocalMap的key是弱引用，而Value是强引用。这就导致了一个问题，ThreadLocal在没有外部对象强引用时，发生GC时弱引用Key会被回收，而Value不会回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。

我们先看看ThreadLocal的get方法的底层实现

既然Key是弱引用，那么我们要做的事，就是在调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots分析后就变成不可达了，下次GC的时候就可以被回收。

如果使用ThreadLocal的set方法之后，没有显示的调用remove方法，就有可能发生内存泄露，所以养成良好的编程习惯十分重要，使用完ThreadLocal之后，记得调用remove方法。

key 使用强引用：引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。

key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

为什么每个线程都输出5？难道他们没有独自保存自己的Number副本吗？为什么其他线程还是能够修改这个值？仔细考察ThreadLocal和Thead的代码，我们发现ThreadLocalMap中保存的其实是对象的一个引用，这样的话，当有其他线程对这个引用指向的对象实例做修改时，其实也同时影响了所有的线程持有的对象引用所指向的同一个对象实例。这也就是为什么上面的程序为什么会输出一样的结果：5个线程中保存的是同一Number对象的引用，在线程睡眠的时候，其他线程将num变量进行了修改，而修改的对象Number的实例是同一份，因此它们最终输出的结果是相同的。
而上面的程序要正常的工作，应该的用法是让每个线程中的ThreadLocal都应该持有一个新的Number对象。

基本思想

步骤

在分治法中，子问题一般是相互独立的，因此，经常通过递归调用算法来求解子问题。

典型 应用

ForkJoinPool 不是为了替代 ExecutorService，而是它的补充，在某些应用场景下性能比 ExecutorService 更好

ForkJoinPool 主要用于实现“分而治之”的算法，特别是分治之后递归调用的函数，例如 quick sort 等

ForkJoinPool 最适合的是计算密集型的任务，如果存在 I/O，线程间同步，sleep() 等会造成线程长时间阻塞的情况时，最好配
合使用 ManagedBlocker。

指某个线程从其他队列里窃取任务来执行

我们需要做一个比较大的任务，我们可以把这个任务分割为若干互不依赖的子任务，为了减少线程间的竞争，于是把些子任务分别放到不同的队列里，并为每个队列创建一个单独的线程来执行队列里的任务，线程和队列一一对应，比如A线程负责处理A队列里的任务。
但是有的线程会先把自己队列里的任务干完，而其他线程对应的队列里还有任务等待处理。干完活的线程与其等着，不如去帮其他线程干活，于是它就去其他线程的队列里窃取一个任务来执行。而在这时它们会访问同一个队列，所以为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务的线程永远从双端队列的尾部拿任务执行。

优点

ForkJoinTask：我们要使用 ForkJoin 框架，必须首先创建一个 ForkJoin 任务。它提供在任务中执行 fork() 和 join() 操作的机制，通常情况下我们不需要直接继承 ForkJoinTask 类，而只需要继承它的子类，Fork/Join 框架提供了以下两个子类：

RecursiveAction：用于没有返回结果的任务。(比如写数据到磁盘，然后就退出了。 一个RecursiveAction可以把自己的工作分割成更小的几块， 这样它们可以由独立的线程或者CPU执行。 我们可以通过继承来实现一个RecursiveAction)

RecursiveTask ：用于有返回结果的任务。(可以将自己的工作分割为若干更小任务，并将这些子任务的执行合并到一个集体结果。可以有几个水平的分割和合并)

CountedCompleter： 在任务完成执行后会触发执行一个自定义的钩子函数

ForkJoinPool ：ForkJoinTask 需要通过 ForkJoinPool 来执行，任务分割出的子任务会添加到当前工作线程所维护的双端队列中，进入队列的头部。当一个工作线程的队列里暂时没有任务时，它会随机从其他工作线程的队列的尾部获取一个任务

主要用于实现“分而治之”的算法，特别是分治之后递归调用的函数

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

与ThreadPool共存，并不是要替换ThreadPool

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
numbers.parallelStream() .forEach(out::println);

内部就是采用ForkJoinPool

ForkJoinPool 实现ForkJoin的线程池 - ThreadPoo

ForkJoinTask<V> 一个描述ForkJoin的抽象类 Runnable/Callable

ForkJoinTask封装了数据及其相应的计算

ForkJoinTask比线程要轻量

ForkJoinTask主要包括两个方法分别实现任务的分拆与合并

ForkJoinPool中的所有的工作线程均有一个自己的工作队列WorkQueue

ForkJoinTask中fork的子任务，将放入运行该任务的工作线程的队头

为了最大化CPU利用率，空闲的线程将从其他线程的队列中“窃取”任务来执行

WorkQueue双端队列最小化任务“窃取”的竞争

最适合的是计算密集型的任务

在需要阻塞工作线程时，可以使用 ManagedBlocker。是否内联方法

不应该在RecursiveTask<R>的内部使用ForkJoinPool.invoke()

ForkJoinPool 中的任务执行分两种

Fork/Join使用的标准范式

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

随机生成2000w条数据在数组当中，然后求和

每次使用时new一个SimpleDateFormat 的 实例，这样可以保证每个实例使用自己的Calendar实例，但是每次使用都需要new一个对象，并且使用后由于没有其他引用，又需要回收，开销会很大。

可以使用syncheronized 对SimpleDtaFormat实例进行同步

使用ThreadLocl,这样每个线程只需要使用一个SimpleDateFormate实例，这相比第一种方式 节省了对象的创建销毁开销，并且不需要使多个线程同步。

在Thread类中，关于处理运行时异常API总共有四个

UncaughtExceptionHandler介绍

代码演示

Hook线程介绍

ThreadHook

在我们的开发中 经常会遇到Hook线程，比如为了防止某个程序被重复启动，在进程启动时 会创建一个lock文件，进程收到中断信号的 时候会删除这个lock文件，我们在mysql服务器、zookeeper/kafka 等系统中都能看到lock文件的存在。

代码演示

Hook线程只有在收到退出信号的时候会被执行，如果在kill的时候使用了参数-9, 那么Hook线程不会得到执行，进程将会立即退出，因此.lock文件将得不到清理。

Hook线程中也可以执行一些资源释放的工作，比如关闭文件句柄、socket链接、数据库connection等。

尽量不要再Hook线程中执行一些耗时长的操作，因为其会导致程序迟迟不会退出。

要new一个FutureTask的实例，有两种方法

架构设计、软件开发

开发管理

沟通协调

作用

效果

职责

考试组

题库组

共同痛点

提高性能，采用多线程，屏蔽细节

每个批量任务拥有自己的上下文环境

自动清除已完成和过期任务 

具体实现-可查询进度的并发任务执行框架

1、用户业务方法的结果？

2、如何执行用户的业务方法？

3、用户如何提交他的工作和查询任务进度？

4、框架的主体类

单体代码

和Spring集成代码

考试后从题库中抽取题目生成大量的离线练习册文档并打印

题目在数据库中存储形式，平均长度800字节：

下图是Diameter协议中的那部分？《img src = "001.jpg"》

一份PDF文档的生成平均时长在50~55秒左右

为什么慢?
一份离线练习册的生成过程

第一版：单web

第二版：服务化

改进

如何继续改进

解决方案

性能优化一定要建立在对业务的深入分析上，比如我们在性能优化的切入点，在缓存数据结构的选择就建立在对业务的深入理解上；

性能优化要善于利用语言的高并发特性，

性能优化多多利用缓存，异步任务等机制，正是因为我们使用这些特性和机制，才让我们的应用在性能上有个了质的飞跃；

引入各种机制的同时要注意避免带来新的不安全因素和瓶颈，比如说缓存数据过期的问题，并发时的线程安全问题，都是需要我们去克服和解决的。