Java中保证多线程间的数据共享的方法详解
作者：奔跑的毛球
在讨论这个问题之前，我们可以先瞅瞅Java的内存模型JMM，JMM可不要和JVM混为一谈。我们说的是内存模型JMM（Java Memory Model）。
Java的内存模型
稍微解释一下CPU的缓存，这里CPU的缓存有三级，L1,L2和L3。
- L1是访问速度最快的，是线程独享。
- L2次之，属于内核独享。
- L3是最慢的，是多核共享。
当CPU执行指令需要数据的时候，会先在L1，L2,L3中依次寻找，若是找不到，则会去JVM中寻找，而JMM则在CPU和主内存之间来保证我们需要的可见性和有序性。
这个JMM就是Java内存模型的核心，可见性有序性都是在这里实现。
而主内存就是JVM，就是我们的堆内存。
保证可见性的方式
可见性是指，当多个线程操作同一个数据的时候，保证一个线程的修改对其他线程是可见的，也就是说不管多个线程如何操作，如何并发，他们在同一时间取到的值是相同的。
为了保证可见性，我们一般有以下几种方案：
volatile
可以用volatile来修饰基本数据类型，可以保证每次CPU操作数据的时候，都直接操作的是主内存的值。
文末我们会说说volatile的原理
synchronized
对于synchronized来说，是谁拿到锁，谁执行操作，对于拿到锁的线程来说，前边线程的操作是可见的。
我会另起一篇文章专门讲解synchronized。
lock
lock是基于CAS和volatile的修改操作，可以保证操作数据时前边操作的可见性。
final
final修饰的是常量啊，没法写，只读，当然是全局可见的
这里有一个小点：
我们清楚，volatile修饰基本数据类型的时候是可以保证可见性的，但是若是修饰的是引用数据类型呢？
一般没人这么搞，甚至平时工作中volatile都很少使用，一不留神系统的性能会降低几个维度。但是面试中常被问到，我们可以这样回答：若volatile修饰的是引用数据类型，则只能保证引用数据类型的地址是可见的，里边的值不可见。就这。
volatile的底层实现
稍微看看volatile的底层实现吧，其实
volatile的底层是汇编的lock指令，这个指令会
强行要求将值写入主内存，并且忽略Store Buffer这种缓存，从而达到可见性的目的，同时利用MESI协议，让其他缓存行失效。
我们晓得将java文件编译为class文件的时候，会基于JIT做优化，调整指令的顺序，从而提升执行效率，这个过程叫指令重排。
在CPU层面也会调整指令的顺序来提升性能。而这个指令重排会导致一些问题，我们看看volatile是如何解决这个问题的。
原理
被volatile修饰的属性，在编译时会在先后增加内存屏障。这里的提到的内存屏障一般有四种
- SS: StoreStore屏障前的读写操作必须全部完成，才会继续屏障之后的操作
- SL: StoreLoad屏障前的写操作必须全部完成，才会继续屏障之后的读操作
- LL: LoadLoad屏障前的读操作必须全部完成，才能继续屏障之后的读操作
- LS: LoadStore屏障前的读操作必须全部完成，才能继续屏障之后的写操作
这里volatile的原理就如下
可以看到对于volatile的写操作
之前添加了StoreStore内存屏障，必须完成之前的读写操作才能继续volatile的写操作。
而后添加了StoreLoad屏障，要求其前边的volatile写操作完成，才能继续之后的读操作。
这样就保证了在对volatile修饰的值执行写操作的时候，之前的读写操作已经全部完成，而其后的读操作在等待写操作完成再去读值。
而对于volatile的读操作
在其后添加了一个LoadLoad屏障和LoadStore屏障，这里这个LoadLoad屏障不是很理解，查阅了诸多资料也没有眉目，若是有小伙伴知晓的，烦请不吝赐教。
而LoadStore屏障则保证了volatile的读操作全部完成之后，再继续之后的写操作。
这样volatile的读操作完成之后，才会执行其他的写操作。保证了读到的值是确定的不变的。
以上就是Java中保证多线程间的数据共享的方法详解的详细内容，更多关于Java多线程间的数据共享的资料请关注脚本之家其它相关文章！