这篇文章主要介绍“Java内存模型实例分析”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“Java内存模型实例分析”文章能帮助大家解决问题。
创新互联公司是一家专业提供回民企业网站建设,专注与成都网站设计、成都网站建设、H5页面制作、小程序制作等业务。10年已为回民众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。
所有的编程语言中都有内存模型这个概念，区别于微架构的内存模型，高级语言的内存模型包括了编译器和微架构两部分。我试图了解了Java、C#和Go语言的内存模型，发现内容基本大同小异，只是这些语言在具体实现的时候略有不同。
我们来看看Java内存模型吧，提到Java内存模型大家对这个图一定非常熟悉：
这张图告诉我们在线程运行的时候有一个内存专用的一小块内存，当Java程序会将变量同步到线程所在的内存，这时候会操作工作内存中的变量，而线程 中变量的值何时同步回主内存是不可预期的。但同时Java内存模型又告诉我们通过使用关键词“synchronized”或“volatile”可以让 Java保证某些约束：
“volatile” — 保证读写的都是主内存的变量
“synchronized” — 保证在块开始时都同步主内存的值到工作内存，而块结束时将变量同步回主内存
通过以上描述我们就可以写出线程安全的Java程序，JDK也同时帮我们屏蔽了很多底层的东西。
但当你深入了解JVM的时候你会发现根本就没有工作内存这个东西，即内存中根本不会分配这么一块空间来运行你的Java程序，那么工作内存到底是什么东西呢？
这个问题也曾经困扰了我很长时间，因为我从来没有从JVM的实现中找到过和主内存同步的代码，因为当使用“volatile”时我仅仅能从源代码中调用了这行语句：
__asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
而这个指令在部分微架构上的主要功能就是防止指令重排，即这条指令前后的其它指令不会越过这个界限执行[注1]。
在现在的x86/x64微架构中读写内存的一致性都是通过MESI（Intel使用MESI-F，AMD使用MOESI）协议保证[注2]，MESI的状态转换图如下：
那Java内存模型中所说的工作内存是什么呢？
我的理解是，首先“工作内存”是一个虚拟的概念，而承载这个概念主要是两部分：
1. 编译器
2. 微架构
作为编译器肯定是执行速度越快越好，所以作为编译器应当尽量减少从内存读数据，如果一个数据在寄存器中，那么直接使用寄存器中的值无疑性能是*** 的，但同时这也会导致可能读不到***的值，这里我们通过在Java语言中为变量加上“volatile”强制告诉编译器这个变量一定要从内存获得，这时编 译器即不会做此类优化【案例见参考资料5（是一个.Net的例子）】。
对于微架构来说，在x86/x64下，CPU会在执行指令时做指令重排，即编译器生成的指令顺序和真正在CPU执行的顺序可能是不一致的。当我们用一个变量做信号的时候这种指令重排会带来悲剧，即如果有如下代码：
x = 0; y = 0; i = 0; j = 0; // thread A y = 1; x = 1; // thread B i = x; j = y;
上面的代码i和j的值会是多少呢？答案是：“00， 01， 10， 11”都是有可能的。
对于这种情况，如果我们想得到确定的结果则需要通过“synchronized”（或者j.c.u.locks）来做线程间同步。
关于“Java内存模型实例分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注创新互联行业资讯频道，小编每天都会为大家更新不同的知识点。
