面试常见：

1. 请你谈谈你对JVM的理解?
2. java8虚拟机和之前的变化更新?
3. 什么是OOM，什么是栈溢出StackOverFlowError? 怎么分析?
4. JVM的常用调优参数有哪些?
5. 内存快照如何抓取？怎么分析Dump文件？
6. 谈谈JVM中，类加载器你的认识？

1. 请你谈谈你对JVM的理解? JVM（Java虚拟机）是Java程序的运行环境，它允许Java程序在不同的平台上运行。JVM负责将Java源代码编译成字节码，并在运行时解释或编译执行这些字节码。JVM还负责内存管理、垃圾回收、安全性等任务。它的主要优点是跨平台性和自动内存管理。

2. java8虚拟机和之前的变化更新? Java 8的虚拟机相比之前的版本有一些变化和更新，其中包括：

• Lambda表达式和函数式接口的支持，使得在JVM中能更方便地使用函数式编程风格。
• 元空间（Metaspace）的引入，取代了永久代（Permanent Generation），用于存储类的元数据信息。
• 默认方法（Default Methods）的支持，允许接口中有具体的方法实现。
• 增强的垃圾回收器性能和功能。
• 新的时间和日期API（java.time包）的引入。

3. 什么是OOM，什么是栈溢出StackOverFlowError? 怎么分析?

• OOM（Out of Memory）是指JVM内存不足，无法分配更多的内存给应用程序使用，导致应用程序无法继续执行的情况。这可能是由于堆内存溢出、方法区（元空间）溢出或者线程栈空间不足等原因引起的。
• 栈溢出（StackOverflowError）是指线程调用栈的深度超过了JVM所允许的最大深度，导致栈空间耗尽而抛出的错误。通常是由于递归调用或者方法调用层级过深引起的。
• 要分析这些问题，可以通过查看JVM的日志、堆栈跟踪信息以及内存使用情况来确定问题的根源，并可能通过调整JVM参数或者修改代码来解决问题。

4. JVM的常用调优参数有哪些? 常用的JVM调优参数包括：

• -Xms：设置初始堆大小
• -Xmx：设置最大堆大小
• -Xss：设置线程栈大小
• -XX:PermSize和-XX:MaxPermSize：设置永久代（Java 8之前）或元空间（Java 8及之后）大小
• -XX:+UseG1GC：启用G1垃圾回收器
• -XX:+UseConcMarkSweepGC：启用CMS垃圾回收器
• -XX:MaxGCPauseMillis：设置最大垃圾回收停顿时间
• -XX:NewRatio：设置新生代与老年代的大小比例

5. 内存快照如何抓取？怎么分析Dump文件？ 内存快照可以通过JVM工具（如jmap、jcmd）或者第三方工具（如VisualVM、MAT）来抓取。分析Dump文件通常可以使用MAT（Memory Analyzer Tool）等工具，这些工具能够解析Dump文件并生成分析报告，帮助定位内存泄漏、对象占用过多内存等问题。

6. 谈谈JVM中，类加载器你的认识？ 类加载器负责将类文件加载到JVM中，并生成对应的Class对象。JVM中的类加载器主要分为三种：启动类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）和应用程序类加载器（Application ClassLoader）。类加载器采用双亲委派模型，即当一个类加载器收到加载类的请求时，它会先将请求委派给父类加载器处理，只有在父类加载器无法完成加载时，才会自己尝试加载。这种机制保证了类的唯一性和安全性。自定义类加载器可以实现一些特殊的类加载行为，例如从网络或者其他非标准的地方加载类。

1.JVM的位置

• JVM（Java虚拟机, Java Virtual Machine）是Java程序的运行环境，它负责解释Java字节码并将其转换为机器码以在特定平台上执行。JVM通常安装在操作系统之上，并提供了一个虚拟的运行时环境来执行Java应用程序。

• JVM的位置通常取决于安装的Java开发工具包（JDK）。在安装了JDK的系统中，JVM的二进制文件通常存储在JDK安装目录的子目录中，例如在Windows系统中，它可能位于C:\Program Files\Java\jdk<version>\bin目录下。

三种JVM:

• Sun公司：HotSpot 用的最多
• BEA：JRockit
• IBM：J9VM

我们学习都是：HotSpot

2.JVM的体系结构

• 红色的为多个线程共享,灰色的为单个线程私有的

• 线程间共享:堆,方法区.

• 线程私有:程序计数器,栈,本地方法栈.

程序在执行之前先要把 java 代码转换成字节码（class 文件），jvm 首先需要把字节码通过一定的方式 类加载器（ClassLoader） 把文件加载到内存中的运行时数据区（Runtime Data Area）的方法区（Method Area） ，而字节码文件是 jvm 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器 执行引擎（Execution Engine） 将字节码翻译成底层系统指令再交由CPU 去执行，而这个过程中需要调用其他语言的接口 本地库接口（Native Interface） 来实现整个程序的功能，这就是这 4 个主要组成部分的职责与功能。
而我们通常所说的 JVM 组成指的是 运行时数据区（Runtime Data Area） ，因为通常需要程序员调试分析的区域就是“运行时数据区”，或者更具体的来说就是“运行时数据区”里面的 Heap（堆）模块。

• jvm调优：99%都是在方法区和堆，大部分时间调堆。 JNI（java native interface）本地方法接口。

• $为什么栈和PC没有垃圾回收？$

  栈（Stack）和 PC（Program Counter，程序计数器）通常不需要进行垃圾回收，因为它们所占用的内存空间具有确定的生命周期，并且由编译器或虚拟机进行管理。

  1. 栈： 栈是一种数据结构，用于存储函数调用时的局部变量、函数参数、返回地址等数据。栈上的数据存储遵循后进先出（LIFO）的原则，每当函数调用时，都会为该函数分配一块栈帧（Stack Frame）用于存储相关数据。当函数执行完毕时，其对应的栈帧会被弹出，从而释放其占用的内存空间。这种自动的分配和释放机制使得栈上的内存管理成本较低，并且不需要进行垃圾回收。

  2. 程序计数器： 程序计数器是一种特殊的寄存器，用于存储当前线程正在执行的指令地址。在程序执行过程中，程序计数器会随着指令的执行而不断更新，指向下一条将要执行的指令。程序计数器的生命周期与线程的生命周期密切相关，当线程结束时，程序计数器的内容也会被销毁。由于程序计数器的内容是由硬件直接管理的，因此不需要进行垃圾回收。

3.类加载器

• 作用：加载Class文件——如果new Student();（具体实例在堆里，引用变量名放栈里） 。
• 先来看看一个类加载到 JVM 的一个基本结构：

• 类是模板，对象是具体的，通过new来实例化对象。car1，car2，car3，名字在栈里面，真正的实例，具体的数据在堆里面，栈只是引用地址。

类加载器分类：

• JVM角度

  • 引导类加载器(启动类加载器 Bootstrap ClassLoader).

  • 其他所有类加载器,这些类加载器由 java 语言实现,独立存在于虚拟机外部,并 且全部继承自抽象类 java.lang.ClassLoader.

• 开发人员角度

  • 启动类加载器/根加载器/启动类加载器 Bootstrap ClassLoader

    • 加载 JAVA_HOME\jre\lib\rt.jar 中的类(runtime, Java 运行环境的核心库目录)

    • 启动类加载器通常只加载指定的核心类库rt.jar，并不会加载 lib 目录下的其他 JAR 文件。

    • 这个类加载器使用 C/C++语言实现,嵌套在 JVM 内部.它用来加载 java 核心类库.并不继承于 java.lang.ClassLoader 没有父加载器，java 程序获取不到

    • 负责加载扩展类加载器和应用类加载器,并为他们指定父类加载器.

    • 出于安全考虑,引用类加载器只加载存放在JAVA_HOME\jre\lib\rt.jar 目录,或者被-Xbootclasspath 参数锁指定的路径中存储放的类

  • 扩展类加载器 Extension ClassLoader

    • Java 语言编写的,由 sun.misc.Launcher$ExtClassLoader 实现.

    • 派生于 ClassLoader 类.

  • 系统类加载器/应用程序类加载器 System/App ClassLoader

    • 从 java.ext.dirs 系统属性所指定的目录中加载类库,或从 JDK 系统安装目录的JAVA_HOME\jre\lib\ext 子目录(扩展目录)下加载类库.如果用户创建的 jar 放在此目录下,也会自动由扩展类加载器加载

    • Java 语言编写的,由 sun.misc.Launcher$AppClassLoader 实现.

    • 派生于 ClassLoader 类.

    • 加载我们自己定义的类,用于加载用户类路径(classpath)上所有的类.

    • 该类加载器是程序中默认的类加载器.

    • ClassLoader 类 ， 它 是 一 个 抽 象 类 ， 其 后 所 有 的 类 加 载 器 都 继 承 自 ClassLoader（不包括启动类加载器）

package github.JVM.Demo01;

/** * @author subeiLY * @create 2021-06-08 07:42 */
public class Test01 {
    public static void main(String[] args) {
        Test01 test01 = new Test01();
        Test01 test02 = new Test01();
        Test01 test03 = new Test01();

        System.out.println(test01.hashCode());
        System.out.println(test02.hashCode());
        System.out.println(test03.hashCode());
/*18360192403250408041173230247 */

        Class<? extends Test01> aClass1 = test01.getClass();

        ClassLoader classLoader = aClass1.getClassLoader();
        System.out.println(classLoader);
        System.out.println(classLoader.getParent());
        System.out.println(classLoader.getParent().getParent());
/*sun.misc.Launcher$AppClassLoader@18b4aac2sun.misc.Launcher$ExtClassLoader@330bedb4null */

        Class<? extends Test01> aClass2 = test02.getClass();
        Class<? extends Test01> aClass3 = test03.getClass();

        System.out.println(aClass1.hashCode());
        System.out.println(aClass2.hashCode());
        System.out.println(aClass3.hashCode());
        /*        2133927002        2133927002        2133927002         */
    }
}

类加载器的分类

• Bootstrap ClassLoader 启动类加载器
• Extention ClassLoader 标准扩展类加载器
• Application ClassLoader 应用类加载器
• User ClassLoader 用户自定义类加载器

类加载过程：

2、2、1 加载：

1. 通过类名（地址）获取此类的二进制字节流。
2. 将这个字节流所代表的静态存储结构转换为方法区（元空间）的运行时结构。
3. 在内存中生成一个代表这个类的 java.lang.Class 对象，作为这个类的各种数据的访问入口。

2、2、2 链接：

1. 验证：

• 文件格式验证：检查 class 文件是否以 CA FE BA BE 开头。
• 主、次版本号验证：确认版本号在当前 Java 虚拟机接收范围内。对于 Java 17.0.1，其主版本号是 17，次版本号是 0, 1 表示补丁或更新版本。
• 元数据验证：对字节码描述的信息进行语义分析，确保符合 Java 语言规范的要求。

2. 准备：

• 为类的静态属性分配内存，并设置默认初始值。
• 不包含用 final 修饰的 static 常量，在编译时进行初始化。

3. 解析：

• 将类的二进制数据中的符号引用替换成直接引用。(符号引用是 Class 文件的逻辑符号，直接引用指向的方法区中某一个地址)

2、2、3 初始化：

• 为类的静态变量赋予正确的初始值，执行类构造器方法 <clinit>() 的过程。该方法是编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并而来的。

实例化过程：

类加载完成 + 以下过程

1. 创建对象：一旦类加载和初始化完成，就可以创建该类的对象实例了。对象实例化的过程包括：

• 分配内存空间：在堆内存中为对象分配内存空间，内存大小取决于对象的大小和结构。

• 初始化对象：将对象的实例变量（即非静态变量）设置为默认值，如果有显式的初始化操作，则会执行对应的初始化代码。

• 调用构造方法：在内存中分配了足够的空间后，会调用对象的构造方法进行初始化。构造方法负责对对象进行初始化操作，可以设置对象的初始状态和执行其他必要的操作。

2. 返回引用：对象实例化完成后，会返回对象的引用，以便能够在程序中使用该对象。

类什么时候初始化：

1. 每个类或接口被首次主动使用时才对其进行初始化，主动使用包括：

• 通过 new 关键字创建对象。
• 访问类的静态变量，包括读取和更新。
• 访问类的静态方法。
• 对某个类进行反射操作。
• 初始化子类会导致父类的初始化。
• 执行该类的 main 函数。

2. 除了以上几种主动使用，以下情况被动使用，不会加载类：

• 引用该类的静态常量，但注意只有已经指定字面量的常量不会导致初始化，对于需要计算才能得出结果的常量会导致类加载。

  //不会导致类初始化,被动使用
  public final static int NUMBER = 5 ; 
   //会导致类加载
  public final static int RANDOM = new Random().nextInt() ;
  

• 构造某个类的数组时不会导致该类的初始化。

  Student[] students = new Student[10] ;
  

4.双亲委派机制

package java.lang;

/** * @author subeiLY * @create 2021-06-08 08:06 */
public class String {
    /*    双亲委派机制:安全    
1.APP-->EXC-->BOOT(最终执行)    BOOT    EXC    APP     */
    public String toString() {
        return "Hello";
    }

    public static void main(String[] args) {
        String s = new String();
        System.out.println(s.getClass());
        s.toString();
    }
    /*    
1.类加载器收到类加载的请求    
2.将这个请求向上委托给父类加载器去完成，一直向上委托，知道启动类加载    
3.启动加载器检查是否能够加载当前这个类，能加载就结束，使用当前的加载器，
    否则，抛出异常，适知子加载器进行加载    
4.重复步骤3     */
}

• idea报了一个错误：

双亲委派机制

1. 如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请 求委托给父类的加载器去执行.

2. 如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终 将到达顶层的启动类加载器.

3. 如果父类加载器可以完成类的加载任务,就成功返回,倘若父类加载器无法完 成加载任务,子加载器才会尝试自己去加载,这就是双亲委派机制.

4. 如果均加载失败，就会抛出 ClassNotFoundException 异常。

优点：

1. 安全：可避免用户自己编写的类替换 Java 的核心类，如 java.lang.String.

2. 避免类重复加载：当父亲已经加载了该类时，就没有必要子 ClassLoader 再加载一次

如何打破双亲委派机制

• Java 虚拟机的类加载器本身可以满足加载的要求，但是也允许开发者自定义类加载器。

• 在 ClassLoader 类中涉及类加载的方法有两个,loadClass(String name), findClass(String name),这两个方法并没有被 final 修饰,也就表示其他子类可以重写.

• 重写 loadClass 方法(是实现双亲委派逻辑的地方,修改他会破坏双亲委派机制, 不推荐)

• 重写 findClass 方法 (推荐)

• 我们可以通过自定义类加载重写方法打破双亲委派机制, 再例如 tomcat 等都有自己定义的类加载器.

• 关于双亲委派机制的博客：

  你确定你真的理解“双亲委派“了吗？！

• 双亲委派模型中，类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码的。

• 实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中, 主要就是以下几个步骤：

  • 1、先检查类是否已经被加载过

  • 2、若没有加载则调用父加载器的loadClass()方法进行加载

  • 3、若父加载器为空则默认使用启动类加载器作为父加载器。

  • 4、如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

• 如何主动破坏双亲委派机制？

  知道了双亲委派模型的实现，那么想要破坏双亲委派机制就很简单了。

  因为他的双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。

• 双亲委派被破坏的例子
  双亲委派机制的破坏不是什么稀奇的事情，很多框架、容器等都会破坏这种机制来实现某些功能。

  • 第一种被破坏的情况是在双亲委派出现之前。

  由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。

  • 第二种，是JNDI、JDBC等需要加载SPI接口实现类的情况。

    DriverManager是被根加载器加载的，那么在加载时遇到以上代码，会尝试加载所有Driver的实现类，但是这些实现类基本都是第三方提供的，根据双亲委派原则，第三方的类不能被根加载器加载。

    于是，就在JDBC中通过引入ThreadContextClassLoader（线程上下文加载器，默认情况下是AppClassLoader）的方式破坏了双亲委派原则。

  • 第三种是为了实现热插拔热部署工具。为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。

  • 第四种时tomcat等web容器的出现。

    Tomcat是web容器，那么一个web容器可能需要部署多个应用程序。

    不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。

    如多个应用都要依赖hollis.jar，但是A应用需要依赖1.0.0版本，但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.hollis.Test.class。

    如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。

    所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web容器单独提供一个WebAppClassLoader加载器。

  • 第五种时OSGI、Jigsaw等模块化技术的应用。

---

面试官：java双亲委派机制及作用

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

• 例子：当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

从上到下第一个ExtClassLoader 改为 BootstrapClassLoader

作用：

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

比如：如果有人想替换系统级别的类：String.java。篡改它的实现，在这种机制下这些系统的类已经被Bootstrap classLoader加载过了（为什么？因为当一个类需要加载的时候，最先去尝试加载的就是BootstrapClassLoader），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。

5.沙箱安全机制

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

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

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

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

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

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

组成沙箱的基本组件:

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

• 类装载器(class loader) :其中类装载器在3个方面对Java沙箱起作用：

  。它防止恶意代码去干涉善意的代码;
  。它守护了被信任的类库边界;
  。它将代码归入保护域，确定了代码可以进行哪些操作。

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

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

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

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

• 存取控制器(access controller)︰存取控制器可以控制核心API对操作系统的存取权限，而这个控制的策略设定，可以由用户指定。
• 安全管理器(security manager)︰是核心API和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高。
• 安全软件包(security package) : java.security下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括:
  • 安全提供者
  • 消息摘要
  • 数字签名
  • 加密
  • 鉴别

6. 本地方法（Native Method）

6.1 本地方法栈（Native Method Stack）

6.2 本地方法接口（Native Method Interface）

6.3 本地方法库（Native Method Libraries）

Java 本地方法（Native Methods）是一种允许 Java 程序调用本地（即非 Java）代码的机制。本地方法是使用特殊关键字 native 声明的 Java 方法，其实现由非 Java 语言编写，通常是由 C 或 C++ 编写的。

Java 本地方法通常用于以下几种情况：

1. 访问系统资源：通过本地方法，Java 程序可以直接调用操作系统提供的底层功能和系统库，例如文件操作、网络通信等。
2. 性能优化：某些任务在 Java 中可能会受到性能限制，通过本地方法可以使用底层语言编写高效的代码，提高程序性能。
3. 与底层硬件交互：本地方法可用于与底层硬件设备进行交互，例如传感器、外设等。
4. 调用其他语言编写的库：Java 本地方法允许 Java 应用程序调用其他语言编写的库，例如 C 或 C++ 编写的动态链接库（DLL）或共享库（SO）。

使用本地方法时，需要在 Java 中声明本地方法，并在本地方法库中提供相应的实现。Java 虚拟机在执行本地方法时会调用本地方法库中对应的函数。

跨平台兼容性、安全性问题以及调试困难等。因此，应该谨慎使用本地方法，并优先考虑在纯 Java 环境中实现功能。

• 编写一个多线程类启动。

 public static void main(String[] args) { 
            new Thread(()->{ },"your thread name").start(); 
 }

• 点进去看start方法的源码：

public synchronized void start() {

        if (threadStatus != 0)
            throw new IllegalThreadStateException();

        group.add(this);

        boolean started = false;
        try {
            start0();    // 调用了一个start0方法
            started = true;
        } finally {
            try {
                if (!started) {
                    group.threadStartFailed(this);
                }
            } catch (Throwable ignore) {

            }
        }
    }
    // 这个Thread是一个类，这个方法定义在这里是不是很诡异！看这个关键字native；
    private native void start0();

• 凡是带了native关键字的，说明 java的作用范围达不到，去调用底层C语言的库！

• JNI：Java Native Interface（Java本地方法接口）

• 凡是带了native关键字的方法就会进入本地方法栈；

• Native Method Stack 本地方法栈

• 本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序，Java在诞生的时候是C/C++横行的时候，想要立足，必须有调用C、C++的程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是 在 Native Method Stack 中登记native方法，在 执行引擎( ExecutionEngine )执行的时候加载Native Libraies。

• 目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间通信很发达，比如可以使用Socket通信，也可以使用Web Service等等，不多做介绍！

7.程序计数器（PC, Program Counter Register）

程序计数器：Program Counter Register

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

PC寄存器（Program Counter Register）是计算机体系结构中的一个重要概念，特别是在处理器的执行过程中。它通常用于指示处理器当前正在执行的指令的位置或下一条要执行的指令的位置。

• 它是一块很小的内存空间,几乎可以忽略不计,也是运行速度最快的存储区域.

• 在 JVM 规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程生命周期保持一致.

• 程序计数器会存储当前线程正在执行的 Java 方法的 JVM 指令地址.

• 它是程序控制流的指示器,分支,循环,跳转,异常处理,线程恢复等基础功能都需要依赖这个计数器来完成.

• 它是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

8.栈

8.1 Java 虚拟机栈（Java Virtual Machine Stacks）

早期也叫 Java 栈，描述的是 Java 方法执行的内存模型，每个方法在执行的同时都会创建一个线帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每个方法从调用直至执行完成的过程，都对应着一个线帧在虚拟机栈中入栈到出栈的过程。

栈的特点

栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器.

JVM 直接对 java 栈的操作只有两个:调用方法 入栈 .执行结束后 出栈 .

对于栈来说不存在垃圾回收问题.

栈中会出现异常,当线程请求的栈深度大于虚拟机所允许的深度时 , 会出现StackOverflowError.

栈的运行原理

• JVM 对 Java 栈的操作主要是对栈帧的入栈和出栈，遵循先进后出（后进先出）的原则。
• 在一条活动的线程中，只会有一个活动栈，即当前执行的方法的栈帧（栈顶）是有效的，这个栈帧称为当前栈（Current Frame），对应的方法称为当前方法（Current Method），定义该方法的类称为当前类（Current Class）。
• 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
• 如果在方法中调用了其他方法，会创建新的栈帧放在栈的顶端，成为新的当前栈帧。
• 不同线程中的栈帧不允许相互引用，即不可能在一个栈中引用另一个线程的栈帧。
• 当前方法调用其他方法后，在方法返回时，当前栈帧会传回此方法的执行结果给前一个栈帧，然后丢弃当前栈帧，使前一个栈帧重新成为当前栈帧。
• Java 方法有两种返回方式：正常的函数返回使用 return 指令，抛出异常也会导致栈帧被弹出。

栈的内部结构

1. 局部变量表（Local Variables）：

• 用于存储方法参数和方法内部定义的局部变量。
• 对于基本数据类型的变量，直接存储其值；对于引用类型的变量，存储指向对象的引用。

2. 操作数栈（Operand Stack）或表达式栈：

• 用于表达式求值。在方法执行过程中，实际上是不断执行语句并进行计算的过程，这些计算过程都借助于操作数栈来完成。

3. 动态链接（Dynamic Linking）或指向运行时常量池的方法引用：

• 方法执行过程中可能需要使用类中的常量，因此需要一个引用指向运行时常量池。

4. 方法返回地址（Return Address）或方法正常/异常退出的定义：

• 当方法执行完毕时，需要返回到之前调用它的地方，因此在栈帧中保存着方法返回地址。

5. 其他辅助数据

• 如异常处理信息、synchronized块的锁信息等。

8.2 本地方法栈（Native Method Stack）

与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java 方法的，而本地方法栈是为虚拟机调用 Native 方法服务的。

1. Java 虚拟机栈用于管理 Java 方法的调用，而本地方法栈则用于管理本地方法的调用。
2. 本地方法栈也是线程私有的，每个线程都有自己的本地方法栈。
3. 本地方法栈的内存大小可以被实现成固定的或者可动态扩展的，与 Java 虚拟机栈类似。内存溢出的处理方式也相同。
4. 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，会抛出 StackOverflowError。
5. 本地方法是用 C 语言编写的，因此需要一种机制将 Java 虚拟机中的 Java 方法与本地方法库中的本地方法进行连接。
6. 具体的做法是在 Native Method Stack 中登记 native 方法，在 Execution Engine 执行时加载本地方法库，从而实现本地方法的调用。

9.方法区（Method Area）

方法区基本理解

1. 方法区概述：

• 方法区是 Java 虚拟机内存的一部分，它是被所有线程共享的内存区域。
• 方法区主要用于存储加载的类字节码、类的元数据信息（包括 class/method/field 等）、static final 常量、static 变量、即时编译器编译后的代码等数据。
• 方法区还包含一个重要的子区域，即运行时常量池。
• 方法区是很重要的系统资源,是硬盘和 CPU 的中间桥梁,承载着操作系统和应用程序的实时运行

2. 方法区与堆的关系：

• 虽然方法区在逻辑上是堆的一部分，但是在 HotSpot JVM 中，方法区也被称为非堆，目的是为了和堆区分开。
• 在 HotSpot JVM 中，方法区是一块独立于 Java 堆的内存空间。

3. 方法区的作用：

• 存储加载的类信息和元数据，包括类的结构信息、方法、字段等。

• 存储静态变量，如 static 变量。

• 存储常量，包括 static final 常量。

• 存储运行时常量池，即类加载时将字面量和符号引用转换为直接引用的内存区域。

  在类加载过程中，虚拟机会将这些字面量和符号引用在运行时常量池中进行动态转换，即将它们转换为直接引用。这个过程中，如果需要解析符号引用所代表的目标，则会在运行时常量池中进行符号解析，找到对应的目标。这样，运行时常量池最终存储的是符号引用解析后的直接引用，这些直接引用指向了实际的类、字段、方法等目标。

4. 方法区的特点：

• 线程共享：方法区被所有线程共享，因为它存储的是类的元数据信息，而类是被所有线程共享的。
• 非堆内存：虽然在逻辑上是堆的一部分，但是在 HotSpot JVM 中，方法区被认为是非堆内存，与 Java 堆区分开。

5. 当 JVM 启动时，方法区被创建。

6. 它的物理内存空间可以与 Java 堆一样不连续。

7. 方法区的大小可以选择固定或可扩展，与堆空间类似。

8. 方法区的大小决定了系统可以保存多少个类，如果定义了太多类导致方法区溢出，虚拟机会抛出内存溢出错误。

9. 关闭 JVM 将释放方法区的内存。

方法区,栈,堆的交互关系

方法区大小设置

• Java 方法区的大小不是固定的，而是可以根据应用的需要进行动态调整。在 Java 8 及以后的版本中，方法区被替代为元空间（Metaspace），它的大小可以通过参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 来指定，代替了原来的 -XX:PermSize 和 -XX:MaxPermSize 参数。

• 默认情况下，元空间大小依赖于平台。在 Windows 系统下，默认的 -XX:MetaspaceSize 是 21MB，而 -XX:MaxMetaspaceSize 的值为 -1，表示没有限制。

• 元空间的初始值（即 -XX:MetaspaceSize）为 21MB，也被称为高水位线。一旦元空间的使用量达到这个值，就会触发 Full GC。为了减少 Full GC 的频率，可以将 -XX:MetaspaceSize 设置为较高的值。

方法区的内部结构

• 方法区存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存以及运行时常量池等。

• 运行时常量池是其中的一部分，是一张表格，虚拟机指令根据其中的内容找到要执行的类名、方法名、参数类型、字面量（常量）等信息。

• 编译期间生成的各种字面量（常量）和符号引用都存放在运行时常量池中。

• 可通过反编译字节码文件查看其中的内容，使用参数 -p 可确保能够查看私有权限类型的字段或方法。

  javap -v -p Hello.class > Hello.txt
  

  // Hello.java
  
  public class Hello {
      public static void main(String[] args) {
          System.out.println("Hello World!");
      }
  }
  

  // Hello.txt
  
  Classfile /D:/Desktop/test/Hello.class
    Last modified 2024-5-26; size 416 bytes
    MD5 checksum e5f397cd2507c3d6e46867c5e9c957c6
    Compiled from "Hello.java"
  public class Hello
    minor version: 0
    major version: 55
    flags: ACC_PUBLIC, ACC_SUPER
  Constant pool:
     #1 = Methodref          #6.#15         // java/lang/Object."<init>":()V
     #2 = Fieldref           #16.#17        // java/lang/System.out:Ljava/io/PrintStream;
     #3 = String             #18            // Hello World!
     #4 = Methodref          #19.#20        // java/io/PrintStream.println:(Ljava/lang/String;)V
     #5 = Class              #21            // Hello
     #6 = Class              #22            // java/lang/Object
     #7 = Utf8               <init>
     #8 = Utf8               ()V
     #9 = Utf8               Code
    #10 = Utf8               LineNumberTable
    #11 = Utf8               main
    #12 = Utf8               ([Ljava/lang/String;)V
    #13 = Utf8               SourceFile
    #14 = Utf8               Hello.java
    #15 = NameAndType        #7:#8          // "<init>":()V
    #16 = Class              #23            // java/lang/System
    #17 = NameAndType        #24:#25        // out:Ljava/io/PrintStream;
    #18 = Utf8               Hello World!
    #19 = Class              #26            // java/io/PrintStream
    #20 = NameAndType        #27:#28        // println:(Ljava/lang/String;)V
    #21 = Utf8               Hello
    #22 = Utf8               java/lang/Object
    #23 = Utf8               java/lang/System
    #24 = Utf8               out
    #25 = Utf8               Ljava/io/PrintStream;
    #26 = Utf8               java/io/PrintStream
    #27 = Utf8               println
    #28 = Utf8               (Ljava/lang/String;)V
  {
    public Hello();
      descriptor: ()V
      flags: ACC_PUBLIC
      Code:
        stack=1, locals=1, args_size=1
           0: aload_0
           1: invokespecial #1                  // Method java/lang/Object."<init>":()V
           4: return
        LineNumberTable:
          line 1: 0
  
    public static void main(java.lang.String[]);
      descriptor: ([Ljava/lang/String;)V
      flags: ACC_PUBLIC, ACC_STATIC
      Code:
        stack=2, locals=1, args_size=1
           0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
           3: ldc           #3                  // String Hello World!
           5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
           8: return
        LineNumberTable:
          line 3: 0
          line 4: 8
  }
  SourceFile: "Hello.java"
  
  

方法区的垃圾回收

方法区（例如 Hotspot 虚拟机中的元空间或者永久代）并非没有垃圾收集行为。尽管《Java 虚拟机规范》对方法区的约束非常宽松，甚至可以不要求虚拟机在方法区中实现垃圾收集，但实际情况并非如此。方法区的垃圾收集虽然难以达到令人满意的效果，特别是在类卸载方面，条件相当苛刻，但有时却是必要的。

方法区的垃圾收集主要涉及两部分内容：清理运行时常量池中废弃的常量和不再使用的类型，也称为类卸载。

判定一个常量是否“废弃”相对较简单，但判定一个类型是否属于“不再被使用的类”则更为苛刻，需要同时满足以下三个条件：

1. 该类所有的实例都已经被回收。即 Java 堆中不存在该类及其任何派生子类的实例。
2. 加载该类的类加载器已经被回收。除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常很难达成这一条件。
3. 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法通过反射访问该类的方法。

• 存储类的结构信息、静态变量、常量、方法字节码等数据

• 方法区主要包含以下内容：

  1. 类信息（Class Information）：方法区存储了加载的类的元数据信息，包括类的名称、父类的名称、类的修饰符、方法和字段的描述符等。这些信息对于JVM在运行时动态加载、链接和执行类非常重要。

  2. 静态变量（Static Variables）：类的静态变量被存储在方法区中。这些变量在类加载时被分配内存，并在整个程序执行期间保持不变。静态变量的生命周期与类的生命周期相同。

  3. 常量池（Constant Pool），JDK7之前：方法区中包含了常量池，用于存储类中的字面常量、符号引用等信息。常量池中的内容包括类和接口的全限定名、字段和方法的名称和描述符、字符串常量等。

  4. 方法字节码（Method Bytecode）, .class文件：类中的方法字节码被存储在方法区中。这些字节码被JVM解释执行或者编译成本地机器代码执行。

  5. 运行时常量池（Runtime Constant Pool）：与常量池对应的是运行时常量池，它是常量池的一部分，用于存储编译时生成的字面常量和符号引用，在类加载后被JVM转换为运行时数据结构。

• 过度使用静态变量、大量的类加载、频繁的字符串常量等操作都可能导致方法区内存溢出的问题。

10.三种JVM

• Sun公司HotSpot java Hotspot™64-Bit server vw (build 25.181-b13，mixed mode)
• BEA JRockit
• IBM 39 VM
• 我们学习都是：Hotspot

11.堆（Java Heap）

概述：

1. JVM 实例只有一个堆内存，堆是 Java 内存管理的核心区域。
2. Java 堆区在 JVM 启动时被创建，其空间大小确定，是 JVM 管理的最大内存块。
3. 堆内存大小可调节，如 -Xms:10m（堆起始大小）和 -Xmx:30m（堆最大内存大小）。
4. 通常将起始值和最大值设置为一致，以减少垃圾回收后重新分配堆内存大小的次数，提高效率。
5. 根据《Java 虚拟机规范》，堆可以处于物理上不连续的内存空间，但在逻辑上应视为连续的。
6. 所有线程共享 Java 堆，也可划分线程私有的缓冲区。
7. 《Java 虚拟机规范》指出，所有对象实例都应在运行时分配在堆上。
8. 方法结束后，堆中的对象不会立即移除，只有在垃圾收集时才会被移除。
9. 堆是 GC（Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。

堆内存区域划分：

Java8 及之后堆内存分为 :新生区(新生代)+老年区(老年代)

新生区分为 Eden(伊甸园)区和 Survivor(幸存者)区

为什么分区(代)？

1. 将对象根据存活概率进行分类，对存活时间长的对象，放到固定区，从而减少扫描垃圾时间及 GC 频率。

2. 针对分类进行不同的垃圾回收算法，对算法扬长避短。

对象创建内存分配过程

在 JVM 中，为新对象分配内存是一个复杂而严谨的任务。设计者需要考虑内存分配的位置、算法以及与内存回收相关的问题，包括内存碎片的产生。整个过程如下：

1. 新对象首先被分配到伊甸园区（Eden），该区域大小有限制。
2. 当伊甸园区（Eden）填满时，如果程序需要创建更多对象，JVM 的垃圾回收器将执行垃圾回收（Minor GC），销毁伊甸园区（Eden）中不再被引用的对象，并将新对象放入伊甸园区（Eden）。
3. 剩余对象从伊甸园区（Eden）移动到幸存者 0 区（to 区）。
4. 如果再次触发垃圾回收，上次存放在幸存者 0 区（from 区）的对象，如果没有被回收，将被移到幸存者 1 区（to 区），保证每次都有一个空的幸存者区（to 区）。
5. 如果再次经历垃圾回收，存放在幸存者 0 区的对象会重新移到幸存者 0 区，然后继续移到幸存者 1 区。
6. 当对象的 GC 年龄达到默认值（通常为 15 次）或者自定义的阈值时，将会从新生代转移到老年代，这个阈值可以通过参数 -XX:MaxTenuringThreshold=<N> 设置。

• 在对象头中，它是由 4 位数据来对 GC 年龄进行保存的，所以最大值为 1111，即为15。所以在对象的 GC 年龄达到 15 时，就会从新生代转到老年代。

7. 在老年区，当内存不足时，会触发 Major GC，对老年区进行内存清理。
8. 如果在执行了 Major GC 后仍然无法保存对象，就会导致 OutOfMemoryError 异常，例如 Java.lang.OutOfMemoryError:Java heap space。

新生区与老年区配置比例

在 Java 虚拟机中，可以通过调整堆结构的配置来优化内存使用，其中包括新生代与老年代的占比以及伊甸园和幸存者空间的比例。

• 默认情况下，新生代与老年代在堆结构中的占比由参数 -XX:NewRatio 控制，默认值为 2。这表示新生代占 1，老年代占 2，新生代占整个堆的 1/3。如果需要调整，可以设置为其他值，例如 -XX:NewRatio=4，表示新生代占 1，老年代占 4，新生代占整个堆的 1/5。通过调整老年代的大小，可以优化项目中生命周期较长对象的存储。

• 在 HotSpot 虚拟机中，默认情况下，伊甸园区（Eden）和两个幸存者空间（Survivor）的比例为 8:1:1。可以通过选项 -XX:SurvivorRatio 进行调整。例如，设置 -XX:SurvivorRatio=8，表示调整幸存者空间的比例，此时新生区的对象默认生命周期超过 15 次，将会被转移到老年代进行养老。

  

分代收集思想 Minor GC、Major GC、Full GC

在 JVM 进行垃圾回收（GC）时，并非每次都会同时回收新生代和老年代，通常大部分情况下只会回收新生代。HotSpot VM 实现了两种主要类型的垃圾回收，即部分收集和整堆收集：

1. 部分收集：这种类型并非完整收集整个 Java 堆的垃圾，而是针对特定区域的垃圾回收。部分收集又分为两种类型：

• 新生代收集（Minor GC / Yong GC）：仅回收新生代（包括伊甸园区、幸存者区 S0 和 S1）的垃圾。
• 老年代收集（Major GC / Old GC）：仅回收老年代的垃圾。

2. 整堆收集（Full GC）：这种类型涉及到整个 Java 堆（包括新生代、老年代以及永久代或者元空间）的垃圾回收。

Full GC（Full Garbage Collection）会回收整个Java堆（Heap），包括新生代（Young Generation）、老年代（Old Generation）以及永久代（如果是经典的Java 8及之前版本）或元空间（如果是Java 8及之后的版本）中的对象。

• 整堆收集的出现情况包括：
  • 手动调用 System.gc(); 方法时。
  • 当老年代空间不足时。
  • 当方法区空间不足时。
  • 在开发期间应尽量避免整堆收集，因为它会引起停顿时间较长的暂停，影响程序的性能。

堆空间的参数设置

官网地址
| 参数 |描述 |

| :–: | :–: |
| -XX:+PrintFlagsInitial | 查看所有参数的默认初始值 |
| -XX:+PrintFlagsFinal | 查看所有参数的最终值(修改后的值) |
| -Xms | 初始堆空间内存(默认为物理内存的 1/64) |
| -Xmx | 最大堆空间内存(默认为物理内存的 1/4) |
| -Xmn | 设置新生代的大小(初始值及最大值) |
| -XX:NewRatio | 配置新生代与老年代在堆结构的占比 |
| -XX:SurvivorRatio | 设置新生代中 Eden 和 S0/S1 空间比例 |
| -XX:MaxTenuringTreshold| 设置新生代垃圾的最大年龄 |
| XX:+PrintGCDetails | 输出详细的 GC 处理日志 |

注意： $字符串常量池所在区域的变化？为啥？$

{–1)提高回收效率，避免永久代溢出；2）更好的GC控制}

• JDK1.7 之前，运行时常量池包含的字符串常量池和静态变量存放在方法区, 此时 HotSpot 虚拟机对方法区的实现为永久代。

• JDK1.7 字符串常量池和静态变量被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是 HotSpot 中的永久代 。

• JDK1.8 HotSpot 移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池和静态变量还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)

  

字符串常量池有什么作用？

字符串重用，避免重复创建。

字符串常量池为什么要调整位置（<JDK7: 永久代；>=JDK7: 堆空间）

• 提高GC效率，避免永久代溢出（因为JDK7方法区的实现还是永久代）

      JDK7 及以后的版本中将字符串常量池放到了堆空间中。因为方法区的回收效率很低，在 Full GC 的时候才会执行永久代的垃圾回收，而 Full GC 是老年代的空间不足、方法区不足时才会触发。
  

  这就导致字符串常量池回收效率不高，而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

      将字符串常量池移到堆空间中，使得它可以享受到堆空间自动调整大小的优势，避免了永久代内存溢出的问题。
  
      永久代的垃圾收集行为与新生代和老年代不同，这增加了 GC 管理的复杂性。通过将字符串常量池移到堆空间中，可以统一 GC 对整个堆空间的管理，简化了 GC 管理的逻辑。
  

12.新生区、养老区

• 新生区是类诞生，成长，消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。

• 新生区又分为两部分：伊甸区（Eden Space）和幸存者区（Survivor Space），所有的类都是在伊甸区被new出来的，幸存区有两个：0区 和 1区，当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（Minor GC）。将伊甸园中的剩余对象移动到幸存0区，若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区，那如果1区也满了呢？（这里幸存0区和1区是一个互相交替的过程）再移动到养老区，若养老区也满了，那么这个时候将产生MajorGC（Full GC），进行养老区的内存清理，若养老区执行了Full GC后发现依然无法进行对象的保存，就会产生OOM异常 “OutOfMemoryError ”。如果出现 java.lang.OutOfMemoryError：java heap space异常，说明Java虚拟机的堆内存不够，原因如下：

  • 1、Java虚拟机的堆内存设置不够，可以通过参数 -Xms（初始值大小），-Xmx（最大大小）来调整。

  • 2、代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）或者死循环。

13.永久区

• 永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class，Interface的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。
• 如果出现 java.lang.OutOfMemoryError：PermGen space，说明是 Java虚拟机对永久代Perm内存设置不够。一般出现这种情况，都是程序启动需要加载大量的第三方jar包，
• 例如：在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载，最终导致Perm区被占满。

熟悉三区结构后方可学习JVM垃圾回收机制

• 实际而言，方法区（Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名，叫做Non-Heap（非堆），目的就是要和堆分开。

• 对于HotSpot虚拟机，很多开发者习惯将方法区称之为 “永久代（Parmanent Gen）”，但严格本质上说两者不同，或者说使用永久代实现方法区而已，永久代是方法区（相当于是一个接口interface）的一个实现，Jdk1.7的版本中，已经将原本放在永久代的字符串常量池移走。

• 常量池（Constant Pool）是方法区的一部分，Class文件除了有类的版本，字段，方法，接口描述信息外，还有一项信息就是常量池，这部分内容将在类加载后进入方法区的运行时常量池中存放！

14.堆内存调优

• -Xms：设置初始分配大小，默认为物理内存的 “1/64”。
• -Xmx：最大分配内存，默认为物理内存的 “1/4”。
• -XX:+PrintGCDetails：输出详细的GC处理日志。

1. runtime.totalMemory()：

• 这个方法返回Java虚拟机当前已经使用的内存量。
• 它表示当前已经分配给Java虚拟机的内存量，包括已使用的和尚未使用的部分。
• 在Java程序运行期间，随着内存的分配和释放，这个值可能会不断变化。

2. runtime.maxMemory()：

• 这个方法返回Java虚拟机试图使用的最大内存量。
• 它表示Java虚拟机能够从操作系统获取的最大内存量。
• 当Java程序运行时，Java虚拟机会根据需要动态调整可用内存的大小，但不会超过这个最大内存量。

3. runtime.freeMemory()

• 这个方法返回Java虚拟机当前空闲的内存量，即还没有被分配给程序使用的内存。

• 它表示Java虚拟机中尚未被分配的、可用于新对象分配的内存量。

• 在Java程序运行期间，这个值可能会随着程序的内存分配和释放而不断变化。

测试1

代码测试

默认情况下:分配的总内存是电脑内存的1/4,初始化的内存是电脑的1/64

public class Test {
    public static void main(String[] args) {
        Runtime runtime = Runtime.getRuntime();
        System.out.println("runtime.availableProcessors(): " + runtime.availableProcessors());
        double maxMemory = (double) runtime.maxMemory();
        double totalMemory = (double) runtime.totalMemory();
        double freeMemory = (double) runtime.freeMemory();
        double usedMemory = totalMemory - freeMemory;
        System.out.println("runtime.maxMemory(): " + maxMemory + "bytes, " + (maxMemory / 1024) + "KB, " + (maxMemory / 1024 / 1024) + "MB, " + (maxMemory / 1024 / 1024 / 1024) + "GB");
        System.out.println("runtime.totalMemory(): " + totalMemory + "bytes, " + (totalMemory / 1024) + "KB, " + (totalMemory / 1024 / 1024) + "MB");
        System.out.println("runtime.freeMemory(): " + freeMemory + "bytes, " + (freeMemory / 1024) + "KB, " + (freeMemory / 1024 / 1024) + "MB");
        System.out.println("usedMemory: " + usedMemory + "bytes, " + (usedMemory / 1024) + "KB, " + (usedMemory / 1024 / 1024) + "MB");
    }
}

runtime.availableProcessors(): 16
runtime.maxMemory(): 3.754426368E9bytes, 3666432.0KB, 3580.5MB, 3.49658203125GB
runtime.totalMemory(): 2.53231104E8bytes, 247296.0KB, 241.5MB
runtime.freeMemory(): 2.47940152E8bytes, 242129.0546875KB, 236.45415496826172MB
usedMemory: 5290952.0bytes, 5166.9453125KB, 5.045845031738281MB

JVM参数缩写的含义–帮助记忆
JVM的参数缩写很容易混淆，理解每个参数的具体含义可以帮助记忆。

VM选项有三种：

• : 标准VM选项，VM规范的选项
  -X: 非标准VM选项，不保证所有VM支持
  -XX: 高级选项，高级特性，但属于不稳定的选项

对于第二类参数，其语义分别是
-Xms: 堆的初始化初始化大小，助记：memory startup

-Xmx: 堆的最大内存数，等同于-XX:MaxHeapSize，助记：memory maximum
-Xmn: 堆中新生代初始及最大大小，如果需要进一步细化，初始化大小用-XX:NewSize，最大大小用-XX:MaxNewSize，助记：memory nursery/new
-Xss: 线程栈大小，等同于-XX:ThreadStackSize，助记：stack size

JVM参数缩写的含义–帮助记忆_jvm参数 x是什么意义-CSDN博客

• IDEA中进行VM调优参数设置，然后启动。

发现，默认的情况下分配的内存是总内存的 1/4，而初始化的内存为 1/64 ！

• VM options:

-Xms1024m -Xmx1024m -XX:+PrintGCDetails

• VM参数调优：把初始内存，和总内存都调为 1024M，运行，查看结果！

• 来大概计算分析一下！

$305664K(PSYoungGen)+699392K(ParOldGen)=1005056KB=981.5MB$

• 再次证明：元空间并不在虚拟机中，而是使用本地内存。（逻辑上存在，物理上不存在）

测试2

代码：

package github.JVM.Demo02;

import java.util.Random;

/** * @author subeiLY * @create 2021-06-08 10:22 */
public class Demo02 {
    public static void main(String[] args) {
        String str = "suneiLY";
        while (true) {
            str += str + new Random().nextInt(88888888)
                    + new Random().nextInt(999999999);
        }
    }
}

• vm参数：

-Xms8m -Xmx8m -XX:+PrintGCDetails

• 测试，查看结果！

• 这是一个young 区域撑爆的JAVA 内存日志，其中 PSYoungGen 表示 youngGen分区的变化, 1536k 表示 GC 之前的大小, 488k 表示GC 之后的大小。

• 整个Young区域的大小从 1536K 到 672K , young代的总大小为 7680K。

• user – 总计本次 GC 总线程所占用的总 CPU 时间。

• sys – OS 调用 or 等待系统时间。

• real – 应用暂停时间。

• 如果GC 线程是 Serial Garbage Collector 串行搜集器的方式的话（只有一条GC线程,）， real time 等于user 和 system 时间之和。

• 通过日志发现Young的区域到最后 GC 之前后都是0，old 区域 无法释放，最后报堆溢出错误。

其他文章链接

• 一文读懂 - 元空间和永久代
• Java方法区、永久代、元空间、常量池详解

15. 垃圾收集算法

15.0 概述

什么是垃圾

不再被程序所引用的对象或数据

为什么需要GC

• 简化内存管理

• 防止内存泄漏

• 降低内存碎片化，提高内存利用率

应该关心哪些区域的回收

垃圾收集器可以针对不同区域进行回收，包括年轻代、老年代、全栈（包括本地方法栈和虚拟机栈）以及方法区（元空间）等。在这些区域中，Java 堆通常是垃圾收集器的主要工作重点。

从回收频率来看，通常有以下情况：

1. 频繁收集 Young 区：年轻代中的对象通常具有较短的生命周期，因此需要经常进行回收。年轻代的垃圾收集通常使用较轻量的垃圾收集算法，如复制算法，以提高回收效率。

2. 较少收集 Old 区：老年代中的对象通常具有较长的生命周期，因此需要较少的回收。老年代的垃圾收集通常使用更复杂的垃圾收集算法，如标记-清除算法或标记-整理算法，以提高效率并减少对应用程序的影响。

3. 基本不收集元空间（方法区）：元空间（方法区）通常用于存储类的结构信息、常量池、静态变量等，它的内存管理由 JVM 自行管理，并不像 Java 堆那样频繁进行对象的分配和回收。在某些情况下，可能会触发类的卸载，但是这种情况相对较少，因此元空间的回收频率通常很低。

方法区和永久代以及元空间有什么关系

永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式

为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace)

• 避免永久代内存溢出

• 减少 Full GC概率

15.1. Dump内存快照

Dump 转储

​ 在运行java程序的时候，有时候想测试运行时占用内存情况，这时候就需要使用测试工具查看了。在eclipse里面有 Eclipse Memory Analyzer tool(MAT)插件可以测试，而在idea中也有这么一个插件，就是JProfiler，一款性能瓶颈分析工具！

作用：

• 分析Dump文件，快速定位内存泄漏；

• 获得堆中对象的统计数据

• 获得对象相互引用的关系

• 采用树形展现对象间相互引用的情况

安装JProfiler

1. IDEA插件安装

2. 安装JProfiler监控软件

• 下载地址：ej-technologies - Java APM, Java Profiler, Java Installer Builder

3. 下载完双击运行，选择自定义目录安装，点击Next。

• 注意：安装路径，建议选择一个文件名中没有中文，没有空格的路径 ，否则识别不了。然后一直点Next。

4. 注册

// 注册码仅供大家参考
L-Larry_Lau@163.com#23874-hrwpdp1sh1wrn#0620
L-Larry_Lau@163.com#36573-fdkscp15axjj6#25257
L-Larry_Lau@163.com#5481-ucjn4a16rvd98#6038
L-Larry_Lau@163.com#99016-hli5ay1ylizjj#27215
L-Larry_Lau@163.com#40775-3wle0g1uin5c1#0674

5. 配置IDEA运行环境

• Settings–Tools–JProflier–JProflier executable选择JProfile安装可执行文件。（如果系统只装了一个版本， 启动IDEA时会默认选择）保存。

• 代码测试：

package github.JVM.Demo02;

import java.util.ArrayList;

/** * @author subeiLY * @create 2021-06-08 11:13 */
public class Demo03 {
    byte[] byteArray = new byte[1*1024*1024]; // 1M = 1024K


    public static void main(String[] args) {
        ArrayList<Demo03> list = new ArrayList<>();
        int count = 0;
        try {
            while (true) {
                list.add(new Demo03());  // 问题所在
                count = count + 1;
            }
        } catch (Error e) {
            System.out.println("count:" + count);
            e.printStackTrace();
        }
    }
}

• vm参数 ： -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

• 寻找文件：

使用 Jprofiler 工具分析查看

双击这个文件默认使用 Jprofiler 进行 Open大的对象！

大对象

Thread Dump – 线程转储

• 从软件开发的角度上，dump文件就是当程序产生异常时，用来记录当时的程序状态信息（例如堆栈的状态），用于程序开发定位问题。

15.2. 垃圾回收相关算法 – 标记阶段

垃圾标记阶段： 主要是为了判断对象是否是垃圾对象

判断方法： 引用计数算法和可达性分析算法

1. 引用计数法 （Reference Counting）

• 每个对象有一个引用计数器，当对象被引用一次则计数器加1，当对象引用失效一次，则计数器减1，对于计数器为0的对象意味着是垃圾对象，可以被GC回收。

• 目前虚拟机基本都是采用可达性算法，从GC Roots 作为起点开始搜索，那么整个连通图中的对象边都是活对象，对于GC Roots 无法到达的对象变成了垃圾回收对象，随时可被GC回收。

• 优点

  • 实现简单，垃圾对象便于辨识；

  • 判定效率高，回收没有延迟性。

• 缺点

  1. 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。

  2. 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。

  3. 引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在.Java 的垃圾回收器中没有使用这类算法。

2. 可达性分析算法

可达性分析算法，也称为根搜索算法或追踪性垃圾收集，是一种用于垃圾收集的算法。相对于引用计数算法而言，可达性分析算法具有以下优势：

1. 解决循环引用问题：可达性分析算法能够有效地解决引用计数算法中可能出现的循环引用问题。在循环引用的情况下，引用计数算法可能导致对象永远无法被回收，从而导致内存泄漏。而可达性分析算法通过搜索对象之间的引用关系，可以准确地确定对象是否可达，避免了这一问题的发生。

2. 实现简单高效：可达性分析算法实现相对简单，并且执行效率较高。该算法的核心思想是从一组根对象开始，通过遍历对象之间的引用关系，标记出所有可达的对象，然后将未被标记的对象视为垃圾进行回收。这种算法能够有效地识别和回收不再被程序引用的对象，从而释放内存空间。

3. 被Java和C#选择：Java和C#等现代编程语言选择了可达性分析算法作为其垃圾收集的主要算法。这是因为可达性分析算法能够更好地应对复杂的内存管理场景，保证程序的内存使用效率和稳定性。追踪性垃圾收集（Tracing Garbage Collection）就是可达性分析算法的一种实现方式。

可达性分析实现思路

所谓"GCRoots”根就是一组必须活跃的引用
其基本思路如下：

1. 可达性分析算法是以根（GCRoots）为起始点，按照从上至下的方式搜索被根对象所连接的目标对象是否可达。
2. 使用可达性分析算法后，内存中的存活对象都会被根直接或间接连接着，搜索所走过的路径称为引用链（Reference Chain）
3. 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。

GC Roots 可以是哪些元素？

1. 虚拟机栈中引用的对象：包括各个线程被调用的方法中使用到的参数、局部变量等。当线程执行一个方法时，虚拟机栈会为该方法创建一个栈帧，栈帧中包含了该方法的局部变量表，其中存放了对对象的引用。

2. 方法区中类静态属性引用的对象：例如，Java 类的引用类型静态变量。类的静态变量存放在方法区中，如果某个静态变量引用了一个对象，则该对象会被视为 GC Roots。

3. 所有被同步锁 synchronized 持有的对象：当一个对象被某个线程持有了同步锁，即进入了同步代码块或同步方法，那么该对象被认为是 GC Roots。

4. Java 虚拟机内部的引用：这包括基本数据类型对应的 Class 对象，以及一些常驻的异常对象，如 NullPointerException、OutOfMemoryError 等，以及系统类加载器等。

对象的 Finalization 机制

finalize() 方法机制：

• finalize() 方法是对象销毁前的回调方法。
• Java 提供了对象终止（finalization）机制，允许开发人员提供对象被销毁之前的自定义处理逻辑。
• 当垃圾回收器发现没有引用指向一个对象时，即将垃圾回收此对象之前，总会先调用该对象的 finalize() 方法，每个对象的 finalize() 方法只会被调用一次。
• finalize() 方法允许在子类中被重写，用于在对象被回收时进行资源释放，比如关闭文件、套接字和数据库连接等。

Object 类中 finalize() 源码：

protected void finalize() throws Throwable { }

注意事项：

• 永远不要主动调用某个对象的 finalize() 方法，应该交给垃圾回收机制调用。
• 原因包括：
  1. 在 finalize() 时可能会导致对象复活。
  2. finalize() 方法的执行时间不确定，完全由 GC 线程决定，极端情况下，若不发生 GC，则 finalize() 方法将没有执行机会。
  3. 一个糟糕的 finalize() 方法会严重影响 GC 的性能，比如死循环。

生存还是死亡？

由于 finalize() 方法的存在，虚拟机中的对象一般处于三种可能的状态：

1. 可触及的：从根节点开始，可以到达这个对象。
2. 可复活的：对象的所有引用都被释放，但是对象有可能在 finalize() 中复活。
3. 不可触及的：对象的 finalize() 被调用，并且没有复活，那么就会进入不可触及状态。

具体过程：

• 判定一个对象是否可回收，至少要经历两次标记过程：
  1. 如果对象到 GC Roots 没有引用链，则进行第一次标记。
  2. 进行筛选，判断此对象是否有必要执行 finalize() 方法：
  • 如果对象没有重写 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，则视为“没有必要执行”，对象被判定为不可触及的。
  • 如果对象重写了 finalize() 方法，且还未执行过，那么会被插入到队列中，由 Finalizer 线程触发其 finalize() 方法执行。
• finalize() 方法是对象逃脱死亡的最后机会，稍后 GC 会对队列中的对象进行第二次标记。
• 如果对象在 finalize() 方法中与引用链上的任何一个对象建立了联系，那么会被移出“即将回收”集合，之后对象会再次出现没有引用存在的情况，这时 finalize() 方法不会再次调用，对象会直接变成不可触及的状态。

15.3. 垃圾回收相关算法 – 回收阶段

1.复制算法(Copying)

• 年轻代中使用的是Minor GC，采用的就是复制算法（Copying）。

什么是复制算法？

执行过程

1. 对象分配阶段： 初始时，所有的新对象都会被分配到 Eden 区。

2. Minor GC 触发： 当 Eden 区填满时，会触发 Minor GC（也称为新生代 GC）。

3. 存活对象复制： 在 Minor GC 过程中，GC 首先会检查所有存活的对象，并将它们复制到 Survivor 区中的一个。如果一个对象经过一次 Minor GC 后仍然存活，它就会被复制到另一个 Survivor 区，而不是被清除。通常来说，每次 Minor GC 后，存活的对象都会被复制到一个新的 Survivor 区。

4. 年龄增加： 经过多次 Minor GC 后，存活的对象会逐渐增加年龄。一般来说，每经过一次 Minor GC，对象的年龄就会增加一岁。当一个对象的年龄达到一定阈值（通常是 15 岁），它就会被晋升到老年代（Old Generation）。

5. Major GC 触发： 在老年代空间不足或进行 Full GC（全局垃圾回收）时，会触发 Major GC（老年代 GC）。这时，会对整个堆内存进行清理和整理。

优点

• 解决了内存碎片问题由于每次回收后存活对象都会被移动到一个新的区域，因此不会产生内存碎片。
• 简单高效实现简单，不需要进行复杂的内存整理操作（标记，清除），同时也可以高效地回收大量的短生命周期对象。

缺点

• 双倍内存消耗由于需要将存活对象复制到另一个区域，因此需要额外的内存空间。
• 无法处理长生命周期对象对于长时间存活的对象，需要经过多次 Minor GC 后才会被晋升到老年代，这可能会导致老年代的内存占用过高。

应用场景

• 如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大，效率较高

  • 老年代大量的对象存活，那么复制的对象将会有很多，效率会很低

  • 在新生代，对常规应用的垃圾回收，一次通常可以回收 70% - 99% 的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代

• Minor GC 会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移动到Old generation中，也就是说，一旦收集后，Eden就是变成空的了

• 当对象在Eden（包括一个Survivor区域，这里假设是From区域）出生后，在经过一次Minor GC后，如果对象还存活，并且能够被另外一块Survivor区域所容纳 （上面已经假设为from区域，这里应为to区域，即to区域有足够的内存空间来存储Eden 和 From 区域中存活的对象），则使用复制算法将这些仍然还活着的对象复制到另外一块Survivor区域（即 to 区域）中，然后清理所使用过的Eden 以及Survivor 区域（即form区域），并且将这些对象的年龄设置为1，以后对象在Survivor区，每熬过一次MinorGC，就将这个对象的年龄 + 1，当这个对象的年龄达到某一个值的时候（默认是15岁，通过- XX:MaxTenuringThreshold 设定参数）这些对象就会成为老年代。

• -XX:MaxTenuringThreshold 任期门槛=>设置对象在新生代中存活的次数

面试题：如何判断哪个是to区呢？一句话：谁空谁是to

原理解释：

• 年轻代中的GC，主要是复制算法（Copying）

• HotSpot JVM 把年轻代分为了三部分：一个 Eden 区 和 2 个Survivor区（from区 和 to区）。默认比例为 8:1:1，一般情况下，新创建的对象都会被分配到Eden区（一些大对象特殊处理），这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区，对象在Survivor中每熬过一次Minor GC ， 年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中，因为年轻代中的对象基本上 都是朝生夕死，所以在年轻代的垃圾回收算法使用的是复制算法！复制算法的思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产 生内存碎片！

• 在GC开始的时候，对象只会在Eden区和名为 “From” 的Survivor区，Survivor区“TO” 是空的，紧接着进行GC，Eden区中所有存活的对象都会被复制到 “To”，而在 “From” 区中，仍存活的对象会根据他们的年龄值来决定去向。
• 年龄达到一定值的对象会被移动到老年代中，没有达到阈值的对象会被复制到 “To 区域”，经过这次GC后，Eden区和From区已经被清空，这个时候， “From” 和 “To” 会交换他们的角色， 也就是新的 “To” 就是GC前的“From” ， 新的 “From” 就是上次GC前的 “To”。
• 不管怎样，都会保证名为To 的Survicor区域是空的。 Minor GC会一直重复这样的过程。直到 To 区 被填满 ，“To” 区被填满之后，会将所有的对象移动到老年代中。

• 因为Eden区对象一般存活率较低，一般的，使用两块10%的内存作为空闲和活动区域，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的Eden 对象转移到10%的to空闲区域，接下来，将之前的90%的内存，全部释放，以此类推；

• 好处：没有内存碎片；坏处：浪费内存空间。

劣势：

• 复制算法它的缺点也是相当明显的。
  • 1、他浪费了一半的内存，这太要命了。
  • 2、如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视，所以从以上描述不难看出。复制算法要想使用，最起码对象的存活率要非常低才行，而且 最重要的是，我们必须要克服50%的内存浪费。

2.标记清除(Mark-Sweep)

如何选择Eden区复制到Survivor区的对象？---- 标记清除

1. 标记存活对象： GC 会从根对象开始，通过可达性分析（Reachability Analysis）标记所有在程序执行过程中仍然是活动的对象。这些根对象可能是线程栈中的引用、静态变量、本地变量表中的引用等。所有与这些根对象直接或间接相连的对象都会被标记为存活对象。

2. 复制到 Survivor 区： 在标记阶段结束后，GC 会遍历 Eden 区中的所有对象，将其中标记为存活的对象复制到 Survivor 区的其中一个。通常情况下，复制后的对象是按照它们在 Eden 区中的顺序复制到 Survivor 区的，但具体实现可能有所不同。

3. 清空 Eden 区： 复制完所有存活对象后，Eden 区中所有未被复制的对象都会被认定为垃圾，并且整个 Eden 区将被清空，以便为后续的对象分配提供空间。

4. 年龄增加： 存活在 Survivor 区的对象的年龄会增加。每次经过一次 Minor GC，存活对象会被复制到另一个 Survivor 区，并且它们的年龄会增加。当达到一定的年龄阈值后，对象会被晋升到老年代。

标记清除（Mark-Sweep）

• 回收时，对需要存活的对象进行标记；

• 回收不是绿色的对象。

• 当堆中的有效内存空间被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

• 标记：从引用根节点开始标记所有被引用的对象，标记的过程其实就是遍历所有的GC Roots ，然后将所有GC Roots 可达的对象，标记为存活的对象。

• 清除： 遍历整个堆，把未标记的对象清除。

• 缺点：

  • 这个算法需要暂停整个应用，会产生内存碎片。

  • 两次扫描（标记+清除），严重浪费时间。

用通俗的话解释一下 标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清 除掉，接下来便让程序恢复运行。

劣势：

1. 首先、它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用 程序，这会导致用户体验非常差劲

2. 其次、主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象 都是随机的出现在内存的各个角落，现在把他们清除之后，内存的布局自然乱七八糟，而为了应付 这一点，JVM就不得不维持一个内存空间的空闲列表，这又是一种开销。而且在分配数组对象的时 候，寻找连续的内存空间会不太好找。

• Q: 可达性分析（Reachability Analysis）具体过程？

• A: 可达性分析是垃圾回收算法中用于确定对象是否可访问（或者说“可达”）的一种技术。它的基本思想是从一组称为“根”的起始对象开始，递归地查找所有通过引用链与根对象相连接的对象，并将它们标记为可达的。而无法通过这些引用链到达的对象，则被视为不可达的，即可被回收的垃圾对象。

  具体的可达性分析过程如下：

  1. 标记根对象： 可达性分析从一组称为根的对象开始。这些根对象通常包括：
  • 程序的活动线程的栈中引用的对象；
  • 静态变量引用的对象；
  • 特定于应用程序的任何其它对象，被认为是程序的入口点。

  2. 递归遍历： 从根对象开始，递归地遍历所有与根对象直接或间接相关的对象。这一步骤通常使用深度优先搜索（DFS）或广度优先搜索（BFS）等算法来实现。

  3. 标记可达对象： 在遍历的过程中，将所有访问到的对象标记为可达。如果一个对象已经被标记为可达，那么它的所有引用对象也会被继续遍历和标记。

  4. 清除不可达对象： 一旦所有可达的对象都被标记完毕，剩余的未被标记的对象即为不可达对象，即垃圾对象。这些对象可以被安全地回收，以释放其所占用的内存空间。

• Q: 存活对象定义？

• A: 在可达性分析过程中，存活对象指的是通过根对象可达的对象，即那些可以被程序使用到的对象。垃圾对象则是不可达的对象，即那些程序不再使用的对象，可以被垃圾回收器回收的对象。

• Q: 引用根节点是啥？

• A: 引用根节点是指可达性分析开始时所使用的起始对象集合。这些根节点通常包括程序中活动线程的栈帧中的引用、静态变量引用的对象、以及其他特定于应用程序的入口点对象。通过从这些根节点出发，可达性分析可以遍历整个对象图，并确定哪些对象是可达的，哪些对象是不可达的。

3.标记压缩/标记整理（Mark-Compact）

• 标记整理说明：老年代一般是由标记清除或者是标记清除与标记整理的混合实现。
• 标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法
• 二者的本质差异在于标记-清除算法是一种非移动式的回收算法（空闲列表记录位置），标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策
• 可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时JVM 只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

什么是标记压缩？

原理：

• 在整理压缩阶段，不再对标记的对象作回收，而是通过所有存活对象都像一端移动，然后直接清除边界以外的内存。可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被 清理掉，如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

• 标记、整理算法 不仅可以弥补 标记、清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价；

原理

标记压缩是一种垃圾回收算法，主要用于老年代（Old Generation）的内存区域，旨在解决长生命周期对象的内存管理问题。与标记清除算法不同，标记压缩算法在回收垃圾对象后会对存活对象进行整理，以减少内存碎片化。

该算法一般包括以下步骤：

1. 标记存活对象： 与标记清除算法相似，标记压缩算法首先通过可达性分析标记所有存活的对象。

2. 压缩存活对象： 在标记阶段结束后，存活对象通常会在堆内存中是不连续的，这可能导致内存碎片的产生。为了解决这个问题，标记压缩算法会将所有存活对象向堆内存的一端移动，使它们成为连续的块。这个过程被称为压缩（Compaction）。

3. 更新引用： 在移动存活对象的过程中，需要更新所有指向这些对象的引用，以确保它们仍然指向正确的内存地址。

4. 清除未标记的对象： 在压缩存活对象后，所有未被标记的对象被认为是垃圾，并且可以被安全地回收。

优点

• 减少内存碎片化：（相较于标记清除算法的改进）通过将存活对象整理成连续的块，可以降低内存碎片的产生，提高内存利用率。
• 改善内存分配性能：（相较于标记清除算法的改进）连续的内存块有利于快速、高效地分配内存空间。
• 减少所需使用的内存（相较于复制算法的改进）消除了复制算法当中，内存减半的高额代价。

缺点

• 需要额外的移动操作：将存活对象整理成连续的块需要额外的内存移动操作，可能会增加垃圾回收的时间成本。
• 不适用于所有场景：对于内存分配频繁、存活对象较多的情况，压缩操作可能会带来较大的性能开销。

尽管标记压缩算法在某些情况下效果显著，但它通常用于老年代的垃圾回收，而在新生代通常采用复制算法。

15.4. 总结

• 内存效率：复制算法 > 标记清除算法 > 标记压缩算法 （时间复杂度）；

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

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

	复制	标记清除	标记整理
速率	最快	中等	最慢
空间开销	多，活动对象的两倍空间	少	少
内存碎片	无	有	无
移动对象	有	无	有

难道就没有一种最优算法吗？

答案： 无，没有最好的算法，只有最合适的算法 。 -----------> 分代收集算法

分代收集算法

为什么要使用分代收集？

• 不同对象的生命周期不同，需要采取不同的收集方式以提高回收效率。
  • 长生命周期的对象：Http 请求中的 Session 对象、线程、Socket 连接
  • 短生命周期的对象：String 对象
• 分代收集根据对象的生命周期将 Java 堆分为新生代和老年代，以便根据各自特点使用不同的回收算法，提高垃圾回收效率。

年轻代（Young Gen）

• 区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
• 适合使用复制算法进行回收整理，速度最快。
• 复制算法内存利用率不高的问题通过 HotSpot 中的两个 survivor 空间设计得到缓解。

老年代（Tenured Gen）

• 区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
• 大量存活率高的对象存在，复制算法不合适。
• 一般采用标记-清除或标记-清除与标记-压缩混合实现。

分代收集的优势

• 分代收集考虑到不同对象的生命周期，提高了垃圾回收的效率。
• 几乎所有的垃圾回收器都采用分代的思想，区分新生代和老年代，以提高回收效率。

复制算法内存利用率不高的问题通过 HotSpot 中的两个 survivor 空间设计得到缓解，为什么能得到缓解？

复制算法（Copying Algorithm）核心思想是将内存分为两块，每次只使用其中一块，当这一块的内存用完后，将其中存活的对象复制到另一块内存中，同时清理掉当前内存中的垃圾对象，以此来达到内存整理的目的。

复制算法的一个问题是，它会导致内存利用率不高，因为每次只能使用其中一块内存，另一块内存则被浪费掉。

为了缓解这个问题，HotSpot 中采用了两个 survivor 空间的设计。在新生代中，将其中一块内存细分为两个相等大小的区域，分别称为 Eden 区和 From 区（另一块内存则是 To 区）。每次进行内存回收时，存活的对象会被复制到 To 区，并清理掉 Eden 区和 From 区中的垃圾对象，而下一次内存回收时，会交换 Eden 区和 From 区的角色，即存活的对象会被复制到原来的 From 区，而清理的操作则会在另外一块区域进行。

这样，就可以使得两个 survivor 空间都得到了充分利用，从而缓解了复制算法内存利用率不高的问题。

System.gc(); Runtime.getRuntime().gc();

• 在默认情况下，通过调用 System.gc() 或者 Runtime.getRuntime().gc()，会显式触发 Full GC（全垃圾回收），同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
• 尽管调用 System.gc()，但它附带一个免责声明，即无法保证对垃圾收集器的调用会立即生效。
• JVM（Java 虚拟机）的实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则会显得过于麻烦。
• 在一些特殊情况下，我们可以在运行之间调用 System.gc()，但这通常被视为是不推荐的做法。

内存溢出

• 定义： 内存溢出（Out of Memory，OOM）是指程序在申请内存时，没有足够的内存空间供其使用，导致申请失败或者操作系统无法为其分配所需内存，从而导致程序崩溃。

• 原因： 内存溢出通常发生在程序占用的内存增长速度超过了垃圾回收的速度，或者程序持续申请内存导致系统无法满足需求时。

• 示例： 当应用程序在运行过程中，分配的内存不断增加，直至达到系统所能提供的极限时，就会发生内存溢出。常见情况包括不合理的内存使用、内存泄漏等。

• 处理方式： 避免内存溢出的方法包括优化代码，减少内存使用量，释放不再使用的对象等。另外，通过监控和调整堆内存大小、调整垃圾回收策略等方式也可以缓解内存溢出问题。

内存泄漏：

• 定义： 内存泄漏指的是程序在运行过程中，不再需要使用的内存却没有被正确释放或回收，导致系统无法再次使用这些内存，最终耗尽可用内存，导致程序性能下降或崩溃。

• 原因： 内存泄漏通常是由于程序中的对象持续存在而未被正确释放，或者持有对其他对象的引用，导致这些对象无法被垃圾回收器回收。

• 示例： 常见的内存泄漏包括未关闭的资源（如数据库连接、文件流等）、长生命周期的对象持有短生命周期对象的引用、静态集合类未及时清理等。

• 处理方式： 避免内存泄漏的方法包括及时释放不再使用的资源、避免循环引用、使用弱引用或软引用等方式管理对象生命周期，以及通过工具和代码审查等手段检测和修复潜在的内存泄漏问题。

Stop-the-World (STW)

• 定义： Stop-the-World（STW）是指在进行垃圾回收（GC）时，应用程序的所有线程都会被暂停，没有任何响应，以确保垃圾回收器可以安全地执行其工作。这个暂停的过程就是STW。

• 必要性：

  1. 保证一致性： 在进行可达性分析等垃圾回收算法时，需要在一个能确保系统一致性的快照中进行分析。一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上，以防止分析过程中对象引用关系不断变化，导致分析结果不准确，出现漏标、错标等问题。
  2. 恢复应用程序线程： 被STW中断的应用程序线程会在完成GC之后恢复。频繁的STW会让用户感觉到应用程序卡顿，类似于网络速度不快导致视频卡顿的感觉，因此需要尽量减少STW的发生，以提升用户体验。

• 优化和减少STW的方法：

  1. 优化GC算法： 不断优化GC算法，提高回收效率，尽可能缩短STW的暂停时间，减少对应用程序的影响。
  2. 增强并行和并发处理： 使用并行GC和并发GC等技术，尽可能在不中断应用程序线程的情况下进行垃圾回收，减少STW的发生。
  3. 调整GC策略和参数： 根据应用程序的特点和需求，合理调整GC策略和参数，以达到最佳的性能和用户体验。

• JVM自动处理： STW是由JVM在后台自动发起和完成的，对用户来说是不可见的，JVM会自动将应用程序的工作线程全部暂停，执行必要的垃圾回收操作，然后恢复应用程序线程的正常运行。

16. 垃圾收集器（GC, Garbage Collector）

• 角色定位： 垃圾收集器是内存回收的实践者，负责实际执行垃圾回收算法。
• 规范灵活性： Java虚拟机规范并未对垃圾收集器进行过多规定，可以由不同厂商、不同版本的JVM自行实现。
• 发展多样性： 随着JDK版本迭代，Java发展了众多垃圾回收器，适用于不同场景和需求，选择适合的垃圾回收器是JVM调优的重要组成部分。

分类

• 按线程数：

  • 单线程垃圾回收器(Serial): 只有一个线程进行垃圾回收，适用于小型简单场景，但在垃圾回收时会暂停其他用户线程。
  • 多线程垃圾回收器(Parallel): 内部提供多个线程进行垃圾回收，在多CPU情况下提升垃圾回收效率，但同样会暂停其他用户线程。

• 按工作模式：

  • 独占式和并发式垃圾回收器。

• 按内存区间：

  • 年轻代和老年代垃圾回收器。

性能指标

• 吞吐量（Throughput）

  • 运行用户代码的时间占总运行时间的比例，反映系统的处理能力。

  • 总运行时间：程序的运行时间+ 内存回收的时间

  • 垃圾收集开销： 垃圾收集所用时间与总运行时间的比例，反映垃圾回收对系统性能的影响。

• 暂停时间（Pause Time）

  • 执行垃圾收集时，程序的工作线程被暂停的时间，直接影响用户体验。
  • 内存占用： Java堆区所占的内存大小，反映系统内存利用率。
  • 快速（Promptness）： 一个对象从诞生到被回收所经历的时间，影响内存资源的释放效率。

HotSpot 垃圾收集器

图中展示了 7 种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

收集器名称	线程性质	垃圾收集算法	是否需要STW
Serial 收集器	单线程	复制算法	是
ParNew 收集器	多线程	复制算法	是
Parallel Scavenge 收集器	多线程	复制算法	是
Serial Old 收集器	单线程	标记-整理算法	是
Parallel Old 收集器	多线程	标记-整理算法	是
CMS（Concurrent Mark-Sweep）收集器	多线程	标记-清除算法	否
G1 收集器	多线程	标记-整理/清除算法	是

新生代收集器：

1. Serial 收集器（Serial Garbage Collector）： 单线程收集器，使用复制算法，在新生代中工作。适用于小型或中小型应用，简单高效。
2. ParNew 收集器（Parallel New Garbage Collector）： 多线程收集器，是Serial收集器的多线程版本，也使用复制算法，但可以利用多核CPU，提高垃圾收集效率。
3. Parallel Scavenge 收集器： 也是一个多线程收集器，专注于吞吐量。它的主要目标是达到一个可控的吞吐量，并在满足吞吐量的同时尽可能地减少停顿时间。适用于后台运行、需要高吞吐量的大型应用。使用复制算法。

老年代收集器：

1. Serial Old 收集器： 单线程收集器，是Serial收集器的老年代版本，使用标记-整理算法，在老年代中工作。
2. Parallel Old 收集器： 多线程收集器，是Parallel Scavenge收集器的老年代版本，也使用标记-整理算法，但是针对老年代的特点进行了优化，提高了并行性和吞吐量。
3. CMS（Concurrent Mark-Sweep）收集器： 是一种以最短停顿时间为目标的垃圾收集器。它使用的是标记-清除算法，可以与应用程序线程并发执行，减少停顿时间。适用于对停顿时间有严格要求的应用场景。

混合收集器：

1. G1 收集器（Garbage-First Garbage Collector）： 一种面向全堆的垃圾收集器，它将堆划分为多个小块，根据应用程序的行为动态地确定哪些区域需要优先进行垃圾回收。它可以同时处理新生代和老年代的垃圾，具有更可预测的暂停时间，并且适用于大内存应用和需要低延迟的应用。

16.1 CMS（Concurrent Mark Sweep）回收器

CMS（Concurrent Mark Sweep，并发标记清除）收集器是一种以最短回收停顿时间为目标的垃圾收集器。它通过允许用户线程和垃圾收集线程并发执行来实现垃圾收集过程中的低停顿。下面我们来详细了解CMS收集器的工作过程和其优缺点：

CMS收集器的工作过程

1. 初始标记（Initial Mark）：在这个阶段，垃圾收集器会暂停所有用户线程（Stop The World），然后使用一条初始标记线程对所有与GC Roots直接关联的对象进行标记。

2. 并发标记（Concurrent Mark）：在这个阶段，垃圾收集线程会与用户线程并发执行。它进行可达性分析，标记出所有废弃对象，即可达对象。

3. 重新标记（Remark）：重新标记阶段也需要暂停用户线程，但是使用多条标记线程并发执行，标记出并发标记过程中新出现的废弃对象。

4. 并发清除（Concurrent Sweep）：在这个阶段，只使用一条GC线程，与用户线程并发执行，清除刚才标记的对象。这个阶段的耗时较长。

CMS收集器的优点：

• 并发收集：CMS收集器可以在很大程度上与用户线程并发执行，从而减少了停顿时间，用户在进行垃圾收集时不会感到明显的卡顿。

CMS收集器的弊端：

• 内存碎片：由于CMS是基于标记-清除算法实现的，容易产生内存碎片，影响内存的连续分配和性能。

• 并发阶段的性能损耗：尽管CMS在并发阶段不会导致用户线程停顿，但会占用一部分线程资源，导致应用程序变慢，总吞吐量会降低。

• 无法处理浮动垃圾：CMS收集器无法处理浮动垃圾（floating garbage），这可能导致堆空间的不断增长。

三色标记算法

三色标记算法是一种用于改善Java虚拟机（JVM）垃圾回收性能的算法，最初从CMS（Concurrent Mark-Sweep）垃圾收集器引入并发标记的概念。它通过引入并发标记来解决在垃圾收集过程中引用关系链可能会改变的问题。

该算法将对象的状态分为三种颜色：黑色、灰色和白色。

• 黑色：表示对象已被标记，且对象下的所有属性也都已被标记，例如GCRoots对象。
• 灰色：表示对象已被垃圾收集器扫描，但对象中仍存在未被扫描的引用，需要从该对象中寻找垃圾。
• 白色：表示对象尚未被垃圾收集器访问，即表示不可达。

三色标记的过程如下：

1. 初始时，将GC Roots直接关联的对象置为黑色。
2. 将黑色对象直接引用的对象置为灰色。
3. 遍历灰色对象的所有引用，将灰色对象本身置为黑色，其引用置为灰色。
4. 重复步骤3，直到没有灰色对象为止。
5. 最终，存活的对象为黑色，白色对象将被回收。

然而，并发标记的过程中，用户线程仍在运行，可能导致漏标和错标的情况。

漏标

• 漏标指的是在扫描过程中，用户线程修改了对象的引用关系，使得本应该被回收的对象被误标记为存活，最终导致垃圾回收不及时。

• 例子：

  假设 GC 已经在遍历对象 B 了，而此时用户线程执行了 A.B=null 的操作，切断了 A 到 B 的引用；本来执行了 A.B=null 之后，B、D、E 都可以被回收了，但是由于 B 已经变为灰色，它仍会被当做存活对象，继续遍历下去。最终的结果就是本轮 GC 不会回收 B、D、E，留到下次 GC 时回收，也算是浮动垃圾的一部分。

错标

• 错标指的是在扫描过程中，用户线程修改了对象的引用关系，使得本应该被保留的对象被错误标记为垃圾，最终导致程序运行错误。

• 例子：

  

  假设 GC 线程已经遍历到 B 了，此时用户线程执行了以下操作：

     B.D=null;//B 到 D 的引用被切断
  
     A.xx=D;//A 到 D 的引用被建立
  

  B 到 D 的引用被切断，且 A 到 D 的引用被建立。

  此时 GC 线程继续工作，由于 B 不再引用 D 了，尽管 A 又引用了 D，但是因为 A 已经标记为黑色，GC 不会再遍历 A 了，所以 D 会被标记为白色，最后被当做垃圾回收。

解决错标的问题——原始快照和增量更新

错标的结果比漏表严重的多，浮动垃圾可以下次 GC 清理，而把不该回收的对象回收掉，将会造成程序运行错误。

错标只有在满足下面两种情况下才会发生：

• 灰色对象指向白色对象的引用全部被断开

• 黑色对象建立指向白色对象的引用

  

解决错标的问题的方法有两种：原始快照和增量更新：

• 原始快照：当灰色对象指向白色对象的引用被断开时，记录这些引用关系。当扫描结束后，以这些灰色对象为根，重新扫描一次。

• 增量更新：当黑色对象建立指向白色对象的引用时，记录这些新的引用关系。当扫描结束后，以这些记录中的黑色对象为根，重新扫描一次。相当于一旦黑色对象建立了指向白色对象的引用，就将其标记为灰色对象。

总结

• CMS 为了让 GC 线程和用户线程一起工作，回收的算法和过程比以前旧的收集器要复杂很多。究其原因，就是因为 GC 标记对象的同时，用户线程还在修改对象的引用关系。因此 CMS 引入了三色算法，将对象标记为黑、灰、白三种颜色的对象，将用户线程修改的引用关系记录下来，以便在重新标记阶段可以修正对象的引用。

• 虽然 CMS 从来没有被 JDK 当做默认的垃圾收集器，存在很多的缺点，但是它开启了「GC 并发收集」的先河，为后面的收集器提供了思路。

16.2 G1（Garbage First）回收器

既然我们已经有了前面几个强大的 GC，为什么还要发布 Garbage First（G1）GC？

• 原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC 就不能保证应用程序正常进行，而经常造成 STW 的 GC 又跟不上实际的需求，所以才会不断地尝试对 GC 进行优化。G1（Garbage-First）垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一.

• 与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。

• 官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。

• G1 是一款面向服务端应用的垃圾收集器。

为什么名字叫做 Garbage First（G1）呢？

• 因为 G1 是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的逻辑上连续的）。使用不同的 Region 来表示 Eden、幸存者0 区，幸存者 1 区，老年代等。

• G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region.

• 由于这种方式的侧重点在于回收垃圾价值最大的区间（Region），所以我们给 G1 一个名字：垃圾优先（Garbage First）。

  

垃圾回收过程

如下图所示，G1 收集器收集器收集过程有初始标记、并发标记、最终标记、筛选回收，和 CMS 收集器前几步的收集过程很相似：

• 初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，需要停止用户线程，单线程执行。

• 并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活对象，这个阶段耗时较长，但可以和用户线程并发执行。

• 最终标记：修正在并发标记阶段引用户程序执行而产生变动的标记记录。

• 筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来指定回收计划（用最少的时间来回收包含垃圾最多的区域.这就是 Garbage First 的由来——第一时间清理垃圾最多的区块），这里为了提高回收效率，并没有采用和用户线程并发执行的方式，而是停顿用户线程。

  

优点

1. 可预测的停顿时间：G1致力于提供可预测的停顿时间，这对于需要高可用性和低延迟的应用程序非常重要。

2. 高效的内存利用：通过区域化的内存管理和混合收集，G1能够更加高效地利用内存，从而降低了内存碎片化的风险。

3. 并发标记：G1的并发标记机制可以减少应用程序的停顿时间，提高了系统的吞吐量和响应速度。

4. 自适应调整：G1能够根据实际情况动态调整自身的行为，以适应不同的系统资源和应用程序负载。

适用场景

要求尽可能可控 GC 停顿时间；内存占用较大的应用。

相关设置

默认垃圾回收器信息:

• 命令: -XX:+PrintCommandLineFlags -version

• -XX:InitialHeapSize=263937920 -XX:MaxHeapSize=4223006720 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 
  java version "1.8.0_351"
  Java(TM) SE Runtime Environment (build 1.8.0_351-b10)
  Java HotSpot(TM) 64-Bit Server VM (build 25.351-b10, mixed mode)
  

• JDK 8 默认的垃圾回收器:

  • 年轻代使用 Parallel Scavenge GC
  • 老年代使用 Parallel Old GC

垃圾回收详细信息打印:

• 命令: -XX:+PrintGCDetails -version

设置默认垃圾回收器:

Serial 回收器:

• -XX:+UseSerialGC
  • 年轻代使用 Serial GC
  • 老年代使用 Serial Old GC

ParNew 回收器:

• -XX:+UseParNewGC
  • 年轻代使用 ParNew GC
  • 不影响老年代

CMS 回收器:

• -XX:+UseConcMarkSweepGC
  • 老年代使用 CMS GC

G1 回收器:

• -XX:+UseG1GC
  • 手动指定使用 G1 收集器执行内存回收任务

G1 回收器配置:

• -XX:G1HeapRegionSize
  • 设置每个 Region 的大小

17. 执行引擎（Execution Engine）

Java 虚拟机（JVM）执行引擎是 Java 虚拟机的核心组件之一，负责将 Java 字节码转换为机器码并执行程序。执行引擎通常包含解释器和即时编译器两种执行方式。

1. 解释器（Interpreter）： 字节码（逐条） --> 机器码

解释器逐条解释执行 Java 字节码，将字节码翻译成对应平台的机器指令，然后由处理器执行。解释器的优点是简单、易于实现，适用于快速启动和简单测试。然而，解释执行通常速度较慢，因为它需要动态地将每条字节码翻译为机器码。

2. 即时编译器（Just-In-Time Compiler，JIT）： 字节码（一次性） --> 机器码

即时编译器将字节码编译成本地机器码，以提高执行速度。JIT 编译器可以选择性地将频繁执行的热点代码编译成机器码，而不是每次都解释执行。这种方式可以显著提高程序的性能，尤其是对于密集计算型和性能敏感的应用程序。

在实际中，JVM 的执行引擎通常会结合解释器和即时编译器两种执行方式，称为混合模式执行。在程序启动时，解释器可以快速地启动并执行字节码，同时即时编译器会监视程序的执行情况，并且根据一定的触发条件对热点代码进行即时编译，从而提高程序的整体性能。

另外，现代的 JVM 还可以使用 Ahead-Of-Time（AOT）编译器，预先将整个应用程序编译成本地机器码，以减少启动时间和减少运行时的开销。这种方式适用于一些对启动时间和运行时性能要求较高的场景，例如移动设备、嵌入式系统等。

综上所述，JVM 执行引擎通过解释器和即时编译器的组合，以及可能的 AOT 编译器，实现了 Java 程序的高效执行，并且在性能和启动时间之间做出了权衡。

3. 执行引擎除了包括解释器和即时编译器外，还包括垃圾回收器（Garbage Collector，GC），它是 Java 虚拟机（JVM）中的另一个核心组件。

前端编译 VS 执行引擎的解释、编译执行

1. 前端编译：从 Java 程序员-字节码文件的这个过程叫前端编译.
2. 执行引擎这里有两种行为：一种是解释执行，一种是编译执行（这里的是后端编译）。

什么是解释器？什么是 JIT 编译器？有什么不同的地方？

1. 解释器（Interpreter）： 字节码（逐条） --> 机器码

2. 即时编译器（Just-In-Time Compiler，JIT）： 字节码（一次性） --> 机器码

3. 区别

• 执行方式： 解释器逐行解释源代码并立即执行，而 JIT 编译器在运行时将源代码或中间表示编译成机器代码，然后执行编译后的机器代码。

• 性能： 通常情况下，JIT 编译器的性能优于解释器，因为它将代码编译成机器代码，避免了解释器逐行解释的性能开销。JIT 编译器的优化也能够更好地利用硬件特性和程序的执行路径，从而进一步提高性能。

• 启动时间： 解释器通常比 JIT 编译器具有更快的启动时间，因为解释器不需要额外的编译步骤。然而，一旦 JIT 编译器完成了编译，后续执行会更快。

• 内存使用： 解释器通常需要更少的内存，因为它只需要存储源代码或中间表示，并逐行解释执行。相比之下，JIT 编译器需要存储编译后的机器代码，可能会占用更多的内存空间。

为什么 Java 是半编译半解释型语言？

• Java 最初被定位为“解释执行”，随后发展出可以直接生成本地代码的编译器。
• JVM（Java 虚拟机）在执行 Java 代码时通常会将解释执行与编译执行结合起来。
• JVM 设计者们的初衷是为了满足 Java 程序实现跨平台特性，避免采用静态编译方式，即由高级语言直接生成本地机器指令。因此，实现了解释器在运行时逐行解释字节码执行程序的想法。

解释器与 JIT 编译器的作用和原理

• 解释器是一个运行时“翻译者”，将字节码文件中的内容翻译为对应平台的本地机器指令执行，但执行效率较低。
• JIT（Just-In-Time）编译器将字节码翻译成本地代码，并将其缓存存储在方法区的 JIT 代码缓存中，执行效率更高。
• JIT 编译器根据代码被调用执行的频率决定是否需要将字节码编译为本地机器指令。对于频繁调用的“热点代码”，JIT 编译器会进行深度优化，提升 Java 程序的执行性能。

解释器和 JIT 编译器的协同作用

• 解释器在程序启动后可以立即发挥作用，响应速度快，省去编译的时间，立即执行。
• 编译器需要一定的执行时间将代码编译成本地代码，但编译后的代码执行效率高。
• 为了在执行速度和响应速度之间取得平衡，Java 使用解释器与 JIT 编译器并存的架构。解释器可以立即执行代码，而编译器则将代码编译为本地代码以提升执行效率。

18. JMM(Java Memory Model)

内存结构（不是JMM）：

• 在Java内存模型中，描述了在多线程代码中，哪些行为是正确的、合法的，以及多线程之间如何进行通信，代码中变量的读写行为如何反应到内存、CPU缓存的底层细节。

• 在Java中包含了几个关键字：volatile、final和synchronized，帮助程序员把代码中的并发需求描述给编译器。Java内存模型中定义了它们的行为，确保正确同步的Java代码在所有的处理器架构上都能正确执行。

• 缓存一致性

  • 但是随着cpu的发展，内存的读写速度也远远赶不上cpu。因此cpu厂商在每颗cpu上加上高速缓存，用于缓解这种情况。现在cpu和内存的交互大致如下。

  • cpu上加入了高速缓存这样做解决了处理器和内存的矛盾(一快一慢)，但是引来的新的问题 - 缓存一致性

  • 在多核cpu中，每个处理器都有各自的高速缓存(L1,L2,L3)，而主内存确只有一个

• 如何保证数据一致性——缓存一致性协议

  

• JMM(Java 内存模型)主要定义了对于一个共享变量，当另一个线程对这个共享变量执行写操作后，这个线程对这个共享变量的可见性。

• CPU缓存模型

  

• 指令重排序：

  • 编译器优化重排（JVM、JIT 编译器等） —> 指令并行重排 —> 内存系统重排

  • 指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致

  • 编译器和处理器（指令并行重排和内存系统重排）的处理

    • 对于编译器，通过禁止特定类型的编译器重排序的方式来禁止重排序

    • 对于处理器，通过插入内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）的方式来禁止特定类型的处理器重排序

• 内存屏障（Memory Barrier）

  • 确保对共享内存的操作顺序和可见性

  • 读屏障（Read Barrier）

    • 读屏障确保在读取共享内存时，先要保证之前的写操作对于当前线程是可见的。这可以防止读取到过期或无效的数据。

  • 写屏障（Write Barrier）

    • 写屏障则确保在写入共享内存时，先要保证之前的写操作已经对其他线程可见。这可以防止写入的数据被缓存在本地，而没有及时刷新到共享内存中，导致其他线程无法看到最新的数据。

1. 什么是JMM？

• JMM：（Java Memory Model的缩写）
• 把 JMM 看作是 Java 定义的并发编程相关的一组规范，除了抽象了线程和主内存之间的关系之外，其还规定了从 Java 源代码到 CPU 可执行指令的这个转化过程要遵守哪些和并发相关的原则和规范，其主要目的是为了简化多线程编程，增强程序可移植性的。

2. Java 内存区域和 JMM 有何区别

Java 内存区域和内存模型是完全不一样的两个东西：

• JVM 内存结构和 Java 虚拟机的运行时区域相关，定义了 JVM 在运行时如何分区存储程序数据，就比如说堆主要用于存放对象实例。
• Java 内存模型和 Java 的并发编程相关，抽象了线程和主内存之间的关系就比如说线程之间的共享变量必须存储在主内存中，规定了从 Java 源代码到 CPU 可执行指令的这个转化过程要遵守哪些和并发相关的原则和规范，其主要目的是为了简化多线程编程，增强程序可移植性的。

3. 他干嘛的？官方，其他人的博客，对应的视频！

• 作用：缓存一致性协议，用于定义数据读写的规则(遵守，找到这个规则)。

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

• Java 内存模型定义来以下八种同步操作

  • 锁定（lock）: 作用于主内存中的变量，将他标记为一个线程独享变量。

  • 解锁（unlock）: 作用于主内存中的变量，解除变量的锁定状态，被解除锁定状态的变量才能被其他线程锁定。

  • read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load 动作使用。

  • load(载入)：把 read 操作从主内存中得到的变量值放入工作内存的变量的副本中。

  • use(使用)：把工作内存中的一个变量的值传给执行引擎，每当虚拟机遇到一个使用到变量的指令时都会使用该指令。

  • assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

  • store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的 write 操作使用。

  • write（写入）：作用于主内存的变量，它把 store 操作从工作内存中得到的变量的值放入主内存的变量中。

• JMM对这八种指令的使用，制定了如下规则：（java内存模型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的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，使用java的happen-before规则来进行分析。

• happens-before 原则

• 区分事件发生的前后顺序, 更想表达的意义是前一个操作的结果对于后一个操作是可见的，无论这两个操作是否在同一个线程里

• 设计思想

  • 为了对编译器和处理器的约束尽可能少，只要不改变程序的执行结果（单线程程序和正确执行的多线程程序），编译器和处理器怎么进行重排序优化都行。

  • 对于会改变程序执行结果的重排序，JMM 要求编译器和处理器必须禁止这种重排序。

• happens-before 常见规则（8条）

  如果两个操作不满足上述任意一个 happens-before 规则，那么这两个操作就没有顺序的保障，JVM 可以对这两个操作进行重排序。

  1. 程序顺序规则：一个线程内，按照代码顺序，书写在前面的操作 happens-before 于书写在后面的操作；

  2. 解锁规则：解锁 happens-before 于加锁；

  3. volatile 变量规则：对一个 volatile 变量的写操作 happens-before 于后面对这个 volatile 变量的读操作。说白了就是对 volatile 变量的写操作的结果对于发生于其后的任何操作都是可见的。

  4. 传递规则：如果 A happens-before B，且 B happens-before C，那么 A happens-before C；

  5. 线程启动规则：Thread 对象的 start()方法 happens-before 于此线程的每一个动作。

• 并发编程三个重要特性

  1. 原子性（Atomicity）：
  • 原子性指的是一个操作是不可中断的整体，要么全部执行成功，要么全部不执行，不存在中间状态。在 Java 中，可以通过 synchronized 关键字、各种 Lock（如 ReentrantLock）以及各种原子类（如 AtomicInteger）来实现原子性操作。
  • synchronized 和 Lock 可以保证在同一时刻只有一个线程可以访问关键代码段，从而保证了原子性。
  • 原子类利用 CAS 操作（比较并交换）来保证原子性，其中可能也会使用 volatile 或 final 关键字来辅助实现。
  2. 可见性（Visibility）：
  • 可见性指的是当一个线程修改了共享变量的值时，其他线程能够立即看到修改后的最新值。在 Java 中，可通过 synchronized、volatile 和 Lock 来实现可见性。
  • 使用 volatile 关键字可以告诉 JVM，该变量是共享且不稳定的，需要每次都从主存中读取，从而确保了可见性。
  3. 有序性（Ordering）：
  • 有序性指的是程序执行的顺序与编写时的顺序一致，不会因为指令重排序而导致逻辑错误。在 Java 中，可通过 volatile 关键字来禁止指令重排序优化，从而保证有序性。

19. 调优

• 为了减少 Full GC 的频率，可以将元空间大小 -XX:MetaspaceSize 设置为较高的值。

参考

Java方法区、永久代、元空间、常量池详解_java永久地址-CSDN博客

狂神说笔记——JVM入门07 - subeiLY - 博客园

java内存模型JMM理解整理 - 阿姆斯特朗回旋炮 - 博客园

JVM（Java虚拟机）-史上最全、最详细JVM笔记-CSDN博客

什么是Java内存模型 - 简书

深入理解JVM-内存模型（jmm）和GC - 简书

JVM 方法区和元空间什么关系？为什么要将永久代替换为元空间？-CSDN博客

JVM 垃圾清理 标记-清除算法 常量池移除问题 · Issue #747 · Snailclimb/JavaGuide · GitHub

JMM（Java 内存模型）详解 | JavaGuide