小目标之读懂JVM—java内存模型与线程

这一章已经到了这本书讲解的最后一部分“高效并发”的知识点了，下一章也是关于并发的知识点，讲解的是线程安全和锁优化。计算机的运算性能很强大，而相较于运算性能来说，它的存储和通信子系统速度则过慢，因此为了能最大程度的发挥计算机的运算能力，而不被其它较慢的处理所拖累，多任务处理几乎是一项必备功能了。Java语言和虚拟机提供了很多工具来简化并发开发，但了解并发内幕仍是帮助定位和解决并发问题必不可少的条件。

虚拟机的许多并发问题在物理机上面也有体现。为了充分利用计算机处理器的性能，就需要让计算机并发执行多个运算任务，但是绝大多数的运算任务都不仅仅是单纯的运算，它还包含存取数据时与磁盘的交互即I/O操作，而耗时很久的I/O操作很难消除，为了能更好的利用处理器的高速性能，现代计算机系统都会加入一层读写速度尽可能接近处理器运算速度的高速缓存(Cache)来作为内存和处理器之间的缓冲，让处理器运算的数据尽量多的从高速缓存中获取即能极大优化运行速度。但是高速缓存也引入了缓存一致性(Cache Coherence)的问题，在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存(Main Memory)，因此当多个处理器运算任务都涉及同一主内存区域时，就可能导致各自的缓存数据不一致。为了解决这种不一致的问题，就需要各个处理器访问缓存时遵循一些协议，根据协议去进行操作。“内存模型”就可以理解成特定的操作协议下，对特定内存或高速缓存进行读写访问的过程抽象。不同架构的物理机可以有不一样的内存模型，而java虚拟机也有自己的内存模型。

除了增加高速缓存外，为了充分利用处理器内部的运算单元，处理器可能会对输入代码进行乱序执行优化，类似的java虚拟机的即时编译器也有指令重排序的优化。

java虚拟机规范试图定义一种java内存模型来屏蔽各种硬件和操作系统的内存访问差异，实现java程序在各种平台下能达到一致的内存访问效果。之前的c/c++直接使用物理硬件和操作系统的内存模型时，会导致有可能一套平台上并发完全正常的程序在另一套平台上经常出错的问题。JDK1.5之后java内存模型逐渐成熟和完善了。

java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量指的是被共享的实例字段、静态字段、数组对象的元素等。java内存模型规定了所有变量均存储在主内存(Main Memory)中，此处的主内存指的是虚拟机内存的一部分，每条线程还有自己的工作内存(Working Memory)，类似于物理机的高速缓存。线程工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间也无法访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存完成。

java内存模型定义了8种操作来完成一个变量从主内存拷贝到工作内存、再从工作内存同步回主内存之类的实现细节。虚拟机实现时需保证这8种操作是原子的、不可再分的(double、long类型load、store、read、write操作某些平台可有例外)。8种操作分别为lock(锁定：作用于主内存变量，将一个变量标识为一条线程独占的状态)，unlock(解锁：作用于主内存变量，讲一个处于锁定状态的变量释放，释放后的变量才可以被其它线程锁定)，read(读取：作用于主内存变量，将一个变量的值从主内存传输到线程的工作内存中，以便之后的load动作使用)，load(载入：作用于工作内存变量，将read操作从主内存中得到的变量值存入工作内存的变量副本中)、user(使用：作用于工作内存变量，将工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量值的字节码指令时就会执行这个操作)、assign(赋值：作用于工作内存的变量，将一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量复制的字节码指令时执行这个操作)、store(存储：作用于工作内存变量，将工作内存中一个变量的值传送到主内存中，以便之后的write使用)、write(写入：作用于主内存变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中)。如果要把一个变量从主内存复制到工作内存，就需要顺序执行read和load操作，要把一个变量从工作内存同步回主内存，就要顺序执行store和write操作。只要求顺序执行，没保证是连续执行，即read和load之间可插入其它指令。java内存模型还规定了一些执行时必须满足的规则，如assign操作不允许线程丢弃，即变量在工作内存修改后必须同步修改至主内存。这些内存访问操作和规则限定，以及下面介绍的volatile的一些特殊规定，就确定了java程序中哪些内存访问操作并发下是安全的。

volatile是java虚拟机提供的最轻量级的同步机制。volatile变量具备两种特性：

        一是保证此变量对所有线程的可见性。变量值在线程间传递时均需要通过主内存来完成。线程A修改一个普通变量的值，然后向主内存执行回写，另一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量值才会对B可见。线程B未触发从主内存的读取操作之前，新变量值对B是不可见的。volatile变量保证了每个线程使用该变量前，必须先刷新(即读取主内存的值)，即使各个线程工作内存中的volatile变量会不一致，先刷新的机制也保证了各个线程拿到的volatile变量与主内存中该变量一致，即每个线程修改后的volatile值，其它线程可以立刻得知。但是volatile只保证了读取时是一致的，但若线程A和线程B同时读取了主内存中volatile的值V，并且都在工作内存中对V的副本进行了修改，同时写入主内存的时候就回出现写覆盖问题。例如volatile变量为int v=1,线程A对V做加一操作，线程B对v做减一操作，每个操作均分为:读取主内存V的值至线程工作内存、进行运算、存入工作内存的运算结果到主内存。那么A和B并发执行时可以同时读取到v的最新值，但是A和B运算完后同时写入运算结果到主内存时就会出现写覆盖问题，可能A先写入，B后写入，最后v就为0，也可能B先写入，A后写入，最后v就为2。两种情况均不是我们想要的单线程条件下V变量的v仍为1的结果。

        特性二是禁止指令重排序优化。比如主内存中有两个变量boolean v1=false;int v2=1;线程A执行操作v2=2;v1=true;线程B执行操作if(v1){v2=v2+1}，那么可能会存在指令重排序的情况，就是A中的指令执行时因为v2=2和v1=true不具有数据依赖性，第二行代码不依赖第一行代码，则可能为了优化运行效率，重排后的指令先执行v1=true在执行v2=2，对于线程A来说这种重排序并无影响，但是对于读取同一份变量的线程B来说就会出现v2=2的情况，不是预期的v2=3的结果。volatile变量会在汇编代码中增加一个lock的操作，该操作相当于一个内存屏障(Memory Barrier)，lock操作可以使得本CPU的cache写入内存，同时该写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于对Cache中的变量做了一次“write和store”操作，所以就可让volatile的变量对其它CPU立即可见，也即第一条特性的原理。这条lock操作也保证了之前的操作都已经执行完毕，就形成了“指令重排序无法越过内存屏障”的效果。

java内存模型对volatile变量定义时有一些特殊规则，比如volatile变量进行use的前一步动作必须是load，load的下一个动作必须是use，assign的下一个动作必须是store，store的上一个动作必须是assign，先被use/assign的变量也会先被read/write。

java内存模型允许64位的double和long的没有被volatile修饰的变量读写操作可划分为两次32位的操作，也即是多个线程共享一个未被声明为volatile的long或double的变量时，可能会存在读取到半个变量被其它线程修改、半个变量还未被修改的情况。java内存模型虽然允许这么实现，但却强烈建议虚拟机把long和double变量的读写实现成原子操作。目前各种商用虚拟机几乎都是将其作为原子操作实现的。

java内存模型主要围绕着并发过程中的原子性、可见性和有序性3个特征建立的。

        原子性操作即包含read、load、assign、use、store和write，可以认为基本数据类型的访问读写都是原子性的(double、long非原子性协定为例外，但无需额外注意)，更大范围的原子性可以通过java内存模型提供的lock和unlock来满足，虚拟机提供了字节码命令monitorenter和monitorexit来隐式地使用这两个操作，对应的java代码就是同步块synchronized关键字。

         可见性是指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。之前提到过java内存模型是通过主内存作为传递媒介的方式实现的可见性，无论是普通变量还是volatile变量都是如此，区别在于volatile变量保证变量更新后可立即同步至主内存，被使用时可立即从主内存刷新，所以volatile保证了多线程操作时变量的可见性，而普通变量不能保证这一点。除了volatile之外，java还有两个关键字synchronized和final也保证了可见性。synchronized的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中”这条规则获得的，而final的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器未传递“this”引用，那在其它线程中就能看见final的值。

        有序性是指操作的有序性，java程序天然的有序性就是“线程内有序，线程外无序”，即一个线程内都是串行的语义，而线程外由于“指令重排序”以及“工作内存和主内存同步延迟”的现象导致了一个线程观察另外一个线程时是无序的。java语言提供了volatile和synchronized两个关键字来保证操作的有序性。volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。

        java内存模型有序性不仅仅靠volatile和synchronized去完成，它有一个“先行发生”(happens-before)原则保证有序性。先行发生原则包含：程序次序原则(一个线程内，按照程序代码顺序，前面的操作先行发生于后面的操作，准确说是按照控制流顺序，因为存在分支、循环等结构)、管程锁定原则(一个unlock操作先行发生于后面对同一个锁的lock操作，“后面“指时间上的先后顺序)、volatile变量原则(对一个volatile变量的写操作先行发生于后面对这个变量的读操作，“后面”指时间上的先后顺序)、线程启动原则(Thread对象的start方法先行发生于此线程的每一个动作)、线程终止原则(线程中的所有动作先行发生于对此线程的终止检测)、线程中断原则(对线程interrupt方法的调用先行发生于被中断线程的代码检测到中断事件的发生)、对象终结原则(一个对象的初始化完成先行发生于它的finalize方法的开始)、传递性(如果操作A先行发生于操作B，操作B先行发生于操作C，则A先行于C)。

        并发不一定依赖多线程，php中会有多进程并发的情况，但是java中更多的是多线程的情况。线程比进程更轻量，也是CPU调度的基本单位，java.lang.Thread类中大多数关键方法都声明为Native的，Native方法就意味着该方法没有使用平台无关的手段实现，即内部实现与具体硬件和操作系统相关。线程的实现主要有3种方式：使用内核线程实现、使用用户线程实现、使用用户线程加轻量级进程混合实现。

        内核线程(Kernel-Level Thread)就是直接由操作系统内核(Kernel)支持的线程，这种线程由内核完成线程切换，内核通过操纵调度器(Scheduler)对线程进行调度，并负责将线程任务映射到各个处理器上，每个内核线程可视为内核的一个分身，这样操作系统就可以同时处理多件事情。程序一般不会直接调用内核线程，而是去使用内核线程的一个高级接口-轻量级内核进程(Light Weight Process，LWP)，轻量级进程就是我们通常意义上讲的线程，每个轻量级进程都由一个内核线程支持。这种轻量级进程和内核线程1:1的关系就称为一对一的线程模型。这种模式下每个轻量级进程都是一个独立的调度单元，即使一个轻量级进程阻塞了，也不影响整个进程的工作，但是由于轻量级进程基于内核线程实现，所以各种线程操作均需要进行系统调用，系统调用就会在用户态(User Model)和内核态(Kernel Mode)来回切换，代价相对较高，且轻量级进程要消耗一定的内核资源，因此一个系统支持轻量级进程的数量有限。

        使用用户线程实现即指线程完全建立在用户空间的线程库上，系统内核不能感知其存在。用户线程的操作完全在用户态中完成，可不需要切换到内核态，操作快速低消耗，也支持规模更大的线程数量，这种进程与用户线程之间1:N的关系称为一对多的线程模型，但是用户线程由于没有内核的支援，处理阻塞问题、多处理器系统的线程映射等问题就很难解决。因此现在使用用户线程的程序越来越少了。

        使用用户线程加轻量级进程混合实现就是将前两者方式结合在一起，这种模式下，即存在用户线程、也存在轻量级进程，用户线程还是在用户空间中，线程的操作依然快速低消耗，而轻量级进程作为用户线程和内核线程之间的桥梁，就可以使用内核提供的线程调度和处理器映射等功能，这种模式下，用户线程和轻量级进程的数量比不定，就是多对多的线程模型。

        线程调度分为协同式线程调度(Cooperative Thread-Scheduling)和抢占式线程调度(Preemptive Threads-Scheduling)，协同式即是用多久cpu由线程自己决定，线程执行完工作后再通知系统切换到另外一个线程，如果一个线程编写出问题导致死循环就会导致程序一直阻塞，甚至可能导致系统崩溃。抢占式即是抢占cpu时间片，例如cpu每100ms就调用一个线程，下一个100ms切换至另一个线程，由排队的线程之间去抢占cpu的执行时间。java采用的就是抢占式调度。这种情况当一个进程出问题后，还可以通过类似任务管理器杀掉该进程。java抢占式调度时可以通过设置线程优先级“建议”系统给某些线程多分配执行时间，另一些线程少分配时间，但是java的线程优先级并不靠谱，因为它是通过映射到系统的原生线程上实现的，虽然很多线程都提供线程优先级，但优先级不一定和java线程优先级一致，如java线程有10个优先级，但是Solaris中有2的32次方种优先级，多的话可以留空位映射，像Windows中只有7种优先级时，就会出现java几个优先级映射到相同优先级的情况。而且线程优先级也并不太靠谱，优先级实际运行中也可能被各个系统自行优化改变。