这篇文章主要讲解了“Java并发中的内存模型”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Java并发中的内存模型”吧！
在讲JMM之前，我想先和大家聊聊硬件层面的东西。大家应该都知道执行运算操作的CPU本身是不具备存储能力的，它只负责根据指令对传递进来的数据做相应的运算，而数据存储这一任务则交给内存去完成。虽然内存的运行速度虽然比起硬盘快非常多，但是和3GHZ，4GHZ,甚至5GHZ的CPU比起来还是太慢了，在CPU的眼中，内存运行的速度简直就是弟弟中的弟弟，等内存进行一次读写操作，CPU能思考成百上千次人生了:grin:。但是CPU的运算能力是紧缺资源啊，可不能这么白白浪费了，所以得想办法解决这一个问题。
没有什么问题是一个缓存不能解决的，如果有，那就再加一个缓存 ——鲁迅：反正我没说这句话
所以人们就想到了给CPU增加一个高速缓存（为什么是加高速缓存而不是给内存提高速度就牵扯到硬件成本问题了）来解决这个问题，比如像博主用的Intel的I9 9900k CPU就带了高达16M的三级缓存，所以硬件上的内存模型大概如下图所示。
如图可以很清楚的看到，在CPU内部构建了一到多层的缓存，并且其中的L1 Cache是CPU内核心独有的，不同的Core之间是不能共享的，而L2 Cache则是所有的核心共享。简单来说就是CPU在读取一个数据时会先去最近的Cache层级上读取，如果找不到则会去下一个层级寻找，都找不到的话就会从内存中去加载，而如果Cache中能拿到所需要的数据就不会去内存读取。在将数据写回的时候也会先写入Cache中，等待合适的时机再写入到内存中（其中有一个细节就是缓存行的问题，关于这部分内容放在文章结尾）。而由于存在多个cache层级，并且部分cache还不能够被共享，所以会存在内存可见性的问题。
举个简单的例子： 假设现在存在两个Core，分别是CoreA和CoreB并且他们都拥有属于自己的L1Chace和共用的L2Cache。同时有一个变量X的值为1，该变量已经被加载在L2Cahce上。此时CoreA执行运算需要用到变量X，先去L1Cache寻找，未命中，继续在L2Cache寻找，命中成功，将X=1载入L1Cahce，再经过一系列运算后将X修改为2并写入L1Cache。于此同时CoreB刚好也需要X来进行运算，此时他去自己的L1Cahce寻找，未命中，继续L2Cache寻找，命中成功，将X=1载入自己的L1Cache。此时就出现了问题，CoreA明明已经将X的值修改为2了，CoreB读取到的依然是X=1，这就是内存可见性问题。
看到这里的小伙伴们可能要问了，博主你啥情况啊，你这写的渐渐忘记标题了啊，说好了Java内存模型，你扯这么多硬件上的问题干啥啊？(╯‵□′)╯︵┻━┻
小伙伴们别着急，其实JMM和上面的硬件层次上的模型很像，不信看下面的图片
怎么样，是不是看起来很像，可以简单的理解为线程的工作内存就是CPU里Core独占的L1Cahce，而主内存就是共享的L2Cache。所以上述的内存一致性问题也会在JMM中存在，而JMM就需要制定一些列的规则来保证内存一致性，这也是Java多线程并发的一个疑难点，那么JMM制定了哪些规则呢？
lock （锁定）作用于主内存的变量，将一个变量标识为一个线程独占状态
unlock（解锁）作用于主内存的变量，将一个处于锁定状态的变量释放出来，释放之后才能被其他线程锁定
read（读取）作用于主内存的变量，将一个变量的值从主内存传输到线程工作内存中，便于之后的load操作使用
load（载入）作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
assign（赋值）作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。
同时还规定了执行上述八个操作时必须遵循以下规则：
如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作， 如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
不允许read和load、store和write操作之一单独出现
不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
（上述部分参考并引用《深入理解Java虚拟机》中的内容）
对于volatile修饰的变量，JMM对其有一些特殊的规定。
往简单来说volatile关键字可以理解为，有一个volatile修饰的变量x，当一个线程需要使用该变量的时候，直接从主内存中读取，而当一个线程修改该变量的值时，直接写入到主内存中。根据之前的分析我们能得出具备这些特性的volatile能够保证一个变量的内存可见性和内存一致性。
指令重排序是一个大部分CPU都有的操作，同时JVM在运行时也会存在指令重排序的操作。 简单举个:chestnut:
private void test(){ int a,b,c;//1
a=1;//2
b=3;//3
c=a+b;//4
}假设有上面这么一个方法，内部有这4行代码。那么JVM可能会对其进行指令重排序，而指令重排序的规定则是as-if-serial 不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。根据这一规定，编译器和处理器不会对有依赖关系的指令重排序，但是对没有依赖的指令则可能会进行重排序。放在上面的例子里面就是，第1行代码和2，3，4行代码是有依赖关系的，所以第一行代码的指令必须排在2，3，4之前，因为不可能对一个未定义的变量进行赋值操作。而第2，3行代码之间并没有相互依赖关系，所以此处可能会发生指令重排序，先执行3，再执行2。而最后的第4行代码和之前的3行代码都有依赖关系，所以他一定会放在最后执行。
既然JVM特别指出指令重排序只在单线程下和未排序的效果一致，那是否表示在多线程下会存在一些问题呢？ 答案是肯定的，多线程下指令重排序会带来一些意想不到的结果。
int a=0; //flag作为一个标识符，标识是否写入完成
boolean flag = false; public void writer(){
a=10;//1
flag=true;//2
} public void reader(){ if (flag)
System.out.println("a:"+a);
}假设存在一个类，他有上述部分的field和method，该类在设计上以flag作为写入是否完成的标志，在单线程下这并不会存在问题。而此时有两个线程分别执行writer和reader方法，暂时不考虑内存可见性的问题，假设对a和flag的写入，是立即被其他线程所知晓的，这个时候大家觉得输出a的值为多少？10？
即使不考虑内存可见性，此时a的值还是有可能会输出0，这就是指令重排序带来的问题。在上述代码中注释1和2处的代码是没有依赖关系的，在单线程下先执行1还是2都没有任何问题，根据as-if-serial 原则此时就可能会发生指令重排序。
而volatile关键字可以禁止指令重排序。
我们都知道JMM定义的8个主内存和工作内存之间的操作都是具备原子性的，但是对long和double这两个64位的数据类型有一些例外。
允许虚拟机将没有被volatile修饰的long和double的64数据的读写操作划分为两次32位的读写操作，即不要求虚拟机保证对他们的load ,store,read,write四个操作的原子性。 但是大部分的虚拟机实现都保证了这四个操作的原子性的，所以大部分时候我们都不需要刻意的对long，double对象使用volatile修饰。
volatile是Java提供的保证内存可见性的最轻量级操作，比起重量级的synchronized能快上不少，但是具体能快多少这部分没办法量化。而我们可以知道的是volatile修饰的变量读操作的性能消耗几乎和普通变量相差无几，而写操作则会慢上一些。所以当volatile能解决我们的问题的时候（内存可见性和禁止指令重排序），我们应该优先选择使用volatile而不是锁。
简单概括就是
当程序进入synchronized块时，把在synchronized块中用到的变量从工作内存中清楚，这样在需要访问这些变量的时候会重新从主内存中获取。当程序退出synchronized块时，把对块中恭喜变量的修改刷新到主内存。 如此依赖synchronized也能保证了内存的可见性。
final也能保证内存的可见性
被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把this引用传递出去，那么其他线程中就能看见final字段的值。
根据前面的文章，我们知道CPU和Memory之间是有Cache的，而Cache内部是按行存储的，行拥有固定的大小，这些行被称为缓存行。 当CPU访问的某个变量不在Cache中时，就会去内存里获取，并将该变量所在内存的一个缓存行大小的数据读入Cache中。由于一次读取并不是单个对象而是一整个缓存行，所以可能会存在多个变量被读入一个缓存行中。而一个缓存行只能同时被一个线程操作，所以当多个线程同时修改一个缓存行里的多个变量时会造成其他线程等待从而带来性能损耗（但是在单线程情况下，伪共享反而会提升性能，因为一次性可能会缓存多个变量，节省后续变量的读取时间）。
在Java8之后可以使用JDK提供的@sun.misc.Contended注解来解决伪共享，像Thread中的threadLocalRandom 字段就使用了这个注解。
感谢各位的阅读，以上就是“Java并发中的内存模型”的内容了，经过本文的学习后，相信大家对Java并发中的内存模型这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
