一、概述
多任务处理的原因：计算机的运行速度与它的存储和通信子系统速度的差距太大，大量的时间都花费在磁盘I/O、网络通信或者数据库访问上。为了不让处理器大部分的时间都处于等待其他资源的状态，就可以让计算机同时处理几项任务。
一个服务端同时对多个客户端提供服务：每秒事务处理数是衡量一个服务器好坏的重要指标。对于计算量相同的任务，程序线程并发协调得越有条不紊，效率自然就越高；反之，线程之间频繁阻塞，甚至产生死锁，将会大大降低程序的并发能力。
二、硬件的效率与一致性
1、高速缓存：作为内存和处理器之间的一层缓冲，很好地解决了处理与内存的速度矛盾。
2、缓存一致性：当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致的问题。
3、内存模型：在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机可以拥有不同的内存模型，而Java虚拟机也拥有自己的内存模型。
4、指令重排序优化（乱序执行优化）：为了使得处理器内部的运算单元能够尽量被充分利用，处理器可能会对输入的代码进行指令重排序优化，保证该结果与顺序执行的结构是一致的，但是并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致。因此如果存在一个计算机任务依赖另一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。（只能保证最终结果无误）
三、Java内存模型
目的：屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。（在此之前，主流程序语言直接使用物理硬件和操作系统的内存模型，因此可能会出现程序在一套平台上并发完全正常，而在另一套平台上并发访问却经常出错的问题）
1、主内存和工作内存
对应物理机中的主存和高速缓冲
1.1.Java内存模型的主要目的：定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量只包括实例字段、静态字段和构成数组对象的元素，不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不会存在竞争问题。
1.2.Java内存与物理硬件的内存相似
每条线程都有自己的工作内存，里面保存了被该线程使用到的变量的主内存拷贝副本。线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。
注意：这里所讲的主内存和工作内存和Java内存区域中的Java堆、栈、方法区等不适同一个层次的内存划分。这两者基本没有关系。如果硬要勉强对应起来。那主内存主要对应于Java堆中的对象实例部分，而工作内存则对应于虚拟机栈中的部分区域。从更低层次上说，主内存就直接对应于物理硬件的内存，虚拟机可能会让工作内存优先存储于寄存器和高速缓冲中。
2、内存间交互操作
关于主内存和工作内存之间的交互协议，Java内存模型定义了以下8中操作来完成，虚拟机实现时必须保证以下的每一种操作都是原子的、不可再分的。
load（线程独占）、unlock（将变量从锁定状态释放出来）、read（把变量值从内存读取出来传给工作内存）、load（把read指令读取出来的变量值放入到工作内存的变量副本中）、use（把工作内存中的一个变量传递给执行引擎）、assign（把执行引擎中的一个变量值赋给工作内存）、store（从工作内存获取一个变量值传到主内存中）、write（把store指令读出来的变量值放入到主内存的变量中）
Java内存模型规定了执行以上8中基本操作时必须满足的8条规则：
#不允许read和load、store和write操作之一单独出现。并且它们要顺序执行（注意可以不连续执行）
#不允许一个线程丢弃它的assign操作，即变量在工作内存中改变了之后就必须把该变化同步回主内存
#不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存
#一个变量只能在主内存中“诞生”
#一个变量在同一时刻只允许一条线程对其进行lock操作，但是lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同数量的unlock才能解锁
#如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量之前，需要重新执行load或assign操作初始化变量的值
#如果一个变量实现没有被lock锁定，那就不允许对它进行unlock操作，也不允许去unlock一个被其他线程锁定住的变量
#对一个变量执行unlock之前，必须先把此变量同步回主内存中。
3、对于volatile型变量的特殊规则——volatile给变量带来的两种特性
3.1.特性一——保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对其他线程来说是可以立即得知的。
但是由于Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。
代码清单：
package Thread;
public class VolatileTest {
public static volatile int race = 0;
public static void increase(){
race++;
}
private static final int THREAD_COUNT = 20;
public static void main(String[] args){
Thread[] threads =new Thread[THREAD_COUNT];
for(int i=0;i<THREAD_COUNT;i++){
threads[i] =new Thread(new Runnable(){
@Override
public void run() {
for(int i = 0;i< 10000;i++){
increase();
}
}
});
threads[i].start();
}
System.out.println(race);
}
}
运行结果：
这段代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果这段代码能够正确并发的话，输出的结果应该是200000，但是我们会发现输出的值远小于200000。
结果分析：
我们发现volatile关键字并不能保证运算过程的安全性。我们来看一下它的字节码。
只有一行代码的increase()方法在被加载为字节码时分解成了四条字节码指令（也就是该操作不是原子的）。当getstatic指令把race的值取到操作数栈顶时，volatile关键字保证了race的值在此时是正确的。但是在执行iconst_1,iadd这些指令的时候，其它的线程可能已经把race的值加大了，而在操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存之中。（即使只有一条字节码也并不意味着这条指令就是一个原子操作，一条字节码在解释执行时，解释器将要运行许多代码才能实现它的语义；如果是编译执行，一条字节码指令也可能转化为若干条本地机器码指令）
3.2.volatile适用的场景
需满足以下两条规则
#运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
#变量不需要与其他的状态变量共同参与不变约束
若不满足，我们仍然需要通过加锁（使用syncronized或java.util.concurrent中的原子类）来保证原子性。（也就是把increase()方法编译出来的指令固定为一个原子操作，不可再分）。——也就是只有一个线程完成了increase()方法中的所有指令，才允许其他线程对这个变量进行操作。
3.3.特性二——禁止指令重排序
实现方式——添加lock指令（相当于一层内存屏障，指令排序时不能把后面的指令重排序到内存屏障之前的位置）
lock前缀的作用：使得本线程的Cache写入了内存，该写入动作也会引起别的线程无效化其Cache，所以通过这样一个空操作，可以让前面volatile变量的修改对其他的线程立即可见。
指令重排序的定义：指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。但并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保障程序能够得出正确的执行结果。
4、对double和long型变量的特殊规则
long和double的非原子性规定。在实际开发中，目前各种商用虚拟机都太选择把64位数据的读写操作作为原子操作来对待。
5、原子性、可见性与有序性
5.1.原子性：
我们大致可以认为基本数据类型的读写操作时具备原子性的。
如果应用场景需要一个更大范围的原子性保证，Java内存还提供了lock和unlock操作来满足这种需求（也就是syncronized关键字）
5.2.可见性：
当一个线程修改了共享变量的值时，其它线程能够立即得知这个修改。
普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。普通变量则不能保证这一点。
syncronized同步块的可见性：是由“对一个变量执行unlock之前，必须先把这个变量同步回到主内存中”实现了。
final关键字的可见性：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去，那在其它线程中就能看见final字段的值。
5.3.有序性：
如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察一个另一个线程，所有的操作都是无序的。
前半句是指“线程内表现为串行的语句”，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。
6、先行发生原则
6.1.作用：用来判断数据是否存在竞争、线程是否安全
6.2.示例
//线程A
i=1
//线程B
j=i
//线程C
i=2假设线程A中的操作“i=1”先行发生于线程B的操作“j=i”，那么可以确定在线程B的操作结束后，变量j的值一定等于1.现在再来考虑线程C，我们依然保持线程A和B之间的线性发生关系，而线程C出现在线程A和B之间，但是线程B和C之间没有先行发生关系。那j的值是多少呢？答案是不确定的。1和2都有可能，这时候线程B就存在读取到过期数据的风险，不具备多线程安全。
6.3.Java程序中天然存在的一些先行发生关系
#程序次序规则：按照控制流顺序，书写在前面的操作先行与书写在后面的操作
#管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作
#volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作
#线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作
#线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测
#线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
#对象终结规则：一个对象的初始化完成先行发生于它的finalize()方法的开始
#传递性：如果操作A先行发生操作B，操作B先行发生于操作C，那就可以得出操作A先行发生与操作C的结论。
Java语言中无需任何同步手段保障就能成立的线性规则就只有上面这些了。
6.4.“时间上的先后顺序”与“先行发生”的不同
代码清单
private int value=0;
public void setValue(int value){
this.value=value;
}
public void getValue(){
return value;
}假设存在线程A和线程B，线程A先（时间上的先后）调用了“setValue(1)”，然后线程B调用了同一个对象的“getValue()”，那么线程B收到的返回值是什么？
我们一次分析一下先行发生原则中的各项规则。由于两个方法不在一个线程中，所以程序次序规则在这里不适用；没有同步块，不会发生lock和unlock操作。其他的也都不符合。因此尽管线程A在操作时间上先行与线程B，但是无法确定在翻译成指令集以后，那个方法会先被执行完成，自然也就无法确定线程B中“getValue()”方法的返回结果。
解决方案：
#把setter和getter方法都定义为syncronized，这样就可以套用管程锁定规则；
#把value定义为volatile变量，由于setter方法对value的修改不依赖于value的原值，满足volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行发生关系。
总结：时间先后顺序与先行发生原则之间基本没有关系。
四、Java与线程
1、线程的实现
1.1.定义：线程是比进程更轻量级的调度执行单位。线程的引入可以把一个进程的资源分配和执行调度分开，各个线程可以共享进程资源（内存地址，文件I/O等），又可以独立调度。——线程是CPU调度的基本单位
（我们可以把做饭比作一个进程，这个进程包括厨房中的厨师和食材，其中每一位厨师就相当于每一个线程，他们负责执行调度食材，而不需要管食材怎么拿进来的，拿进来以后要怎么放等问题）
1.2.线程实现：
Java语言提供了在不同硬件和操作系统平台下对线程的统一处理，每个已经执行start()方法且还未结束的java.lang.Thread类的实例就代表了一个进程。
Thread类中的所有关键方法都声明为native。一个native方法往往意味着这个方法没有办法使用或无法使用平台无关的手段来实现。
实现线程的三种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。
1.3.内核线程（KLT）
定义：直接由操作系统内核支持的线程。这种线程由内核来完成切换，内核通过操纵调度器对线程进行调度，并将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就做多线程内核。
轻量级进程（LWP）：内核线程的高级接口。也就是我们通常意义上所讲的线程。
一对一的线程模型：轻量级进程与内核线程之间1:1的关系
优点：每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作。
局限：各种线程操作都需要进行系统调用。而系统调用的代价相对较高，需要在用户态和内核态中来回切换。轻量级进程要消耗一定的内核资源，因此一个系统支持轻量级进程的数量是有限的。
1.4.用户线程
广义上定义：一个线程只要不是内核进程就是用户进程。因此从这个定义上来讲，轻量级进程也是用户进程，但轻量级进程的实现始终是建立在内核之上的，许多操作都要进行系统调用，效率会受到限制。
狭义上定义：完全建立在用户空间上的线程叫做用户线程，系统内核不能感知线程的存在。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。
一对多的线程模型：进程与用户线程之间1：N的关系。
优点：不需要切换到内核态，操作非常快速且低消耗。可以支持更待规模的线程数量。不需要系统内核。
劣势：没有系统内核的支援。实现的程序比较复杂。现在使用用户线程的程序越来越少了。
1.5.用户线程+轻量级进程
用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能和处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险。
多对多的线程模型：用户线程与轻量级进程的数量比是不定的，即为N:M的关系。
1.6.Java线程的实现
操作系统支持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的，这点在不同的平台上没有办法达成一致。
2、Java的线程调度
线程调度：值系统为线程分配处理器使用权的过程。分为协同式线程调度和抢占式线程调度。
2.1.协同式线程调度
线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。
优点：实现简单。而且由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可知的，所以没有什么线程同步的问题。
局限：线程执行时间不可控制，甚至一个线程如果编写出问题，不告知系统进行线程切换，那么程序就会一直阻塞在那里。
2.2.抢占式线程调度——Java使用的就是抢占式线程调度
每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定。
优点：线程的执行时间是系统可控的，不会有一个线程导致整个进程阻塞的问题。
Java语言通过设置了10个不同的线程优先级，来实现给不同优先级的线程分配不同的执行时间，当两个线程都处于Ready状态时，优先级高的线程容易被系统优先选择执行。
但是“线程优先级不是很靠谱”：一是在一些平台上不同的优先级实际会变得相同；（Java的线程是通过映射到系统的原生线程来上来实现的，所以线程调度最终还是取决于操作系统，虽然现在很多操作系统都提供线程优先级的概念，但不一定能和Java线程的一一对应）二是优先级可能会被系统执行改变。
3、状态转换
Java语言定义了线程的五种状态，在任意一个时间点，一个线程只能有且只有其中的一种状态
3.1.新建：创建后尚未启动的线程
3.2.运行：Runnable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU给它分配执行时间
3.3.无限期等待：处于这种状态的线程不会等待CPU分配执行时间，它们要等待被其他线程显式地唤醒。以下方法会让线程进入无限期的等待
#没有设置Timeout参数的Object.wait()方法
#没有设置Timeout参数的Thread.join()方法
#LockSupport.park()方法
3.4.限期等待：处于这种状态的线程也不会被CPU分配执行时间，不过无效等待被其它线程唤醒，在一定时间后它们会由系统自动唤醒。以下方法会让线程进入限期等待：
#Thread.sleep()方法
#设置了Timeout参数的Object.wait()方法
#设置了Timeout参数的Thread.join()方法
#LockSupport.parkNanos()方法
#LockSupport.parkUntil()方法
3.5.阻塞：线程被阻塞了。
“阻塞状态”：在等待一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；
“等待状态”：在等待一段时间。或者唤醒动作的发生；
在程序等待进入同步区域的时候，线程将进入这种状态
3.6.结束：已终止线程的线程状态，线程已经结束执行
博客内容来自《深入理解Java虚拟机》。
