关于java:Java-内存模型

1次阅读

共计 3172 个字符，预计需要花费 8 分钟才能阅读完成。

之前始终把 Java 内存模型 和 JVM 内存构造 搞混。其实两者是不同的货色。

Java 内存模型（Java Memory Model，JMM）定义了 java 运行时如何与硬件内存进行交互，比方规定了一个线程如何看到其余内存批改后共享变量的值。一些高级个性也建设在 JMM 的根底上，比方 volatile 关键字。

而 JVM 内存构造，定义了 JVM 内存是如何划分的。

上面咱们介绍 JMM。并从三个方面介绍：为什么，是什么，解决了什么

咱们都晓得一台根本的计算机有 CPU 和内存两个货色。

CPU 负责计算，内存负责存储运行的程序和数据。

每次 CPU 计算时它会通过地址总线（Address Bus）向内存发送一个地址信号，指定要读取内存单元的地址。而后进行期待 。
之后内存将数据通过数据总线返回给 CPU, CPU 会将数据加载到寄存器中解决。而后将后果存储回内存。

但随着计算机性能的倒退，CPU 的计算速度越来越快。这个期待的工夫（即内存读写的速度）相比计算的工夫变得越来越长，CPU 就无奈及时取得须要的数据，导致性能降落。

为了放慢运行的速度，加了一个CPU 高速缓存。每次须要读取数据的时候，先从内存读取到 CPU 缓存中，CPU 再从 CPU 缓存中读取。因为 CPU 高速缓存则间接集成在 CPU 外部，与 CPU 之间的间隔更近，因而访问速度大大放慢了。

实际上会分为一级缓存、二级缓存、和三级缓存，并且会有多核 CPU。如下图

在多核 CPU 的状况下，每个 CPU 都有本人的高速缓存，而它们又共享同一块主内存。就会产生 缓存一致性 问题。

比方，初始化 a = 0;

线程 a 执行 a = a + 1;

线程 b 执行 a = a + 1;

多核 CPU 下可能会产生上面这种状况：

CPU1 执行线程 a, 从内存读取 a 为 0，存到高速缓存中。
CPU2 执行线程 b, 从内存读取 a 为 0，存到高速缓存中。
CPU1 进行运算，得出后果 1，写回内存 i 的值为 1。
CPU2 进行运算，得出后果 1，写回内存 i 的值为 1。

而在咱们看来，正确后果应该是 2.

谬误的起因就是：两个 CPU 的高速缓存是互相独立的，无奈感知互相数据变动。

这就造成了缓存一致性问题。

怎么在硬件层面上解决这个问题? 比方 MESI 协定。

该协定定义了 四种缓存数据状态：

批改（Modified）：该数据在高速缓存中批改了，还没同步到主内存，数据只存在于本缓存，与主内存不统一
独占（Exclusive）: 我刚从内存中读取进去，他人没读过，数据只存在于本缓存中，与主内存统一
共享（Shared）：很多人同时从内存读该数据，数据存在于很多缓存中，与主内存统一
生效（Invalid）：有人对该数据操作了，这不是最新的，数据有效

在该协定下，下面执行的运算就变成了这样：

CPU1 执行线程 a, 从内存读取 a 为 0，存到高速缓存中。
CPU2 执行线程 b, 从内存读取 a 为 0，存到高速缓存中。
CPU1 进行运算，得出后果 1，写回内存 i 的值为 1。通过音讯的形式通知其余持有 i 变量的 CPU 缓存，将这个缓存的状态值为 Invalid。
CPU2 进行运算，从缓存中取值，但该值曾经是 Invalid，从新从内存中获取。读取 a 为 1，放入高速缓存
CPU2 进行运算，得出后果 2，写回内存 i 的值为 2。

从下面的例子，咱们能够晓得 MESI 缓存一致性协定，实质上是定义了一些内存状态，而后通过音讯的形式告诉其余 CPU 高速缓存，从而解决了数据一致性的问题。

说了这么多，到底为什么要有 Java 内存模型呢？

起因之一 就是下面提到的缓存一致性问题：在不同的 CPU 中，会应用不同的缓存一致性协定。例如 MESI 协定用于奔流系列的 CPU 中，而 MOSEI 协定则用于 AMD 系列 CPU 中，Intel 的 core i7 处理器应用 MESIF 协定。

当然还有其余起因，比方指令重排序导致的可见性问题等

那么怎么对立呢？要晓得，Java 的最大特点是 Write Once, Run Anywhere

为了解决这个问题，Java 封装了一套标准，这套标准就是Java 内存模型。

Java 内存模型想屏蔽各种硬件和操作系统的拜访差别，保障了 Java 程序在各种平台下对内存的拜访都能失去统一成果。目标是解决多线程存在的原子性、可见性（缓存一致性）以及有序性问题。

Java 线程之间的通信就是由 JMM 管制，从形象的角度来说，JMM 定义了线程和主内存之间的形象关系。JMM 的形象示意图如图所示

实际上，这个本地内存并不实在存在，只是 JMM 的抽象概念，它既可能在缓存，也可能在寄存器等。

从图上能够看出，线程 A 无奈间接拜访线程 B 的工作内存，线程间通信必须通过主内存。

JMM 通过管制主内存与每个线程的本地内存之间的交互，来提供内存可见性保障。

可见性指：指一个线程批改了共享变量的值后，其余线程是否可能立刻看到这个批改的值。

JMM 提供的一些高级个性解决了原子性，可见性的问题。

比方当初：

private volatile boolean isRunning = true;

    public void run() {while (isRunning) {// do some work}
    }

    public void stop() {isRunning = false;}

isRunning 变量被申明为 volatile，这意味着所有的读写操作都是从主存中进行的，而不是从缓存中进行的。

又比方 synchronized 关键字不仅保障可见性，同时也保障了原子性（互斥性）。在更底层，JMM 通过内存屏障来实现内存的可见性以及禁止重排序

比方输出

 private static Object lock = new Object();

    static class ThreadA implements Runnable {
        @Override
        public void run() {synchronized (lock) {for (int i = 0; i < 100; i++) {System.out.println("Thread A" + i);
                }
            }
        }
    }

    static class ThreadB implements Runnable {
        @Override
        public void run() {synchronized (lock) {for (int i = 0; i < 100; i++) {System.out.println("Thread B" + i);
                }
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {new Thread(new ThreadA()).start();
        Thread.sleep(10);
        new Thread(new ThreadB()).start();}

这里申明了一个名字为 lock 的对象锁。咱们在 ThreadA 和 ThreadB 内须要同步的代码块里，都是用 synchronized 关键字加上了同一个对象锁 lock

还没写残缺，倡议看 https://zhuanlan.zhihu.com/p/29881777

操作系统作为对底层硬件的形象，天然也须要解决 CPU 高速缓存与内存之间的缓存一致性问题。各个操作系统都对 CPU 高速缓存与缓存的读写访问过程进行形象，最终失去的一个货色就是「内存模型」。
Java 语言作为运行在操作系统层面的高级语言，为了解决多平台运行的问题，在操作系统根底上进一步形象，失去了 Java 语言层面上的内存模型。
JMM 是形象的，他是用来形容一组规定，通过这个规定来管制各个变量的拜访形式，围绕原子性、有序性、可见性等开展的。

参考：
http://concurrent.redspider.group/article/02/6.html
https://www.cnblogs.com/chanshuyi/p/deep-insight-of-java-memo…
https://zhuanlan.zhihu.com/p/29881777

正文完