jmm-java内存模型

java内存模型----底层原理

底层原理

从Java代码到最终执行的CPU指令的流程：

最开始，我们编写的Java代码，是*.java文件
在编译（javac命令）后，从刚才的*.java文件会变出一个新的Java字节码文件（*.class）
JVM会执行刚才生成的字节码文件（*.class），并把字节码文件转化为机器指令
机器指令可以直接在CPU上运行，也就是最终的程序执行

而不同的JVM实现会带来不同的“翻译”，不同的CPU平台的机器指令又千差万别；所以我们在java代码层写的各种Lock，其实最后依赖的是JVM的具体实现（不同版本会有不同实现）和CPU的指令，才能帮我们达到线程安全的效果。

由于最终效果依赖处理器，不同处理器结果不一样，这样无法保证并发安全，所以需要一个标准，让多线程运行的结果可预期，这个标准就是JMM。

在这里插入图片描述

JMM定义

为什么需要JMM
- C语言不存在内存模型的概念
- 依赖处理器，不同处理器结果不一样
- 无法保证并发安全
- 需要一个标准，让多线程运行的结果可预期
定义
- java memory model是一组规范，需要各个JM的实现来遵守JMM规范，以便于开发者可以利用这些规范，更方便地开发多线程程序。如果没有这样的一个JMM内存模型来规范，那么很可能经过了不同JVM的不同规则的重排序之后，导致不同的虚拟机上运行的结果不一样那是很大的问题。
- volatile、synchronized、Lock等的原理都是JMM。如果没有JMM，那就需要我们自己指定什么时候用内存栅栏等，那是相当麻烦的，幸好有了JMM，让我们只需要用同步工具和关键字就可以开发并发程序。

重排序

什么是重排序，代码案例

/**
 * 描述：     演示重排序的现象 “直到达到某个条件才停止”，测试小概率事件。
   思路参考自https://tech.meituan.com/2014/09/23/java-memory-reordering.html
 * CountDownLatch用于控制一个或多个线程等待其他线程完成操作后再继续执行
 * CountDownLatch内部维护了一个计数器，该计数器初始值为N，代表需要等待的线程数目。每当一个线程完成了自己的任务后，调用countDown()方法将计数器的值减1。
 * 当计数器到达0时，表示所有的线程都已完成任务，所有在await()方法上等待的线程会被唤醒，可以继续执行。
 * 在需要等待的地方加上栅栏latch.await()
 */
public class OutOfOrderExecution {

    private static int x = 0, y = 0;
    private static int a = 0, b = 0;

    public static void main(String[] args) throws InterruptedException {
        int i = 0;
        for (; ; ) {
            i++;
            x = 0;
            y = 0;
            a = 0;
            b = 0;

            CountDownLatch latch = new CountDownLatch(3);

            Thread one = new Thread(() -> {
                try {
                    latch.countDown();
                    latch.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                a = 1;
                x = b;
            });
            Thread two = new Thread(() -> {
                try {
                    latch.countDown();
                    latch.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                b = 1;
                y = a;
            });
            two.start();
            one.start();
            latch.countDown();
            one.join();
            two.join();

            String result = "第" + i + "次（" + x + "," + y + ")";
            if (x == 0 && y == 0) {
                System.out.println(result);
                break;
            } else {
                System.out.println(result);
            }
        }
    }

}
//结果分析：
//a=1;x=b(0);b=1;y=a(1)，最终结果是x=0,y=1
//b=1;y=a(0);a=1;x=b(1)，最终结果是x=1, y=0
//b=1;a=1;x=b(1);y=a(1)，最终结果是x=1,y=1
//x=0,y=0时，发生了重排序，此时执行顺序是：
//y = a;
//a = 1;
//x = b;
//b = 1;
//什么是重排序:在线程1内部的两行代码的实际执行顺序和代码在Java文件中的顺序不一致，代码指令并不是严格按照代码语句顺序执行的，它们的顺序被改变了，这就是重排序，这里被颠倒的是y=a和b=1这两行语句。

重排序的好处：提高处理速度

对比重排序前后的指令优化

*重排序的3种情况**

编译器优化：包括JVM，JIT编译器等
- 编译器（包括JVM，JIT编译器等）出于优化的目的（例如当前有了数据a，那么如果把对a的操作放到一起效率会更高，避免了读取b后又返回来重新读取a的时间开销），在编译的过程中会进行一定程度的重排，导致生成的机器指令和之前的字节码的顺序不一致。在刚才的例子中，编译器将y=a和b=1这两行语句换了顺序（也可能是线程2的两行换了顺序，同理），因为它们之间没有数据依赖关系，那就不难得到 x =0，y = 0 这种结果了。
CPU指令重排
- CPU 的优化行为，和编译器优化很类似，是通过乱序执行的技术，来提高执行效率。所以就算编译器不发生重排，CPU 也可能对指令进行重排，所以我们开发中，一定要考虑到重排序带来的后果。
内存"重排序"
- 内存系统内不存在重排序，但是内存会带来看上去和重排序一样的效果，所以这里的“重排序”打了双引号。由于内存有缓存的存在，在JMM里表现为主存和本地内存，由于主存和本地内存的不一致，会使得程序表现出乱序的行为。在刚才的例子中，假设没编译器重排和指令重排，但是如果发生了内存缓存不一致，也可能导致同样的情况：线程1 修改了 a 的值，但是修改后并没有写回主存，所以线程2是看不到刚才线程1对a的修改的，所以线程2看到a还是等于0。同理，线程2对b的赋值操作也可能由于没及时写回主存，导致线程1看不到刚才线程2的修改。

可见性

为什么会有可见性问题

在这里插入图片描述

CPU有多级缓存，导致读的数据过期
高速缓存的容量比主内存小，但是速度仅次于寄存器，所以在CPU和主内存之间就多了Cache层
线程间的对于共享变量的可见性问题不是直接由多核引起的，而是由多缓存引起的。
如果所有个核心都只用一个缓存，那么也就不存在内存可见性问题
每个核心都会将自己需要的数据读到独占缓存中，数据修改后也是写入到缓存中，然后等待刷入到主存中。所以会导致有些核心读取的值是一个过期的值。

解决可见性问题解析

通过使用volatile强制flush修改的变量到主存中，使得其他线程可见

JMM的抽象：主内存和本地内存

什么是主内存和本地内存

Java 作为高级语言，屏蔽了这些底层细节，用 JMM 定义了一套读写内存数据的规范，虽然我们不再需要关心一级缓存和二级缓存的问题，但是，JMM 抽象了主内存和本地内存的概念。
这里说的本地内存并不是真的是一块给每个线程分配的内存，而是JMM 的一个抽象，是对于寄存器、一级缓存、二级缓存等的抽象。

主内存和本地内存的关系

JMM有以下规定

所有的变量都存储在主内存中，同时每个线程也有自己独立的工作内存，工作内存中的变量内容是主内存中的拷贝
线程不能直接读写主内存中的变量,而是只能操作自己工作内存中的变量，然后再同步到主内存中
主内存是多个线程共享的，但线程间不共享工作内存,如果线程间需要通信，必须借助主内存中转来完成

因为所有的共享变量存在于主内存中，每个线程有自己的本地内存，而且线程读写共享数据也是通过本地内存交换的，所以才导致了可见性问题。

在这里插入图片描述

Happens-Before原则

什么是happens-before

happens-before规则是用来解决可见性问题的:在时间上，动作A发生在动作B之前，B保证能看见A，这就是happens-before。
两个操作可以用 happens-before 来确定它们的执行顺序:如果一个操作 happens-before 于另一个操作，那么我们说第一个操作对于第二个操作是可见的。

happens-before规则有哪些？

单线程规则
锁操作(synchronized和Lock)
volatile变量
线程启动
线程join
传递性：如果hb(A,B)而且hb(B,C)，那么可以推出hb(A，C)
中断：一个线程被其他线程interrupt时，那么检测中断(isInterrupted)或者抛出InterruptedException一定能看到:
构造方法
工具类的Happens-Before原则
线程安全的容器get一定能看到在此之前的put等存入动作
CountDownLatch
Semaphore是一种用于控制同时访问特定资源的线程数量的工具，它基于信号量模型，通过协调各个线程来合理使用公共资源
- 计数器：Semaphore内部维护一个计数器，表示可用许可证的数量
- 等待队列：包含一个等待队列，用于存储因获取许可证而被阻塞的线程
Future
线程池
CyclicBarrier

原子性

什么是原子性

一系列的操作，要么全部执行成功，要么全部不执行，不会出现执行一半的情况，是不可分割的。
ATM取钱
i++不是原子性的
用synchronized实现原子性

java中原子操作有哪些

除long和double之外的基本类型(int,byte,boolean, short, char,float)的赋值操作
所有引用reference的赋值操作，不管是 32 位的机器还是 64 位的机器
java.concurrent.Atomic.* 包中所有类的原子操作

long和double的原子性

问题描述:官方文档、对于 64 位的值的写入，可以分为两个 32 位的操作进行写入、读取错误、使用 volatile解决
结论:在32位上的JVM上，long和 double的操作不是原子的，但是在64位的JVM上是原子的
实际开发中:商用Java虚拟机中不会出现

原子操作 + 原子操作 != 原子操作

简单地把原子操作组合在一起，并不能保证整体依然具有原子性

比如我去ATM机两次取钱是两次独立的原子操作，但是期间有可能银行卡被借给女朋友，也就是被其他线程打断并被修改。
全同步的HashMap也不完全安全(如果单独操作是没有问题的，但一系列的操作组合在一起之后多线程运行依然会发生线程安全问题)。所以对我们而言以后在线程并发编程的时候，对于我们lock锁保护的范围要额外的注意，这样才能保证我们程序的正确性。
原子操作组合在一起，并不能保证整体依然具有原子性
比如我去ATM机两次取钱是两次独立的原子操作，但是期间有可能银行卡被借给女朋友，也就是被其他线程打断并被修改。
全同步的HashMap也不完全安全(如果单独操作是没有问题的，但一系列的操作组合在一起之后多线程运行依然会发生线程安全问题)。所以对我们而言以后在线程并发编程的时候，对于我们lock锁保护的范围要额外的注意，这样才能保证我们程序的正确性。