当前位置：首页 > news >正文

Java内存模型与线程

news 2025/6/17 11:21:56

硬件的效率和一致性

充分利用计算机处理器的能力：大量的时间都花费在磁盘I/O、网络通信或者数据库访问上，让计算机同时处理几项任务。

计算机并发执行若干个运算任务：

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

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

缓存一致性（Cache Coherence）:在多路处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），这种系统称为共享内存多核系统（Shared Memory Multiprocessors System），如图所示。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。如果真的发生这种情况，那同步回到主内存时该以谁的缓存数据为准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly及Dragon Protocol等。

内存模型:它可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型，而Java虚拟机也有自己的内存模型，并且与这里介绍的内存访问操作及硬件的缓存访问操作具有高度的可类比性。

乱序执行：除了增加高速缓存之外，为了使处理器内部的运算单元能尽量被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序执行的结果重组，保

证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，Java虚拟机的即时编译器中也有指令重排序（Instruction Reorder）优化。

java内存模型

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

在此之前，主流程序语言（如C和C++等）直接使用物理硬件和操作系统的内存模型。因此，由于不同平台上内存模型的差异，有可能导致程序在一套平台上并发完全正常，而在另外一套平台上并发访问却经常出错，所以在某些场景下必须针对不同的平台来编写程序。

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

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

内存间的交互操作

lock（锁定）:给主内存的变量上锁，把一个变量标识为一条线程独占的状态。（主）

unlock（解锁）:解锁该变量。（主）

read（读取）：作用于主内存的变量，将变量从主内存到工作内存，方便load使用。（主）

load（载入）：将read操作读取到的变量放到工作内存的变量副本中。（工作）

use（使用）：工作内存中的变量传递给执行引擎，每当虚拟机遇到需要使用该变量的值的字节码指令时就会执行该操作。（工作）

assign（赋值）：执行引擎中接收的值赋给工作内存中的变量，每当虚拟机遇到一个给变量赋值的字节码指令时就会执行该操作。（工作）

store（存储）：将工作内存变量的值传到主内存，给后面的write操作使用。（工作）

write（写入）：把store操作得到的变量值放入主内存的变量中。

注意：

read和load一起使用，从主内存读取数据，store和write一起使用，工作内存写回主内存，不允许只出现一个，他们中间可以有其他的操作；

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

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

不允许丢弃他最近的assign操作，就是变量再工作内存中改变了之后，要同步回主内存；

不允许线程无原因的（未发生任何assign操作）就把工作内存的数据同步回主内存。

一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或

assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作；

·一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执

行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁；

·如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量

前，需要重新执行load或assign操作以初始化变量的值；

·如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个

被其他线程锁定的变量；

·对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）；

volatile型变量的特殊操作

是Java虚拟机提供的最轻量级的同步机制，但是很多程序员都习惯去避免使用它，遇到需要处理多线程数据竞争问题的时候一律使用synchronized关键字或者java.util.concurrent包里面的锁来进行同步。

一个变量被定义为volatile将具备的特性

可见性：第一项是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的，对于普通的变量就不行，因为普通变量要先写回主存中，新变量值才会对另一线程可见。

对volatile变量所有的写操作都能立刻反映到其他线程之中。换句话说，volatile变量在各个线程中是一致的。

误区：基于volatile变量的运算在并发下是线程安全的，volatile变量在各个线程的工作内存中是不存在一致性问题的（从物理存储的角度看，各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题），但是Java里面的运算操作符并非原子操作，这导致volatile变量的运算在并发下一样是不安全的。

禁止指令重排序优化：volatile变量禁止指令重排序优化，普通变量可以，也就是所有用到变量的地方的结果正确，但是中间的执行顺序不一定按照原来的代码顺序执行。因为在同一个线程的方法执行过程中无法感知到这点，这就是Java内存模型中描述的所谓“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics）。

volatile的性能

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

volatile和synchronized：由于虚拟机对锁实行的许多消除和优化，使得我们很难确切地说volatile就会比synchronized快上多少，大多数场景下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修饰的变量不会被指令重排序优化，从而保证代码的执行顺序与程序的顺序相同。

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

非原子性协议：Java内存模型要求lock、unlock、read、load、assign、use、store、write这八种操作都具有原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性，这就是所谓的“long和double的非原子性协定”（Non-Atomic Treatment of double and long Variables）。

如果一个long或double变量未被volatile修饰，当多个线程共享时，可能会出现访问的值是“半个变量”的数值，但是是非常罕见的。在目前主流平台下商用的64位Java虚拟机中并不会出现非原子性访问行为。

了解：

对于32位的Java虚拟机，譬如比较常用的32位x86平台下的HotSpot虚拟机，对long类型的数据确实存在非原子性访问的风险。从JDK 9起，HotSpot增加了一个实验性的参数-XX：+AlwaysAtomicAccesses（这是JEP 188对Java内存模型更新的一部分内容）来约束虚拟机对所有数据类型进行原子性的访问。而针对double类型，由于现代中央处理器中一般都包含专门用于处理浮点数据的浮点运算器（Floating Point Unit，FPU），用来专门处理单、双精度的浮点数据，所以哪怕是32位虚拟机中通常也不会出现非原子性访问的问题，实际测试也证实了这一点。笔者的看法是，在实际开发中，除非该数据有明确可知的线程竞争，否则我们在编写代码时一般不需要因为这个原因刻意把用到的long和double变量专门声明为volatile。

原子性、可见性、有序性

**原子性（Automicity）：原子性指的是一个操作要么全部执行成功，要么全部不执行，不会出现执行一半的情况。**read、load、assign、use、store、write这六个操作可以直接保证原子性，可以大致认为基本数据类型的访问和读写操作都是具备原子性的（列外就是long、double）。

使用更大范围的原子性：java内存模型提供lock和unlock操作，尽管虚拟机未把操作开放给用户使用，但是提供了字节码指令monitorenter、monitorexit来隐式使用这操作，对应java代码就是synchronized关键字，因此在synchronized块之间的操作也具有原子性。

**可见性（Visibility）: **一个线程修改了变量的值后，在另一个线程中可以立即得知这个修改，java的内存模型不论是对于普通变量还是volatile变量，是通过在变量修改后将新值同步回主内存，在变量读取前从内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的。

volatile可保证新值能立即同步到主内存，及每次使用前立即从主内存刷新。我们可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证。

final和synchronized也可以实现可见性，synchronized是通过对一个变量执行unlock操作前，必须先将他同步回主内存中（store和write实现）；被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那么在其他线程中就能看见final字段的值。

this逃逸： **** 在 Java 程序中，类的构造器构造还未彻底完成前（即实例初始化阶段还未完成），将自身 this 引用向外抛出并被其他线程复制（访问）了该 this 引用，就可能会访问到该 this 还未被初始化的变量，甚至可能会造成更大严重的问题。

有序性（Ordering）： 有序性是指程序操作的执行顺序与代码中书写的顺序一致。可以使用通过使用synchronized或volatile来控制有序性，确保重要操作按照预期顺序执行。volatile禁止指令重排序，而synchronized是一个变量在一段时间内，只允许一条线程对其进行lock操作。