JVM系列-java内存模型（JMM）

秒速五厘米 2022-12-21 15:55 134阅读 0赞

Java内存模型\*\*（Java Memory Model ，JMM）\*\*与JVM运行时数据区是不一样的。**这两者是完全不同的概念，绝对不能混为一谈。**

## 一、JMM与JVM的区别 ##

**JVM运行时数据区**，是Java虚拟机在运行时对该Java进程占用的内存进行的一种逻辑上的划分，包括方法区、堆内存、虚拟机栈、本地方法栈、程序计数器。这些区块实际都是Java进程在Java虚拟机的运作下通过不同数据结构来对申请到的内存进行不同使用。

**Java内存模型**，是Java语言在多线程并发情况下对于共享变量读写(实际是共享变量对应的内存操作)的规范，主要**用于java程序访问共享内存时，屏蔽不同的操作系统、不同的硬件的差异，从而解决多线程可见性、原子性等问题**。

我们编写完程序后，编译器和处理器都会有相应的优化，以提高运行效率。优化分为很多种，比如指令重排序。指令重排序了，性能提高了，但是还能得到我们想要的执行结果吗？

优化的前提是执行的结果依然正确，这就需要有额外的保证，JMM就是给java程序员做保证的，保证优化后结果依然正确同时性能提高。

## 二、happens-before原则 ##

JMM是如何保证提高性能的通过结果依然正确？JVM规范规定了Java虚拟机对多线程内存操作的一些规则：**happens-before原则**。主要体现在volatile，synchronized这两个关键字上。

happens-before（**happens-before原则不能简单从字面理解成一个操作发生在另一个操作的前面**）八大原则：

*  单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。
 *  锁的happen-before原则：同一个锁的unlock操作happen-before此锁的lock操作。
 *  volatile的happen-before原则：对一个volatile变量的写操作happen-before对此变量的任意操作(当然也包括写操作了)。
 *  happen-before的传递性原则：如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。
 *  线程启动的happen-before原则：同一个线程的start方法happen-before此线程的其它方法。
 *  线程中断的happen-before原则：对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。
 *  线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。
 *  对象创建的happen-before原则：一个对象的初始化完成先于他的finalize方法调用。

**在同一个线程中，书写在前面的操作happen-before后面的操作：** 好多文章把这理解成书写在前面先发生于书写在后面的代码，但是指令重排序，确实可以让书写在后面的代码先于书写在前面的代码发生。这是里把happen-before 理解成“先于什么发生”，其实happen-beofre在这里没有任何时间上的含义。比如下面的代码：

int a = 3;      //1
    int b = a + 1; //2

这里 //2 对b赋值的操作会用到变量a，那么java的“单线程happen-before原则”就保证 //2的中的a的值一定是3，而不是0等其他值，因为//1 书写在//2前面, //1对变量a的赋值操作对//2一定可见。因为//2 中有用到//1中的变量a，再加上java内存模型提供了“单线程happen-before原则”，所以java虚拟机不许可操作系统对//1 //2 操作进行指令重排序，即不可能有//2 在//1之前发生。但是对于下面的代码：

int a = 3;
    int b = 4;

两个语句直接没有依赖关系，所以指令重排序可能发生，即对b的赋值可能先于对a的赋值。

**同一个锁的unlock操作happen-beofre此锁的lock操作：** 话不多说直接看下面的代码：

public class A { 
       public int var;
    
       private static A a = new A();
    
       private A(){ }
    
       public static A getInstance(){ 
           return a;
       }
    
       public synchronized void method1(){ 
           var = 3;
       }
    
       public synchronized void method2(){ 
           int b = var;
       }
    
       public void method3(){ 
           synchronized(new A()){  //注意这里和method1 method2 用的可不是同一个锁哦
               var = 4;
           }
       }
    }

main(){ 
       	//线程1执行的代码：
    	A.getInstance().method1(); 
    
    	//线程2执行的代码：
    	A.getInstance().method2(); 
    
    	//线程3执行的代码：
    	A.getInstance().method3(); 
        
    }

如果某个时刻执行完“线程1” 马上执行“线程2”，因为“线程1”执行A类的method1方法后肯定要释放锁，“线程2”在执行A类的method2方法前要先拿到锁，符合“锁的happen-before原则”，那么在“线程2”method2方法中的变量var一定是3，所以变量b的值也一定是3。但是如果是“线程1”、“线程3”、“线程2”这个顺序，那么最后“线程2”method2方法中的b值是3，还是4呢？其结果是可能是3，也可能是4。的确“线程3”在执行完method3方法后的确要unlock，然后“线程2”有个lock，但是这两个线程用的不是同一个锁，所以JMM这个两个操作之间不符合八大happen-before中的任何一条，所以JMM不能保证“线程3”对var变量的修改对“线程2”一定可见，虽然“线程3”先于“线程2”发生。

**对一个volatile变量的写操作happen-before对此变量的任意操作：**

volatile int a;
    
    //线程1
    a = 1; //1
    
    //线程2
    b = a;  //2

如果线程1 执行//1，“线程2”执行了//2,并且“线程1”执行后,“线程2”再执行,那么符合“volatile的happen-before原则”所以“线程2”中的a值一定是1。

\*\*如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作：\*\*如果有如下代码块：

volatile int var;
    int b;
    int c;
    
    //线程1
    b = 4; //1
    var = 3; //2
    
    //线程2
    c = var; //3
    c = b; //4

假设“线程1”执行//1 //2这段代码,“线程2”执行//3 //4这段代码。如果某次的执行顺序如下：  
//1 //2 //3 //4。那么有如下推导( hd(a,b)表示a happen-before b）：

> 因为有hd(//1,//2) 、hd(//3,//4) (单线程的happen-before原则)  
> 且hd(//2,//3) （volatile的happen-before原则）  
> 所以有 hd(//1,//3),可导出hd(//1,//4) (happen-before原则的传递性)  
> 所以变量c的值最后为4  
> 如果某次的执行顺序如下：  
> //1 //3 //2// //4 那么最后4的结果就不能确定喽。其原因是 //3 //2 直接符合上述八大原则中的任何一个，不能通过传递性推测出来什么。

通过对上面的四个原则的详细解释，省下的四个原则就比较显而易见了。

## 三、总结 ##

总结：happens-before原则主要体现在volatile，synchronized这两个关键字上。

*  volatile 是JVM提供的对共享变量在多线程读写时的可见性保证，主要作用是对volatile修饰的共享变量禁止被缓存（这里跟CPU的高速缓存和缓存一致性协议有关），不做重排序（重排序：在CPU处理速度远大于内存读写速度的现状下为了提高性能而进行的优化），但是并不保证共享变量操作的原子性。
 *  synchronized 是JVM提供的锁机制，通过锁的特性和内存屏障保证锁住区域操作的原子性、可见性、有序性。
 *  锁争抢的是对象（static锁的是类对象，非static锁的是当前对象，即this，锁方法块锁的是自定义对象）在堆内存中对象头的一块内存的“主权”，只有一个线程能获取该“主权”，即排他性，通过锁的排他性保证对锁住区域的操作的原子性
 *  通过在代码前后加入加载屏障（Load Barrier）和存储屏障（Store Barrier），能保证锁住代码块或者方法中对共享变量的操作的可见性
 *  通过在代码前后加入获取屏障（Acquire Barrier）和释放屏障（Release Barrier），能保证锁住代码块或者方法中对共享变量的操作的有序性

参考：

https://www.cnblogs.com/tiancai/p/9636199.html

https://zhuanlan.zhihu.com/p/92341957

完成，收工！

![9eb4a567542d61401f58205e15bebef4.png][]

【**传播知识，共享价值**】，感谢小伙伴们的关注和支持，我是【**诸葛小猿**】，一个彷徨中奋斗的互联网民工。

![bb524598e6bab0c999aed8590647cea0.png][]

[9eb4a567542d61401f58205e15bebef4.png]: /images/20221120/3d4214c9a714453188d3160a34cbe6c9.png
[bb524598e6bab0c999aed8590647cea0.png]: https://img-blog.csdnimg.cn/img_convert/bb524598e6bab0c999aed8590647cea0.png