深入理解Java虚拟机（第3版）学习笔记——Java 内存模型与线程（超详细）_深入理解java虚拟机深入理解java内存模型-CSDN博客

本文链接：https://blog.csdn.net/qq_53578500/article/details/126074793

深入理解Java虚拟机（第3版）学习笔记——Java 内存模型与线程（超详细）

12.1 概述

服务端的应用是Java语言最擅长的领域之一，各种中间件服务器、各类框架也都努力地替程序员隐藏尽可能多的线程并发细节，使得程序员在编码时能更关注业务逻辑，而不是花费大部分时间去关注此服务会同时被多少人调用、如何处理数据争用、协调硬件资源。但是无论语言、中间件和框架再如何先进，开发人员都不应期望它们能独立完成所有并发处理的事情，了解并发的内幕仍然是成为一个高级程序员不可缺少的课程。

衡量一个服务端性能的高低好坏，每秒事务处理数（Transactions Per Second， TPS）是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS值与程序的并发能力又有非常密切的关系。

12.2 硬件的效率与一致性

高速缓存：计算机系统加入了一层或多层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲。

内存（几乎所有计算机的存储设备）的读写操作与处理器的运算速度有着几个数量级的差距

引入高速缓存后的好处：将运算需要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

引入高速缓存后产生的问题：

缓存一致性问题：
- 前提：在多核处理器系统中，每个处理器都有各自相互独立的高速缓存，并且它们共享同一内存
- 当多个处理器的操作涉及到同一份内存时，肯能会导致各自的缓存不一致
为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI（Illinois Protocol）、MOSI、 Synapse、Firefly及Dragon Protocol等。

处理器、高速缓存、主内存间的交互关系：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uHGleTvv-1659171834256)(D:\note\笔记仓库\图片\image-20220729110405830.png)]$

12.3 Java内存模型

《Java虚拟机规范》中曾试图定义一种“Java内存模型” （Java Memory Model，JMM）来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。

12.3.1 主内存与工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节

注意：此处的变量只针对线程共享的变量，例如实例字段、静态字段和数组的元素；不包括一些线程私有的变量，例如局部变量和方法参数

Java内存模型：

Java内存模型规定了所有的变量都存储在主内存中（物理上它仅是虚拟机内存的一部分）。
每条线程有自己的工作内存（Working Memory，可与前面讲的处理器高速缓存类比）
线程的工作内存中存了被该线程使用的变量的主内存副本

假设线程中访问一个10MB大小的对象，也会把这10MB的内存复制一份出来吗？

事实上并不会如此，这个对象的引用、对象中某个在线程访问到的字段是有可能被复制的，但不会有虚拟机把整个对象复制一次
线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。
不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，
线程、主内存、工作内存三者的交互关系如图12- 2所示，注意与图12-1进行对比

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-anAlIpl0-1659171834257)(D:\note\笔记仓库\图片\image-20220729111357566.png)]$

12.3.2 内存间交互操作

一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节，Java内存模型中定义了以下8种操作（除了double、long类型外，每一种操作都是原子的、不可再分的）来完成：

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

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操作）。

Java内存模型的操作简化为read、write、lock和unlock四种，但这只是语言描述上的等价化简，Java内存模型的基础设计并未改变

如何确定一个操作在并发环境下是否安全？

先行发生原则：后面会介绍

12.3.3 对于volatile型变量的特殊规则

当一个变量被定义成volatile之后，它将具备两项特性：

可见性：保证此变量对所有线程的可见性：某个线程对变量的修改，其它线程可见

一个被定义为volatile类型的变量被修改后，会被直接写入主内存，并通知其它线程的工作内存中的该变量缓存失效。之后访问该变量的时候，都需要去主内存中访问。
有序性：禁止指令重排序优化

通过内存屏障来实现，在内存屏障之后的代码不可以重排序到内存屏障之前的代码。

由于volatile变量不保证原子性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁（使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性： ·

运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
变量不需要与其他的状态变量共同参与不变约束（类中的各个字段有相互依赖的关系）。

通过双锁检测（Double Check Lock，DCL）单例代码来更近一步说明什么volatile怎么防止重排序：

代码清单12-5 DCL单例模式

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变量赋值的部分如代码清单12-6所示。

代码清单12-6 对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)”==操作

内存屏障：Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置
这个操作的作用相当于一个内存屏障，只有一个处理器访问内存时，并不需要内存屏障；但如果有两个或更多处理器访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。
这里的关键在于==lock前缀，查询IA32手册可知，它的作用是将本处理器的缓存写入了内存，该写入动作也会引起别的处理器或者别的内核无效化（Invalidate）其缓存==，这种操作相当于对缓存中的变量做了一次前面介绍Java内存模式中所说的“store和write”操作

我们再回头来看看Java内存模型中对volatile变量定义的特殊规则的定义

假定T表示一个线程，V和W分别表示两个volatile型变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：

只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作；并且，只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。线程T对变量V的use动作可以认为是和线程T对变量V的load、read动作相关联的，必须连续且一起出现。

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

这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改。
volatile修饰的变量不会被指令重排序优化，从而保证代码的执行顺序与程序的顺序相同

12.3.4 针对long和double型变量的特殊规则

前面说过，Java内存模型对要求lock、unlock、read、load、assign、use、store、write这八种操作都具有原子性，但是对于64位的数据类型**（long和double）**，在模型中特别定义了一条宽松的规定：

允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行
long和double的非原子性协定（Non-Atomic Treatment of double and long Variables）。允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性

由于非原子性协定，对long和double类型的变量可能会造成线程不安全（经测验、概率及其小）

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

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

1.原子性（Atomicity）

基本数据类型的访问、读写都是具备原子性的（例外就是long和double的非原子性协定）

如果应用场景需要一个更大范围的原子性保证可通过synchronized和juc下的包实现。

通过字节码指令monitorenter和monitorexit来隐式地实现java内存模型的lock和unlock操作

2.可见性（Visibility）

可见性就是指当一个线程修改了共享变量的值时，其他线程能够立即得知这个修改

Java中是如何实现可见性的？

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此。

普通变量与volatile变量的区别是：

volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

synchronized和final也能保证可见性：

同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）”这条规则获得的。
而final关键字的可见性是指：被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去，那么在其他线程中就能看见final字段的值。

3.有序性（Ordering）

有序性其实是针对多个线程互相观察才产生的

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。

前半句是指“线程内似表现为串行的语义”（Within-Thread As-If-Serial Semantics）
后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

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

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

12.3.6 先行发生原则

“先行发生”原则：先行发生是Java内存模型中定义的两项操作之间的偏序关系，比如说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到

“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等

Java内存模型下一些==“天然的”先行发生关系==，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用：

程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
管程锁定规则（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()方法检测到是否有中断发生。
对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize()方法的开始。
传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

由于Java中线程争夺CPU资源是采用抢占式的机制：所以**“时间上的先发生”并不代表这个操作会是”先行发生“**

12.4 Java与线程

Java语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理

Thread类的大部分方法被Native修饰，

12.4.1 线程的实现

实现线程主要有三种方式：使用内核线程实现（1：1实现），使用用户线程实现（1：N实现），使用用户线程加轻量级进程混合实现（N：M实现）。

1.内核线程实现

内核线程：每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就称为多线程内核。内核线程（Kernel-Level Thread，KLT）也就是直接由操作系统内核（Kernel，下称内核）支持的线程

使用内核线程实现的方式也被称为1：1实现。

程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Y4SoV8n4-1659171834258)(D:\note\笔记仓库\图片\image-20220729130327738.png)]$

如何完成线程切换？

由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。

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

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

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

2.用户线程实现

使用用户线程实现的方式被称为1：N实现。

广义上的用户线程：一个线程只要不是内核线程，都可以认为是用户线程。广义上来看，轻量级进程也属于用户线程

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jYt5aKpe-1659171834259)(D:\note\笔记仓库\图片\image-20220729130859143.png)]$

侠义上的用户线程：

侠义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。
用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态

缺点：

由于没有系统内核的支援，所有的线程操作都需要由用户程序自己去处理。

线程的创建、销毁、切换和调度都是用户必须考虑的问题

在多处理器系统中，有一些问题解决起来很困难，甚至无法实现。

3.混合实现

将内核线程与用户线程一起使用的实现方式，被称为N：M实现

在这种混合实现下，既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。

4.Java线程的实现

JDK 2以前采用用户线程的方式实现

JDK 3以后，以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的

12.4.2 Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，调度主要方式有两种：

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

优点：实现简单，切换操作对于线程来说可见

缺点：如果一个线程中编写的代码有问题，那么很容易造成阻塞效果
抢占式调度：每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定

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

缺点：如果想要主动获取执行时间，线程本身是没有什么办法的。需要等待其它线程唤醒

Java使用的是抢占式调度，可通过设置优先级的方式”建议“操作系统给某些线程多分配一些时间。

12.4.3 状态转换

Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并且可以通过特定的方法在不同状态之间转换。这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）：已终止线程的线程状态，线程已经结束执行。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zDYkD1SE-1659171834260)(D:\note\笔记仓库\图片\image-20220729132436221.png)]$

12.5 Java与协程

12.5.1 内核线程的局限

1：1的内核线程模型是如今Java虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。

12.5.2 协程的复苏

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

什么是协程？

协程：我们又称为微线程，协程它不像线程和进程那样，需要进行系统内核上的上下文切换，协程的上下文切换是由开发人员决定的

协程是一种用户级的轻量级线程。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈。因此：

协程能保留上一次调用时的状态（即所有局部状态的一个特定组合），每次过程重入时，就相当于进入上一次调用的状态，换种说法：进入上一次离开时所处逻辑流的位置。

携程的核心概念

协程的概念最核心的点其实就是函数或者一段程序能够被挂起（说暂停其实也没啥问题），待会儿再恢复

由此可见，协程的优点如下：

轻量：无需系统内核的上下文切换，减小开销；
无需原子操作锁定及同步的开销，不用担心资源共享的问题；
单线程即可实现高并发，单核 CPU 即便支持上万的协程都不是问题，所以很适合用于高并发处理，尤其是在应用在网络爬虫中

协程的缺点

无法使用 CPU 的多核

程的本质是个单线程，它不能同时用上单个 CPU 的多个核，协程需要和进程配合才能运行在多
CPU上。当然我们日常所编写的绝大部分应用都没有这个必要，就比如网络爬虫来说，限制爬虫的速度还有其他的因素，比如网站并发量、网速等问题都会是爬虫速度限制的因素。除非做一些密集型应用，这个时候才可能会用到多进程和协程。
处处都要使用非阻塞代码

写协程就意味着你要一值写一些非阻塞的代码，使用各种异步版本的库