笔记系列：Java内存模型JMM

Java的内存模型，即JMM。依托于操作系统的存储结构，JVM作为虚拟机相当于操作系统之上的一个软件。因此，本文先介绍了操作系统层面的存储结构、硬件级的数据一致性问题以及相对应的一些策略等的知识，这里面也涉及到指令乱序执行的问题，给出了验证的代码。然后结合JVM对于软件层面的一些内存屏障的实现，例如volatile、synchronized关键字。最后是比较重要的java的对象和内存的关系，包括了类的创建过程以及在内存中的排布状态细节，这里包括了通过java代理的使用来观察对象的大小等实际代码的操作。 说明：仍旧是笔记系列。 关键字：JMM，volatile，synchronized，agent，指令重排，乱序证明，对象大小，总线锁，缓存锁，缓存行，伪共享，内存屏障。

1、操作系统的存储结构

呈现一个金字塔型，整体呢又可以把金字塔一分为5层。从上至下依次为：

1、CPU

2、主板

3、内存

4、磁盘

5、网络

可以看到CPU是最快的，但是最窄，也就是说它虽然快，但存储量不大。CPU又可以分为三层，从上至下分别为：

1、寄存器register

2、L1高速缓存

3、L2高速缓存

从1到3，也是尊崇金字塔规律，越来越慢，但是存储量越来越大。这是一颗CPU内部的存储结构。继续看上面的5层结构，CPU下面就是主板。主板上面插着内存条、磁盘、网卡等。按道理来讲他们是平级的，但是由于内部原理不同，他们的存储速度和存储量有很大的差别。CPU下面是主板，多颗CPU共享一块L3高级缓存，注意这个L3高级缓存不是内存，而是主板自带的，它比内存要快，但是没有内存储量大。接下来继续往下，就是内存，我们比较熟悉，然后是磁盘，也叫硬盘，那么其实磁盘之上内存之下还应该有一个SSD固态硬盘的存在，这个我们也比较了解。最底部一层是网络，基于网络存储肯定是最慢的，然而它的储量上不封顶，远不是一台主机能比拟的。

2、硬件层数据一致性问题

2.1 CPU缓存不一致

前面提到了，从主板开始，多颗CPU共享存储空间，也就是说除了寄存器、L1、L2是单颗CPU的内部存储结构以外，金字塔再往下的存储工具，都是被多颗CPU所共享的。所以这就有一个问题，就是在多颗CPU在读取共享存储空间的时候，要保证数据的一致性。那么这个保证该具体如何实现呢？有总线锁和缓存锁。

2.2 总线锁

那么一种实现的情况，是相当于一个CPU在访问共享空间的时候，为数据上锁，其他CPU在访问时要等待。但这样的话，会造成一个CPU在读取共享空间会给整个总线上锁，其他CPU哪怕要访问其他的变量，也必须要等待。所以它很慢，这种实现情况已经过时。

2.3 缓存锁：MESI Cache一致性协议

硬件层的一致性协议很多，intel使用的是MESI。具体实现原理就是，给每一个缓存做了标记，相对于主存，它的四种标记状态有：Modified、Exclusive、Shared、Invalid，这四种状态的首字母合起来就是MESI。具体的协议：

1、Modified，修改过。

2、Exclusive，只有我在用，其他人不关心

3、Shared，大家都在用

4、Invalid，我用的时候，别人改过了。所以这时候，我要再主动去主存中读取一遍。

这四种状态以及特定处理，保证了各个CPU之间的缓存保持一致性。

但有些无法被缓存的数据，或者跨越多个缓存行的数据，依然必须使用总线锁。因此现代CPU的数据一致性实现是通过缓存锁(MESI ...)加上总线锁。

2.4 缓存行

CPU读取缓存以cache line为基本单位，目前多数实现是64字节。

2.5 伪共享

假如两个数据x和y位于同一个缓存行，被CPU所读取，会产生一个问题。当一颗CPU中的x被修改，会通知另一个CPU重新读取（相当于MESI的Invalid状态，那么就需要重新读取一遍）。然后另一个CPU其实没有用到x，它只是用了y，但是由于x和y在同一个缓存行，所以它被迫要重新读。相同的情况可能会蔓延到各个CPU，这会带来无效的开销，是由缓存行带来的。这种问题叫做伪共享。

伪共享指位于同一缓存行的两个不同数据，被两个不同的CPU锁定，产生互相影响的伪共享问题。

2.6 缓存行对齐

就是针对伪共享的情况，还是以上面的x和y为例，就是强制把x和y放到两个缓存行中，这样一来，x和y就不再互相影响，会提高效率。这就是缓存行对齐。Disruptor高性能开源框架就采用了缓存行对齐的能力。那么如何把x和y放到两个缓存行中呢？我们知道一个缓存行是64字节，我们可以在对象申请内存空间的时候，先定义7个long类型变量先占据56个字节，然后只剩8个字节放x，那么这个缓存行肯定是满了，这时候y再申请的时候一定会放到另一个缓存行中。

缓存行对齐其实就是空间换时间，通过浪费掉56个字节的空间，完成对于伪共享问题的避免，实现缓存行对齐，提高性能。

2.7 乱序执行

CPU执行速度非常快，大约是主存IO速度的100倍。假设CPU从内存中读入5条指令，其中第一条指令是从内存中读取一个值。如果CPU在执行第一条指令的时候，什么也不做，它需要等待100倍的空闲时间，这无疑是浪费的。因此，现代CPU都会在执行内存读取时，不去等待而是去分析下一条指令内容，不让CPU空闲着，尽可能提高效率。如果下一条指令与第一条没有直接依赖关系，则可以在第一条指令还在内存取值的时候，CPU直接去执行下一条指令。这时候看上去，第一条指令和第二条指令是并行着的。所以这时候，CPU就是一个乱序执行。

高性能编程得合理利用操作系统底层硬件设计，所以看上去没什么道理。这里使用WCBuffer去合并写，如果你能用代码把这个特性利用上了，那么你的程序肯定比没利用上底层特性的要快！

上面是分析乱序执行读的操作，写操作也可以提高效率，就是通过CPU寄存器和L1缓存中间的WCBuffer来执行。WCBuffer是Write Combining Buffer，即写合并缓存。这个缓存只有4个字节。所以如果要利用WCBuffer，即写合并，就需要控制数据在4个字节的空间里进行操作，多条指令在该缓存中进行合并操作，然后一次性把结果写入低级存储。

2.8 乱序证明

public static void main(String[] args) throws InterruptedException {
    int i = 0;
    for(;;) {
        i++;
        x = 0; y = 0;
        a = 0; b = 0;
        Thread one = new Thread(new Runnable() {
            public void run() {
                //由于线程one先启动，下面这句话让它等一等线程two. 读着可根据自己电脑的实际性能适当调整等待时间.
                shortWait(100000);
                a = 1;
                x = b;
            }
        });

        Thread other = new Thread(new Runnable() {
            public void run() {
                b = 1;
                y = a;
            }
        });
        one.start();other.start();
        one.join();other.join();
        String result = "第" + i + "次 (" + x + "," + y + "）";
        if(x == 0 && y == 0) {
            System.err.println(result);
            break;
        } else {
            //System.out.println(result);
        }
    }
}

这段代码的一些情况：

1、x和y初始化都是0。

2、for循环是无限循环，只有x和y同时等于0的时候才会跳出。

3、判定x和y同时等于0的跳出条件是在两个线程执行以后执行的。

4、第一个线程首先会等待10_0000L毫秒，强制让第二个线程先执行。

5、第一个线程a=1和x=b。第二个线程b=1和y=a。注意，他们之间都不存在指令依赖。

如果线程内指令是顺序执行的，那么有几种结果：

1、第二个线程b=1肯定会先执行成功，而第一个线程a=1不一定在y=a之前执行完毕。若a=1未执行完毕，则(x,y)=(1,0)。

2、若a=1时，y=a还未执行，则(x,y)=(1,1)。

如果第一个线程不设等待时间，则第二个线程的b=1未必会先执行。则结果除了以上两种情况以外，分析的内容差不多就省略了，直接列出结果：

1、若x=b执行时，b=1还未执行完毕，则(x,y)=(0,1)。

2、若x=b执行时，b=1已执行完毕，则(x,y)=(1,1)。

所以，即使第一个线程不增加等待，(x,y)=[(1,0),(0,1),(1,1)]，就是没有(0,0)的情况发生！

那么，当CPU指令乱序执行的时候，可能会出现(0,0)的情况，因为这两个线程内分别的2个指令均没有上下的依赖关系，所以乱序执行的前提有了。那么如果乱序执行，什么时候会出现(0,0)的情况呢？其实很简单，就是这两个线程内分别的2个指令的执行顺序全部颠倒了，即：

1、第一个线程，先执行x=b，再执行a=1。

2、第二个线程，先执行y=a，再执行b=1。

那么就可能出现：

1、当x=b执行的时候，b=1尚未执行，x=0。

2、当y=a执行的时候，a=1尚未执行，y=0。

所以，当程序能够识别到(0,0)的情况时，也就反证了CPU乱序执行指令了。下面看一下输出结果：

第461766次 (0,0）

一定会输出结果的，因为前提条件有了（指令间无依赖关系），则CPU乱序执行指令是确定的，只是执行时间的长短就不一定了，你不一定要等待多久，才能等到这个输出。

3、特定情况下保证有序

3.1 硬件级别保证有序

x86 CPU内存屏障：

• sfence，save屏障。在sfence指令前的写操作必须在指令后的写操作前完成。
• Ifence，load屏障。读操作不能重排。
• mfence，读写混合。读写操作均不能重排。

原理就是通过硬件级CPU的设定，在两条有可能乱序执行的指令之间加一道栅栏(fence)，强制保证不会乱序执行。

3.2 intel lock汇编指令

intel汇编指令集中也包括了lock命令，也可以实现屏障。

3.3 JVM的内存屏障

JVM的内存屏障依赖于硬件级别的内存屏障或者汇编的lock指令。JVM本质上是操作系统上面的软件，所以JVM来保证内存屏障是作为软件来依赖硬件的实现。JVM的内存屏障的规范包括：

• LoadLoad屏障：两条指令都是读，中间加一层双读内存屏障，保证顺序。
• StoreStore屏障：两条指令都是写，中间加一层双写内存屏障，保证顺序。
• LoadStore屏障：先读后写两条指令，中间加一层读写内存屏障，保证顺序。
• StoreLoad屏障：先写后读两条指令，中间加一层写读内存屏障，保证顺序。

不同的cpu的硬件层面的实现不同，例如龙芯、x86、arm等芯片设计框架，他们对于内存屏障的实现都不同，而JVM是跨平台的，它提出一种规范，基于不同底层向上提供统一的软件层级的内存屏障实现。

4、volatile

一段java代码要经过几个阶段：编码=》Class=》JVM=》操作系统。那我们研究volatile，也按照这个路线循迹追踪。

4.1 字节码

先编写一段代码：

我们看到变量a和b在字节码层面的唯一区别是访问标志，Access Flag不同，加了volatile修饰的变量b会变为0x0040。

4.2 JVM的处理

JVM对于volatile的实现，是基于3.3的处理。

1、针对写操作，StoreStore内存屏障 + volatile 写操作 + StoreLoad内存屏障。为什么后面是StoreLoad呢？第一个Store好理解，因为前面接的是写操作，第二个Load的含义就是你读的操作必须在我写完以后，保证了一致性。

2、针对读操作，LoadLoad内存屏障 + volatile 读操作 + LoadStore内存屏障。这里也一样，为什么后面是LoadStore呢？第一个Load是因为前面接的是读操作，第二个Store就是你再接写的指令一定是在我读完以后，保证了一致性。

4.3 操作系统层面

通过汇编代码去调用底层硬件层面的能力，保证对内存区域加锁，lock汇编指令。

工具：hsdis，HotSpot Dis Assembler。JVM反汇编。

5、synchronized

目前synchronized指令的优化速度已经可以替代volatile关键字来执行线程安全了。

我们仍旧按照字节码、JVM以及操作系统的方式来分析synchronized关键字的内部实现原理。

5.1 字节码

首先写一个代码，我们定义一个同步的空方法m，观察它的字节码。

与volatile关键字相同，我们增加的m方法只是增加了访问标志Access_Flag为synchronized。

下面再看一下synchronized关键字上锁的一种使用方法所对应的字节码的情况。

当我们使用synchronized关键字来上锁的时候，可以看到JVM的字节码有了变化。如上图所示，JVM的code，有monitorenter和monitorexit的指令。

注意这个指令是JVM的指令集，不是操作系统的。

所以，这种方式的JVM级别的实现已经与volatile不同了，synchronized关键字明显能够支持的情况更加多元。

有两个exit的意思，是因为其中有一个是处理异常退出的情况。

5.2 JVM的处理

JVM这里的处理是通过C++实现的内容，它会拿到Class的字节码以后去执行，我们可以参照JVM规范查询一下monitorenter和monitorexit的内容。

1、monitorenter，进入一个针对某对象的监控中，它的字节码是0xc2。每个对象都会关联一个监控器，当这个监控器有owner的时候，会被上锁。它可以有1个或多个对应的monitorexit指令，为了实现synchronized状态。这里面包括对于操作数栈的访问计数的控制，当它为0的时候，可以给它指定owner。

2、monitorexit，执行monitorexit指令的当前线程一定是监控器的owner，它关联者一个对象实例。当操作数栈中的访问计数为0的时候，当前线程退出监控器，不再是当前对象的owner。其他线程可以尝试成为这个owner。

其实这个过程就是JVM在内存中对于操作权利的监控，用来调度不同线程的owner身份。

5.3 操作系统层面

仍旧是通过汇编语言的方式，x86的话还是lock comxchg XXXX 语句。

6、指令排序规范

6.1 java并发内存模型

java线程 <> 工作内存 <> |save| 主

java线程 <> 工作内存 <> |and | <==> 内

java线程 <> 工作内存 <> |load| 存

6.2 happens-before原则

JVM规范，规定有些指令不可以指令重排。java语言规范，Java Language Specification，有专门的说明，有哪些情况不能指令重排。

as if serial ，单线程执行结果与多线程指令重排的结果一致。

7、对象与内存

7.1 对象的创建过程

T t = new T();`

1、classloading

2、class linking(verfification, preparation, resolution)

3、class initializing

4、申请对象内存

5、成员变量赋默认值

6、调用构造方法<init>，①成员变量顺序赋初始值。②执行构造方法语句（先调用父类，再调用子类，若子类有实现）。

7.2 对象在内存中的存储布局

7.2.1 观察JVM虚拟机配置

通过java -version中间增加 -XX:+PrintCommandLineFlags，进行查看。

-XX:ConcGCThreads=3 -XX:G1ConcRefinementThreads=10 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=268435456 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=4294967296 -XX:MinHeapSize=6815736 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC openjdk version "15.0.5" 2021-10-19 OpenJDK Runtime Environment Zulu15.36+13-CA (build 15.0.5+3-MTS) OpenJDK 64-Bit Server VM Zulu15.36+13-CA (build 15.0.5+3-MTS, mixed mode, sharing)

可以观察到虚拟机的初始堆大小、最大堆大小等信息。

7.2.2 普通对象

1、markword，对象头, 在HotSpot JVM中被称为markword，8个字节。

2、ClassPointer，类指针。一个对象有一个指针指向Class，例如对象t有一个指针，指向T.Class。

3、Instance，实例数据，成员变量，类指针下面有一个区域，记录成员变量的内容，例如int a =8。

4、Padding对齐，8字节的倍数。64位机器是按块读取，如果不足一个块，就是需要对齐。

7.2.3 数组对象

1、对象头

2、CLassPointer

3、数组长度，指定数组长度，4个字节。

4、数组数据

5、对齐

区块链的区块跟这个设计有点像，包括网络传输对象，也都是相似。

7.2.4 实例：查看对象大小

类加载器中很多具体的例如加载的操作都是native方法完成的，native方法是操作系统级别的本地方法，是C++实现的，这部分内容对于java来讲是黑盒的。但是在Class文件被加载到JVM之前，Java提供了一个代理，它在中间拦截，可获得Class的具体信息。本例就是通过Agent功能来获取对象的大小。

首先来编写Agent，最好新起一个单独的工程。创建一个AgentObjSize类。

package com.evsward.agent;

import java.lang.instrument.Instrumentation;

public class AgentObjSize {
    /**
     * 通过调试器，可以获得对象大小
     */
    private static Instrumentation inst;

    public static void premain(String agentArgs, Instrumentation _inst) {
        inst = _inst;
    }

    public static long sizeOf(Object o) {
        return inst.getObjectSize(o);
    }

}

其中要注意到的是Instrumentation类，这是一个仪表接口，可以理解为JVM虚拟机的仪表。它是在java.lang.instrument包下。

Instrumentation 提供了调试Java代码所需要的服务。调试器是将字节码添加到方法中，以便收集工具所使用的数据。

所以声明静态的Instrumentation对象以及声明静态premain方法是固定的写法。sizeOf方法是我们获取到inst实例以后自己编写使用的，用于对外提供服务。

如果要想该类AgentObjSize真正成为Agent，还需要指定MINIFEST.MF文件。在src下新建包META-INF，然后手动创建MF文件，或者也可以在Idea中配置Project Structure -> Artifacts -> 添加JAR -> copy to the output directory and link via manifest，确定以后，会在项目文件中自动帮你生成好META-INF包和MINIFEST.MF文件，然后再手动修改MINIFEST.MF文件即可。最后回到项目中Build -> Build Artifacts -> build，打包成jar。

Manifest-Version: 1.0
Main-Class: 
Premain-Class: com.evsward.agent.AgentObjSize

以上是MINIFEST.MF最终的内容情况。

然后我们开启一个新工程，把上面的jar引入到工程中（Project Structure -> Libraries -> 添加jar进来）。然后新建一个类ObjectUseAgent用来调用Agent方法。

package com.evswards.jvm;

import com.evsward.agent.AgentObjSize;

public class ObjectUseAgent {
    public static void main(String[] args) {
        System.out.println(AgentObjSize.sizeOf(new Object()));
        System.out.println(AgentObjSize.sizeOf(new int[]{}));
        System.out.println(AgentObjSize.sizeOf(new P()));
    }
    //一个Object占多少个字节
    // -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
    // 开启UseCompressedOops，默认会开启UseCompressedClassPointers
    // Oops = ordinary object pointers
    private static class P {
        //8 _markword
        //4 _class pointer
        int id;         //4
        String name;    //4
        int age;        //4

        byte b1;        //1
        byte b2;        //1

        Object o;       //4
        byte b3;        //1

    }
}

然后去执行该main方法，执行前要Edit Configuration，在vm options命令中添加：

-javaagent:{指向你的jar包全路径}.jar

该参数-javaagent就是用来指定agent类的。然后再运行main函数，可以得到结果：

16 24 48

注意，这里默认设定了压缩参数，开启UseCompressedOops，默认会开启UseCompressedClassPointers。

所以，我们可以在上面vm options命令中继续添加 -XX:-UseCompressedClassPointers以及 -XX:-UseCompressedOops命令，然后去执行main方法，查看结果的不同。对象的大小，会受到压缩参数的影响，若加入压缩，ClassPointer指针会被从8个字节压缩成4个字节，另外的引用对象，例如String、Object的对象也会被从8个字节压缩成4个字节。这里可以分别尝试添加与删除压缩参数然后执行一下main方法去验证。

7.2.5 对象头的具体内容

对象头是markword，HotSpot JVM 64位机器，8个字节，定义在markOop.hpp文件中：

包括了：

1、锁定信息，代表了该对象是否被锁定。

2、GC的标记，用作垃圾回收

3、对象的hashcode，System.identityHashCode(...)

8个字节共64位，通过对这64位内存空间的使用，记录了对象的状态。

7.2.6 对象定位

当我们new出一个对象的时候，对象是如何找到类的，有两种方式：

1、句柄池，间接指针。

2、直接指针，HotSpot使用。