JVM--知识点整理

action
120 阅读22分钟

1. JVM 的位置

JVM 在操作系统上

2. JVM 的体系结构

3. 类加载器和双亲委派机制

作用：加载 .class 文件

public static void main(String[] args) {
    // 类就相当于是一个模板，对象是具体的实例
    Person p1 = new Person();
    Person p2 = new Person();
    Person p3 = new Person();
    // 三个实例的 hashCode 值不一样
    System.out.println(p1.hashCode());
    System.out.println(p2.hashCode());
    System.out.println(p3.hashCode());
    Class<? extends Person> aClass1 = p1.getClass();
    Class<? extends Person> aClass2 = p1.getClass();
    Class<? extends Person> aClass3 = p1.getClass();
    // 这里用到都是同一个模板，hashCode 值一样
    System.out.println(aClass1.hashCode());
    System.out.println(aClass2.hashCode());
    System.out.println(aClass3.hashCode());
    // 得到类加载其，同一个类加载器
    System.out.println(aClass1.getClassLoader());
    System.out.println(aClass2.getClassLoader());
    System.out.println(aClass3.getClassLoader());
}

加载器包括：

  1. 虚拟机自带的加载器

  2. 启动类（根）加载器（BootstrapClassLoader）

    用 c+ 编写的，加载 java 核心库 java.* ，构造 ExtClassloader 和 AppClassLoader。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作

  3. 扩展类加载器（ExtClassLoader）

    java 编写，加载扩展库，如：classpath 中的 jre，javax.* 或者 java.ext.dir 指定位置中的类，开发者可以直接使用标准扩展类加载器

  4. 应用程序（系统）加载器（AppClassLoader）

    java 编写，加载程序所在的目录，如：user.dir 所在的位置的 class

  5. 用户自定义类加载器（CustomClassLoader）

    java 编写，用户自定义的类加载器，可加载指定路径的 class 文件

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先检查这个classsh是否已经加载过了
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    // c==null表示没有加载，如果有父类的加载器则让父类加载器加载
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        //如果父类的加载器为空 则说明递归到bootStrapClassloader了
                        //bootStrapClassloader比较特殊无法通过get获取
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {}
                if (c == null) {
                    //如果bootstrapClassLoader 仍然没有加载过，则递归回来，尝试自己去加载class
                    long t1 = System.nanoTime();
                    c = findClass(name);
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

原文参考地址： www.jianshu.com/p/1e4011617…

双亲委派机制

当某个类加载器需要加载某个 .class 文件时，它首先把这个任务委托给它的上级类加载器，递归这个操作，如果上级的类加载器没有加载，自己才会去加载这个类。

作用：

  1. 防止重复加载同一个 .class，通过委托去上面问一问，加载过了，就不用再加载一遍。保证数据安全
  2. 保证核心 .class 不能被篡改。通过委托方式，不会去篡改核心 .class，即使篡改也不会去加载，即使加载也不会是同一个 .class 对象了。不同的加载器加载同一个 .class 也不是同一个 Class 对象。这样就保证了 Class 的执行安全。

APP -- EXC -- BOOT（最终执行）

在项目中创建一个 java.lang 的包，包里面创建一个 String 类，这个类在被调用就相当于与 java 自带的 String 类在相同的路径下。

package java.lang;
​
public class String {
​
    public String toString() {
        return "Hello";
    }
​
    public static void main(String[] args) {
        String s = new String();
        s.toString();
    }
​
}
​
// 执行结果会报错
错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
   public static void main(String[] args)
否则 JavaFX 应用程序类必须扩展javafx.application.Application
       
1. 类加载器收到类加载的请求
2. 将这个请求向上委托给父类加载器去完成，一直向上委托，直到启动类加载器
3. 启动类加载器检查是否能够加载当前这个类，能加载就结束，使用当前的加载器，否则，抛出异常，通知子加载器进行加载
4. 重复步骤 3

4. 沙箱安全机制

Java 安全模型的核心就是 Java 沙箱（sandbox），什么是沙箱？沙箱是一个限制程序运行的环境。沙箱机制就是将 Java 代码限定在虚拟机（JVM） 特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的 Java 程序运行都可以指定沙箱，可以定制安全策略。

在 Java 中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的 Java 实现中，安全依赖于沙箱（Sandbox）机制。下图是 JDK1.0 的安全模型

但是如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。因此在后续的 Java1.1 版本中，针对安全机制做了改进，增加了安全策略，允许用户指定代码对本地资源的访问权限。下图 JDK1.1 安全模型

在 Java1.2 版本中，再次改进了安全机制，增加了 代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。下图是 JDK1.2 安全模型

f

当前最新的安全机制实现，则引入了域（Domain）的概念，虚拟机会把所有代码加载到不同的系统域和应用域，系统域部分专门负责关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域（Protected Domain），对应不一样的权限（Permission）。存在不同域中的类文件就具有了当前域的全部权限，下图是 jdk1.6 最新的安全模型

组成沙箱的基本组件：

  • 字节码校验器（bytecode verifier）：确保 Java 类文件遵循 Java 语言规范，这样可以帮助Java 程序实现内存保护，但并不是所有的类文件都会经过字节码校验，比如核心类

  • 类加载器（Class Loader）：启动类加载器在3 个方面对 Java 沙箱器作用

    • 它防止恶意代码去干涉善意的代码；双亲委派机制
    • 它守护了被信任的类库边界；
    • 它将代码归入保护域，确定了代码可以进行那些操作。

    虚拟机为不同的类加载器载入类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由 Java 虚拟机为每一个类加载器维护的，它们互相之间甚至不可见。

类加载器采用的机制是双亲委派模式

  1. 从最内层 JVM 自带类加载器开始加载，外层恶意同名类得不到加载从而无法使用；

  2. 由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

    存取控制器（access controller）：存取控制器可以控制核心 API 对操作系统的存取权限，而这个控制的策略设定，可以由用户指定。

    安全管理器（security manager）：是核心 API 和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高

    安全软件包（security package）：java.security 下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括：

    • 安全提供者
    • 信息摘要
    • 数字签名
    • 加密
    • 鉴别

5. Native

public class Demo {
​
    public static void main(String[] args) {
​
        new Thread(()  -> {
        // 进入 start() 方法可以看到调用了下面那个 start0() 本地方法
        }, "my thread name").start();
​
    }
    // 带有 native 关键字的，说明 java 的作用范围达不到了，回去调用底层 C 语言的操作
    // 会进入本地方法栈
    // 调用本地方法接口 JNI
    // JNI 作用：扩展 java 使用，融合不同的编程语言为 Java 所用，最初为了融合 C 、C++，
        // Java 诞生的时候 C、C++ 比较流行，想要立足，必须要调用 C 、C++ 的程序
    // 它在内存区域中专门开辟了一块标记区域：Native Method Stack，用来登录 native 方法
    // 在最终执行的时候，加载本地方法库中的方法通过 JNI
    // Java 程序驱动打印机、管系统、企业级应用中使用较少。
    private native void start0();
}

  • Native Method Stack、

    它的具体做法是 Native Method Stack 中登记 native 方法，在（Execution Engine）执行引擎执行的时候加载 Native Libraies（本地库）。

  • PC 寄存器

    空间占用很小，可以忽略不记

    程序计数器：Program Counter Register

    每个线程都有一个程序计数器，是线程私有的，就是一个指针，指向方法区中的方法字节码（用来存储指向一条指令的地址，也指向将要执行的指令代码），在执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不计。

  • 方法区

    Method Area 方法区

    方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码在此定义，简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间。

    静态变量（static）、常量（final）、类信息（Class 模板）（构造方法、接口定义）、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关。

6. 栈

栈就是一种数据结构；先进后出，后进先出。

栈内存，主管程序的运行，生命周期和线程同步；线程结束，栈内存也就释放了，对于栈来说是不存在垃圾回收机制的，一旦线程结束，栈就结束了。

栈包含：8大基本类型 + 对象的引用 + 实例的方法

栈运行原理：每执行一个方法就会产生一个栈帧，栈帧压入栈中

程序正在执行的方法，一定是在栈顶的

7. 三种JVM

  • Sun 公司 : Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
  • BEA 公司 : Oracle JRockit （原来的 Bea JRockit）电脑软件，系列产品是一个全面的Java运行时解决方案组合。
  • IBM : J9VM

8. 堆 Heap

一个 JVM 只有一个 堆 内存，堆内存的大小是可以调节的。

类加载器读取了类文件后，一般会把类、方法、常量等放到堆中，保存我们所有引用类型的真实对象。

堆内存中分为三个区域：

  • 新生区（伊甸园区）
  • 养老区
  • 永久区

假如 new 了一个 Student 对象，第一次 GC 回收的时候没有被回收就进入幸存0区，幸存0区满了之后进入幸存1区

也就是一个对象经历了多次的 GC 之后还能存留下来的就会进入幸存区

GC 垃圾回收主要是在 伊甸园区和养老区，假设内存满了就会报错：OOM，堆内存不够：Java.lang.OutOfMemoryError: Java heap space

JDK8 以后，永久存储区改名：元空间

8.1 新生区养老区

  • 类：诞生和成长的地方，还有可能死亡（被GC 回收）的地方；
  • 伊甸园区：所有的对象都是在 伊甸园区new 出来的，假设 伊甸园区只能存储 10 个对象，如果存满10就会触发一次轻 GC，两种情况：1. 有的对象可能还存在引用，那么它的活下来了，进入幸存者区 2. 有的清掉之后就没有了；
  • 幸存者区（0区、1区）：如果伊甸园区一直向幸存者区存储，导致伊甸园和幸存者区都满存了，就会触发一次重 GC ，中 GC 会对伊甸园和幸存者区都进行一次清理，这次清理活下来的就进入养老区。如果新生区和养老区都满存了，就会 OOM，JVM 崩掉了

99% 的对象都是临时对象，活不到养老区的。

8.2 永久区

这个区域是常驻内存的，用来存放 JDK 自身携带的 Class 对象，Interface 元数据，存储的是 Java 运行时的一些环境或者类信息，这个区域不存在垃圾回收，关闭虚拟机的时候就会释放这个区域的内存。

一个启动类，加载了大量的第三方 jar 包，tomcat 部署了太多的应用，大量动态生成的反射类，不断地被加载，直到内存满，就会出现 OOM；

  • jdk 1.6 之前：永久代，常量池是在方法区中
  • jdk 1.7：永久代，但是慢慢退化了，区永久代，常量池在堆中。
  • jdk 1.8 之后：无永久代，常量池在元空间

元空间：逻辑上存在，物理上不存在

// 默认情况下：分配的总内存是电脑内存的 1/4，而初始化的内存的 1/64
public static void main(String[] args) {
    // 返回虚拟机试图使用的最大内存
    long l = Runtime.getRuntime().maxMemory();
    System.out.println("最大内存：" + l + " ;  " + (l / 1024 / 1024) + "MB");// 字节
    // 返回 jvm 的总内存
    long l1 = Runtime.getRuntime().totalMemory();
    System.out.println("总内存：" + l1 + " ;  " + (l1 / 1024 / 1024) + "MB");
}
// 结果
最大内存：3791650816 ;  3616MB
总内存：257425408 ;  245MB

设置 VM options 参数：-Xms1024m -Xmx1024m -XX:+PrintGCDetails

得到下面的结果，计算 305664K（伊甸园区） + 699392K（养老区） == 1005056 ，除以 1024 等于 981.5 == 总内存；

而这里只是相加了 伊甸园区 和 养老区 两个区域就等于总内存了，所以证明 元空间理论上存在，物理上不存在

如果碰到 OOM ，证明堆空间满了

  1. 尝试扩大堆内存，运行看结果，如果修改了在有错误可能是代码的问题

    设置 -Xms 和 -Xmx 参数

  2. 如果还错，分析内存看一下那个地方出现了问题

设置 -Xms 8m -Xmx8m，这个 8m 是非常小的了，所以运行肯定会报 OOM 错误

//-Xms8m -Xmx8m -XX:+PrintGCDetails
​
public static void main(String[] args) {
    String str = "hello";
    while (true) {
        str += str + new Random(888888).nextInt();
    }
}
​
/* 结果 */
// 轻 GC
[GC (Allocation Failure) [PSYoungGen: 1536K->504K(2048K)] 1536K->809K(7680K), 0.0014667 secs] [Times: user=0.08 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2021K->504K(2048K)] 2326K->1115K(7680K), 0.0011365 secs] [Times: user=0.05 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1907K->504K(2048K)] 2519K->1771K(7680K), 0.0017996 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1556K->504K(2048K)] 2823K->3075K(7680K), 0.0008657 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2040K->496K(2048K)] 4611K->4107K(7680K), 0.0011879 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
// 重要 GC
[Full GC (Ergonomics) [PSYoungGen: 1549K->0K(2048K)] [ParOldGen: 4635K->2565K(5632K)] 6185K->2565K(7680K), [Metaspace: 3563K->3563K(1056768K)], 0.0052045 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1054K->0K(2048K)] [ParOldGen: 4613K->2053K(5632K)] 5668K->2053K(7680K), [Metaspace: 3563K->3563K(1056768K)], 0.0046838 secs] [Times: user=0.09 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1085K->0K(2048K)] 5186K->4101K(7680K), 0.0003869 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 4101K->4101K(7680K), 0.0002605 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 4101K->3911K(5632K)] 4101K->3911K(7680K), [Metaspace: 3563K->3563K(1056768K)], 0.0077730 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 3911K->3911K(7680K), 0.0003516 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
// 重 GC 也不管用了，因为 新生区 养老区 都满存了，所以异常 OOM
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 3911K->3891K(5632K)] 3911K->3891K(7680K), [Metaspace: 3563K->3563K(1056768K)], 0.0070311 secs] [Times: user=0.08 sys=0.01, real=0.01 secs] 
Heap
 PSYoungGen      total 2048K, used 61K [0x00000000ffd80000, 0x0000000100000000, 0x0000000100000000)  eden space 1536K, 4% used [0x00000000ffd80000,0x00000000ffd8f648,0x00000000fff00000)  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGen       total 5632K, used 3891K [0x00000000ff800000, 0x00000000ffd80000, 0x00000000ffd80000)  object space 5632K, 69% used [0x00000000ff800000,0x00000000ffbccda0,0x00000000ffd80000) Metaspace       used 3595K, capacity 4536K, committed 4864K, reserved 1056768K  class space    used 399K, capacity 428K, committed 512K, reserved 1048576KException in thread "main" java.lang.OutOfMemoryError: Java heap space    at java.util.Arrays.copyOf(Arrays.java:3332)    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)    at java.lang.StringBuilder.append(StringBuilder.java:208)    at com.lss.HeapTest.main(HeapTest.java:15)​Process finished with exit code 1​

8.3 JProfiler

假设在一个项目中突然出现了 OOM 故障排除的时候可以通过：

  • 能够看到第几行出错：内存快照分析工具：MAT（Eclipse）、JProfiler
  • Dubgu，一行行分析代码：如果上线这样分析太麻烦

MAT、JProfiler 作用：

  • 分析 Dump 内存文件，快速定位内存泄漏
  • 获取堆中的数据
  • 获得大的对象
  1. 在 Idea 中安装插件

  1. 官网下载一个客户端工具

    官网地址：www.ej-technologies.com/products/jp…

测试，下载 Dump 文件

// 这种一直循环，一直创建实例，一定会出现 OOM 异常的
public class HeapTest {
    byte[] array = new byte[1 * 1024 * 1024]; // 1m
    public static void main(String[] args) {
​
        ArrayList<HeapTest> list = new ArrayList<>();
        int count = 0;
​
        try {
            while (true) {
                list.add(new HeapTest());
                count = count + 1;
            }
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}
​
// 设置 VM.options : -Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
// -Xms：设置初始化内存分配大小，默认 内存 1/64
// -Xmx：设置最大分配内存，默认 1/4 
// -XX:+PrintGCDetails  打印GC垃圾回收信息
// -XX:+HeapDumpOnOutOfMemoryError  OOM Dump
/* 输出 */
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid18056.hprof ... // 找到这个文件，在项目的根目录
Heap dump file created [8179122 bytes in 0.020 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at com.lss.HeapTest.<init>(HeapTest.java:7)
    at com.lss.HeapTest.main(HeapTest.java:15)

双击这个文件打开，进入 Jprofiler 分析工具

这里明显可以看到对象的大小占 87%

9. GC 垃圾回收机制

不能手动回收

GC 的作用区在 堆（堆中包括方法区）

JVM 在进行 GC 的时候，会有三个区域：新生代、幸存区（from、to）、老年区；GC 清理的时候不是对这三个区域统一回收，大部分的时候，回收都是在新生代。

GC 两种类型：

  • 轻 GC（普通的 GC），只是针对新生代、偶尔关注一下幸存区
  • 重 GC（全局 GC），全局

GC 算法包括：标记清除法、标记压缩、复制算法、引用计数法

9.1 引用计数法

这种情况下，每创建一个对象就会被分配一个计数器，没使用一次这个对象计数器就会 +1，引用计数法就是根据这些使用的次数，假设有下面 4 个对象，对象C 的使用次数为 0 ，所以在进行 GC 回收的时候就会把 对象C 回收清除掉。

缺点：计数器本身也会有消耗，这种方式几乎不再使用，不够高效

9.2 复制算法

新生代主要用的是 复制算法

幸存区：from ，to 是会相互交换的

这里需要区别交换之后的 from、to：交换的时候谁空谁是 to

  1. 每次 GC 都会将 Eden 活的对象移到幸存区中，一旦 Eden 区被 GC 之后，就是空的
  2. 假设一个对象经过 Eden GC 之后活下来了，然后会选择移到幸存区中，从 from 和 to 中选择一个足够存活的区域
  3. 假设 from 、 to 都是空的，选择移到一个空的幸存区，变成 幸存区 from，另一个空的区域就是 幸存区 to
  4. 如果从 Eden 区到幸存区的时候，from 和 to 都有数据，还需要留出一个 to ，保证是空的。将一个区的东西复制到另一个区，这样能保证一个区域是空的，就是 to

当一个对象经历了 15（默认）次 GC ，还没有死掉就会进入 养老区；可以通过参数：-XX:MaxTenuringThreshold=xx 来设定老年代的时间。

  • 好处：没有内存的碎片
  • 坏处：浪费了内存空间（幸存区）：多了一半空间永远是空 to。假设一个对象 100% 存活（极端情况），那么就会把所有的对象都拷贝到幸存区中，就会出现问题

复制算法最佳使用场景：对象存活度较低的时候：新生区

9.3 标记清除算法

  • 优点：不需要额外的空间
  • 缺点：两次扫描严重浪费时间；会产生内存碎片；

标记压缩算法

再次扫描，向一端移动存活的对象，防止内存碎片产生

标记清除压缩算法

先标记清除几次，然后到一定的次数再进行压缩

9.4 GC 算法总结

内存效率：复制算法 > 标记清除算法 > 标记压缩算法

内存整齐度：复制算法 == 标记压缩算法 > 标记清除算法

内存利用率：标记压缩算法 == 标记清除算法 > 复制算法

没有最好的算法，只有最合适的算法。GC ：分代收集算法

年轻代：

  • 存活率低
  • 复制算法

老年代：

  • 区域法，存活率高
  • 标记清除（内存不是太多） + 标记压缩混合实现

10. JMM

  1. 什么是 JMM

    Java平台自动集成了线程以及多处理器技术，这种集成程度比Java以前诞生的计算机语言要厉害很多，该语言针对多种异构平台的平台独立性而使用的多线程技术支持也是具有开拓性的一面，有时候在开发Java同步和线程安全要求很严格的程序时，往往容易混淆的一个概念就是内存模型。究竟什么是内存模型？内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节，对象最终是存储在内存里面的，这点没有错，但是编译器、运行库、处理器或者系统缓存可以有特权在变量指定内存位置存储或者取出变量的值。【JMM】（Java Memory Model的缩写）允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存之间移动的次序拥有重要的特权，除非程序员使用了volatile或synchronized明确请求了某些可见性的保证。

  2. 干什么？

    作用：缓存一致性协议，用于定义数据读写的规则

    JMM 定义了线程工作内存和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory）

    解决共享对象可见性这个问题：volilate

JMM 对八种指令的使用，指定了以下的规则：

  • 不允许 read 和 load 、store 和 write 操作之一单独出现。即使用了 read 必须 load，使用了 store 必须 write
  • 不允许线程丢弃他最近的 assign 操作，即工作变量的数据改变了之后，必须告知主存
  • 不允许一个线程将没有 assign 的数据从工作内存同步回主内存
  • 一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未初始化的变量。就是对变量实施 use、store 操作之前，必须经过 assign 和 load 操作
  • 一个变量同一时间只有一个线程能对其进行 lock。多次 lock 后，必须执行相同次数的 unlock 才能解锁
  • 如果对一个变量进行 lock 操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新 load 或 assign 操作初始化变量的值
  • 如果一个变量没有被 lock，就不能对其进行 unlock 操作。也不能 unlock 一个被其他线程锁住的变量
  • 对一个变量进行 unlock 操作之前，必须把此变量同步回主内存。

JMM 对这八种操作规则和对 volatile 的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则非常的复杂，很难在实践中直接分析。

学习参考视频地址： www.bilibili.com/video/BV1iJ…

avatar
文章
阅读
粉丝