[JVM]了断局:内存模型与线程

系统管理员 2022-12-01 01:18 174阅读 0赞

--------------------

# 一.前言 #

Java内存模型的主要目的是定义程序中各种变量的访问规则， 即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。 Java内存模型规定了所有的变量都存储在主内存（Main Memory） 中（此处的主内存与介绍物理硬件时提到的主内存名字一样， 两者也可以类比， 但物理上它仅是虚拟机内存的一部分） 。 每条线程还有自己的工作内存（Working Memory， 可与前面讲的处理器高速缓存类比） ， 线程的工作内存中保存了被该线程使用的变量的主内存副本， 线程对变量的所有操作（读取、 赋值等） 都必须在工作内存中进行， 而不能直接读写主内存中的数据。 不同的线程之间也无法直接访问对方工作内存中的变量， 线程间变量值的传递均需要通过主内存来完成.

**线程、 主内存、 工作内存三者的交互关系:**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70][]

# 二.内存间交互操作 #

关于主内存与工作内存之间具体的交互协议， 即一个变量如何从主内存拷贝到工作内存、 如何从工作内存同步回主内存这一类的实现细节， Java内存模型中定义了以下8种操作来完成。 Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、 不可再分的（对于double和long类型的变量来说， load、 store、 read和write操作在某些平台上允许有例外

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

如果要把一个变量从主内存拷贝到工作内存， 那就要按顺序执行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操作） 。

# 三.对于volatile型变量的特殊规则 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 1][]

当一个变量被定义成volatile之后， 它将具备两项特性： 第一项是保证此变量对所有线程的可见性， 这里的“可见性”是指当一条线程修改了这个变量的值， 新值对于其他线程来说是可以立即得知的。 而普通变量并不能做到这一点， 普通变量的值在线程间传递时均需  
要通过主内存来完成。 比如， 线程A修改一个普通变量的值， 然后向主内存进行回写， 另外一条线程B在线程A回写完成了之后再对主内存进行读取操作， 新变量值才会对线程B可见。

> 由于volatile变量只能保证可见性， 在不符合以下两条规则的运算场景中， 我们仍然要通过加锁（使用synchronized、 java.util.concurrent中的锁或原子类） 来保证原子性：
> 
>   
> ·运算结果并不依赖变量的当前值， 或者能够确保只有单一的线程修改变量的值。  
> ·变量不需要与其他的状态变量共同参与不变约束
> 
>

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

volatile变量读操作的性能消耗与普通变量几乎没有什么差别， 但是写操作则可能会慢上一些， 因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

> 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所做的修改。  
> ·假定动作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修饰的变量不会被指令重排序优化， 从而保证代码的执行顺序与程序的顺序相同。

# 四.原子性、 可见性与有序性 #

## 1.原子性（Atomicity） ##

由Java内存模型来直接保证的原子性变量操作包括read、 load、 assign、 use、 store和write这六个， 我们大致可以认为， 基本数据类型的访问、 读写都是具备原子性的. (例外: long和double的非原子性协定 小概率发生.)

在synchronized块之间的操作也具备原子性。

# 2.可见性（Visibility） #

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

除了volatile之外， Java还有两个关键字能实现可见性， 它们是synchronized和final。

# 3.有序性（Ordering） #

Java程序中天然的有序性可以总结为一句话：

> 如果在本线程内观察， 所有的操作都是有序的； 如果在一个线程中观察另一个线程， 所有的操作都是无序的。

前半句是指“线程内似表现为串行的语义”（Within-Thread As-If-Serial Semantics） ，

后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

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

# 五.先行发生原则 #

>  
> 
> ·**程序次序规则（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的结论。
> 
>

> 时间先后顺序与先行发生原则之间基本没有因果关系， 所以我们衡量并发安全问题的时候不要受时间顺序的干扰， 一切必须以先行发生原则为准

# 六.线程的实现 #

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

使用内核线程实现（1： 1实现） ， 使用用户线程实现（1： N实现） ， 使用用户线程加轻量级进程混合实现（N： M实现） 。

# #

## 1.内核线程实现 ##

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 2][]

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

**轻量级进程也具有它的局限性**： 首先， 由于是基于内核线程实现的， 所以各种线程操作， 如创建、 析构及同步， 都需要进行系统调用。 而系统调用的代价相对较高， 需要在用户态（User Mode） 和内核态（Kernel Mode） 中来回切换。 其次， 每个轻量级进程都需要有一个内核线程的支持， 因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间） ， 因此一个系统支持轻量级进程的数量是有限的.

# #

## 2.用户线程实现 ##

**使用用户线程实现的方式被称为1： N实现**。 广义上来讲， 一个线程只要不是内核线程， 都可以认为是用户线程（User Thread， UT） 的一种， 因此从这个定义上看， 轻量级进程也属于用户线程， 但轻量级进程的实现始终是建立在内核之上的， 许多操作都要进行系统调用， 因此效率会受到限制， 并不具备通常意义上的用户线程的优点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 3][]

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

用户线程的优势在于不需要系统内核支援， 劣势也在于没有系统内核的支援， 所有的线程操作都需要由用户程序自己去处理。 线程的创建、 销毁、 切换和调度都是用户必须考虑的问题， 而且由于操作系统只把处理器资源分配到进程， 那诸如“阻塞如何处理”“多处理器系统中如何将线程映射到其他处理器上”这类问题解决起来将会异常困难， 甚至有些是不可能实现的。 因为使用用户线程实现的程序通常都比较复杂， 除了有明确的需求外（譬如以前在不支持多线程的操作系统中的多线程程序、 需要支持大规模线程数量的应  
用） ， 一般的应用程序都不倾向使用用户线程。 Java、 Ruby等语言都曾经使用过用户线程， 最终又都放弃了使用它。

## 3.混合实现 ##

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 4][]

## 4.Java线程的实现 ##

以HotSpot为例， 它的**每一个Java线程都是直接映射到一个操作系统原生线程来实现的**， 而且中间没有额外的间接结构， 所以HotSpot自己是不会去干涉线程调度的（可以设置线程优先级给操作系统提供调度建议） ， 全权交给底下的操作系统去处理， 所以何时冻  
结或唤醒线程、 该给线程分配多少处理器执行时间、 该把线程安排给哪个处理器核心去执行等， 都是由操作系统完成的， 也都是由操作系统全权决定的。

# 七.Java线程调度 #

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

如果使用协同式调度的多线程系统， 线程的执行时间由线程本身来控制， 线程把自己的工作执行完了之后， 要主动通知系统切换到另外一个线程上去。协同式多线程的最大**好处是实现简单**， 而且由于线程要把自己的事情干完后才会进行线程切换， 切换操作对线程自己是可知的， 所以一般没有什么线程同步的问题。** 坏处也很明显：** 线程执行时间不可控制， 甚至如果一个线程的代码编写有问题，  
一直不告知系统进行线程切换， 那么程序就会一直阻塞在那里。

如果使用抢占式调度的多线程系统， 那么每个线程将由系统来分配执行时间， 线程的切换不由线程本身来决定。 譬如在Java中， 有Thread::yield()方法可以主动让出执行时间，但是如果想要主动获取执行时间， 线程本身是没有什么办法的。 在这种实现线程调度的方  
式下， 线程的执行时间是系统可控的， 也不会有一个线程导致整个进程甚至整个系统阻塞的问题。

虽然说Java线程调度是系统自动完成的， 但是我们仍然可以“建议”操作系统给某些线程多分配一点执行时间， 另外的一些线程则可以少分配一点——这项操作是通过设置线程优先级来完成的。 **Java语言一共设置了10个级别的线程优先级**（Thread.MIN\_PRIORITY至Thread.MAX\_PRIORITY  \[ 1 - 10 \]  ） 。 在两个线程同时处于Ready状态时， 优先级越高的线程越容易被系统选择执行。线程优先级并不是一项稳定的调节手段， 这不仅仅体现在某些操作系统上不同的优先级实际会变得相同这一点上， 还有其他情况让我们不能过于依赖线程优先级： 优先级可能会被系统自行改变， 例如在Windows系统中存在一个叫“优先级推进器”的功能（PriorityBoosting， 当然它可以被关掉） ， 大致作用是当系统发现一个线程被执行得特别频繁时，可能会越过线程优先级去为它分配执行时间， 从而减少因为线程频繁切换而带来的性能损耗。 因此， 我们并不能在程序中通过优先级来完全准确判断一组状态都为Ready的线程将会先执行哪一个。

# 八.状态转换 #

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 5][]

> **·新建（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） ： 已终止线程的线程状态， 线程已经结束执行

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]: /images/20221123/6ad2ac5d6cb946e19ceb26d1d6d5c249.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 1]: /images/20221123/2daac94856a14954aec9021f17cc9456.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 2]: /images/20221123/06d84be62f9349bc9a17f7cdd0b46e4f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 3]: /images/20221123/c250a0ea221140738918ec11d3e0201a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 4]: /images/20221123/5489c6053b974ca9ab7c26429e570c50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 5]: /images/20221123/d54c0ba479dd4c8995b8bc7555bea4ca.png