一文带你深入了解JMM（Java内存模型）

本文链接：https://blog.csdn.net/xjx666666/article/details/132132231

JMM（Java内存模型）详解

为什么要有内存模型？

要想回答这个问题，我们需要先弄懂传统计算机硬件内存架构。

硬件内存架构

在这里插入图片描述
（1）CPU

去过机房的同学都知道，一般在大型服务器上会配置多个CPU，每个CPU还会有多个核，这就意味着多个CPU或者多个核可以同时（并发）工作。如果使用Java 起了一个多线程的任务，很有可能每个 CPU 都会跑一个线程，那么你的任务在某一刻就是真正并发执行了。

（2）CPU Register

CPU Register也就是 CPU 寄存器。CPU 寄存器是 CPU 内部集成的，在寄存器上执行操作的效率要比在主存上高出几个数量级。

（3）CPU Cache Memory

CPU Cache Memory也就是 CPU 高速缓存，相对于寄存器来说，通常也可以成为 L2 二级缓存。相对于硬盘读取速度来说内存读取的效率非常高，但是与 CPU 还是相差数量级，所以在 CPU 和主存间引入了多级缓存，目的是为了做一下缓冲。

（4）Main Memory

Main Memory 就是主存，主存比 L1、L2 缓存要大很多。

注意：部分高端机器还有 L3 三级缓存。

缓存一致性问题

由于主存与 CPU 处理器的运算能力之间有数量级的差距，所以在传统计算机内存架构中会引入高速缓存来作为主存和处理器之间的缓冲，CPU 将常用的数据放在高速缓存中，运算结束后 CPU 再将运算结果同步到主存中。

使用高速缓存解决了 CPU 和主存速率不匹配的问题，但同时又引入另外一个新问题：缓存一致性问题。
在这里插入图片描述
在多CPU的系统中(或者单CPU多核的系统)，每个CPU内核都有自己的高速缓存，它们共享同一主内存(Main Memory)。当多个CPU的运算任务都涉及同一块主内存区域时，CPU 会将数据读取到缓存中进行运算，这可能会导致各自的缓存数据不一致。

因此需要每个 CPU 访问缓存时遵循一定的协议，在读写数据时根据协议进行操作，共同来维护缓存的一致性。这类协议有 MSI、MESI、MOSI、和 Dragon Protocol 等。

MSI协议在我看来和JMM规范很像，都是用来保证并发情况下的缓存一致性问题（MSI的并发是多处理器）。

JMM规范的原因

因为Java程序是多线程的，即使你运行的Java程序是单线程的，但在Java虚拟机（JVM）中仍然存在多线程执行的情况，比如GC线程、JIT编译线程等，JMM规范需要保证这些线程与主程序之间的数据同步和可见性，所以在我看来JMM是多线程编程的产物。如果是完全单线程那么就没有JMM规范的必要了，JMM规范（针对于Java多线程编程的规范）就是用来解决多线程编程中的并发问题的。

线程本地内存的原因

但是线程中本地线程的引入又是什么原因呢，多线程直接操作共享内存有并发安全问题（竞态条件：指多个线程对共享资源进行竞争和修改时，由于执行顺序的不确定性，导致最终结果出现错误或者不符合预期的情况），引入线程本地内存再写回共享内存不是也会有并发安全问题吗。

本地内存优点：

保存线程私有的数据：因为是线程私有的，所以只允许当前线程操作（对其他线程不可见）。但是如果没有本地内存，那么这些线程私有数据都需要存储到共享内存里面，那么这些线程私有数据在线程操作时也会有并发问题（其他线程可以操作），但是有了线程本地内存之后，这些线程私有数据就无需进行同步操作。所以线程本地内存的存在可以避免在线程在多线程编程中对共享数据进行同步带来的开销和复杂性（因为私有数据无需同步）。开销即减少多线程之间的竞争（共享数据操作会竞争，因为要保证数据一致性），降低开销就可以提高并发性能。复杂性指的是不用考虑一部分数据（线程私有数据）的并发安全性问题。
高效的内存访问：线程本地内存位于线程的工作内存中，而工作内存是CPU缓存的一部分。在处理器中访问缓存中的数据比访问主内存中的数据要快得多，因此使用线程本地内存可以提高内存访问的效率。

这两点就是本地内存引入的原因。

但是本地内存同样也会因为需要写回主内存，写回时就也有可能出现并发安全问题，因此JMM也对此写回操作做了规范。

因为我们无法避免Java多线程编程（性能的必要原因），那么因为多线程有并发安全问题，所以必须解决这个问题，因此就有JMM规范，JMM规范就是用来解决Java多线程编程带来的并发问题的。

处理器优化和指令重排序

为了提升性能在 CPU 和主内存之间增加了高速缓存，但在多线程并发场景可能会遇到缓存一致性问题。那还有没有办法进一步提升 CPU 的执行效率呢？答案是：处理器优化。

为了使处理器内部的运算单元能够最大化被充分利用，处理器会对输入代码进行乱序执行处理，这就是处理器优化。

除了处理器会对代码进行优化处理，很多现代编程语言的编译器也会做类似的优化，比如像 Java 的即时编译器（JIT）会做指令重排序。
在这里插入图片描述

处理器优化其实也是重排序的一种类型，这里总结一下，重排序可以分为三种类型：

编译器优化的重排序。编译器在不改变单线程程序语义放入前提下，可以重新安排语句的执行顺序。
指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序。由于处理器使用缓存和读写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

并发编程的问题

熟悉 Java 并发的同学肯定对这三个问题很熟悉：『可见性问题』、『原子性问题』、『有序性问题』。如果从更深层次看这三个问题，其实就是上面讲的『缓存一致性』、『处理器优化』、『指令重排序』造成的。
缓存一致性问题其实就是可见性问题，处理器优化可能会造成原子性问题，指令重排序会造成有序性问题，你看是不是都联系上了。

出了问题总是要解决的，那有什么办法呢？首先想到简单粗暴的办法，干掉缓存让 CPU 直接与主内存交互就解决了可见性问题，禁止处理器优化和指令重排序就解决了原子性和有序性问题，但这样一夜回到解放前了，显然不可取。

所以技术前辈们想到了在物理机器上定义出一套内存模型，规范内存的读写操作。内存模型解决并发问题主要采用两种方式：限制处理器优化和使用内存屏障。

JMM是什么？

同一套内存模型规范，不同语言在实现上可能会有些差别。我们这里仅学习 Java 内存模型实现原理。

JMM 是Java内存模型（ Java Memory Model），简称JMM，即实现Java并发的共享内存模型。它本身只是一个抽象的概念，并不真实存在，它描述的是一种规则或规范，是和多线程相关的一组规范。通过这组规范，定义了程序中对各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。需要每个JVM的实现都遵守这样的规范，有了JMM规范的保障，并发程序运行在不同的虚拟机上时，得到的程序结果才是安全可靠可信赖的。如果没有JMM内存模型来规范，就可能会出现，经过不同 JVM 翻译之后，运行的结果不相同也不正确的情况。

Java并发采用的是共享内存模型（而非消息传递模型），线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。多个线程之间是不能直接传递数据交互的，它们之间的交互只能通过共享变量来实现。同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。

但想搞懂JMM即Java内存模型，我认为必须先要知道内存模型的概念！

内存模型可以理解为在特定的操作协议下，对特定的内存（或者高速缓存）进行读写访问过程的抽象描述。不同架构下的物理机拥有不一样的内存模型，Java虚拟机是一个实现了**跨平台（JMM的原因）**的虚拟系统，因此它也有自己的内存模型，即Java内存模型（Java Memory Model： JMM）。Java内存模型描述了Java程序中各个变量（实例变量、静态变量以及数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节。

因此它不是对物理内存的规范，而是在虚拟机基础上衍生的规范，从而使JVM实现平台一致性，以达到Java程序能够“一次编写，到处运行”。

JMM结构规范大致如下：

JMM规定了所有的变量都存储在主内存（Main Memory）中。每个线程都有一个自己私有的工作内存（Working Memory）,线程的工作内存中保存了该线程使用到的主内存中的变量的副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量（volatile修饰的变量仍然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般）。不同的线程之间无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。

在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

主内存和本地内存结构

Java线程之间的通信由Java内存模型（JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。本地内存它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化之后的一个数据存放位置。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。

计算机在执行程序时，每条指令都是在CPU中执行的。而执行指令的过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程，跟CPU执行指令的速度比起来要慢的多（硬盘 < 内存 <缓存cache < CPU）。因此如果任何时候对数据的操作都要通过和内存的交互来进行的话就会大大降低指令执行的速度。因此在CPU里面就有了高速缓存，也就是当程序在运行过程中，会将运算所需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时，就可以直接从它的高速缓存中读取数据或向其写入数据了。当运算结束之后，再将高速缓存中的数据刷新到主存当中。

JMM 抽象出主存储器（Main Memory）和工作存储器（Working Memory）两种。
·主存储器是实例对象所在的区域，所有的实例都存在于主存储器内。比如，实例所拥有的字段即位于主存储器内，主存储器是所有的线程所共享的。
·工作存储器是线程所拥有的作业区，每个线程都有其专用的工作存储器。工作存储器存有主存储器中必要部分的拷贝，称之为工作拷贝（Working Copy）。
所以，线程无法直接对主内存进行操作，此外，线程A想要和线程B通信，只能通过主存进行。

Java 运行时内存区域与硬件内存的关系

了解过 JVM 的同学都知道，JVM 运行时内存区域是分片的，分为栈、堆等，其实这些都是 JVM 定义的逻辑概念。在传统的硬件内存架构中是没有栈和堆这种概念。

从图中可以看出栈和堆既存在于高速缓存中又存在于主内存中，所以两者并没有很直接的关系。

JMM的三大特性：

Java Memory Model(Java内存模型)是围绕着并发编程中可见性、原子性、有序性这三个特性而建立的模型。

原子性

一个操作（可能包含很多子操作）不能被打断，要么全部执行完毕，要么全部不执行。在这点上有点类似于事务操作，要么全部执行成功，要么回退到执行该操作之前的状态。

基本类型数据的访问大都是原子操作，long 和double类型的变量是64位，但是在32位JVM中，32位的JVM会将64位数据的读写操作分为2次32位的读写操作来进行，这就导致了long、double类型的变量在32位虚拟机中是非原子操作，数据有可能会被破坏，也就意味着多个线程在并发访问的时候是线程非安全的。

可见性

只要有一个线程对共享变量的值做了修改，其他的线程立即能够看到（感知到）该变量的这次修改（变化）。

Java内存模型是通过将在工作内存中的变量修改后的值同步到主内存，在读取变量前从主内存刷新最新值到工作内存中这种依赖主内存的方式来实现可见性的。

有以下四种方式可以实现可见性：

无论是普通变量还是volatile变量都是如此，区别在于：volatile的特殊规则保证了volatile变量值修改后的新值立刻同步到主内存，每次使用volatile变量前立即从主内存中刷新，因此volatile保证了多线程之间的操作变量的可见性，而普通变量则不能保证这一点。

除了volatile关键字能实现可见性之外，还有synchronized，Lock，final也是可以的。

使用synchronized关键字，在同步方法/同步块开始时（Monitor Enter）,使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在同步方法/同步块结束时(Monitor Exit),会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。
使用Lock接口的最常用的实现是ReentrantLock(重入锁)来实现可见性：当我们在方法的开始位置执行lock.lock()方法，这和synchronized开始位置（Monitor Enter）有相同的语义，即使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在方法的最后finally块里执行lock.unlock()方法，和synchronized结束位置（Monitor Exit）有相同的语义,即会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。
final关键字的可见性是指：被final修饰的变量，在构造函数数一旦初始化完成，并且在构造函数中并没有把“this”的引用传递出去（“this”引用逃逸是很危险的，其他的线程很可能通过该引用访问到只“初始化一半”的对象），那么其他线程就可以看到final变量的值。

有序性

对于一个线程的代码而言，我们总是以为代码的执行是从前往后的，依次执行的。这么说不能说完全不对，在单线程程序里，确实会这样执行；但是在多线程并发时，程序的执行就有可能出现乱序。有序性用一句话可以总结为：**在本线程内观察，所有的操作都是有序的；而在一个线程内观察另一个线程，所有的操作都是无序的。前半句是指 as-if-serial 语义：线程内似表现为串行，后半句是指：“指令重排序现象”和“工作内存与主内存同步延迟现象”。**处理器为了提高程序的运行效率，提高并行效率，可能会对代码进行优化。编译器认为，重排序后的代码执行效率更优。这样一来，代码的执行顺序就未必是编写代码时候的顺序了，在多线程的情况下就可能会出错。

在代码顺序结构中，我们可以直观的指定代码的执行顺序, 即从上到下按序执行。但编译器和CPU处理器会根据自己的决策，对代码的执行顺序进行重新排序，优化指令的执行顺序，提升程序的性能和执行速度，使语句执行顺序发生改变，出现重排序，但最终执行结果看起来相同（在单线程情况下）。

有序性问题 指的是在多线程的环境下（单线程不存在“指令重排”和“工作内存与主内存同步延迟”现象），由于执行语句重排序后，重排序的这一部分没有一起执行完，就切换到了其它线程，导致计算结果与预期不符的问题。这就是编译器的编译优化给并发编程带来的程序有序性问题。

Java 语言提供了 volatile 和 synchronized 这两个关键字来保证线程之间操作的有序性，volatile 关键字是因为本身通过加入内存屏障来禁止指令的重排序，而 synchronized 关键字是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则来实现的有序性，此规则决定了持有同一个对象锁的两个同步块只能串行进入。

关键词synchronized与volatile总结

synchronized的特点
一个线程执行互斥代码过程如下：

获得同步锁；
清空工作内存；
从主内存拷贝对象副本到工作内存；
执行代码(计算或者输出等)；
刷新主内存数据；
释放同步锁。

所以，synchronized既保证了多线程的并发有序性和原子性，又保证了多线程的内存可见性。有序性和原子性都是通过同一时刻只有一个线程可以进入锁住的代码保证的（不被其他线程中断，避免了部分执行）。

volatile是第二种Java多线程同步的手段。一个被volatile修饰的变量，JMM会确保所有线程看到的是一致的变量值。volatile可以保证内存可见性，但不能保证并发有序性(不具有原子性)。

重排序

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：

编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从java源代码到最终实际执行的指令序列，会分别经历上面这三种重排序：
上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。
在这里插入图片描述
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

处理器重排序与内存屏障指令

现代的处理器（物理处理器即CPU）使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：处理器排序后对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！为了具体说明，请看下面示例：

Processor A	Processor B
a = 1; //A1	b = 2; //B1
x = b; //A2	y = a; //B2
初始状态：a = b = 0//A3
处理器允许执行后得到结果：x = y = 0

假设处理器A和处理器B按程序的顺序并行执行内存访问，最终却可能得到x = y = 0的结果。具体的原因如下图所示：

A3->A2-B2->A1-A2;//指令并不会按照程序的顺序执行，这样的话，和你预想的结果天壤之别

这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对读写操作做重排序。

为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为下列四类：

屏障类型	指令示例	说明
LoadLoad Barriers	Load1; LoadLoad; Load2	确保Load1数据的装载，之前于Load2及所有后续装载指令的装载。
StoreStore Barriers	Store1; StoreStore; Store2	确保Store1数据对其他处理器可见（刷新到内存），之前于Store2及所有后续存储指令的存储。
LoadStore Barriers	Load1; LoadStore; Store2	确保Load1数据装载，之前于Store2及所有后续的存储指令刷新到内存。
StoreLoad Barriers	Store1; StoreLoad; Load2	确保Store1数据对其他处理器变得可见（指刷新到内存），之前于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障之前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。

StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他三个屏障的效果。现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型：

名称	代码示例	说明
写后读	a = 1; b = a;	写一个变量之后，再读这个位置。
写后写	a = 1;a = 2;	写一个变量之后，再写这个变量。
读后写	a = b;b = 1;	读一个变量之后，再写这个变量。

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。

前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial语义

as-if-serial语义的意思指：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守as-if-serial语义。

double pi  = 3.14;    //A  
double r   = 1.0;     //B  
double area = pi * r * r; //C

在这里插入图片描述

如上图所示，A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的结果将会被改变）。但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序。下图是该程序的两种执行顺序：
在这里插入图片描述

as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

volatile的原理和实现机制

下面看一下volatile到底如何保证可见性和禁止指令重排序的：

下面这段话摘自《深入理解Java虚拟机》：

“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

2）它会强制将对缓存的修改操作立即写入主存；

3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

使用volatile关键字的场景

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：
　　1）对变量的写操作不依赖于当前值
　　2）该变量没有包含在具有其他变量的不变式中

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

事实上，我的理解就是上面的2个条件需要保证操作是原子性操作，才能保证使用volatile关键字的程序在并发时能够正确执行。

3.关于同步的规定：

1.线程解锁前，必须把共享变量的值刷新回主内存。

2.线程加锁前，必须将主内存的最新值读取到自己的工作内存。

3.加锁解锁是同一把锁。

4.解释说明

在JVM中，栈负责运行（主要是方法），堆负责存储（比如new的对象）。由于JVM运行程序的实体是进程也就是一条条线程，而每个线程在创建时，JVM都会为其创建一个工作内存（有些地方称为栈空间），工作内存是每个线程的私有数据区域。而JAVA内存模型中规定，所有变量都存储在主内存中，主内存是共享内存区域，所有线程都可以访问。

但线程对变量的操作（读取赋值等）必须在自己的工作内存中进行。首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后，再将变量写回到主内存。由于不能直接操作主内存中的变量，各个线程的工作内存中存储着主内存中的变量副本，因此，不同的线程之间无法直接访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成。