Java中是如何保证多线程间的数据共享的？

末蓝、 2024-03-23 10:52 54阅读 0赞

在讨论这个问题之前，我们可以先瞅瞅Java的内存模型**JMM**，**JMM**可不要和**JVM**混为一谈。我们说的是内存模型`JMM（Java Memory Model）`。

## Java的内存模型 ##

![format_png][]

稍微解释一下CPU的缓存，这里CPU的缓存有三级，L1,L2和L3。

*  L1是访问速度最快的，是线程独享。
 *  L2次之，属于内核独享。
 *  L3是最慢的，是多核共享。

当CPU执行指令需要数据的时候，会先在L1，L2,L3中依次寻找，若是找不到，则会去JVM中寻找，而JMM则在CPU和主内存之间来保证我们需要的可见性和有序性。

这个JMM就是**Java内存模型的核心**，可见性有序性都是在这里实现。  
而主内存就是JVM，就是我们的堆内存。

## 保证可见性的方式 ##

> 可见性是指，当多个线程操作同一个数据的时候，保证一个线程的修改对其他线程是可见的，也就是说不管多个线程如何操作，如何并发，他们在同一时间取到的值是相同的。

为了保证可见性，我们一般有以下几种方案：

### volatile ###

可以用**volatile**来修饰基本数据类型，可以保证每次CPU操作数据的时候，都直接操作的是主内存的值。

`文末我们会说说volatile的原理`

### 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的原理就如下

![format_png 1][]

可以看到对于volatile的写操作

之前添加了`StoreStore`内存屏障，必须完成之前的读写操作才能继续volatile的写操作。  
而后添加了`StoreLoad`屏障，要求其前边的volatile写操作完成，才能继续之后的读操作。

> 这样就保证了在对volatile修饰的值执行写操作的时候，之前的读写操作已经全部完成，而其后的读操作在等待写操作完成再去读值。

而对于volatile的读操作，

在其后添加了一个`LoadLoad屏障`和`LoadStore屏障`，这里这个LoadLoad屏障不是很理解，查阅了诸多资料也没有眉目，若是有小伙伴知晓的，烦请不吝赐教。  
而`LoadStore屏障`则保证了volatile的读操作全部完成之后，再继续之后的写操作。

> 这样volatile的读操作完成之后，才会执行其他的写操作。保证了读到的值是确定的不变的。

这样Java的线程间共享值的处理方式就大致讲解完毕了。

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/f56bfc17db8b40aabadb193f12fed5fd.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/0b35e9adabc440cdb7062b46c32c5b07.png