深入理解Java虚拟机（周志明第三版）- 第十二章：Java内存模型与线程

系列文章目录

第一章： 走近Java
第二章： Java内存区域与内存溢出异常
第三章： Java垃圾收集器与内存分配策略

---

一、概述

        多任务处理是现代计算机几乎必备的功能，不仅是因为计算机的运算能力强大了，还有一个很重要的原因是计算机的运算速度与它的存储和通信子系统的速度差距太大，大量的时间花费在磁盘IO、网络通信或数据库访问上，为了不希望处理器在大部分时间里都处于等待其他资源的空闲状态，就必须使用一些手段压榨处理器的运算能力，否则会造成很大的性能浪费，而让计算机同时处理几项任务则是最容易想到的，也被证明是非常有效的压榨手段。

        另外一种更具体的并发应用场景就是一个服务端同时对多个客户端提供服务。衡量一个服务性能的好坏，每秒事务处理数（TPS）是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS与程序的并发能力有非常密切的关系。对于计算量相同的任务，线程并发协调越有条不紊，效率越高；线程间竞争频繁，互相阻塞甚至死锁，将会大大降低程序并发能力。

        服务端应用是Java语言擅长的领域之一。而Java语言和虚拟机提供了许多工具，将并发编程的门槛降低了不少，且各种中间件、各类框架等也可能隐藏线程并发细节，使得程序员在编码时更关注业务逻辑。

但是无论语言、中间件和框架再如何先进，开发人员都不应期望它们能独立完成所有并发处理的事情，了解并发的内幕仍然是成为一个高级程序员不可缺少的课程。

---

二、硬件的效率和一致性

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

什么是缓存一致性问题？如何解决？
在多路处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存，这种系统成为共享多核系统，当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，如果发生这种情况，那同步回到主内存时该以谁的缓存数据为准呢？为了解决一致性问题，需要各个处理器访问缓存时遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI等。

内存模型可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型。

除了增加高速缓存之外，为了使处理器内部的运算单元能尽量被充分使用，处理器可能会对输入代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，Java虚拟机的即时编译器也有指令重排序优化。

---

三、Java内存模型

Java内存模型屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。

1、主内存与工作内存

        Java内存模型的主要目的是定义了程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层操作细节。这里的变量包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不存在竞争问题，且为了获得更好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器是否需要进行调整代码执行顺序这类优化措施。

Java内存模型规定了所有的变量都存储在主内存中，每个线程还有自己的工作内存（类比高速缓存），线程的工作内存中保存了该线程使用的变量的主内存副本，线程对变量的所有读写操作都必须在工作内存中进行，而不能直接读写主内存中的数据，不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递都需要通过主内存来完成。如图：

2、内存间交互

        关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节。Java内存模型定义了以下8种操作来完成，Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的：

• lock（锁定）：作用于主内存的变量，将一个变量标识为一条线程独占的状态
• unlock（解锁）：作用于主内存的变量，将一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
• read（读取）：作用于主内存的变量，将一个变量的值从主内存传输到线程的工作内存中，以便随后的load使用
• load（载入）：作用于工作内存的变量，将read操作读取的变量值放入工作内存的变量副本中
• use（使用）：作用于工作内存的变量，将工作内存中变量值传递给执行引擎，每当虚拟机遇到需要使用变量值的字节码指令时将执行该操作
• assign（赋值）：作用于工作内存的变量，将从执行引擎接收的值赋给工作内存的变量，每当虚拟机遇到给变量赋值的字节码指令时执行该操作
• store（存储）：作用于工作内存的变量，将工作内存中一个变量的值传送到主内存中，以便随后的write使用
• write（写入）：作用于主内存的变量，将store操作从工作内存取到的变量值放入主内存的变量中

如果将一个变量从主内存拷贝到工作内存中，就要按顺序执行read和load操作，如果把变量从工作内存同步回主内存，就要按顺序执行store和write操作。Java内存模型只要求上述两个操作必须顺序执行，但不要求是连续执行，即可能：read:a read:b load:b load:a。除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则：

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

3、对于volatile型变量的特殊规则

关键字volatile是虚拟机提供的最轻量级的同步机制。

变量修饰为volatile有什么用？
1、保证此变量对所有线程的可见性，即当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的，而普通变量的值在线程间传递时均需要通过主内存来完成，例线程A修改一个普通变量的值后，然后向主内存进行回写，另外一条线程B在线程A回写完成后再对主内存进行读取操作，新变量值才对线程B可见。

volatile变量在各个线程的工作内存中是不存在一致性问题的（物理存储角度看，各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题，但是Java里运算操作符并非原子操作（自增++、自减–等），这导致volatile变量的运算在并发下一样是不安全的）
        
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景下，仍然要通过加锁（synchronized、current并发包中的锁或原子类）来保证原子性：
        -运算结果不依赖变量的当前值，或者确保只有单一的线程修改变量值
        -变量不需要与其他的状态变量共同参与不变约束

2、禁止指令重排序优化，普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致

4、针对long和double变量的特殊规则

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

5、原子性、可见性与有序性

原子性

由Java内存模型直接保证的原子性变量操作包括read、load、assign、use、store和write这6个，大致可以认为，基本数据类型的访问、读写都是原子性的，此外更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足需求，如更高层次的字节码指令monitorenter和monitorexit来隐式地使用，这两个字节码指令反映到Java代码中就是同步块-synchronized关键字

可见性

指当一个线程修改了变量值后，其他线程能够立即得知这个修改。volatile变量的特殊规则保证了新值能立即同步到主内存中，以及每次使用前立即从主内存刷新。

有序性

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

6、先行发生规则

为什么有这个规则？
如果Java内存模型中所有的有序性都依靠volatile和synchronized来完成，那么将会有很多操作变得非常啰嗦，但是我们在编写Java程序时并没有察觉到这一点，就是因为Java语言中有一个先行发生原则

什么是先行发生？
先行发生是Java内存模型中定义的两项操作之间的偏序关系。例如操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能够被操作B观察到，"影响"包括了修改内存中共享变量的值、发送消息、调用了方法等。

什么是Java内存模型的先行发生规则？

• 程序次序规则：在一个线程内，按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作
• 管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作
• volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作
• 线程启动规则：Thread对象的start()方法先行发生于此线程的每个动作
• 线程终止规则：线程中所有操作都先行发生于对此线程的终止检测
• 线程中断规则：对线程interrupt()方法的调用先行发生于被中断的代码检测到中断事件的发生
• 对象终结规则：一个对象的初始化操作先行发生于它的finalize()方法的开始
• 传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那么可以得出操作A先行发生于操作C

Java内存模型的先行发生规则有什么用？
满足上述先行发生规则的场景无需使用任何同步手段保障。

---

四、Java与线程

1、线程的实现

线程是比进程更轻量级的调度执行单元，线程的引入可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源（内存地址、文件IO等），又可以独立调度。

实现线程主要有三种方式：

使用内核线程实现（1:1实现）

内核线程指直接由操作系统内核支持的线程，由内核来完成线程切换，内核通过操纵调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。

轻量级进程是内核线程的一种高级接口，也是我们通常意义讲的线程，每一个轻量级进程都由一个内核线程支持。

优劣：
每个轻量级进程都成为一个独立的调度单元，即使其中一个轻量级进程阻塞了，也不会影响整个进程继续工作。但由于是基于内核线程实现的，各种线程操作需要进行系统调用，代价相对较高，需要在用户态和内核态来回切换，且一个轻量级进程对应一个内核线程，轻量级进程要消耗一定的内核资源（内核线程的栈空间），因此一个系统支持轻量级进程的数据是有限的

使用用户线程实现（1：N实现）

用户线程指完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。用户线程的创建、同步、销毁、调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也能够支持更大的线程数量。

优劣：
用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核支援，所有的线程操作都需要用户程序自己去处理，因此用户线程实现的程序通常都比较复杂。

使用用户线程加轻量级进程混合实现（N:M实现）

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

Java线程如何实现

Java线程的实现并不受Java虚拟机规范的约束，这是一个与具体虚拟机相关的话题。
目前主流平台上的主流商用虚拟机的线程模型普遍使用基于操作系统原生线程模型实现，即1:1实现模型

Hotspot虚拟机中，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以Hotspot是不会干涉线程调度的，全权交给底层的操作系统去处理。

2、Java线程调度

线程调度指系统为线程分配处理器使用权的过程，调度主要方式有两种：协同式线程调度和抢占式线程调度。

协同式线程调度：
指线程的执行时间由线程本身控制，线程把自己的工作执行完后，要主动通知系统切换到另外一个线程上去。协同式调度的好处是实现简单且切换动作对自己本身是可知的，一般没有什么线程同步的问题；坏处是线程执行时间不可控，可能会一个线程阻塞影响整个进程或系统

抢占式线程调度：
指每个线程的执行时间由系统来分配，线程的切换不由线程本身决定。在这种实现线程调度方式下，线程的执行时间是系统可控的，也不会因为一个线程导致整个进程或系统阻塞

Java使用的线程调度方式是抢占式线程调度。Java语言一共设置了10个级别的线程优先级。当两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行（线程优先级并不是一项稳定的调节手段）。

3、状态转换

Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一个状态，并且可以通过特定的方法在不同状态之间转换：

• 新建（New）：创建后尚未启动的线程处于这种状态
• 运行（Runnable）：包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着操作系统为它分配执行时间
• 无限期等待（Waiting）：处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线程显式唤醒。以下方法会让线程陷入无限期的等待状态：没有设置Timeout参数的Object::wait()方法；没有设置Timeout参数的Thread::join()方法；LockSupport::park()方法。
• 限期等待（Timed Waiting）：处于这种状态的线程也不会被分配处理器执行时间，不过无须等待被其他线程显式唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状 态：Thread::sleep()方法；设置了Timeout参数的Object::wait()方法；设置了Timeout参数的Thread::join()方法；LockSupport::parkNanos()方法；LockSupport::parkUntil()方法
• 阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时 间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态
• 结束（Terminated）：已终止线程的线程状态，线程已经结束执行

---

五、Java与协程（了解即可）

1、内核线程的局限

目前Java线程面临的困境：对Web应用的服务要求，不论是在请求数量上还是在复杂度上，与十多年前相比已不可同日而语，这一方面是源于业务量的增长，另一方面来自于为了应对业务复杂化而不断进行的服务细分。现代B/S系统中一次对外部业务请求的响 应，往往需要分布在不同机器上的大量服务共同协作来实现，这种服务细分的架构在减少单个服务复杂度、增加复用性的同时，也不可避免地增加了服务的数量，缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算，这样组合多个服务的总耗时才不会太长；也要求每一个服务提供者都要能同时处理数量更庞大的请求，这样才不会出现请求由于某个服务被阻塞而出现等待。

Java目前的并发编程机制就与上述架构趋势产生了一些矛盾，1：1的内核线程模型是如今Java虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。以前处理一个请求可以允许花费很长时间在单体应用中，具有这种线程切换的成本也是无伤大雅的，但现在在每个请求本身的执行时间变得很短、数量变得很多的前提下， 用户线程切换的开销甚至可能会接近用于计算本身的开销，这就会造成严重的浪费

2、协程的复苏

为什么内核线程调度切换成本高？
内核线程的调度成本主要来自于用户态与内核态之间的状态转换，而这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本

协程的主要优势是轻量。在64位Linux上HotSpot的线程栈容量默认是1MB，此外内核数据结构还会额外消耗16KB内存。与之相对的，一个协程的栈通常在几百个字节到几KB之间，所以Java虚拟机里线程池容量达到两百就已经不算小了，而很多支持协程的应用中，同时并存的协程数量可数以十万计

协程的局限是需要在应用层面实现的内容特定多

3、Java的解决方案

---

六、附录