内存模型

• 如果要把一个变量从 主内存复制到工作内存 ，那就要 顺序地执行 read 和 load 操作
• 如果要把变量从 工作内存同步回主内存 ，就要 顺序地执行 store 和 write 操作

      注意，Java内存模型只要求上述两个操作必须按顺序执行，而没有保证是连续执行

      也就是说，read与load之间、store与write之间是可插入其他指令的

      如对主内存中的变量a、b进行访问时，一种可能出现顺序是read a、read b、load b、load a

除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则：

• 不允许 read 和 load 、 store 和 write 操作之一 单独出现 ，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现
• 不允许一个线程丢弃它的最近的assign操作，即变量在 工作内存中改变了之后必须把该变化同步回主内存
• 不允许一个线程无原因地， 没有发生过任何 assign 操作 ，把数据从线程的 工作内存同步回主内存中
• 一个 新的变量只能在主内存中诞生 ，不允许在工作内存中直接使用一个 未被初始化 （ load 或 assign ）的变量，换句话说，就是 对一个变量实施 use 、 store 操作之前，必须先执行过了 assign 和 load 操作
• 一个变量在 同一个时刻只允许 一条线程 对其进行 lock 操作
  • 但 lock 操作可以被 同一条线程 重复执行多次 ，多次执行 lock 后，只有 执行相同次数的 unlock 操作 ，变量才会被解锁
  • 如果对一个变量执行 lock 操作，那将会 清空工作内存中此变量的值 ，在 执行引擎 使用这个变量前，需要 重新执行 load 或 assign 操作 初始化变量的值
• 如果一个变量 事先没有被 lock 操作锁定 ，那就 不允许对它执行 unlock 操作 ，也 不允许去 unlock 一个 被其他线程 锁定 住的变量
  • 对一个变量执行 unlock 操作之前，必须 先把此变量同步回主内存中 ，也就是执行 store 、 write 操作

       基于理解难度和严谨性考虑，最新的JSR-133文档中，已经放弃采用这8种操作去定义Java内存模型的访问协议了

      仅是描述方式改变了，Java内存模型并没有改变

当一个变量定义为 volatile 之后，它将保证此变量对所有线程的 可见性 ，这里的 可见性 是指 当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的 。而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成

      例如，线程A修改一个普通变量的值，然后向主内存进行回写

      另外一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量值才会对线程B可见

关于volatile变量的可见性，经常会被开发人员误解，认为以下描述成立：“volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程之中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的”。这句话的论据部分并没有错，但是其论据并不能得出 基于volatile变量的运算在并发下是安全的 这个结论。volatile变量在 各个线程的工作内存中不存在一致性问题 （在各个线程的工作内存中，volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题），但是Java里面的 运算并非原子操作 ，导致 volatile变量的运算在并发下一样是不安全的 ，可以通过一段简单的演示来说明原因，请看下面代码：

class VolatileTest {

    private static volatile int race = 0;

    private static void increase() {
        race++;
    }

    private static final int THREADS_COUNT = 20;

    public static void main(String[] args) {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < THREADS_COUNT; i++) {
            threads[i] = new Thread(() -> {
                    for (int i1 = 0; i1 < 10000; i1++) {
                        increase();
                    }
            });
            threads[i].start();
        }

        // 等待所有累加线程都结束
        while (Thread.activeCount() > 1)
            Thread.yield();

        System.out.println(race);
    }
}

      这段代码发起了20个线程，每个线程对race变量进行10000次自增操作

      如果这段代码能够正确并发的话，最后输出的结果应该是200000

      然而运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字

问题就出现在自增运算 race++ 之中，用Javap反编译这段代码后会得到下面代码，发现只有一行代码的 increase() 方法在Class文件中是由 4条字节码指令构成的 （return指令不是由race++产生的，这条指令可以不计算），从字节码层面上很容易就分析出并发失败的原因了：

• 当 getstatic 指令把 race的值 取到 操作栈顶 时， volatile关键字保证了race的值在此时是正确的
• 但是在执行 iconst_1 、 iadd 这些指令的时候， 其他线程可能已经把race的值加大了 ，而 在操作栈顶的值就变成了过期的数据 ，所以 putstatic 指令执行后就可能 把较小的race值同步回主内存 之中

public static void increase();
  descriptor: ()V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=2, locals=0, args_size=0
       0: getstatic     #2                  // Field race:I
       3: iconst_1
       4: iadd
       5: putstatic     #2                  // Field race:I
       8: return
    LineNumberTable:
      line 11: 0
      line 12: 8

      客观地说，在此使用字节码来分析并发问题，仍然是不严谨的

      因为即使编译出来只有一条字节码指令，也并不意味执行这条指令就是一个原子操作

      一条字节码指令在解释执行时，解释器将要运行许多行代码才能实现它的语义

      如果是编译执行，一条字节码指令也可能转化成若干条本地机器码指令

      此处使用-XX：+PrintAssembly参数输出反汇编来分析会更加严谨一些，但考虑到阅读的方便，并且字节码已经能说明问题，所以此处使用字节码来分析

由于 volatile 变量只能保证可见性，在不符合以下两条规则的运算场景中，仍然要通过 加锁 来 保证原子性 ：

• 运算结果并 不依赖变量的当前值 ，或者能够确保只有 单一的线程 修改变量的值
• 变量 不需要与其他的状态变量 共同参与不变约束

如下的代码所示的这类场景就很适合使用 volatile 变量来控制并发，当 shutdown() 方法被调用时，能保证所有线程中执行的 doWork() 方法都立即停下来：

volatile boolean shutdownRequested；

public void shutdown（）{
    shutdownRequested=true；
        }

public void doWork（）{
    while（！shutdownRequested）{
            //do stuff
        }
}

使用volatile变量的第二个语义是 禁止指令重排序优化 ，普通的变量仅仅会保证在 该方法的执行过程中所有 依赖赋值结果 的地方都能获取到正确的结果 ，而 不能保证 变量赋值操作 的顺序与 程序代码中的执行顺序 一致 。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的 线程内表现为串行的语义

继续通过一个例子来看看为何指令重排序会干扰程序的并发执行，演示程序如代码所示：

 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关键字则可以避免此类情况的发生

      这里虽然使用Java作为伪代码，但所指的重排序优化是机器级的优化操作，提前执行是指这句话对应的汇编代码被提前执行

指令重排序是并发编程中最容易让开发人员产生疑惑的地方，除了上面伪代码的例子之外，再举一个可以实际操作运行的例子来分析volatile关键字是如何禁止指令重排序优化的。下面代码是一段标准的DCL单例代码，可以观察加入 volatile 和 未加入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();
    }
}

编译后，这段代码对instance变量赋值部分如下所示：

0x01a3de0f：mov$0x3375cdb0，%esi         ；……beb0cd75 33
                                        ；{oop（'Singleton'）}
0x01a3de14：mov%eax，0x150（%esi）      ；……89865001 0000
0x01a3de1a：shr$0x9，%esi                ；……c1ee09
0x01a3de1d：movb$0x0，0x1104800（%esi）    ；……c6860048 100100
0x01a3de24：lock addl$0x0，（%esp）        ；……f0830424 00
                                        ；*putstatic instance
                                        ；-
Singleton：getInstance@24

通过对比就会发现，关键变化在于有volatile修饰的变量，赋值后（前面 mov%eax，0x150(%esi) 这句便是赋值操作）多执行了一个 lock addl ＄0x0，(%esp) 操作，这个操作相当于一个 内存屏障 （指重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；但如果有两个或更多CPU访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。关键在于lock前缀，它的作用是使得 本CPU的Cache写入了内存 ，该写入动作也会 引起别的CPU或者别的内核无效化其Cache ，这种操作相当于对Cache中的变量做了一次前面介绍Java内存模式中所说的 store和write 操作。所以通过这样一个空操作，可让前面volatile变量的 修改对其他CPU立即可见

lock 指令中的 addl ＄0x0，(%esp) （把ESP寄存器的值加0）显然是一个 空操作

采用这个空操作而不是空操作指令nop是因为IA32手册规定 lock前缀不允许配合nop指令使用 

从硬件架构上讲，指令重排序是指 CPU采用了允许将 多条指令不按程序规定的顺序分开发送给各相应电路单元处理 。但并不是说指令任意重排，CPU需要能 正确处理指令依赖情况以保障程序能得出正确的执行结果

      譬如 指令1 把地址 A 中的值加10，指令2把地址 A 中的值乘以2，指令3把地址 B 中的值减去3

      这时指令1和指令2是有依赖的，它们之间的顺序不能重排，因为 (A+10) * 2 与 A * 2 +10 显然不相等

      但指令3可以重排到指令1、2之前或者中间，只要保证CPU执行后面依赖到A、B值的操作时能获取到正确的A和B值即可

      所以在本内CPU中，重排序看起来依然是有序的

实际上， lock addl＄0x0, (%esp) 指令把 修改同步到内存 时，意味着 所有之前的操作都已经执行完成 ，这样便形成了 指令重排序无法越过内存屏障 的效果

volatile 能让代码比使用其他的同步工具更快吗？在某些情况下，volatile的同步机制的性能确实要优于锁，但是由于虚拟机对锁实行的许多消除和优化，使得很难量化地认为volatile就会比synchronized快多少。如果让volatile自己与自己比较，那可以确定一个原则: volatile变量 读操作的性能消耗与普通变量几乎没有什么差别 ，但是 写操作则可能会慢一些 ，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁低，在volatile与锁之中选择的唯一依据仅仅是 volatile的语义能否满足使用场景的需求

最后，回头看一下Java内存模型中对volatile变量定义的特殊规则。假定 T 表示一个 线程 ， V 和 W 分别表示两个 volatile型变量 ，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：

1. 只有当线程 T 对变量 V 执行的前一个动作是 load 的时候，线程 T 才能对变量 V 执行 use 动作；并且，只有当线程 T 对变量 V 执行的后一个动作是 use 的时候，线程 T 才能对变量 V 执行 load 动作。线程T对变量V的use动作可以认为是和 线程 T 对变量 V 的 load、read动作相关联，必须连续一起出现。这条规则要求在 工作内存 中， 每次使用 V 前都必须先从主内存刷新最新的值 ，用于保证能看见其他线程对变量 V 所做的修改后的值
2. 只有当线程 T 对变量 V 执行的前一个动作是 assign 的时候，线程 T 才能对变量 V 执行 store 动作；并且，只有当线程 T 对变量 V 执行的后一个动作是 store 的时候，线程 T 才能对变量 V 执行 assign 动作。线程 T 对变量 V 的 assign动作可以认为是和线程T对变量V的 store、write 动作相关联，必须连续一起出现。这条规则要求在工作内存中， 每次修改 V 后都必须立刻同步回主内存中 ，用于保证其他线程可以看到自己对变量V所做的修改

volatile屏蔽指令重排序的语义在JDK 1.5中才被完全修复

此前的JDK中即使将变量声明为volatile也仍然不能完全避免重排序所导致的问题（主要是volatile变量前后的代码仍然存在重排序问题）

这点也是在JDK 1.5之前的Java中无法安全地使用DCL（双锁检测）来实现单例模式的原因 

Java内存模型要求lock、unlock、read、load、assign、use、store、write这8个操作都具有原子性，但是对于64位的数据类型 ( long 和 double )，在模型中特别定义了一条相对宽松的规定： 允许虚拟机将没有被 volatile 修饰的64位数据的读写操作划分为 两次32位的操作 来进行 ，即允许虚拟机实现选择可以不保证64位数据类型的 load 、_store_ 、 read 和 write 这4个操作的原子性，这点就是所谓的 long和double的非原子性协定

如果有多个线程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了 半个变量 的数值

      不过这种读取到“半个变量”的情况非常罕见，在目前商用Java虚拟机中不会出现

      因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作

      但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现

在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因此在编写代码时 一般不需要把用到的long和double变量专门声明为volatile

由Java内存模型来直接保证的 原子性 变量操作包括 read 、 load 、 assign 、 use 、 store 和 write

      大致可以认为基本数据类型的访问读写是具备原子性的，例外就是long和double的非原子性协定

      只要知道这件事情就可以了，无须太过在意这些几乎不会发生的例外情况

如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了 lock 和 unlock 操作来满足这种需求，尽管虚拟机未把 lock 和 unlock 操作直接开放给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来 隐式 地使用这两个操作，这两个字节码指令反映到Java代码中就是 同步块 synchronized 关键字，因此在 synchronized 块之间的操作也具备 原子性

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

除了 volatile 之外，Java还有两个关键字能实现可见性，即 synchronized 和 final ：

• synchronized：可见性是由 对一个变量执行 unlock 操作之前，必须先把此变量同步回主内存中（执行 store 、 write 操作） 这条规则获得的
• final: 可见性是由 被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把 this 的引用传递 出去 ，那在其他线程中就能看见final字段的值。如下面代码所示，变量i与j都具备可见性，它们无须同步就能被其他线程正确访问：

public static final int i；
public final int j；

static{
    i=0；
    //do something
}

{
    //也可以选择在构造函数中初始化
    j=0；
    //do something
}

this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象

Java内存模型的 有序性 在讲解volatile时也详细地讨论过了，Java程序中天然的有序性可以总结为：

• 如果在 本线程 内观察，所有的操作都是 有序的 ：线程内表现为 串行 的语义
• 如果在 一个线程中观察另一个线程 ，所有的操作都是 无序的 ：
  • 指令重排序 现象
  • 工作内存与主内存同步延迟 现象

Java语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的 有序性 ：

• volatile关键字本身就包含了 禁止指令重排序 的语义
• synchronized则是由 一个变量在同一个时刻只允许一条线程对其进行lock操作 这条规则获得的，这条规则决定了 持有同一个锁的两个同步块只能 串行地 进入

介绍完并发中3种重要的特性后，synchronized 关键字在需要这3种特性的时候都可以作为其中一种的解决方案

因此大部分的并发控制操作都能使用 synchronized 来完成

synchronized的“万能”也间接造就了它被程序员滥用的局面，越“万能”的并发控制，通常会伴随着越大的性能影响

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

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

• 优点：内核线程保证了每个轻量级进程都成为一个 独立的调度单元 ，即使有一个 轻量级进程在系统调用中阻塞了，也不会影响整个进程的继续工作
• 缺点：
  • 基于内核线程实现，因此各线程操作等 需要系统调用 ， 系统调用代价高 ，需要在用户态和内核态来回切换
  • 每个轻量级进程都需要一个内核线程的支持，因此 轻量级进程要消耗一定的内核资源 ，如内核线程的栈空间，因此一个系统支持 轻量级进程的数量是有限的

从广义上来讲，一个线程只要不是内核线程，就可以认为是 用户线程 ( UT )，因此，从这个定义上来讲，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作都要进行系统调用，效率会受到限制

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

• 优点：这种线程 不需要切换内核态 ， 效率非常高 且低消耗，也可以支持 规模更大 的线程数量
• 缺点：由于 没有系统内核的支援 ，所有的线程操作都需要用户程序自己处理。 阻塞处理 等问题的解决十分困难 ，甚至不可能完成。所以使用用户线程会 非常复杂

还有一种将 内核线程 与 用户线程 一起使用 的实现方式。在这种混合实现下，既存在用户线程，也存在轻量级进程：

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

在这种混合模式中， 用户线程 与 轻量级进程 的 数量比是不定的 ，即为 N：M 的关系，如图所示：这种就是多对多的线程模型

      许多UNIX系列的操作系统，如Solaris、HP-UX等都提供了N：M的线程模型实现

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

• 好处：
  • 实现简单
  • 由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可知的，所以 没有什么线程同步 的问题
    • Lua语言中的 协同例程 就是这类实现
• 坏处：线程 执行时间不可控制 ，甚至如果一个线程编写有问题，一直不告知系统进行线程切换，那么程序就会一直阻塞在那里

      很久以前的Windows 3.x系统就是使用协同式来实现多进程多任务的，相当不稳定，一个进程坚持不让出CPU执行时间就可能会导致整个系统崩溃

如果使用 抢占式 调度的多线程系统，那么每个线程将由 系统来分配执行时间 ，线程的切换不由线程本身来决定

      在Java中，Thread.yield() 可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的 

最大的优点：线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题

      与前面所说的Windows 3.x的例子相对，在Windows 9x/NT内核中就是使用抢占式来实现多进程的

      当一个进程出了问题，还可以使用任务管理器把这个进程“杀掉”，而不至于导致系统崩溃