Java内存模型-JMM

r囧r小猫 2021-09-21 11:58 475阅读 0赞

# Java内存模型-JMM #

本文是基于CentOS 7.3系统环境，进行Java内存模型的学习和使用

*  **CentOS 7.3**

--------------------

## 1. Java内存模型 ##

### 1.1 什么是Java内存模型 ###

Java内存模型（Java Memory Model）本身是一种规范或者一组规则，同时这组规则围绕着可见性、原子性、有序性，定义了程序中各个变量的访问方式。

### 1.2 主内存和工作内存 ###

1.  各个线程中的工作内存中存储主内存中的变量副本
2.  线程对变量的所有操作都有必须在工作内存中执行
3.  线程不能直接读写主内存中的变量
4.  不同线程之间也无法直接访问对方工作内存之间的变量
5.  线程之间的变量值的传递均需要通过主内存来完成

### 1.3 内存间的交互操作 ###

Java内存模型中定义了8种原子操作

1.  lock：锁定，作用于主内存的变量，它将一个变量标识为一个线程独占的状态
2.  unlock：解锁，作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放出来的变量才可以被其他线程锁定
3.  read：读取，作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
4.  load：载入，作用于工作内存的变量，它把read操作从主内存中得到的变量的值放入工作内存的变量副本中
5.  use：使用，作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作
6.  assign：赋值，作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时将会执行这个操作
7.  store：存储，作用于工作内存的变量，它把工作内存中一个变量的值传递给主内存中，以便随后的write操作使用
8.  write：写入，作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中

### 1.4 内存操作注意事项 ###

1.  要把一个变量从主内存复制到工作内存，需要顺序执行read和load操作
2.  要把一个变量从工作内存同步回主内存，需要顺序执行store和write操作
3.  load、use、read必须连续一起出现
4.  assign、store、write必须连续一起出现

### 1.5 JMM关于同步的规定 ###

1.  线程解锁前，必须把共享变量的值刷新回主内存
2.  线程加锁前，必须读取主内存的最新值到自己的 工作内存
3.  加锁解锁是同一把锁

### 1.6 线程 ###

#### 1.6.1 定义 ####

线程是CPU调度的最小单位，也称为轻量级进程，是由进程通过系统调用，克隆出的一个轻量级进程，与所属进程的其他线程共享所属进程的资源（内存、文件I/O等），可以被CPU独立调度。

#### 1.6.2 线程之间通信的方式 ####

1.  共享变量，需要进行加锁同步

#### 1.6.3 线程状态 ####

1.  新建（new）  
    创建后尚未启动的线程处于这种状态
2.  运行（runable）  
    包括了就绪ready和运行running状态，处于runable状态的线程有可能正在执行，有可能正在等待CPU为其分配执行时间片
3.  等待（waiting）  
    等待状态有分为无限期等待（wating）和有限期等待（time wating）。
4.  阻塞（block）  
    等待一个排他锁的线程处于这种状态。
5.  终止（terminated）  
    已终止的线程处于这种状态

#### 1.6.4 线程状态转换 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center]

### 1.7 进程 ###

进程是资源分配的最小单位，是计算机正在运行的程序的实例

#### 1.7.1 进程之间通信的方式 ####

1.  管道
2.  信号量
3.  共享内存
4.  套接字
5.  消息队列

### 1.8 final关键字 ###

可以修饰类属性、类方法和类

*  **修饰类属性**

1.  该属性一旦被初始化便不可改变，这里不可改变的意思对基本类型来说是其值不可变，而对对象属性来说其引用不可再变。
2.  其初始化可以在两个地方：一是其定义处，也就是说在 final 属性定义时直接给其赋值；二是在构造函数中。
3.  这两个地方只能选其一，要么在定义时给值，要么在构造函数中给值，不能同时既在定义时赋值，又在构造函数中赋予另外的值。

*  **修饰类方法**  
    说明这种方法提供的功能已经满足当前要求，不需要进行扩展，并且也不允许任何从此类继承的类来重写这种方法，但是继承仍然可以继承这个方法
 *  **修饰类**  
    表示该类是无法被任何其他类继承的，意味着此类在一个继承树中是一个叶子类，并且此类的设计已被认为很完美而不需要进行修改或扩展。

## 2. volatile ##

volatile是Java虚拟机提供的轻量级的同步机制。

1.  保证可见性
2.  不保证原子性
3.  禁止指令重排

### 2.1 保证可见性 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 1]  
由于JVM运行程序的实体是线程，而每一个线程在创建时，JVM都会为其创建一个工作内存。工作内存是每一个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有的线程都可以访问，但是线程对变量的操作必须在工作内存中进行，首先要将变量从主内存中拷贝到自己的工作内存中，然后对变量进行操作，操作完成后再将变量写回主内存，此时主内存会通知其他线程该共享变量的最新值，这种机制就是JMM可见性。synchronized和final也能实现可见性

### 2.2 不保证原子性 ###

原子性：不可分割，某个线程在做某个业务过程时，中间不可以被中断，整个过程要么同时成功，要么同时失败

public void addPlusPlus(){ 
    	n++;
    }

正如上面的函数，n++一个语句在字节码中被拆分成3个指令：

1.  执行getfield拿到主内存中的原始值n
2.  执行iadd进行加1操作
3.  执行putfield写操作，吧累加后的值写回主内存

### 2.3 如何解决原子性 ###

使用相应的原子类，例如AtomicInteger，其值已经被声明为volatile，因此使用该类，既能保证volatile提供的可见性、有序性，又能保证原子性

public class AtomicInteger extends Number implements java.io.Serializable { 
        private static final long serialVersionUID = 6214790243416807050L;
    
        
        private static final Unsafe unsafe = Unsafe.getUnsafe();
        private static final long valueOffset;
    
        static { 
            try { 
                valueOffset = unsafe.objectFieldOffset
                    (AtomicInteger.class.getDeclaredField("value"));
            } catch (Exception ex) {  throw new Error(ex); }
        }
    
        private volatile int value;
    
        public AtomicInteger(int initialValue) { 
            value = initialValue;
        }
    	......
    }

### 2.4 禁止指令重排 ###

#### 2.4.1 指令重排 ####

1.  计算机在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排，但是必须考虑指令之间的数据依赖性。
2.  多线程环境中线程交替出现，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的

#### 2.4.2 内存屏障 ####

在指令间插入一条内存屏障，会告诉编译器和CPU，不管什么指令都不能和这条内存屏障进行指令重排序，也就是说，通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化

1.  保证特定操作的执行顺序
2.  保证某些变量的内存可见性

#### 2.4.3 内存屏障的执行 ####

1.  对volatile变量执行写操作时  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 2]
2.  对volatile变量执行读操作时  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 3]

### 2.5 先行发生原则（happens-before） ###

### 2.5.1 为什么会有先行发生原则 ###

因为jvm会对代码进行编译优化，指令会出现重排序的情况，为了避免编译优化对并发编程安全性的影响，需要happens-before规则定义一些禁止编译优化的场景，保证并发编程的正确性

### 2.5.2 什么是先行发生 ###

先行发生是Java内存模型JMM中定义的两个操作之间的偏序关系，操作A先行发生操作B，也就是说发生操作B之前，操作A产生的影响会被操作B观察到。

*  **程序次序规则**  
    在一个线程中，按照程序代码顺序，写在前面的操作先行发生于写在后面的操作
 *  **管程锁定规则**  
    一个unlock操作先行发生于后面对同一个锁的lock操作。
 *  **volatile变量规则**  
    对一个volatile变量的写操作先行发生于后面对这个变量的读操作。
 *  **传递性规则**  
    如果操作A先行发生于操作B，操作B先行发生于操作C，那么操作A先行发生于操作C
 *  **线程启动规则**  
    Thread对象的start()方法先行发生于线程的每一个动作
 *  **程序终止规则**  
    线程执行结束后，所有的操作都先行发生于检测到线程终止事件的发生。可以通过Thread.join()方法结束线程，或者通过Thread.isAlive()返回值检测到线程已终止执行。
 *  **程序中断规则**  
    对线程调用interrupt()方法先行发生于检测到中断事件的发生。可以通过Thread.interrupted()方法检测是否中断发生
 *  **对象终结规则**  
    一个对象的初始化完成（构造函数执行结束），先行发生于它的finalize()方法之前。GC在回收对象之前，会调用该方法

### 2.6 volatile应用场景 ###

### 2.6.1 单例模式DCL ###

DCL：double check lock双端检锁机制

public class SingletonDemo { 
    
        private static SingletonDemo instance = null;
    
        private SingletonDemo() { 
            System.out.println(Thread.currentThread().getName() + "\t SingletonDemo is created.");
        }
    
        public static SingletonDemo getInstance() { 
            if (instance == null) { 
                synchronized (SingletonDemo.class){ 
                    if (instance == null){ 
                        instance = new SingletonDemo();
                    }
                }
            }
            return instance;
        }
    }

### 2.6.2 单例模式DCL不一定线程安全 ###

1.  双端检锁机制不一定线程安全，因为有指令重排的存在
2.  加入volatile后，可以禁止指令重排
3.  原因在于某一个线程执行到第一次检测，读取到的instance不为null时，instance的引用对象可能没有完成初始化

### 2.6.3 创建单例对象过程 ###

instance = new SingletonDemo();

可以分为以下3步完成

memory = allocate(); //1. 分配对象内存空间
    initial (memory); //2. 初始化对象
    instance = memory; //3. 设置instance指向刚分配的内存地址，此时instance != null

步骤2和步骤3不存在数据依赖关系，因此这种重排优化是允许的

### 2.6.4 如何解决DCL线程安全性 ###

添加volatile关键字

public class SingletonDemo { 
    	// 添加volatile关键字
        private static volatile SingletonDemo instance = null;
    
        private SingletonDemo() { 
            System.out.println(Thread.currentThread().getName() + "\t SingletonDemo is created.");
        }
    
        public static SingletonDemo getInstance() { 
            if (instance == null) { 
                synchronized (SingletonDemo.class){ 
                    if (instance == null){ 
                        instance = new SingletonDemo();
                    }
                }
            }
            return instance;
        }
    }

### 2.5 为什么不用synchronized同步锁 ###

杀鸡焉用牛刀，synchronized同步锁是悲观锁，Synchronized同步锁能够保证线程安全，但是Synchronized会让没有得到锁资源的线程进入BLOCKED状态，而后在争夺到锁资源后恢复为RUNNABLE状态，这个过程中涉及到线程状态的转变，代价比较高。

## 3. 为什么atomic能解决原子性问题 ##

atomic原子更新类是使用CAS实现的，而不是synchronized

### 3.1 CAS是什么 ###

1.  CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换，它是一条并发原语，原语属于操作系统用语范畴，是由若干条指令组成，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行的过程中不允许被中断，也就能保证原子性。
2.  CAS的功能是更新一个变量的时候，首先判断其内存地址V的值是否为预期值A，如果是则更新为新的值B，否则返回false，这个过程是原子的。

### 3.2 CAS与synchronized同步锁 ###

1.  Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去重新尝试更新
2.  CAS会不断地重新尝试更新，这种过程称为自旋。

### 3.3 CAS实例 ###

public class CASDemo{ 
    	public static void main(String[] args){ 
    		AtomicInteger atomicInteger = new AtomicInteger(5);
    		//main do things
    		System.out.println(atomicInteger.compareAndSet(5,2019)+"\t current data: "+atomicInteger.get());
    		System.out.println(atomicInteger.compareAndSet(5,2020)+"\t current data: "+atomicInteger.get());
    	}
    }

### 3.3 CAS底层实现原理 ###

Unsafe类和自旋

#### 3.3.1 Unsafe类 ####

1.  Unsafe类是CAS核心类，由于Java方法无法直接访问底层系统，需要通过本地方法来访问，Unsafe类相当于一个后门，给予该类可以直接操作特定内存的数据。Unsafe类位于rt.jar/sum.misc包中，其内部方法仿佛像C的指针一样直接操作内存，因为Java中的CAS操作的执行依赖于Unsafe类的方法
2.  调用Unsafe类中的CAS方法，JVM会帮助我们实现出CAS汇编指令，而CAS是一种并发原语，原语属于操作系统用语范畴，是由若干条指令组成，用于完成某个功能的一个过程，并且原语的执行必须是连续，在执行过程中不允许被中断，这就保证了原子性，也保证了数据的一致性。

#### 3.3.2 自旋 ####

public final int getAndAddInt(Object var1, long var2, int var4){ 
    	int var5;
    	do{ 
    		//var1表示变量的对象，var2表示内存地址，
    		//该方法表示从内存地址var2获取对象var1的值，
    		//相当于从主内存拷贝数据到工作内存，
    		//并赋值给工作内存中变量的副本
    		var5 = this.getIntVolatile(var1, var2);
    		//compareAndSwapInt方法的意思是，从主内存地址var2中获取值放入变量var1中，与var5中的值比较，如果一致，那么更新为var5+var4
    	}while(!this.compareAndSwapInt(var1, var2, var5, var5+var4));
    	return var5;
    }

### 3.4 CAS缺点 ###

#### 3.4.1 循环时间长，开销大 ####

如果CAS失败，那么会一直进行尝试，如果CAS长时间一直不成功，可能会给CPU带来很大的开销

//unsafe.getAndAddInt()
    public final int getAndAddInt(Object var1, long var2, int var4){ 
    	int var5;
    	do{ 
    		var5 = this.getIntVolatile(var1, var2);
    	}while(!this.compareAndSwapInt(var1, var2, var5, var5+var4));
    	return var5;
    }

#### 3.4.2 不能保证代码块的原子性 ####

只能保证一个共享变量的原子操作，对多个共享变量操作时，循环CAS就无法保证操作的原子性，此时需要使用锁来保证原子性

#### 3.4.3 存在ABA问题 ####

ABA问题，当两个线程共同访问一个共享变量时，线程1和线程2从主内存拷贝回公主内存时的值都为A，假设线程2比线程1执行快，线程2将值修改为B，然后写入主内存，此时主内存中的值为B。然后，线程2又将值从B修改会A，又写入主内存，此时主内存中的值为A。此时，线程1将值与主内存中的值进行比较时，发现两个值一样，线程1会认为该值没有被修改过，但是此值应该被修改过了。

#### 3.4.4 如何解决ABA问题 ####

采用原子引用类+版本号（类似于时间戳）  
JUC提供了原子时间戳引用类AtomicStampedReference，可以解决ABA问题

### 3.5 原子引用类 ###

JDK提供了像AtomicInteger、AtomicBoolean等原子类型，然而对于用户自定义的User、Order类型，却没有提供相应的类型。但是，用户可以利用原子引用类AtomicReference泛型类，定义自己的引用类

class User{ 
    	String userName;
    	int age;
    }
    
    public static void main(String[] args) { 
    	User zhang = new User("zhangsan", 22);
    	User li = new User("lisi", 25);
    	AtomicReference<User> atomicReference = new AtomicReference();
    	atomicReference.set(zhang);
    	atomicReference.compareAndSet(zhang, li);
    	System.out.println(atomicReference.get().toString());
    }

#### 3.5.1 ABA问题产生源码分析 ####

package com.chaoyue.jmm;
    
    import java.util.concurrent.TimeUnit;
    import java.util.concurrent.atomic.AtomicReference;
    
    public class ABADemo { 
    
        private static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);
    
        public static void main(String[] args) { 
            System.out.println("===================ABA问题的产生====================");
            new Thread(() -> { 
                atomicReference.compareAndSet(100, 101);
                atomicReference.compareAndSet(101, 100);
            }, "t1").start();
    
            new Thread(() -> { 
                try { 
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                }
                
                System.out.println(atomicReference.compareAndSet(100, 2020) + "\t" + atomicReference.get());
            }, "t2").start();
        }
    }

#### 3.5.2 ABA问题解决源码分析 ####

package com.chaoyue.jmm;
    
    import java.util.concurrent.TimeUnit;
    import java.util.concurrent.atomic.AtomicReference;
    import java.util.concurrent.atomic.AtomicStampedReference;
    
    public class ABADemo { 
    
        private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<Integer>(100, 1);
    
        public static void main(String[] args) { 
            System.out.println("===================ABA问题的解决====================");
            new Thread(() -> { 
                int stamp = atomicStampedReference.getStamp();
                System.out.println(Thread.currentThread().getName() + "\t" + "第1次版本号：" + stamp);
    
                try { 
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                }
                atomicStampedReference.compareAndSet(100,101,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
                System.out.println(Thread.currentThread().getName() + "\t" + "第2次版本号：" + atomicStampedReference.getStamp());
    
                atomicStampedReference.compareAndSet(101,100,atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
                System.out.println(Thread.currentThread().getName() + "\t" + "第3次版本号：" + atomicStampedReference.getStamp());
    
            }, "t3").start();
    
            new Thread(() -> { 
                int stamp = atomicStampedReference.getStamp();
                System.out.println(Thread.currentThread().getName() + "\t" + "第1次版本号：" + stamp);
    
                try { 
                    TimeUnit.SECONDS.sleep(3);
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                }
                boolean result = atomicStampedReference.compareAndSet(100, 2019, stamp, stamp + 1);
                System.out.println(Thread.currentThread().getName()+"\t修改成功否："+result+"\t当前版本号:"+atomicStampedReference.getStamp());
            }, "t4").start();
        }
    }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center]: /images/20210920/0b24ca40f44b4715b173651ebb14342e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210920/f369e3c38bd749f3836f913cd2ef6b83.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210920/1579a0f3fa8a471792f5ec68db22adc2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNTk5NDc5_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20210920/a6905ddbd5004fb68f4e6f2d6519b92c.png