Java内存模型底层实现原理（三十一）

末蓝、 2023-01-01 01:55 126阅读 0赞

Java内存模型又称JMM，其底层实现原理需要详细说一下，非常有利于技术的提高：

**1、JMM**  **基础** **-** **计算机原理**

Java  内存模型即  Java Memory Model ，简称  JMM 。 JMM  定义了  Java  虚拟机 (JVM)在计算机内存 (RAM) 中的工作方式。JVM 是整个计算机虚拟模型，所以  JMM 是隶属于 JVM  的。 Java1.5  版本对其进行了重构，现在的  Java  仍沿用了  Java1.5 的版本。Jmm  遇到的问题与现代计算机中遇到的问题是差不多的。 物理计算机中的并发问题，物理机遇到的并发问题与虚拟机中的情况有不少 相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。 根据《Jeff Dean  在  Google  全体工程大会的报告》我们可以看到

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

计算机在做一些我们平时的基本操作时，需要的响应时间是不一样的。 （以下案例仅做说明，并不代表真实情况。） 如果从内存中读取 1M  的  int  型数据由  CPU  进行累加，耗时要多久？ 做个简单的计算，1M  的数据， Java  里  int  型为  32  位， 4  个字节，共有 1024\*1024/4 = 262144 个整数 ，则  CPU  计算耗时： 262144 \*0.6 = 157 286  纳秒， 而我们知道从内存读取 1M  数据需要  250000  纳秒，两者虽然有差距（当然这个 差距并不小，十万纳秒的时间足够 CPU  执行将近二十万条指令了），但是还在 一个数量级上。但是，没有任何缓存机制的情况下，意味着每个数都需要从内存 中读取，这样加上 CPU  读取一次内存需要  100  纳秒， 262144  个整数从内存读取 到 CPU  加上计算时间一共需要  262144\*100+250000 = 26 464 400  纳秒，这就存在 着数量级上的差异了。 而且现实情况中绝大多数的运算任务都不可能只靠处理器“计算”就能完成， 处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个 I/O  操作是 基本上是无法消除的（无法仅靠寄存器来完成所有运算任务）。早期计算机中cpu 和内存的速度是差不多的，但在现代计算机中， cpu  的指令速度远超内存的 存取速度, 由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所 以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高 速缓存（Cache ）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复 制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样 处理器就无须等待缓慢的内存读写了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

在计算机系统中，寄存器划是  L0  级缓存，接着依次是  L1 ， L2 ， L3 （接下来 是内存，本地磁盘，远程存储）。越往上的缓存存储空间越小，速度越快，成本 也更高；越往下的存储空间越大，速度更慢，成本也更低。从上至下，每一层都 可以看做是更下一层的缓存，即：L0  寄存器是  L1  一级缓存的缓存， L1  是  L2  的 缓存，依次类推；每一层的数据都是来至它的下一层，所以每一层的数据是下一 层的数据的子集

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

在现代  CPU  上，一般来说  L0 ，  L1 ， L2 ， L3  都集成在  CPU  内部，而  L1  还分 为一级数据缓存（Data Cache ， D-Cache ， L1d ）和一级指令缓存（ Instruction Cache ，

I-Cache ， L1i ），分别用于存放数据和执行数据的指令解码。每个核心拥有独立 的运算处理单元、控制器、寄存器、L1 、 L2  缓存，然后一个  CPU  的多个核心共 享最后一层 CPU  缓存  L3

**2、物理内存模型带来的问题**

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为 计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence）。在多处理器系统中，每个处理器都有自己的高速缓存，而它们又 共享同一主内存（MainMemory ）。当多个处理器的运算任务都涉及同一块主内 存区域时，将可能导致各自的缓存数据不一致。

现代的处理器使用写缓冲区临时保存向内存写入的数据。写缓冲区可以保证 指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产 生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同 一内存地址的多次写，减少对内存总线的占用。虽然写缓冲区有这么多好处，但 每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作 的执行顺序产生重要的影响：处理器对内存的读/ 写操作的执行顺序，不一定与 内存实际发生的读/ 写操作顺序一致。

![20201230162242681.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

处理器  A  和处理器  B  按程序的顺序并行执行内存访问，最终可能得到  x=y=0 的结果。处理器 A  和处理器  B  可以同时把共享变量写入自己的写缓冲区（步骤  A1 ， B1），然后从内存中读取另一个共享变量（步骤  A2 ， B2 ），最后才把自己写缓 存区中保存的脏数据刷新到内存中（步骤 A3 ， B3 ）。当以这种时序执行时，程 序就可以得到 x=y=0  的结果。 从内存操作实际发生的顺序来看，直到处理器 A  执行  A3  来刷新自己的写缓 存区，写操作 A1  才算真正执行了。虽然处理器  A  执行内存操作的顺序为： A1 → A2，但内存操作实际发生的顺序却是  A2 → A1 。 如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？为了 解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根 据协议来进行操作，这类协议有 MSI 、 MESI （ Illinois Protocol ）、 MOSI 、 Synapse 、 Firefly 及  Dragon Protocol  等。

**3、伪共享**

前面我们已经知道， CPU  中有好几级高速缓存。但是  CPU  缓存系统中是以 缓存行（cache line ）为单位存储的。目前主流的  CPU Cache  的  Cache Line  大小都 是 64Bytes 。 Cache Line  可以简单的理解为  CPU Cache  中的最小缓存单位，今天的 CPU 不再是按字节访问内存，而是以  64  字节为单位的块 (chunk) 拿取，称为一个 缓存行(cache line) 。当你读一个特定的内存地址，整个缓存行将从主存换入缓存。 一个缓存行可以存储多个变量（存满当前缓存行的字节数）；而 CPU  对缓 存的修改又是以缓存行为最小单位的，在多线程情况下，如果需要修改“共享同 一个缓存行的变量”，就会无意中影响彼此的性能，这就是伪共享（False Sharing ）。 为了避免伪共享，我们可以使用数据填充的方式来避免，即单个数据填充满 一个 CacheLine 。这本质是一种空间换时间的做法。但是这种方式在  Java7  以后 可能失效。

Java8  中已经提供了官方的解决方案， Java8  中新增了一个注解

@sun.misc.Contended 。

比如  JDK  的  ConcurrentHashMap  中就有使用

![20201230162335282.png][]

加上这个注解的类会自动补齐缓存行，需要注意的是此注解默认是无效的， 需要在 jvm  启动时设置 \-XX:-RestrictContended  才会生效。

测试代码如下：

/**
     * 类说明：伪共享
     */
    public class FalseSharing  implements Runnable
    {
        //创建和CPU数相同的线程
        public final static int NUM_THREADS =
                Runtime.getRuntime().availableProcessors();
        public final static long ITERATIONS = 500L * 1000L * 1000L;
        private final int arrayIndex;
    
        /*数组大小和CPU数相同*/
    //    private static VolatileLong[] longs = new VolatileLong[NUM_THREADS];
    //    private static VolatileLongPadding[] longs = new VolatileLongPadding[NUM_THREADS];
    
        private static VolatileLongAnno[] longs = new VolatileLongAnno[NUM_THREADS];
        static{
            /*将数组初始化*/
            for (int i = 0; i < longs.length; i++){
                longs[i] = new VolatileLongAnno();
            }
        }
    
        public FalseSharing(final int arrayIndex){
            this.arrayIndex = arrayIndex;
        }
    
        public static void main(final String[] args) throws Exception{
            final long start = System.nanoTime();
            runTest();
            System.out.println("duration = " + (System.nanoTime() - start));
        }
    
        private static void runTest() throws InterruptedException{
            /*创建和CPU数相同的线程*/
            Thread[] threads = new Thread[NUM_THREADS];
            for (int i = 0; i < threads.length; i++){
                threads[i] = new Thread(new FalseSharing(i));
            }
    
            for (Thread t : threads){
                t.start();
            }
    
            /*等待所有线程执行完成*/
            for (Thread t : threads){
                t.join();
            }
        }
    
        /*访问数组*/
        public void run(){
            long i = ITERATIONS + 1;
            while (0 != --i){
                longs[arrayIndex].value = i;
            }
        }
    
        public final static class VolatileLong {
            public volatile long value = 0L;
        }
    
        // long padding避免false sharing
        // 按理说jdk7以后long padding应该被优化掉了，但是从测试结果看padding仍然起作用
        public final static class VolatileLongPadding {
            public long p1, p2, p3, p4, p5, p6, p7;
            public volatile long value = 0L;
            volatile long q0, q1, q2, q3, q4, q5, q6;
        }
    
        /**
         * jdk8新特性，Contended注解避免false sharing
         * Restricted on user classpath
         * Unlock: -XX:-RestrictContended
         */
        //@sun.misc.Contended
        public final static class VolatileLongAnno {
            public volatile long value = 0L;
        }
    }

类中，只有一个 long 类型的变量：定义一个 VolatileLong 类型的数组，然后让多个线程同时并发访问这个数组， 这时可以想到，在多个线程同时处理数据时，数组中的多个 VolatileLong 对象可 能存在同一个缓存行中。运行后，可以得到运行结果：花费了 28 秒多。

![20201231102110587.png][]

我们改用进行了缓存行填充的变量，加上相应注解：

@sun.misc.Contended
        public final static class VolatileLongAnno {
            public volatile long value = 0L;
        }

JVM加上配置：

![20201231102016619.png][]

执行结果：

![20201231102429805.png][]

花费了 10  秒， 由上述的实验结果表明，伪共享确实会影响应用的性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221120/a0cea5bbad5a445abd7757b50ac3eeab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221120/2e6b68889f794f3d980ba59029aaabb0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221120/d85fb73ce55d45ea86706e25323fed3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221120/30d90c7d32cb432781695b21abb54918.png
[20201230162242681.png]: /images/20221120/61e104d1fc8b4e7cac9ca212c03dd133.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221120/d518172fb6c643efb5d087117202f2cf.png
[20201230162335282.png]: /images/20221120/52df11b6eef446e995742572c263cf8d.png
[20201231102110587.png]: /images/20221120/3c89e2bbdd2341ab8509ef208433d43a.png
[20201231102016619.png]: /images/20221120/e49f0327a99044f09989885c7fa77474.png
[20201231102429805.png]: /images/20221120/426f0668378e479381d82634e68524ce.png