[Java多线程 三]---JMM内存模型

高效并发

问题提出：为什么要使用高效并发

使用场景一：运行速度的差距

计算机的运行速度与它的存储和通信子系统速度的差距太大，大量的时间都花费在磁盘I/O、网通通信或者数据的访问上。造成很大的浪费，最好的办法就是让计算机同时处理几项任务。

使用场景二：服务端对多客户端

并发另一个场景：服务端同时对多个客户端提供服务。衡量一个服务性能的高低好坏，每秒事务处理数Transactions Per Scend，TPS，是最重要的指标之一，代表一秒内服务端平均响应的请求总数，TPS的值和并发能力联系非常密切。对于计算量相同的任务，程序线程并发协调得有条不紊，效率自然就会越高；反之，程序之间频繁阻塞甚至死锁，将会大大降低程序的并发能力。而服务端是Java最擅长的领域之一。

硬件的效率与一致性

解决运算速度冲突

大多数运算中，处理器都要和内存进行交互，如读取数据、存储结果等。由于计算机存储设备和处理器运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高缓存Cache来作为内存与处理器之间的缓冲：将运算需要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存中同步回内存，这样处理器就无须等待缓慢的内存读写了。

解决运算冲突却导致了高速缓存的一致性问题。

解决缓存一致性冲突

高缓存Cache引入了缓存的一致性Cache Coherence的问题。在多处理器系统中，每个处理器都有自己的高速缓存，又共享同一主内存，可能导致各自的缓存数据不一致。需要各处理器访问缓存时遵循一些协议，在读写时根据协议来操作，如MSI，MESI，MOSI，Snapse,Firefly,dRAGON Protocol等。处理器还可能会对输入的代码进行乱序执行优化，之后又将乱序结果重组，保证该结果与顺序执行结果一致，还有指令重排序优化。

内存模型：在特定的操作协议下对特定的内存或高速缓存进行读写访问的过程抽象。

Java内存模型（JMM）

JMM，Java Memory Model，用来屏蔽掉各种硬件和操作系统之间的内存访问差异，以实现让Java程序在各平台下都能达到一致的内存访问效果。

在此之前，主流程序语言（如C/C++等）直接使用物理硬件和操作系统的内存模型，因此，会由于不同平台上内存模型的差异，有可能导致程序在一套平台上并发完全正常，而在另外一套平台上并发访问却经常出错，因此在某些场景就必须针对不同的平台来编写程序。

JMM主要目标：定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存取出变量这样的底层细节。

注意：此处变量指实例字段，静态字段和构成数组对象的元素，但不包括局部变量，因为其是线程私有的，不会被共享，也就不会有竞争问题。

主内存与工作内存

• JMM规定所有变量均存储在主内存（虚拟机内存的一部分）中。每条线程还有自己的工作内存，类比高速缓存。

• 线程对变量的所有操作都在工作内存中，不能直接在主内存中读写操作。

• 不同线程之间也不能直接访问对方的工作内存中的变量。只能通过主内存来传递变量值。

注意：主内存与工作内存和Java内存区域的堆栈方法区等并不是同一个层次的内存划分。如果硬要对应的话：

• 那从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分 ，而工作内存则对应于虚拟机栈中的部分区域。

• 主内存直接对应于物理硬件的内存，工作内存优先存储寄存器和高速缓存，因为程序运行时主要访问读写的是工作内存。

内存间交互操作

操作顺序

主内存与工作内存之间具体的交互协议：一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存等的细节。

Java内存模型定义了8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子操作。对于long 和double类型的变量，store，read，write，load操作在某些平台上允许有例外。

• lock(锁定)：作用于主内存的变量，它把一个变量标志为一条线程独占的状态。

• unlock(解锁)：作用于主内存中的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

• read(读取)：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。

• load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

• use(使用)：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的字节码指令时将执行这个操作。

• assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接受到的值赋给工作内存的变量，遇到赋值的字节码时执行。

• store(存储)：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。

• write(写入)：作用于主内存中的变量，它把store操作从主内存中得到的变量值放入主内存的变量中。

以上操作，仅保持顺序执行即可，不用保证连续执行。如 read a read b load b load a。

操作冲突

变量操作相关的========================================================

• 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况。

• 不允许一个线程丢弃它的最近assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

• 不允许一个线程无原因的（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。即不能对变量没做任何操作却无原因的同步回主内存

• 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，就是对一个变量执行use和store之前必须先执行过了load和assign操作。

lock操作相关的========================================================

• 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

• 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

• 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定住的变量。

• 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store write）。
  以上可以完全确定Java程序中哪些内存访问操作在并发下是安全的。

volatile型变量

volatile，Java虚拟机提供的最轻量级的同步机制。

可见性

volatile第一可以保证变量对所有线程的可见性，即一条线程修改了变量的值，新值对于其他线程来说是可以立即得知的。volatile变量在各个线程的工作内存中不存在一致性问题（即时存在，由于每次使用之前都得刷新，执行引擎看不到不一致的情况，所以认为是 不存在一致性问题）。

如果运算操作不是原子操作，导致volatile变量的运算在并发下一样是不安全的。依然没法保证volatile同步的正确性。由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，仍需要加锁synchronized或java.util.concurrent中的原子类来保证原子性（如果把一个事务可看作是一个程序,它要么完整的被执行,要么完全不执行。这种特性就叫原子性*）：

• 对变量的写入操作不依赖于该变量的当前值（比如a=0;a=a+1的操作，整个流程为a初始化为0，将a的值在0的基础之上加1，然后赋值给a本身，很明显依赖了当前值），或者确保只有单一线程修改变量。

• 该变量不会与其他状态变量纳入不变性条件中。（当变量本身是不可变时，volatile能保证安全访问，比如双重判断的单例模式。但一旦其他状态变量参杂进来的时候，并发情况就无法预知，正确性也无法保障）。

/**
 * 基于双重判断的单例模式
 */
public class Singleton {

private volatile static Singleton instance;

public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
return instance;
    }

public static void main(String[] args) {
            Singleton.getInstance();
    }
}
//volatile修饰的变量在赋值后会多执行一个lock addl..的操作，相当于一个内存屏障（Memory Barrier/Memory Fence ，指重排序时不能把后面的指令重排序到内存屏障之前的位置，也意味着在该操作时，所有之前的指令操作都已经执行完毕），只有一个CPU访问内存时并不需要，但如果有多个CPU访问同一内存，且其中一个在观测另一个，就需要内存屏障来保证一致性。

内存屏障

volatile还有个特性就是，可以禁止指令进行重排序优化。普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。如下例子：

Map configOptions;
char [] configText;

//此变量必须定义为volatile
volatile boolean initialized = false;

//假设一下代码在线程A中执行，模拟读取配置信息，当读取完成后，将initialized设置为true来通知其他线程配置可使用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;

//假设以下代码在线程B中执行，等待initialized 为true，代表线程A已经把配置信息初始化完成
while(!initialized ){
    sleep();
}
//使用线程A中初始化好的配置信息
doSomethingWithConfig();

如果initialized 没有使用volatile修饰，就可能由于指令重排的优化，导致位于线程A中的最后一句代码“initialized = true”被提前执行，这样在线程B中使用配置信息的代码就可能出现错误。

性能评价

某些情况下volatile的同步机制比锁要好，但很难量化这种优势。volatile自己和自己比较，它的读操作的性能消耗和普通变量几乎没啥区别，但写操作要慢一些，因为需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。即便如此，在大多数场景下，volatile总开销仍然比锁要低，根据volatile语义是否满足场景来选择。如果情况不合适，就使用传统的synchronized关键字同步共享变量的访问，用来保证程序正确性（这个关键字的性能会随着jvm不断完善而不断提升，将来性能会慢慢逼近volatile）。

JMM对volatile的特殊规则

volatile变量V，W，线程T，进行read load use assign store write操作：

• 对于T来说，必须保证对V的load和use连续一起出现，即在工作内存中，每次使用V前都必须先从主内存中刷新最新值，用于保证能看到其他线程对V的修改后的值。

• T对V的assign和store必须连续一起出现。即在工作内存中，每次修改V后都必须立刻同步回主内存中，保证其他线程看到自己对V 的修改。

• 假定A是T对V的use assign，F是A相关联的load或store；P是和F相应的对变量V的read或write；同样，B是T对W的use或assign，G是B相关联的load或store，Q是G相应的对变量W的read或write。如果A先于B，那么P先于Q（volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序顺序相同）。

对于long和double变量的特殊规则

对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写划分为两次32位的操作来进行，即允许虚拟机不保证64位数据类型的load、store、read和write这四个操作的原子性。虚拟机几乎都选择将64位数据的读写操作作为原子操作来对待，因此在编写代码时一般不需要用到将long和double变量专门声明为volatile。

原子性、可见性与有序性

原子性（Atomicity）

Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store和write这六个，我们可以大致的认为基本数据类型的访问读写是具备原子性的（long和double除外）。Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

可见性（Visibility）

可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。

除了volatile之外，Java还有两个关键字能实现可见性，即synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了半”的对象），那在其他线程中就能看见final字段的值。

有序性（Ordering）

Java程序的天然有序性：在本线程内观察，所有操作都是有序的；在一个线程中观察另外一个线程，所有操作都是无序的。（前半句是指线程内表现为串行的语义，后半句是指令重排序现象和工作内存与主内存同步延迟现象）。用synchronized和volatile关键字来保证线程操作之间的有序性。volatile本省就包含禁止指令重排序的语义，而synchronized则是因为：一个变量在同一时刻只允许一条线程对齐进行lock操作。这个规则决定了持有同一个锁的两个同步块只能串行的进入。

先行发生原则

先行发生是Java内存模型中定义的两项操作之间的偏序关系。
如果Java内存模型中所有的有序性都只靠volatile和synchronized来完成，那么有一些操作将会变得很繁琐。java内存模型中的一个重点原则——先行发生原则（Happens-Before），使用这个原则作为依据，来指导你判断是否存在线程安全和竞争问题。 以下先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

八个原则

关于顺序执行的三个原则

• 程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。

• 传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

  • 对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize（）方法的开始。

关于锁定与读写的两个原则

• 管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。

• volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。

关于线程的三个原则

• 线程启动规则（Thread Start Rule）：Thread对象的start（）方法先行发生于此线程的每一个动作。

• 线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join（）方法结束、Thread.isAlive（）的返回值等手段检测到线程已经终止执行

• 线程中断规则（Thread Interruption Rule）：对线程interrupt（）方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted（）方法检测到是否有中断发生。

注意

一个操作“时间上的先发生”不代表这个操作会是“先行发生”

private int value = 0;
public void setValue(int value){
this.value = value;
}
public int getValue(){
return value;
}

假设存在线程A和B，线程A先调用setValue(1)，然后线程B调用了同一个对象getValue()，那么线程B返回的值是什么？分析：两个线程调用，不在一个线程中，所以程序次序规则不适用；没有同步块—管程锁定规则不适用；value没有被volatile修饰，所以volatile变量规则不适用；后面的线程启动、终止、中断规则和对象终结规则也扯不上关系，所以尽管在时间上A先于B，但无法确定B中getValue()返回值结果，因此我们说这里的操作时线程不安全的。

如何修复呢？可以为set、get方法定义为synchronized方法，这样可以使用管程锁定规则；或者把value设定为volatile变量，由于set方法对value的修改不依赖value的原值，满足volatile关键字使用场景。

那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢？很遗憾，这个推论也是不成立的，一个典型的例子就是多次提到的“指令重排序”。所以一个操作“先行发生”不代表这个操作会在时间上先发生

时间先后顺序与先行发生原则之间基本没有太大的关系

Java与线程

并发并不一定依赖多线程，但Java里谈论并发大多数都与线程脱不开关系。主流的操作系统都提供了线程实现，Java语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理。

线程的实现

实现线程主要有3种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。

使用内核线程实现

内核线程（Kernel-Level Thread,KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核（Multi-Threads Kernel）。

程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process,LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1:1的关系称为一对一的线程模型

优点

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作。

缺点

• 首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换.

• 其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的。

使用用户线程实现

用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间1：N的关系称为一对多的线程模型

优点

使用用户线程的优势在于不需要系统内核支援

缺点

劣势也在于没有系统内核的支援，所有的线程操作都需要用户程序自己处理。线程的创建、切换和调度都是需要考虑的问题，而且由于操作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”、“多处理器系统中如何将线程映射到其他处理器上”这类问题解决起来将会异常困难

Java、Ruby等语言都曾经使用过用户线程，最终又都放弃使用它。

使用用户线程加轻量级进程混合实现

在这种混合实现下，既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险。

Java线程的实现

线程模型替换为基于操作系统原生线程模型来实现。因此，在目前的JDK版本中，操作系统支持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的，这点在不同的平台上没有办法达成一致，虚拟机规范中也并未限定Java线程需要使用哪种线程模型来实现。

对于Sun JDK来说，它的Windows版与Linux版都是使用一对一的线程模型实现的，一条Java线程就映射到一条轻量级进程之中，因为Windows和Linux系统提供的线程模型就是一对一的。

在Solaris平台中，由于操作系统的线程特性可以同时支持一对一及多对多

Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种，分别是协同式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling）。

协同式线程调度

如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。

优点

协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可知的，所以没有什么线程同步的问题。

缺点

它的坏处也很明显：线程执行时间不可控制，甚至如果一个线程编写有问题，一直不告知系统进行线程切换，那么程序就会一直阻塞在那里。

抢占式线程调度

如果使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定（在Java中，Thread.yield（）可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的）。

优先级

虽然Java线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配一点执行时间，另外的一些线程则可以少分配一点——这项操作可以通过设置线程优先级来完成。Java语言一共设置了10个级别的线程优先级（Thread.MIN_PRIORITY至
Thread.MAX_PRIORITY），在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。

比Java线程优先级少的系统，就不得不出现几个优先级相同的情况了

状态转换

Java定义了5种线程状态，在任意一个点一个线程只能有且只有其中一种状态。无限等待和等待可以算在一起。所以共五种。

新建(New)

创建后尚未启动的线程。

运行(Runnable)

Runnable包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能等待CPU为它分配执行时间。线程对象创建后，其他线程调用了该对象的start()方法。该状态的线程位于“可运行线程池”中，变得可运行，只等待获取CPU的使用权。即在就绪状态的进程除CPU之外，其它的运行所需资源都已全部获得。

无限期等待(Waiting)

该状态下线程不会被分配CPU执行时间，要等待被其他线程显式唤醒。

• 没有设置Timeout参数的Object.wait（）方法。

• 没有设置Timeout参数的Thread.join（）方法。

• LockSupport.park（）方法。

限期等待(Timed Waiting)

处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态：

• Thread.sleep（）方法。

• 设置了Timeout参数的Object.wait（）方法。

• 设置了Timeout参数的Thread.join（）方法。

• LockSupport.parkNanos（）方法。

• LockSupport.parkUntil（）方法。

阻塞（Blocked）

线程被阻塞了。与等待状态的区别是：阻塞在等待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。

阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。
阻塞的情况分三种：

• 等待阻塞：运行的线程执行wait()方法，该线程会释放占用的所有资源，JVM会把该线程放入“等待池”中。进入这个状态后，是不能自动唤醒的，必须依靠其他线程调用notify()或notifyAll()方法才能被唤醒，，即无限期等待
• 同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入“锁池”中。
• 其他阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。即限期等待。

结束（Terminated）

已终止线程的线程状态，线程已经结束执行。