JVM学习

JVM规范 The Java Virtual Machine Specification

HotSpot实现 hotspot

引言

什么是 JVM

Java Virtual Machine - java 程序的运行环境(java 二进制字节码的运行环境)

好处

一次编写，到处运行
自动内存管理，垃圾回收功能(屏蔽了指针)
数组下标越界检查(C语言是没有的，越界直接进行覆盖了)
多态

比较

jvm jre jdk 这里 JavaGuide 讲的很详细

JVM 是 Java虚拟机，是运行Java字节码的虚拟机。Java 程序通过编译器生成字节码文件，然后经过JVM解释器生成机器码进行执行。不同的系统(Linux、Windows、macOS)有不同的虚拟机实现，目的是让相同的字节码文件能在不同的机器上产生相同的结果。字节码和不同系统的JVM实现是Java语言一次编译、随处运行的关键所在。

JDK 是一个开发工具包，让开发者使用，用来创建和编译Java程序，它包含JRE以及编译器javac和一些其他工具，比如 javadoc,javap(反编译工具)。

JRE 是运行已编译Java程序所需要的环境，主要包含 JVM、Java基础类库。

整体来说

JDK
- JRE
  - JVM 负责跑程序
  - Java 核心类库
- Java开发工具(javac,javap,javadoc,jar)

不过从Java9之后引入了模块化，不再提供独立的 JRE 安装包

常见的 JVM

只要遵从 JVM 规范，我们自己也可以写 JVM，上面是常见的 JVM，比较常用的是 HotSpot 和 OpenJDK。这两个都免费，Oracle JDK 要收费的。下面讲解都是基于 HotSpot JVM。

学习路线

如下图，JVM主要包括三个部分：类加载器，JVM内存结构与执行引擎。一个类经过编译后，必须有类加载器进行加载。类被放在方法区，类的实例对象则被放在堆中，堆中对象在调用方法时会用到虚拟机栈、程序计数器和本地方法栈。方法执行时，每行代码由执行引擎中的程序解释器解释执行，方法中的热点代码(频繁调用)会由JIT即时编译器进行优化编译，GC则负责对堆中不再被引用的对象进行垃圾回收。有时JVM还需要与操作系统进行交互，本地方法接口负责这一职责。

内存结构

程序计数器

作用

Program Counter Register 程序计数器（寄存器实现）

记住下一条jvm指令的执行地址

Java 源代码先通过 javac 编译成 .class 字节码文件，字节码本身就是 JVM 指令的二进制表示。JVM 加载类之后，由执行引擎执行字节码。执行方式有两种：解释器逐条解释执行，或者 JIT 编译器把热点代码编译成本地机器码后交给 CPU 执行。每个 Java 线程都有自己独立的程序计数器，用来记录当前线程下一条要执行的字节码指令地址。当线程失去 CPU 后，再次获得 CPU 时，JVM 可以根据该线程自己的程序计数器继续执行。

Java 程序运行时，程序计数器记录当前线程执行到哪条 JVM 字节码；解释器根据程序计数器取出字节码指令，把它翻译成机器码，最后由 CPU 执行。

{% note danger %}

执行完一个字节码指令后，JVM 程序计数器会改变，但不是 CPU 直接改的，而是 JVM 解释器/JIT 运行时维护的。CPU 直接改变的是它自己的硬件程序计数器。

{% endnote %}

特点
- 是线程私有的，每一个线程都有自己的程序计数器，记录当前线程的代码执行到哪里了
- 虚拟机中唯一一个不会存在内存溢出的部分

虚拟机栈

介绍

JVM 栈是线程运行时需要的一块私有内存，每个线程都有自己的 JVM 栈。

Java 程序启动后，会创建一个主线程，它有自己的JVM栈。主线程执行 main 方法的时候，会为它创建一个栈帧并且压入栈
调用 new Thread().start() 后，新线程启动，也会拥有自己的线程栈。
每调用一个方法，JVM 都会创建一个栈帧并压入当前线程的栈中。

栈帧中主要保存局部变量表、操作数栈、动态链接和方法返回信息。方法执行完成后，对应栈帧出栈，调用者栈帧重新成为当前活动栈帧，程序计数器继续指向调用点之后的下一条字节码指令。

局部变量表(包括参数、局部变量，如果是成员方法还会有隐藏的 this)
操作数栈(JVM执行字节码时临时用来计算的地方)
动态链接(每个栈帧中保存了一个指向运行时常量池的引用，用来在方法执行过程中，把字节码里的符号引用解析成真正可以访问的类、方法、字段引用)
比如字节码写的 调用 #5，然后动态链接帮你找到 #5 是谁，比如 Student.sayHello()，然后真正定位到这个方法去执行。
方法返回信息(返回后回到调用者哪里继续执行)
1. 当前方法是正常返回，还是异常结束
2. 如果有返回值，返回值是什么
3. 当前方法返回后，应该回到调用者的哪里继续执行
4. 恢复哪个调用者栈帧
5. 返回值要不要压回调用者的操作数栈

{% note warning no-icon %}

当 main 调用了 method1 方法之后，到底是怎么恢复？是 method1 给下一条指令地址，还是 main 自己找？还是其他什么？

执行方法调用指令时，JVM 就已经知道"当前方法返回后应该回到哪里继续执行"。被调用方法返回后，JVM 恢复调用者栈帧，并让当前线程的程序计数器指向调用指令后面的下一条字节码。也就是说既不是 main 来做也不是 method1 来做，也不是程序计数器来做，而是JVM的执行引擎来做。

JVM 在执行调用 method1() 的时候，会保存返回所需的信息。这些信息保存在 method1 栈帧中。等 method1 执行完后 (执行了return)，JVM 根据这些返回信息恢复调用者 main 的栈帧，并更新PC，让当前线程的 PC 指向 main 中调用指令之后的下一条字节码。其实这些执行完之后才让 method1 出栈！！！

比如代码

java 复制代码

public static void main(String[] args) {
    method1();
    int x = 10;
}

public static void method1() {
    System.out.println("method1");
}

字节码大概是

java 复制代码

0: invokestatic #method1
3: bipush 10
5: istore_1
6: return

流程

txt 复制代码

main() 调用 method1()
        ↓
JVM 保存调用者 main() 的执行状态(意思就是 method1 返回后，要回到 main 中 invokestatic 后面的下一条指令，也就是 3 号位置)
        ↓
method1 栈帧入栈
        ↓
PC 指向 method1 的第一条字节码
        ↓
method1 执行完 return
        ↓
method1 栈帧出栈
        ↓
main 栈帧恢复活动
        ↓
PC 被设置/恢复到 3

程序计数器不是一个"会主动读东西的对象"。

不是程序计数器自己去读下一条地址，而是 JVM 执行引擎在执行字节码的过程中不断更新程序计数器。方法调用时保存返回位置，方法返回时恢复到那个位置。

{% endnote %}

每个线程同一时刻只能有一个当前活动栈帧，也就是栈顶栈帧。

在 IDEA 中可以查看栈帧和栈帧变量信息

问题解析

垃圾回收是否涉及栈内存？

垃圾回收不会涉及栈内存，因为栈的栈帧会随着方法调用而入栈，随着方法结束而出栈，无需进行垃圾回收。

对，确实，栈帧内存不用GC回收；但是GC还会扫描栈帧里的对象引用，因为栈帧内部的对象引用属于局部变量，属于栈帧，但是申请的对象是在堆里的，栈帧内存释放了，但是堆的还没有，这一部分GC来做，所以GC发现没人指向它，才会释放。

你可能好奇，那为啥不释放栈帧的时候一块把对应堆的对象释放了？

栈帧能自动释放，是因为方法结束后这个栈帧一定没用了；堆对象不能顺手释放，是因为方法结束不代表对象没用了。

对象可能被返回给调用者(作为返回值)
对象可能被存储到别的对象里(比如在这个方法里面把这个局部变量放进了一个全局变量里面)
变量逃逸(在这个方法里面这个对象被其他线程引用，在JUC里面会介绍)

如果每次释放栈帧都检查一次对象是不是没有被人引用那性能消耗太大了

栈内存分配越大越好吗？

栈的大小可以进行设置。可以通过JVM参数设置 -Xss1m，1m 指代大小，Xss 中到 ss 可以理解为 Stack size。

在 IDEA 中可以配置
这个 -ea 是开启断言测试，也就是 assert，跟 -Xss1m 没关系哈，不用管。
线程栈越大则可以进行嵌套调用的方法层级越多，比如递归(如果栈空间不够了，会报 StackOverflowError)，但是并不会变快，所以需要在合理区间，不是越大越好。
因为计算机的物理内存是有限的，线程中栈的大小设置的越大，可以容纳的线程数就会越少(每个线程都有自己的栈)。一般采用系统默认的栈内存大小即可。

比如有 100MB 内存，设置 -Xss1m 那最多能有 100 个线程。如果设置 -Xss512k，那最多可以有 200 个线程。
栈内存是提前分配好的，但是栈帧大小不是固定的，不同方法栈帧大小不一样，复杂点栈帧可能就大。

方法内的局部变量是否线程安全？

如果方法内局部变量没有逃离方法的作用访问，它是线程安全的
如果是局部变量引用了对象，并逃离方法的作用范围，需要考虑线程安全

这个在 JUC 里面会详细讲

java 复制代码

// 多个线程都执行 m1 方法
static void m1() {
    int x = 0;
    for (int j = 0; j < 500; j++) {
        x++;
    }
}

这种情况下不会有线程安全问题，因为每个栈都有独立的栈空间，调用 m1() 方法时，每个线程都有自己的栈帧，都有互不干扰的 i 变量，不会有线程安全问题。

java 复制代码

static int x = 0;

// 多个线程都执行 m1 方法
static void m1() {
    for (int j = 0; j < 500; j++) {
        x++;
    }
}

这个时候就不是线程安全了，为啥因为我线程 A 和线程 B 都在读取和修改 x。

{% note info no-icon %}

为啥对 static int x 的修改，在多线程下是不安全的？

本质原因是因为 x++; 操作不是原子性的。它是被拆解成四个指令的

bash 复制代码

getstatic     x      // 读取静态变量 x
iconst_1             // 准备常量 1
iadd                 // x + 1
putstatic    x       // 把结果写回静态变量 x

也就是说我可能执行了两个指令就上下文切换切走了，另一个线程也来执行 x++，它读到的还是旧值，最后两个线程都把同一个结果写回去，导致其中一次自增丢失。

{% endnote %}

java 复制代码

static void m1() {
    StringBuilder sb = new StringBuilder();
    sb.append("a");
    sb.append("b");
    sb.append("c");
    System.out.println(sb.toString());
}

这个方法是线程安全的，里面的 sb 对象只在当前方法内，没有逃逸

java 复制代码

static void m2(StringBuilder sb) {
    sb.append("a");
    sb.append("b");
    sb.append("c");
    System.out.println(sb.toString());
}

这个方法就是线程不安全的了，因为 sb 作为参数传递进来，那就有可能有两个线程同时用一个 StringBuilder 对象

java 复制代码

StringBuilder sb = new StringBuilder();

new Thread(() -> m2(sb)).start();
new Thread(() -> m2(sb)).start();

比如这样，就存在同时修改的问题，存在线程不安全问题。因为 sb 对象放在堆里面，这两个线程都调用 m2(sb)，就和前面那个 static int x 是一样的，两个线程存在同时修改它的风险。

{% note danger no-icon %}

为啥 StringBuilder 线程不安全呢？

因为它内部维护了可变的字符数据和长度，比如可以粗略理解成：

java 复制代码

char[] value;
int count;

执行：

java 复制代码

sb.append("a");

不是一步完成的，它内部大概需要做这些事：

判断容量够不够
把字符写入内部数组
修改 count 长度

这些操作不是原子的，也没有加锁。所以就可能出现很多问题。所以想要线程安全，要么考虑自己加锁，要么用 StringBuffer，就是性能稍微差点

{% endnote %}

同样的，下面这个也是线程不安全的

java 复制代码

static void m3() {
	StringBuilder sb = new StringBuilder();
    sb.append("a");
    sb.append("b");
    sb.append("c"); // 内部是安全的，因为只要调用这个方法就会创建一个新的 sb, 不会有多个线程修改 sb 的问题
    return sb;
}

sb 返回后可能被多个线程引用去 append。

java 复制代码

StringBuilder sb = m3();

new Thread(() -> sb.append("d")).start();
new Thread(() -> sb.append("e")).start();

栈内存溢出

出现的情况

栈帧过多导致栈内存溢出，比如说方法的递归调用
栈帧过大导致栈内存溢出，一般较少出现，因为栈大小一般挺大，比如 1Mb，栈帧一般就存放一些参数、局部变量等一些其他东西，占用的内存相对较少

我们可以编写一个递归调用的示例

java 复制代码

public class Demo_1 {
    private static int count;

    public static void main(String[] args) {
        try {
            method1();
        } catch (Throwable e) {
            e.printStackTrace();
            System.out.println(count);
        }
    }

    private static void method1() {
        count++;
        method1();
    }
}

报错，可以看到总共调用了 46460 次

bash 复制代码

java.lang.StackOverflowError
	at com.lh.Demo_1.method1(Demo_1.java:17)
	....
	at com.lh.Demo_1.method1(Demo_1.java:17)
	at com.lh.Demo_1.method1(Demo_1.java:17)
46460

可以减小一下栈帧大小，看看调用次数是不是减少，比如设置 -Xss256k

这个时候再跑一下，就只会调用 1479 次了。

线程运行诊断

虚拟机栈占用过多CPU

java 复制代码

/**
 * 演示 cpu 占用过高
 */
public class Demo04 {

    public static void main(String[] args) {
        new Thread(null, () -> {
            System.out.println("1...");
            while(true) {

            }
        }, "thread1").start();


        new Thread(null, () -> {
            System.out.println("2...");
            try {
                Thread.sleep(1000000L);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }, "thread2").start();

        new Thread(null, () -> {
            System.out.println("3...");
            try {
                Thread.sleep(1000000L);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }, "thread3").start();
    }
}

这里我只讲述在 macOS 系统下怎么运行这个代码并且查看CPU占用等，Linux、Windows 下查看类似命令就可以。

bash 复制代码

(base) ice@jimodebingkeledeMac-mini ~ % cd Desktop/cola/code/Java/JVM/src/main/java # 进入目录
(base) ice@jimodebingkeledeMac-mini java % javac com/lh/Demo04.java # 编译
(base) ice@jimodebingkeledeMac-mini java % java com.lh.Demo04 & # 后台运行并拿到进程 PID
[1] 10760
(base) ice@jimodebingkeledeMac-mini java % 1...
2...
3...

(base) ice@jimodebingkeledeMac-mini java % top -pid 10760 # 查看进程 CPU 占用

bash 复制代码

jstack 10760 # 查看进程下的线程信息

可以看到进程的信息，除了JVM虚拟机本身的一些进程之外，这个 thread1、thread2、thread3 都是咱们自己的，然后可以看到 thread1 正在运行，并且指出了在运行哪一行代码。
这里面 tid 代表JVM内部线程标识，nid 代表操作系统线程ID，都是十六进制表示的

macOS 不支持 ps 来查看线程名和 tid 字段，，，Linux 可以。

这里可以看到有个线程 %CPU=100.0 且 STAT=R

bash 复制代码

(base) ice@jimodebingkeledeMac-mini java % kill 10760 # 杀死进程
(base) ice@jimodebingkeledeMac-mini java % 
[1]  + exit 143   java com.lh.Demo04

{% note warning %}

不能直接杀死线程，只能杀进程。。。

{% endnote %}

{% note danger no-icon %}

正常 RUNNABLE 和异常 RUNNABLE 的区别

它 %CPU=99，STAT=R，怎么就知道它有问题呢？

正常情况：

线程 RUNNABLE
CPU 高一会儿，任务执行完就下降
栈位置会变化

异常情况：

线程 RUNNABLE
CPU 长时间很高
多次 jstack 看到它一直卡在同一段代码

比如 while(true)、死循环、频繁重试、复杂计算

{% endnote %}

线程死锁的排查

有的时候运行一个程序迟迟没有结果，可能是出现了死锁，下面演示一下

java 复制代码

package com.lh;

/**
 * 演示线程死锁
 */
class A{};
class B{};
public class Demo05 {
    static A a = new A();
    static B b = new B();


    public static void main(String[] args) throws InterruptedException {
        new Thread(()->{
            synchronized (a) {
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (b) {
                    System.out.println("我获得了 a 和 b");
                }
            }
        }).start();
        Thread.sleep(1000);
        new Thread(()->{
            synchronized (b) {
                synchronized (a) {
                    System.out.println("我获得了 a 和 b");
                }
            }
        }).start();
    }

}

bash 复制代码

(base) ice@jimodebingkeledeMac-mini ~ % cd Desktop/cola/code/Java/JVM/src/main/java # 进入目录
(base) ice@jimodebingkeledeMac-mini java % javac com/lh/Demo05.java # 编译
(base) ice@jimodebingkeledeMac-mini java % java com.lh.Demo05 & # 后台运行并返回进程ID
[1] 14569
(base) ice@jimodebingkeledeMac-mini java % jstack 14569 # 查看信息

在最后有这样一段信息

可以看到先说发现了一个死锁

然后下面详细信息说 Thread-0 正在等待一个 B 锁，锁的地址是 0x000000061fc1c6d0，自己锁住了一个 A 锁，地址是 0x000000061fc1bad0。并且也展示了代码的位置

txt 复制代码

"Thread-0":
	at com.lh.Demo05.lambda$main$0(Demo05.java:22)
"Thread-1":
	at com.lh.Demo05.lambda$main$1(Demo05.java:30)

也就知道程序发生了死锁。通常情况下我们只能杀掉整个Java进程来结束死锁，并且修正代码防止再出现死锁。

bash 复制代码

(base) ice@jimodebingkeledeMac-mini java % kill 14569
(base) ice@jimodebingkeledeMac-mini java % 
[1]  + exit 143   java com.lh.Demo05

本地方法栈

本地方法是用 native 修饰的方法，它没有 Java 方法体，真正实现通常由 C/C++ 等非 Java 语言完成。

当 Java 执行到这个 hashCode() 时，真正进入的是底层的 C/C++ 函数。
java 复制代码
```
public class Object {
    public native int hashCode(); // 本地方法
}
```
为什么存在本地方法？这些方法通常是Java自己做不了或者不适合用Java做
本地方法除了直接调用操作系统 API，也可能是操作 JVM 底层内部结构，比如对象头、锁、线程等待唤醒、运行时类型信息等。
当 Java 程序调用 native 方法时，JVM 会进入对应的本地代码执行。本地代码执行过程中也需要参数、局部变量、返回地址等运行空间，因此 JVM 规范中定义了本地方法栈，用来为 native 方法服务。

Java 方法执行时用 JVM 栈，本地方法执行时可能使用本地方法栈
Object 类中就有很多 native 方法，比如 getClass()、hashCode()、clone()、wait()、notify()、notifyAll() 等。

堆

前面说的程序计数器、虚拟机栈、本地方法栈都是线程私有的，而堆以及后面的方法区都是线程共享的。

定义

通过 new 关键字，创建对象都会使用堆内存

特点

它是线程共享的，堆中对象都需要考虑线程安全的问题
有垃圾回收机制

堆内存溢出

堆中具有垃圾回收机制，但是垃圾回收的前提是堆中的对象不再被引用，因此如果我们有过多无法被回收的对象，就可能导致堆内存溢出。

java 复制代码

public class MemoryOverFlow {
    public static void main(String[] args) {
        int i = 0;
        String a = "hello";
        List list = new ArrayList();
        try {
            while (true) {
                list.add(a); // 一直添加数据，直到堆溢出
                a = a + a;
                i++;
            }
        } catch (Throwable e) {
            e.printStackTrace();
            System.out.println(i);
        }

    }
}

可以通过设置参数 -Xmx 来设置堆内存最大大小，比如设置 -Xmx8m

这个时候跑的轮数就少了，更快溢出了

{% note info %}

实际上有 -Xms 和 -Xmx 两种配置

bash 复制代码

-Xms256m   初始堆大小是 256MB
-Xmx1g     最大堆大小是 1GB

{% endnote %}

堆内存诊断

工作中编写了一段代码，怎么判断这段代码对于内存性能的影响呢？可以用下面这些工具

jps 查看当前系统中有哪些 java 进程
jmap 查看瞬时时刻堆内存占用情况 jmap -heap 进程id
jconsole 图形界面的，多功能的监测工具，可以连续监测

通过下面这个 demo 来演示

java 复制代码

public static void main(String[] args) throws InterruptedException {
    System.out.println("1....."); // 输出提示
    Thread.sleep(30000); // 给 30s 时间我们看进程ID + 看看 Heap 情况
    byte [] arr = new byte[1024 * 1024 * 10];
    System.out.println("2.......");
    Thread.sleep(30000);
    arr = null;
    System.gc(); // arr 置空之后代表可以被垃圾回收了，我们再手动 gc 进行回收一下
    System.out.println("3......");
    Thread.sleep(100000L);
}

{% note warning %}

在这里执行 jmap 报错是因为 jdk8 之后的版本不能再使用这个命令了，需要改用命令 jhsdb jmap --heap --pid xxx。

但是在 macOS 上对于这个命令支持不好，所以我们使用命令 jcmd xxx GC.heap_info 来查看信息

{% endnote %}

我们在控制台输出 1 之后，输出 2 之前，执行如下命令

当前提交给JVM使用的堆大小是 520MB，已使用的堆大小是 14MB

控制台输出 2 之后，执行下面命令

堆大小增加了大约 12MB，虽然我们只申请了 10MB，但是对象本身还有对象头、对齐、G1 region 分配等额外影响，所以看到增加 12MB 左右是正常的

控制台输出 3 之后，执行下面命令

可以通过 jcmd xxx VM.flags 查看堆最大大小、初始大小等等信息，列举其中几个

bash 复制代码

(base) ice@jimodebingkeledeMac-mini JVM % jcmd 18101 VM.flags
18101:
-XX:G1HeapRegionSize=4194304 # G1把堆切成每个小块的大小，4MB
-XX:InitialHeapSize=536870912 
-XX:MaxHeapSize=8589934592 
-XX:+UseG1GC

和上面 jcmd xxx GC.heap_info 进行对应

garbage-first heap 代表用的是 G1 垃圾收集器，对应 VM.flags 里面的 -XX:+UseG1GC，G1 的全称就是 garbage-first。
-XX:MaxHeapSize=8589934592 即 8GB，代表最大堆内存大小
total 532480K 代表当前JVM已经提交的堆内存大小，换算一下就是 520 MB，按理来说应该是 512MB，JVM 启动后，G1 根据运行过程、内部策略、对象分配、对齐等原因，当前实际提交堆变成了 520MB。
InitialHeapSize=536870912 512MB JVM 参数里的初始堆大小配置值。

jconsole

也可以用 jconsole 的方法进行堆内存诊断，使用方法就比较简单，直接在终端输入 jconsole 就会自动弹出来

我们选择进程点击连接就可以查看。

上面这个增大缩小的过程分别是我们分配堆内存和GC的过程。

除了内存(还提供了手动GC按钮)，jconsole还可以监测线程、cpu 占用率以及类的数量变化等。

还可以帮我们坚持死锁的情况

多次垃圾回收内存占用仍很高问题的排查

jvisualvm 也是一个可视化工具，比 jconsole 更好用，在命令行输入 jvisualvm 就能用，但是 JDK1.8 之后或者是比较新的JDK1.8不会再自动集成它了，需要手动下载这个软件

macOS 下可以通过 homebrew 下载

bash 复制代码

brew install --cask visualvm

安装好后，我们用如下代码进行演示

java 复制代码

/**
 * 演示查看对象个数 堆转储 dump
 */
public class Demo1_13 {

    public static void main(String[] args) throws InterruptedException {
    	Thread.sleep(30000L);
        List<Student> students = new ArrayList<>();
        for (int i = 0; i < 200; i++) {
            students.add(new Student());
//            Student student = new Student();
        }
        Thread.sleep(1000000000L);
    }
}
class Student {
    private byte[] big = new byte[1024*1024]; // 1MB
}

启动程序后打开软件我们可以选中进程

我们可以看到堆大小的变化，启动后过了一段时间可以看到堆内存确实变大了很多，我们先点击 Preform GC 手动进行 GC 尝试回收堆内存，发现堆也没啥变化。

然后点击 Heap Dump 来获取当前堆大小的快照

右下角点击 view all 可以查看当前占用堆内存的实例对象，最高的是 ArrayList，里面存放了非常多的 Student，每个都还不小

方法区

定义

方法区是 JVM 中所有线程共享的运行时内存区域，在虚拟机启动时创建。
它主要存放已经被 JVM 加载的类型信息，包括类的结构信息、字段信息、方法信息、构造器信息、方法字节码、运行时常量池等。
需要注意的是，方法区中存放的是字段和方法的描述信息，不是每个对象的字段值；对象的实例字段值仍然存放在堆中。
方法区在 JVM 规范中被描述为堆的一个逻辑部分，但具体虚拟机实现可以不同。例如 HotSpot 在 JDK 8 之后使用元空间 Metaspace 来实现方法区，而元空间使用的是本地内存。

Method Area 方法区：JVM 规范里的概念
- PermGen 永久代：JDK 6 HotSpot 对方法区的实现，永久代不在堆里哈，它是方法区的一种实现，和堆、虚拟机栈是同一级别的运行时数据区域
- Metaspace 元空间：JDK 8 HotSpot 对方法区的实现
元空间位于本地内存，也就是前面提到的操作系统层面的内存(Native Memory)，不在 Java 堆里
在JDK6 及之前，字符串常量池的 String 对象在永久代里面，JDK7 之后，字符串常量池中的 String 对象移动到了堆里，这个时候方法区很多东西还和永久代有关系，JDK8 之后永久代就完全被元空间取代
ClassLoader 对象 java.lang.Class 对象本质是对象，放在堆里
java 复制代码
```
Class<?> clazz = User.class; // 指向在堆中
```

详细举例方法区，无论永久代还是元空间，核心都放着

txt 复制代码

类的元信息
├─ 类名
├─ 父类
├─ 接口
├─ 访问修饰符 public / private / abstract 等
├─ 字段信息
├─ 方法信息
├─ 方法字节码
├─ 运行时常量池
├─ 注解信息
├─ 方法表，例如虚方法表
└─ 类加载器相关信息

比如下面这个类

java 复制代码

public class User {
    private String name;

    public void sayHello() {
        System.out.println("hello");
    }
}

永久代/元空间主要存的是

txt 复制代码

User 这个类叫什么
它继承谁
有哪些字段：name
有哪些方法：sayHello()
sayHello() 的字节码是什么
访问权限是什么
常量池里有哪些符号引用

方法区内存溢出

导入依赖

xml 复制代码

<dependency>
    <groupId>org.ow2.asm</groupId>
    <artifactId>asm</artifactId>
    <version>9.9.1</version>
</dependency>

java 复制代码

public class Demo1_8 extends ClassLoader { // 可以用来加载类的二进制字节码
    public static void main(String[] args) {
        int j = 0;
        try {
            Demo1_8 test = new Demo1_8();
            for (int i = 0; i < 10000; i++, j++) {
                // ClassWriter 作用是生成类的二进制字节码
                ClassWriter cw = new ClassWriter(0);
                // 参数含义：版本号， 访问级别为public， 类名, 包名, 父类， 接口
                cw.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
                // 返回 byte[]
                byte[] code = cw.toByteArray();
                // 将 byte[] 字节码加载成 JVM 中的 Class，类元信息会进入方法区的具体实现区域
                test.defineClass("Class" + i, code, 0, code.length);
            }
        } finally {
            System.out.println(j);
        }
    }
}

设置一个 2M 之后

在 JDK 8 以前，HotSpot 使用永久代 PermGen 实现方法区，可以通过 -XX:MaxPermSize 设置永久代最大大小。例如：-XX:MaxPermSize=8m。如果不断动态生成并加载大量 Class，可能会导致：java.lang.OutOfMemoryError: PermGen space。
在 JDK 8 以后，永久代被移除，HotSpot 改用元空间 Metaspace 实现方法区。可以通过 -XX:MaxMetaspaceSize 设置元空间最大大小。例如：-XX:MaxMetaspaceSize=8m，如果不设置，元空间默认可以一直向操作系统申请内存，直到系统内存不够或者进程内存限制被打满。如果不断动态生成并加载大量 Class，元空间中的类元信息不断增加，也可能导致：java.lang.OutOfMemoryError: Metaspace
在实际工作中，Spring、MyBatis、CGLIB、ASM、动态代理等技术都可能动态生成 Class。如果使用不当，比如不断生成新的类并且类加载器无法被回收，就可能导致方法区/元空间内存溢出。JDK 8 以后元空间使用本地内存，默认上限通常比永久代更宽松，因此发生 OOM 的概率降低了。但如果设置了 -XX:MaxMetaspaceSize，或者动态生成类过多、类加载器无法回收，仍然会出现 Metaspace OOM。

常量池(.class文件常量池)

这是一个 hello world 的代码。

java 复制代码

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("hello world");
    }
}

计算机最终会把这段代码转换为二进制代码后执行，这段二进制代码包含类基本信息、类方法定义(包含指令)、常量池。我们先用 javac 编译，然后通过反编译命令 javap -v xxx.class 把二进制代码转为可读的内容。常量池是指 Constant pool: 下面这些内容。

下面 // 是编译出的文件自带的注释， // --> 是我自己加的

java 复制代码

(base) ice@jimodebingkeledeMac-mini JVM % javac src/main/java/com/lh/HelloWorld.java
(base) ice@jimodebingkeledeMac-mini JVM % javap -v src/main/java/com/lh/HelloWorld.class 
Classfile /Users/ice/Desktop/cola/code/Java/JVM/src/main/java/com/lh/HelloWorld.class
  Last modified 2026年4月27日; size 432 bytes
  SHA-256 checksum 36d7d5a18d7230371bdf2af3ce1c864de68c93da0947d73dbaebb8082b676660
  Compiled from "HelloWorld.java"
public class com.lh.HelloWorld // --> 类声明信息
  minor version: 0
  major version: 61  // --> class 文件版本号，指代 JDK 17 编译出来的
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER  // --> public 类
  this_class: #21                         // com/lh/HelloWorld
  super_class: #2                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 2, attributes: 1  // --> 两个方法，一个main一个生成的无参构造
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Fieldref           #8.#9          // java/lang/System.out:Ljava/io/PrintStream;
   #8 = Class              #10            // java/lang/System
   #9 = NameAndType        #11:#12        // out:Ljava/io/PrintStream;
  #10 = Utf8               java/lang/System
  #11 = Utf8               out
  #12 = Utf8               Ljava/io/PrintStream;
  #13 = String             #14            // hello world
  #14 = Utf8               hello world
  #15 = Methodref          #16.#17        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #16 = Class              #18            // java/io/PrintStream
  #17 = NameAndType        #19:#20        // println:(Ljava/lang/String;)V
  #18 = Utf8               java/io/PrintStream
  #19 = Utf8               println
  #20 = Utf8               (Ljava/lang/String;)V
  #21 = Class              #22            // com/lh/HelloWorld
  #22 = Utf8               com/lh/HelloWorld
  #23 = Utf8               Code
  #24 = Utf8               LineNumberTable
  #25 = Utf8               main
  #26 = Utf8               ([Ljava/lang/String;)V
  #27 = Utf8               SourceFile
  #28 = Utf8               HelloWorld.java
{
  public com.lh.HelloWorld();
    descriptor: ()V
    flags: (0x0001) 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 3: 0

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #13                 // String hello world
         5: invokevirtual #15                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 5: 0
        line 6: 8
}
SourceFile: "HelloWorld.java"

先看

java 复制代码

  public com.lh.HelloWorld();
    descriptor: ()V
    flags: (0x0001) 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 3: 0

() 表示无参数 V 表示返回值为 void
stack=1 表示这个方法的操作数栈最大深度是 1
locals=1 表示局部变量表大小是 1
arg_size 表示这个方法有 1 个参数，这个其实是隐藏参数 this
0: aload_0 把局部变量表中第 0 个变量加载到操作数栈，也就是 this
1: invokespecial #1 调用父类构造方法，看 #1 其实是 java/lang/Object.<init>()V

{% note info %}

locals 是局部变量 + 参数 + this(如果是非static方法) + 编译器可能生成的临时变量

args_size 是参数 + this(如果是非static方法)

{% endnote %}

{% note info %}

操作数栈就是学习数据结构时，要计算表达式值时要借助的存数据的栈。

{% endnote %}

源码等价于

java 复制代码

public HelloWorld() {
	super();
}

然后看 main 方法

java 复制代码

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #13                 // String hello world
         5: invokevirtual #15                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 5: 0
        line 6: 8

([Ljava/lang/String;)V 是对类的参数返回值表述
- [ 代表是个一维数组，[[ 代表二维数组
- L 代表对象类型，就是告诉JVM后面跟着的是一个完整类名，以 ; 结束。基本类型的如下
  - B 表示 byte
  - C 表示 char
  - D 表示 double
  - F 表示 float
  - I 表示 int
  - J 表示 long
  - S 表示 short
  - Z 表示 boolean
    比如 int add(int a, int b) 描述符就是 (II)I
flags 中两个标志，表示方法是 public + static
stack=2 表示操作栈最大深度是 2(方法执行过程中，操作数栈最多同时需要放置几个槽位的数据)
locals=1 只有一个局部变量 args，没有 this 了，因为是静态方法。
0: getstatic #7 获取静态变量 System.out
3: ldc #13 加载字符串 hello world
5: invokevirtual #15 这个是调用 println，其实前面 0: ... 会把 System.out 放入操作数栈，3: ... 会把字符串 "hello world" 放入操作数栈，然后这一步把这两个操作数弹出，执行 println。
LineNumberTable 代表源码行号和字节码偏移量的对应关系，前面第一个数字代表源码的第几行，对应字节码偏移量从多少开始。

{% note info %}

左边的数字 0 3 5 代表字节码偏移量，因为不同的字节码指令占用的字节数不同，所以代表这个字节码指令从哪里开始

{% endnote %}

{% note info %}

常量池本质上可以理解为 .class 文件中的一张常量表。字节码指令中经常通过 #编号 引用常量池中的内容，比如类、字段、方法、字符串字面量、方法描述符等。
.class 文件中的常量池属于静态数据。当类被加载到 JVM 后，常量池中的内容会进入运行时常量池。
运行时常量池中原本的符号引用，比如类引用、字段引用、方法引用，会在解析阶段或实际使用时，被 JVM 解析为直接引用。直接引用可以理解为 JVM 能直接定位到对应类、字段或方法的引用。

{% endnote %}

运行时常量池

{% note danger no-icon %}

当两个类中都引用了 java.lang.Object 类时，并且都加载到 JVM 后，那么这个引用会从各自的常量池中合并吗？

问题是说当两个类都用了 Object 类之后，通过编译，各自的 .class 文件里面都有 java.lang.Object 的引用了，那如果都加载的 JVM 变为运行时常量池会做一个去重吗？

不会把两个类的运行时常量池合并成一个，每个类加载后，都会有自己独立的运行时常量池，不会合并成一个公共常量池

bash 复制代码

A 的运行时常量池
  #2 -> java/lang/Object

B 的运行时常量池
  #2 -> java/lang/Object

但是，它们里面的 java/lang/Object 这个符号引用，最终解析时，都会指向 JVM 中同一个已经加载的 java.lang.Object 类。

{% endnote %}

常量池就是一张表，虚拟机指令根据这个常量表找到要执行的类名、方法名、参数类型、字面量等信息
运行时常量池，常量池是 .class 文件中的，当该类被加载，它的常量池信息就会自动放入运行时常量池，并把里面的符号地址变为真实地址

{% note danger no-icon %}

符号地址变为真实地址，怎么理解呢？

编译阶段

javac 编译后，.class 生成的常量池表，这个时候，.class 文件里面并不知道对应的内存地址在哪
bash 复制代码
```
System.out 这个字段在内存哪里
println 方法在内存哪里
"hello world" 对象在堆哪里
```
只知道类名、字段名、方法名、方法参数、返回值、字符串内容，这就是符号引用
bash 复制代码
```
#7 表示：java/lang/System 类里的 out 字段
#15 表示：java/io/PrintStream 类里的 println(String) 方法
```
类加载阶段：.class 常量池进入运行时常量池

也就是执行命令 java com.lh.HelloWorld。.class 文件中的常量池会进入 JVM 内存，变成运行时常量池，每个类都有自己的运行时常量池。
创建 main 栈帧

这里其实栈帧会指向 HelloWorld 的运行时常量池，这样运行字节码指令的时候，可以去运行时常量池找 #7、#13 的内容
执行字节码

比如执行到了 0: getstatic #7，就先去运行时常量池找，知道它是谁，然后这个字段引用如果还没解析，就会解析它，找到它的直接引用，并保存/缓存解析结果，如果已经解析过，就直接拿来用。

主要是这些符号引用类型会被解析：

bash 复制代码

Class       类引用
Fieldref    字段引用
Methodref   方法引用
InterfaceMethodref 接口方法引用
String      字符串常量使用时会得到 String 对象引用

{% endnote %}

StringTable

StringTable 通常又叫串池，是 hashtable 结构，一张 JVM 维护的全局字符串表，里面保存字符串常量池中字符串对象的引用。

常量池和串池的关系

{% note info %}

这里说一个帮助理解的点，我们展示的都是 javac 编译后，javap 反编译展示的内容。我们要知道 javap 只是为了帮助我们阅读而已，因为 javac 编译生成的二进制文件我们看不懂，所以又这个反编译工具帮我们理解。

{% endnote %}

编译生成的 .class 文件并没有运行！还没有经过解释器执行，所以还没有真正创建对象、进行运算、调用方法。

举例如下代码

java 复制代码

public class Demo1_22 {
	
    public static void main(String[] args) {

        String s1 = "a";
        String s2 = "b";
        String s3 = "ab";
    }
}

java 复制代码

(base) ice@jimodebingkeledeMac-mini JVM % javac src/main/java/com/lh/Demo1_22.java      
(base) ice@jimodebingkeledeMac-mini JVM % javap -v src/main/java/com/lh/Demo1_22.class  
Classfile /Users/ice/Desktop/cola/code/Java/JVM/src/main/java/com/lh/Demo1_22.class
  Last modified 2026年4月27日; size 311 bytes
  SHA-256 checksum 4da7bcdd05418a5d5ed048818835b1b3cb843ae1bd77c85b77ff532c5629defd
  Compiled from "Demo1_22.java"
public class com.lh.Demo1_22
  minor version: 0
  major version: 61
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #13                         // com/lh/Demo1_22
  super_class: #2                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 2, attributes: 1
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = String             #8             // a
   #8 = Utf8               a
   #9 = String             #10            // b
  #10 = Utf8               b
  #11 = String             #12            // ab
  #12 = Utf8               ab
  #13 = Class              #14            // com/lh/Demo1_22
  #14 = Utf8               com/lh/Demo1_22
  #15 = Utf8               Code
  #16 = Utf8               LineNumberTable
  #17 = Utf8               main
  #18 = Utf8               ([Ljava/lang/String;)V
  #19 = Utf8               SourceFile
  #20 = Utf8               Demo1_22.java
{
  public com.lh.Demo1_22();
    descriptor: ()V
    flags: (0x0001) 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 3: 0

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=1, locals=4, args_size=1
         0: ldc           #7                  // String a
         2: astore_1
         3: ldc           #9                  // String b
         5: astore_2
         6: ldc           #11                 // String ab
         8: astore_3
         9: return
      LineNumberTable:
        line 7: 0
        line 8: 3
        line 9: 6
        line 10: 9
}
SourceFile: "Demo1_22.java"

常量池中的信息，都会被加载到运行时常量池中，刚开始运行时常量池中的 a b ab 都是字符串字面量的符号信息，还没变为 java 字符串对象
当执行到 String s1 = "a"; 的时候，也就是执行 0: ldc #7 的时候，先去运行时常量池中找 #7，发现 #7 代表字符串常量 "a"，然后去 StringTable 里面找有没有，找不到，就在堆中创建这个字符串对象，并把引用存入 StringTable，ldc 就可以把这个对象引用压入操作数栈了。所以这个 ldc 指令就帮我们做了一连串的操作来保证拿到的是已经存到串池的 "a" 的引用。另外，赋值操作也就是 "a" 引用给 s1 是下一个命令 astore_1 执行的
所以说这个操作是懒惰的，没执行到就还不创建对象。

字符串变量拼接

java 复制代码

String s4 = s1 + s2;

在 JDK8 中大概改为了

java 复制代码

String s4 = new StringBuilder().append(s1).append(s2).toString();

s1 + s2 底层会用 StringBuilder 拼接，拼接是不会进入字符串常量池的

从 JDK9 开始，字符串拼接默认改成了 invokedynamic + StringConcatFactory，用 invokedynamic，让 StringConcatFactory 在运行期为这个拼接表达式生成合适的拼接逻辑

返回的都是一个新的对象。所以如果打印下面内容

java 复制代码

System.out.println(s3 == s4); // false

{% note info no-icon %}

s3 与 s4 的区别

String s3 = "ab" 时，JVM 执行 ldc 指令，会通过运行时常量池找到字符串字面量 "ab"，然后去 StringTable 查找。如果 StringTable 中没有，就在堆中创建一个 String 对象 "ab"，并把该对象的引用记录到 StringTable 中，最后让 s3 指向这个对象。
String s4 = s1 + s2 时，因为 s1 和 s2 是变量，所以是运行期拼接。JDK 17 中通过 invokedynamic + StringConcatFactory 完成拼接，最终在堆中生成一个新的 String 对象，内容也是 "ab"，并把这个新对象的引用赋给 s4。这个新对象默认不会自动进入 StringTable。在 JDK8 中通过 StringBuilder

所以 s3 和 s4 内容相同，但引用不同，因此 s3 == s4 为 false。

{% endnote %}

编译器优化

java 复制代码

String s1 = "a";
String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2;
String s5 = "a" + "b";

对于 s5，因为 "a" 和 "b" 都是字符串字面量，属于编译期常量，编译器在编译阶段就能确定它们拼接后的结果一定是 "ab"，所以会直接把这句优化为 String s5 = "ab"，s5 和 s3 一样，都是通过 ldc 加载字符串常量池中的 "ab"，指向 StringTable 中同一个 "ab" 字符串对象。不同于 s4，s1 和 s2 是普通变量，编译器不能把它们当作固定不变的编译期常量处理，所以不会直接优化成 "ab"，而是在运行期进行字符串拼接。

{% note warning no-icon %}

如果 s1 和 s2 被 final 修饰，并且值在编译期就能确定，那么 s1 + s2 也会被编译器优化成 "ab"。

java 复制代码

final String s1 = "a";
final String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2;
String s5 = "a" + "b";

System.out.println(s4 == s5); // true
System.out.println(s3 == s5); // true

{% endnote %}

所以，如果我们运行 System.out.println(s3 == s5); 结果为 true

字符串延迟加载

字符串字面量也是延迟成为对象的

前面我们知道，String 对象在真正运行到那一行的时候才会去创建，字符串字面量也是

java 复制代码

public static void main(String[] args) {
    
	// java.lang.String 类型共 8055 个

    System.out.println("1111"); // 8057
    System.out.println("2222"); // 8058
    System.out.println("3333"); // 8059
    System.out.println("4444"); // 8060
    System.out.println("5555"); // 8061
    System.out.println("6666"); // 8062
    System.out.println("7777"); // 8063
    System.out.println("8888"); // 8064
    System.out.println("9999"); // 8065
    System.out.println("0000"); // 8066

    System.out.println("1111"); // 8066
    System.out.println("2222"); // 8066
    System.out.println("3333"); // 8066
    System.out.println("4444"); // 8066
    System.out.println("5555"); // 8066
    System.out.println("6666"); // 8066
    System.out.println("7777"); // 8066
    System.out.println("8888"); // 8066
    System.out.println("9999"); // 8066
    System.out.println("0000"); // 8066
}

{% note info %}

教程里面用的 0~9，但是我发现这些字面量本身就在串池里面，所以换了一组数据来测试。

debug 窗口里面选择这个即可，在第一行打上断点，然后逐行往下执行

可以看到每往下执行一个，数量就加一

{% endnote %}

intern 1.8

{% note info no-icon %}

先对前面做一个总结

常量池中的字符串仅是符号，第一次用到时才变为对象
采用串池的机制，避免重复创建字符串对象
字符串变量拼接的原理是 StringBuilder (1.8)
字符串常量拼接的原理是编译期优化
可以使用 intern 方法，主动将串池中还没有的字符串对象放入串池
- 1.8 将这个字符串对象尝试放入串池，如果有则并不会放入，如果没有则放入串池，会把串池中的对象返回
- 1.6 将这个字符串对象尝试放入串池，如果有则并不会放入，如果没有会把此对象复制一份，放入串池，会把串池中的对象返回
  理解为 1.8 是拷贝的引用，1.6 是拷贝的对象(复制一份全新的对象，引用不一样)
  {% endnote %}

java 复制代码

String s = new String("a") + new String("b");
System.out.println(s == "ab"); // false
String s2 = s.intern(); // 尝试将字符串对象放入串池，如果有则不放入，如果没有则放入串池，会把串池中的对象返回
System.out.println(s2 == "ab"); // true

new String("a") 之后，"a" 会在串池中生成一个，因为它是字面量，之后拿着这个串池中的值，相当于作为构造函数参数来在堆中又生成了一个字符串对象，所以是两个 String 引用。之后两个字符串对象拼接生成一个新的字符串对象 "ab" 放入堆中，并不会放入串池了(第二行代码)。

{% note warning no-icon %}

通过 new String("a") 创建的对象是放在堆中的，不会放在串池，我们可以做一个验证

java 复制代码

String s = "a";
String s1 = new String("a");
System.out.println(s1 == s); // false

说明并没有

{% endnote %}

{% note info no-icon %}

new String("a") 究竟怎么做的？

"a" 是个字面量，实际上还是会去字符串常量池找找 "a" 的引用，没有就在堆中创建一个内容为 "a" 的对象，引用放在字符串池，由串池维护。然后 new String("a") 会根据串池里面的 "a" 字符串对象作为构造参数，在堆中创建一个新的 String 对象。所以这个操作在串池中放了一个对象引用，但是堆中生成了两个对象的。

所以在 Java 中不推荐通过 new String() 方式来创建，因为它会额外创建对象。

{% endnote %}

{% note danger no-icon %}

做个测试，分析一下下面两组代码，两组代码发生了什么，分别输出什么？

测试1

java 复制代码

String s = new String("a") + new String("b");

String s2 = s.intern();
System.out.println(s2 == "ab");
System.out.println(s == "ab");
System.out.println(s2 == s);

s 对象创建的时候，会在串池放上字面量 "a"，"b"，堆上会有两个字符串对象值为 "a"，两个字符串对象值为 "b"，一个字符串对象 "ab"。s.intern() 是把堆中的这个字符串对象 "ab" 的引用放串池了，所以 s2 == "ab" 是 true，s == "ab" 也是 true。s2 就是 s。

测试2

java 复制代码

String s = new String("a") + new String("b");

System.out.println(s == "ab");
String s2 = s.intern();
System.out.println(s2 == "ab");
System.out.println(s == "ab");
System.out.println(s2 == s);

s 对象创建的时候，会在串池放上字面量 "a"，"b"，堆上会有两个字符串对象值为 "a"，两个字符串对象值为 "b"，一个字符串对象 "ab"。这个时候你又 s == "ab" 会出现什么？"ab" 字符串字面量在串池中没有，那就会创建一个，所以堆中又出了一个 "ab" 对象，串池里面指向这个引用。s.intern() 的时候 "ab" 串池有，所以返回串池的这个引用，这个时候 s2 就不是 s 了。所以最终结果是 false true false false

核心点

当程序执行到某个字符串字面量时，JVM 会通过运行时常量池找到这个字面量，然后去 StringTable 中查找是否已经有相同内容的字符串对象引用。如果没有，就在堆中创建对应的 String 对象，并把它的引用记录到 StringTable 中；如果已经有，就直接复用串池中已有的引用。
java 复制代码
```
System.out.println("a");
new String("a");
System.out.println(s == "a");
```
这些只要出现字面量的操作，就会在串池创建或者引用
调用 s.intern() 的时候，如果串池没有这个字符串值的引用，就把 s 引用放进去，否则就返回串池中这个字符串值的引用。
{% endnote %}

intern 1.6

在 JDK1.6 环境下

java 复制代码

String x = "ab";
String s = new String("a") + new String("b"); // 串池 ["a", "b", "ab"] 堆中 ["a", "b", "ab"] + 对应串池中的["a", "b", "ab"]

String s2 = s.intern(); // "ab" 串池有，所以 s2 是返回的串池的 "ab" 引用
System.out.println(s2 == x); // true
System.out.println(s == x);  // false

java 复制代码

String s = new String("a") + new String("b"); // 串池 ["a", "b"] 堆中 ["a", "b", "ab"] + 对应串池中的["a", "b"]

String s2 = s.intern(); // "ab" 串池中没有，所以把 s 拷贝一份放回串池，也就是创建了一个新的字符串对象，值为 "ab"，放入堆中，并且把引用存到串池
String x = "ab"; // 串池中有 "ab"
System.out.println(s2 == x); // true
System.out.println(s == x);  // false

面试题

java 复制代码

String s1 = "a";
String s2 = "b";
String s3 = "a" + "b"; // 编译器优化
String s4 = s1 + s2; // new String("ab")
String s5 = "ab";
String s6 = s4.intern();

System.out.println(s3 == s4); // false
System.out.println(s3 == s5); // true
System.out.println(s3 == s6); // true

String x2 = new String("c") + new String("d");
String x1 = "cd";
x2.intern();

System.out.println(x1 == x2);
// jdk1.8: false
// jdk1.6: false

java 复制代码

String x2 = new String("c") + new String("d");
x2.intern();
String x1 = "cd";

System.out.println(x1 == x2);
// jdk1.8: true
// jdk1.6: false

字符串相关概念关系图

日常来说来说字符串常量池就是串池就是 StringTable

严谨来说，字符串常量池是串池，StringTable 是字符串常量池的实现结构

StringTable 位置

在JDK6中，字符串常量池在永久代中，当大量调用 intern() 或者产生大量字符串常量时，会导致 java.lang.OutOfMemoryError: PermGen space

永久代回收效率低，因为永久代不是普通对象主要活动的区域。普通堆里的对象，Young GC、Old GC、Full GC 都可能参与回收。但是永久代里的类元信息、运行时常量池、字符串常量池相关内容，通常主要在 Full GC 的时候才更可能被处理。回收频率低，条件也苛刻。JDK1.7之后，HotSpot 把字符串常量池中的 String 对象移到了堆中，字符串常量池里的字符串对象可以像普通堆对象一样被 GC 管理

StringTable 垃圾回收

本节就是看一下告诉你字符串常量池 StringTable 放在堆中，也能被垃圾回收

设置虚拟机参数 -Xmx10m -XX:+PrintStringTableStatistics -XX:+PrintGCDetails -verbose:gc

java 复制代码

public static void main(String[] args) throws InterruptedException {
    int i = 0;
    try {
        for (int j = 0; j < 100; j++) { // j=100, j=20000
            String.valueOf(j).intern(); // 字符串对象入池，加入 StringTable 中
            i++;
        }
    } catch (Throwable e) {
        e.printStackTrace();
    } finally {
        System.out.println(i);
    }

}

bash 复制代码

100
Heap # 堆内存占用情况
 PSYoungGen      total 2560K, used 1489K [0x00000007bfd00000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 2048K, 72% used [0x00000007bfd00000,0x00000007bfe744b0,0x00000007bff00000)
  from space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
  to   space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
 ParOldGen       total 7168K, used 0K [0x00000007bf600000, 0x00000007bfd00000, 0x00000007bfd00000)
  object space 7168K, 0% used [0x00000007bf600000,0x00000007bf600000,0x00000007bfd00000)
 Metaspace       used 3249K, capacity 4500K, committed 4864K, reserved 1056768K
  class space    used 350K, capacity 388K, committed 512K, reserved 1048576K
SymbolTable statistics: # 符号表：类字节码中类名、方法名、变量名
Number of buckets       :     20011 =    160088 bytes, avg   8.000
Number of entries       :     13084 =    314016 bytes, avg  24.000
Number of literals      :     13084 =    514592 bytes, avg  39.330
Total footprint         :           =    988696 bytes
Average bucket size     :     0.654
Variance of bucket size :     0.657
Std. dev. of bucket size:     0.810
Maximum bucket size     :         6
StringTable statistics:
Number of buckets       :     60013 =    480104 bytes, avg   8.000 # 哈希表中有 60013 个桶
Number of entries       :       991 =     23784 bytes, avg  24.000 # 里面有 991 个字符串记录
Number of literals      :       991 =     64288 bytes, avg  64.872
Total footprint         :           =    568176 bytes # 占用 555 KB
Average bucket size     :     0.017
Variance of bucket size :     0.016
Std. dev. of bucket size:     0.128
Maximum bucket size     :         2

这是我们放入 100 个的情况下，下面我们试试调整 j < 20000

bash 复制代码

[GC (Allocation Failure) [PSYoungGen: 2048K->512K(2560K)] 2048K->556K(9728K), 0.0078479 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
# [PSYoungGen: 2048K->512K(2560K)] 年轻代
# GC前用了2048K，GC已使用512K
# 2048K->556K(9728K) 整个堆空间的使用，GC前时用了2048K，GC后用了556K
# Times: 垃圾回收耗费的时间
20000
Heap
 PSYoungGen      total 2560K, used 1042K [0x00000007bfd00000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 2048K, 25% used [0x00000007bfd00000,0x00000007bfd848c0,0x00000007bff00000)
  from space 512K, 100% used [0x00000007bff00000,0x00000007bff80000,0x00000007bff80000)
  to   space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
 ParOldGen       total 7168K, used 44K [0x00000007bf600000, 0x00000007bfd00000, 0x00000007bfd00000)
  object space 7168K, 0% used [0x00000007bf600000,0x00000007bf60b010,0x00000007bfd00000)
 Metaspace       used 3301K, capacity 4500K, committed 4864K, reserved 1056768K
  class space    used 357K, capacity 388K, committed 512K, reserved 1048576K
SymbolTable statistics:
Number of buckets       :     20011 =    160088 bytes, avg   8.000
Number of entries       :     13151 =    315624 bytes, avg  24.000
Number of literals      :     13151 =    516800 bytes, avg  39.297
Total footprint         :           =    992512 bytes
Average bucket size     :     0.657
Variance of bucket size :     0.661
Std. dev. of bucket size:     0.813
Maximum bucket size     :         6
StringTable statistics:
Number of buckets       :     60013 =    480104 bytes, avg   8.000
Number of entries       :      7874 =    188976 bytes, avg  24.000
Number of literals      :      7874 =    450632 bytes, avg  57.230
Total footprint         :           =   1119712 bytes
Average bucket size     :     0.131
Variance of bucket size :     0.143
Std. dev. of bucket size:     0.378
Maximum bucket size     :         3

可以看到，放入大概两万个左右，但实际上的 entries 只增加了不到 7000 个，因为开头，Allocation Failure，也就是说咱们的 10M 堆内存不够用，因为分配内存失败触发了垃圾回收机制

StringTable 性能调优

调整 -XX:StringTableSize=桶个数
考虑将字符串对象是否入池

调整 StringTableSize

StringTable 在 HotSpot 中可以理解成一张哈希表(出现碰撞就在后面放链表)，查找性能和桶数量、字符串数量、哈希分布有关。如果字符串数量很多，而桶数量较少，就可能导致哈希冲突增多，影响 StringTable 的查找效率。因此 StringTable 调优的一个重要手段是通过 -XX:StringTableSize 调整桶的数量。但一般情况下不需要手动调优，只有在大量使用 intern() 或者观察到 StringTable 冲突严重时才考虑调整。

下面看看这个对性能的影响

java 复制代码

public static void main(String[] args) throws IOException {
    try (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream("linux.words"), "utf-8"))) { // 单词表，大概有 48 万个单词
        String line = null;
        long start = System.nanoTime();
        while (true) {
            line = reader.readLine();
            if (line == null) {
                break;
            }
            line.intern();
        }
        System.out.println("cost:" + (System.nanoTime() - start) / 1000000);
    }
}

当 -XX:StringTableSize=200000 时，cost:336

当 -XX:StringTableSize=60013 时，也就是默认桶数量，cost:495

当 -XX:StringTableSize=1009 时，cost:3552(每次运行数值都有浮动)

因为每次插入都得先查找看有没有再决定是否插入。

另外，StringTableSize 的大小有范围限制 StringTable size of 1008 is invalid; must be between 1009 and 2305843009213693951

字符串对象入池

使用 StringTable / 字符串入池的目的之一，就是复用相同内容的字符串对象，减少重复对象带来的内存浪费。

我们举例一段代码

java 复制代码

public static void main(String[] args) throws IOException {

    List<String> address = new ArrayList<>();
    System.in.read();
    for (int i = 0; i < 10; i++) {
        try (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream("linux.words"), "utf-8"))) {
            String line = null;
            long start = System.nanoTime();
            while (true) {
                line = reader.readLine();
                if(line == null) {
                    break;
                }
                // address.add(line.intern());
                address.add(line);
            }
            System.out.println("cost:" +(System.nanoTime()-start)/1000000);
        }
    }
    System.in.read();


}

这是不入池的代码，文件中有大约 48 万个单词，循环 10 次，每个单词都会重复 10 遍。

运行程序

可以看到 String + char[] 大概会占用 10% 内存

等把数据放入 list 之后，直接飙升到了将近 90%

然后我们试着改动代码，把 address.add(line); 改为 address.add(line.intern());

占用了大概 56%，降低了很多

直接内存

定义

Direct Memory(直接内存)，属于操作系统内存，不属于 JVM。

常见于 NIO 操作时，用于数据缓冲区
分配回收成本较高，但读写性能高
不受 JVM 内存回收管理

使用以下代码来比较使用传统方式读写与 NIO 读写的区别，注意第一次启动读写性能会较差，需多运行几次，计算平均值。

java 复制代码

/**
 * 演示 ByteBuffer 作用
 */
public class Demo1_9 {
    static final String FROM = "/Users/ice/Desktop/cola/mac软件/office_2024_MAC中文标准版.iso";
    static final String TO = "/Users/ice/Desktop/cola/mac软件/backup/office_2024_MAC中文标准版.iso";
    static final int _1Mb = 1024 * 1024;

    public static void main(String[] args) {
        io(); // io 用时：1535.586957 1766.963399 1359.240226
        directBuffer(); // directBuffer 用时：479.295165 702.291454 562.56592
    }

    private static void directBuffer() {
        long start = System.nanoTime();
        try (FileChannel from = new FileInputStream(FROM).getChannel();
             FileChannel to = new FileOutputStream(TO).getChannel();
        ) {
            ByteBuffer bb = ByteBuffer.allocateDirect(_1Mb);
            while (true) {
                int len = from.read(bb);
                if (len == -1) {
                    break;
                }
                bb.flip();
                to.write(bb);
                bb.clear();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        long end = System.nanoTime();
        System.out.println("directBuffer 用时：" + (end - start) / 1000_000.0);
    }

    private static void io() {
        long start = System.nanoTime();
        try (FileInputStream from = new FileInputStream(FROM);
             FileOutputStream to = new FileOutputStream(TO);
        ) {
            byte[] buf = new byte[_1Mb];
            while (true) {
                int len = from.read(buf);
                if (len == -1) {
                    break;
                }
                to.write(buf, 0, len);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        long end = System.nanoTime();
        System.out.println("io 用时：" + (end - start) / 1000_000.0);
    }
}

{% note warning %}

我是 macOS 系统，没测出来 directBuffer 比 io 快，无论是 200MB 文件还是将近 3GB 的文件都是IO快，没搞明白，先不管了

{% endnote %}

为什么 IO 速度会比较慢呢？directBuffer 比较快呢？

当执行 IO 操作的时候，因为 Java 并不能直接读取文件，所以 CPU 会从用户态转为内核态，磁盘文件会先被读取到系统内存(读到系统内存，Java 并不认识)，然后再从系统内存缓冲区读到 Java 缓冲区，也就是我们创建的堆中的 byte[]

使用 DirectBuffer 时，缓冲区位于堆外内存，数据可以从内核缓冲区拷贝到 Direct Memory，Java 通过 DirectByteBuffer 间接访问这块内存，因此减少了 Java 堆内存参与的一次数据拷贝。

内存溢出

直接内存也有内存溢出问题

java 复制代码

static int _100Mb = 1024 * 1024 * 100;

public static void main(String[] args) {
    List<ByteBuffer> list = new ArrayList<>();
    int i = 0;
    try {
        while (true) {
            ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_100Mb);
            list.add(byteBuffer);
            i++;
        }
    } finally {
        System.out.println(i);
    }
}

分配 72 次，就报错直接缓冲区内存(也叫堆外内存)溢出

释放原理

直接内存它不归 GC 进行回收，因为直接内存不属于 JVM 内存。

我们来解析一下直接内存回收的过程。Unsafe 是 jdk 底层的一个类，用于内存分配，内存回收等，一般普通程序员无需使用，这里我们通过反射获取 Unsafe 对象，演示直接内存分配的底层原理。

java 复制代码

/**
 * 直接内存分配的底层原理：Unsafe
 */
public class Demo1_27 {
    static int _1Gb = 1024 * 1024 * 1024;

    public static void main(String[] args) throws IOException {
        Unsafe unsafe = getUnsafe();
        // 分配内存
        long base = unsafe.allocateMemory(_1Gb);
        unsafe.setMemory(base, _1Gb, (byte) 0);
        System.in.read();

        // 释放内存
        unsafe.freeMemory(base);
        System.in.read();
    }

    public static Unsafe getUnsafe() {
        try {
            Field f = Unsafe.class.getDeclaredField("theUnsafe");
            f.setAccessible(true);
            Unsafe unsafe = (Unsafe) f.get(null);
            return unsafe;
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }
}

运行代码，在任务管理器观察 jdk 进程内存占用发现，内存占用会在 allocateMemory() 后增加 1G，在 freeMemory() 后恢复。因此，直接内存的回收其实不是由 jvm 虚拟机完成，而是通过 Unsafe 对象调用 freeMemory() 完成。

释放后 Java 占用的内存就变得非常少了

下面查看一下 ByteBuffer 类的源码来验证

java 复制代码

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

allocateDirect() 返回一个 DirectByteBuffer 对象

java 复制代码

DirectByteBuffer(int cap) {                   // package-private

    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

调用了 Unsafe 中 allocateMemory() 来实现申请内存
新建 Cleaner 对象来释放内存

Cleaner(虚引用 后面会讲) 中关联的 Deallocator 是什么？可以看到它实现了 Runnable，是回调任务对象，在 run 方法中调用了 Unsafe.freeMemory()。

java 复制代码

private static class Deallocator
        implements Runnable
    {

        private static Unsafe unsafe = Unsafe.getUnsafe();

        private long address;
        private long size;
        private int capacity;

        private Deallocator(long address, long size, int capacity) {
            assert (address != 0);
            this.address = address;
            this.size = size;
            this.capacity = capacity;
        }

        public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            unsafe.freeMemory(address);
            address = 0;
            Bits.unreserveMemory(size, capacity);
        }

    }

直接内存的分配、释放过程可以理解为：调用 ByteBuffer.allocateDirect() 时，底层会通过 Unsafe.allocateMemory() 申请一块堆外内存，同时创建一个 Cleaner 对象，把 DirectByteBuffer 对象和一个释放内存的回调任务绑定起来。

当 DirectByteBuffer 对象不再被引用、被 GC 回收时，Cleaner 会执行 clean() 方法，最终调用 Unsafe.freeMemory() 释放这块直接内存。

{% note danger no-icon %}

Java 到底怎么控制直接内存呢？

Java 是通过 DirectByteBuffer 对象来管理和操作直接内存的。
直接内存本身不在 Java 堆中，GC 不能像回收普通对象一样直接回收它。
因此 DirectByteBuffer 会关联一个 Cleaner 清理器，没有引用指向 DirectByteBuffer 对象时，它可以被 GC 回收，回收的时候 Cleaner 会执行清理逻辑，最终调用 Unsafe.freeMemory() 释放对应的直接内存。之后 DirectByteBuffer 对象也被释放。
猜一下也可以知道，申请和释放内存对应的方法一定是被 native 修饰的
{% endnote %}

显示回收对直接内存的影响

java 复制代码

static int _1Gb = 1024 * 1024 * 1024;

/*
 * -XX:+DisableExplicitGC 显式的GC
 */
public static void main(String[] args) throws IOException {
    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1Gb);
    System.out.println("分配完毕...");
    System.in.read();
    System.out.println("开始释放...");
    byteBuffer = null;
    System.gc(); // 显式的垃圾回收，Full GC
    System.in.read();
}

看这段代码，我们通过 allocateDirect 分配了 1GB 的内存，然后通过设置 byteBuffer = null 让 Java 堆中的 DirectByteBuffer 对象变成可回收状态。调用 System.gc() 方式显示回收这个 byteBuffer 对象，然后触发 Cleaner，调用 clean() 方法释放这块直接内存。

但是 -XX:+DisableExplicitGC 这个设置会让 System.gc() 失效，生产环境下我们会把这个打开，所以如果开启这个就不能保证 DirectBuffer 及时释放掉(意思是 System.gc() 能释放，但是生成环境下一般不用，而且也不好)。

{% note danger no-icon %}

为什么会禁用显示的GC，也就是 -XX:+DisableExplicitGC，让 System.gc() 无效

因为 System.gc() 通常会触发一次 Full GC，特点是会暂停用户线程来执行垃圾回收，停留时间一般比较长(回收新声代、老年代、整理内存、触发STW停顿等，如果堆比较大，停顿会更明显)。为了防止程序员或者第三方库乱调用 System.gc()，导致线上服务突然 Full GC 卡顿。所以通常会开启这个禁止显示GC的配置。但是这样代价就是直接内存不能被及时释放

但是无所谓，正式开发就是如下

java 复制代码

private static void useDirectBuffer() {
    ByteBuffer buffer = ByteBuffer.allocateDirect(_1Mb);

    // 使用 buffer
    buffer.put((byte) 1);
    buffer.flip();

    // 方法结束后，buffer 局部变量失效
    // DirectByteBuffer 对象以后被 GC 回收时，
    // Cleaner 会释放它背后的直接内存
}

真想手动释放可以这样，但是不推荐，因为这个写法用了 JDK 内部类

java 复制代码

public static void main(String[] args) throws IOException {
    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1Gb);
    System.out.println("分配完毕...");
    System.in.read();
    System.out.println("开始释放...");
    ((DirectBuffer) byteBuffer).cleaner().clean(); // 手动调用释放直接内存，没有触发GC机制
    byteBuffer = null;
    System.in.read();
}

{% endnote %}

垃圾回收

如何判断对象可以回收

引用计数法

当一个对象被引用一次则计数 +1，失去引用计数 -1，当计数为 0 则判断为垃圾。但当对象间存在循环引用时会无法被回收。

这里 A 引用了 B，B 记数为 1，B 引用了 A，A 记数为 1。但是这样谁的记数都不会归 0，就都无法被回收，造成内存泄漏。

{% hideToggle 详细举例 %}

没看明白没有问题，我们用 Java 一个真实的例子来举例

java 复制代码

A a = new A();
B b = new B();

a.b = b;
b.a = a;

a 对象在堆中对吧，被 a 这个引用引用了，然后 b.a 也指向了 a 对象。也就是说 a 对象是被引用两次的，同理 b 对象也是。

执行下面这个命令后

java 复制代码

a = null;
b = null;

执行完之后，这个时候 a 对象和 b 对象都只少了一个引用，a.b = b 和 b.a = a 还存在，也就是上面这个循环里面存在的问题。但是这个时候我们的 a 和 b 都是 null 了，我们无法访问 a.b 和 b.a 了，这时候这块内存泄漏了，a 对象和 b 对象都无法被释放了。

{% endhideToggle %}

可达性分析算法

{% note warning %}

JavaScript 就是这么进行回收的

{% endnote %}

核心思想是从一组根对象出发，沿着对象之间的引用关系向下搜索。凡是能被根对象直接或间接访问到的对象，都认为是存活对象；凡是从根对象出发无法到达的对象，就认为是垃圾对象，可以被回收。

Java 虚拟机中的垃圾回收器采用可达性分析来探索所有存活的对象
扫描堆中的对象，看是否能够沿着 GC Root对象为起点的引用链找到该对象，找不到，表示可以回收

哪些对象可以作为根对象呢？使用 eclipse 的 MAT(memory analyzer) 可以进行分析。这个工具比 jvisual 更加专业，可以找到内存泄漏。

代码如下

java 复制代码

/**
 * 演示GC Roots
 */
public class Demo2_2 {

    public static void main(String[] args) throws InterruptedException, IOException {
        List<Object> list1 = new ArrayList<>();
        list1.add("a");
        list1.add("b");
        System.out.println(1);
        System.in.read();

        list1 = null;
        System.out.println(2);
        System.in.read();
        System.out.println("end...");
    }
}

运行起来后用命令 jps 查看线程，在 list 回收前、后分别使用 jmap 抓取目标进程内存的快照，转储为二进制文件，并设置 live 参数在抓取快照前主动触发垃圾回收。操作如下

bash 复制代码

(base) ice@jimodebingkeledeMac-mini jvm % jps
65427 
62475 Main
65549 Launcher
65551 Jps
65550 Demo2_2
(base) ice@jimodebingkeledeMac-mini jvm % jmap -dump:format=b,live,file=1.bin 65550 # 回收前执行
Heap dump file created
(base) ice@jimodebingkeledeMac-mini jvm % jmap -dump:format=b,live,file=2.bin 65550 # 回收后执行
Heap dump file created

使用 MAT 工具，菜单栏 file->open dump file 打开刚才抓取的快照文件。

然后可以通过上述方式，查看 GC Roots

这是 GC Roots 的信息(绿色的 C 代表对象类型，里面的这些 class ... @... 就是根对象)

System Class 系统类，里面存放的对象都是 java.lang.Class 类型，因为类对象被 JVM 加载后，它的信息都会保存一份来使用，注意不是某个类的实例，而是类的 Class 对象，静态变量属于类，所以也会存到这里。里面存放
- static 集合
- 单例对象
- 类加载器加载的 Class 对象
  {% note warning %}
  简单回顾：类元信息主要在元空间里。Class 对象在 Java 堆里，关联着元空间里面的类元数据
  {% endnote %}
JNI Global JNI 全局引用。JNI 是 Java 调用本地方法，也就是 native 方法用的，只要外面的 native 代码(C/C++代码)还抓着这个对象，这个对象就不能被 GC 回收
意思是比如
java 复制代码
```
native void save(Object obj);
```
底层 C/C++ 代码如果把这个 obj 保存起来，长期使用，就会创建一个 JNI Global Reference ，这样即使代码执行 obj = null;，只要 native 代码还保存着这个全局引用，这个对象就不能被 GC。
{% note info %}
JNI Global Reference 这个引用本身不在堆里，它保存在 JVM 的本地数据结构里，属于 JVM/native 层维护的东西，但是它指向的 Java 对象在 Java 堆里。
{% endnote %}
Thread 活着的线程，只要线程还活着，线程栈里的局部变量、方法参数引用的对象就不能回收。

比如我们的 main 线程，我们也可以看到我们在里面存放的 ArrayList 列表。
正在运行的线程、线程栈中的局部变量、方法参数、ThreadLocal 相关对象都存放在这里
Busy Monitor 正在被线程持有锁的对象，比如
java 复制代码
```
synchronized(obj) {
	// 线程正在持有 obj 的锁
}
```
只要某个对象正在被线程当作锁持有，JVM 就不能把它回收；否则锁状态、等待队列、释放逻辑都会出问题。

四种引用

一般认为是四种引用，这个老师觉得是5种(多一个终结器引用)。

强引用

咱们平时写代码最常见的就是强引用

java 复制代码

Object obj = new Object();

这里 obj 就是强引用，只要强引用存在，对象就不会被 GC 回收，即使堆空间不够了，抛出异常也不会回收的

软引用

内存够时，软引用对象可以不回收；内存不够时，GC 会回收软引用指向的对象(前提是它没被强引用引用)

可以配合引用队列来释放软引用自身

java 复制代码

SoftReference<byte[]> ref = new SoftReference<>(new byte[1024 * 1024 * 10]);

适合做缓存，比如图片缓存、临时数据缓存

弱引用

弱引用比软引用更弱，只要发生 GC，并且对象只被弱引用引用，就会被回收

java 复制代码

WeakReference<User> ref = new WeakReference<>(new User());

System.gc();

User user = ref.get(); // 已经是 null

虚引用

虚引用是最弱的一种引用，都不能通过 get() 获取对象。

java 复制代码

ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> ref = new PhantomReference<>(new Object(), queue);

它的主要作用不是拿对象，而是对象被回收前，收到一个通知，常见用途是直接内存回收、资源释放监控、对象回收跟踪。

终结器引用

终结器引用和 finalize() 方法有关(Object 类有 finalize() 方法），可以被重写。

java 复制代码

class User {
    @Override
    protected void finalize() throws Throwable {
        System.out.println("对象即将被回收");
    }
}

当对象重写了 finalize() 方法后，GC 第一次发现它不可达时，不会马上回收它，而是先把它放到一个队列里，让一个专门的线程去执行它的 finalize() 方法。

流程如下

txt 复制代码

A 对象第一次被判定不可达
        ↓
不会马上回收
        ↓
JVM 创建/使用 FinalReference 关联这个对象
        ↓
FinalReference 进入一个队列
        ↓
Finalizer 线程从队列中取出它
        ↓
调用对象的 finalize() 方法
        ↓
如果对象没有复活，下一次 GC 才会真正回收

如果类没有重写这个 finalize() 方法，那么第一次发现 A 对象不可达，GC 就直接回收了。

软引用案例

引用队列不是负责回收对象的，而是负责通知你：这个引用关联的目标对象已经被 GC 处理了。

java 复制代码

/**
 *  设置堆内存大小 20MB
 * -Xmx20m -XX:+PrintGCDetails -verbose:gc
 */

private static final int _4MB = 4 * 1024 * 1024;

public static void main(String[] args) throws IOException {
    List<byte[]> list = new ArrayList<>();
    for (int i = 0; i < 5; i++) {
        list.add(new byte[_4MB]);
    }

    System.in.read();
}

如上代码，会直接报错 java.lang.OutOfMemoryError: Java heap space

我们换为软引用试一试

{% note warning %}

我们原来说 "引用" 的时候似乎对引用、对象并没有严格区分，现在这里得强调一下，强引用它是一个引用变量，不是对象。但是其他几种引用是用来指向对象的一个对象，没错，软引用、弱引用这些也是对象。对象是内存中真正存放数据的实体。所以下面这个 new byte[_4MB] 是会在堆中创建一个 byte[] 对象。

引用有四种类别，SoftReference 本身也是一个 Java 对象，它内部保存了对这个 byte[] 对象的软引用关系。变量 ref 则是一个普通强引用，指向这个 SoftReference 对象。

详细分析 SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB]); 这个语句

new byte[_4MB] 在堆中创建了一个 byte[] 对象。
new SoftReference<>(...) 在堆中创建了一个软引用对象，这个 SoftReference 内部以软引用的方式 关联着 byte[] 对象
ref 强引用指向了这个软引用对象(所以当 ref 为 null 的时候，这个时候就可以GC这个软引用对象了)

所以只要内存不足，这个 new byte[_4MB] 就会被GC，因为它是被软引用的，但是 SoftReference 对象不会，因为它还被强引用着

{% endnote %}

java 复制代码

public static void soft() {
    // list --> SoftReference --> byte[]

    List<SoftReference<byte[]>> list = new ArrayList<>();
    for (int i = 0; i < 5; i++) {
        SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB]);
        System.out.println(ref.get()); // 获取软引用指向的内容
        list.add(ref);
        System.out.println(list.size());

    }
    System.out.println("循环结束：" + list.size());
    for (SoftReference<byte[]> ref : list) {
        System.out.println(ref.get());
    }
}

就不会报堆空间不足了，整体引用关系是

txt 复制代码

ref 变量
   ↓ 强引用
SoftReference 对象
   ↓ 软引用
byte[] 对象

{% note success %}

像缓存图片等不重要的对象，可以通过软引用来引用，当内存不足时就会回收它们。

{% endnote %}

同时可以看到上面，前四个软引用所指的对象已经是 null 了，没有必要把这四个软引用对象保留在 list 集合中了，可以配合引用队列，及时发现哪些 SoftReference 关联的 byte[] 已经被回收了，然后把这些 SoftReference 对象从 list 中移除。

这样 SoftReference 对象本身没有强引用后，之后也可以被 GC 回收。

java 复制代码

List<SoftReference<byte[]>> list = new ArrayList<>();

// 引用队列
ReferenceQueue<byte[]> queue = new ReferenceQueue<>();

for (int i = 0; i < 5; i++) {
    // 关联了引用队列， 当软引用所关联的 byte[]被回收时，软引用自己会加入到 queue 中去
    SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB], queue);
    System.out.println(ref.get());
    list.add(ref);
    System.out.println(list.size());
}

// 从队列中获取无用的 软引用对象，并移除
Reference<? extends byte[]> poll = queue.poll();
while( poll != null) {
    list.remove(poll);
    poll = queue.poll();
}

System.out.println("===========================");
for (SoftReference<byte[]> reference : list) {
    System.out.println(reference.get());
}

最终只剩下一个

{% note info %}

引用队列本身不会帮你回收 SoftReference 对象。它的作用是：当 SoftReference 关联的目标对象被 GC 回收后，JVM 会把这个 SoftReference 对象加入到 ReferenceQueue 中。我们可以从 ReferenceQueue 中取出这些已经失效的 SoftReference，然后把它们从 list、map 等集合中移除。移除之后，如果没有其他强引用指向这些 SoftReference 对象，它们本身才可以被 GC 回收。

{% endnote %}

弱引用案例

和软引用类似，就不跑代码了

java 复制代码

/**
 * 弱引用
 * -Xmx20m -XX:+PrintGCDetails -verbose:gc
 */
public class Demo2_5 {
    private static final int _4MB = 4 * 1024 * 1024;

    public static void main(String[] args) {
        //  list --> WeakReference --> byte[]
        List<WeakReference<byte[]>> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            WeakReference<byte[]> ref = new WeakReference<>(new byte[_4MB]);
            list.add(ref);
            for (WeakReference<byte[]> w : list) {
                System.out.print(w.get()+" ");
            }
            System.out.println();

        }
        System.out.println("循环结束：" + list.size());
    }
}

软引用、弱引用、虚引用都可以用引用队列，用的都是 ReferenceQueue，用法也都一样，并且一个 ReferenceQueue 可以同时放这三种引用，但是通常不建议混用一个队列，毕竟不同引用类型含义不一样

java 复制代码

// 引用队列
ReferenceQueue<byte[]> queue = new ReferenceQueue<>();

WeakReference<byte[]> ref = new WeakReference<>(new byte[_4MB], queue);

终结器引用不能用这个引用队列，它是 JVM 内部自己搞的 Finalizer 队列。

垃圾回收算法

《The Garbage Collection Handbook》可以参考这个书籍

标记清除(Mark Sweep)

标记阶段：

从 GC Roots 出发，沿着引用链查找对象。

能找到的对象标记为存活对象。
清除阶段：

遍历堆内存，把没有被标记的对象当成垃圾对象回收。
回收不是把内存全部清零，而是把这些区域记录为空闲内存，之后分配对象时可以再次使用。

优点：实现简单，不需要移动对象，回收速度相对较快。

缺点：容易产生内存碎片

标记整理(Mark Compact)

标记-整理算法会先从 GC Roots 出发，标记所有可达对象。标记完成后，不是直接清除垃圾对象，而是把存活对象向内存的一端移动，然后直接清理掉边界以外的内存。

优点：内存连续，不容易产生内存碎片。

缺点：整理时需要移动存活对象，移动对象本身有成本；对象移动后地址变了，所有引用这些对象的引用地址也要更新；所以整理过程比单纯标记-清除更耗时。(从第一个有内存碎片的位置开始，后面所有的存活对象都要往前移动，地址都会变)

{% note info %}

如果存活对象比较多，那移动起来就更耗时了，但是标记整理算法适合存活对象多的，因为相对于复制算法，复制算法还需要一块很大的备用空间，但是这个在存活对象多的时候不需要一个很大的空间。

{% endnote %}

复制(Copy)

复制算法会先从 GC Roots 出发，标记出存活对象，然后把 from 区中的存活对象复制到 to 区。复制过程中，存活对象会被紧凑地排列到 to 区，所以同时完成了内存整理，避免了内存碎片。复制完成后，from 区中的垃圾对象不用逐个清理，直接把整个 from 区清空即可。最后交换 from 和 to 的角色，下一次 GC 时再从新的 from 区复制到新的 to 区。

优点：实现简单，回收速度快；复制后内存连续，不会产生内存碎片。并且标记和复制可以同时进行！

缺点：需要额外的空闲区域作为 to 区；如果存活对象很多，复制成本会很高；可用内存会减少，因为要预留一块空间。

分代垃圾回收

JVM 的堆内存采用分代回收机制，通常可以分为新生代和老年代。新生代又可以分为 Eden 区、Survivor From 区和 Survivor To 区。

采用分代回收的原因是：不同对象的生命周期不同，可以针对不同区域使用更合适的垃圾回收策略。

新生代主要存放生命周期较短、朝生夕死的对象，因此会比较频繁地进行垃圾回收，通常采用复制算法。

老年代主要存放生命周期较长、经过多次新生代 GC 后仍然存活的对象，因此 GC 频率较低，通常采用标记-清除或标记-整理算法。

分代回收流程

一个新对象创建出来后，通常会先分配到新生代的 Eden 区。这样设计，是因为大多数对象生命周期很短，用完很快就没用了，所以先放到新生代里。
当 Eden 区逐渐被对象填满，新的对象放不下时，就会触发一次 Minor GC。Minor GC 回收的是新生代，主要检查 Eden + Survivor From。这里会发生 STW，也就是 Stop The World，用户线程会暂停一小段时间。
扫描：GC 会从 GC Roots 出发，判断哪些对象(Eden/Survivor From 中的)还能被访问到。
Minor GC 不会把存活对象留在原位置，而是把存活对象复制到 Survivor To 区。复制过去后，对象年龄会加 1，那些不可达的垃圾对象直接被回收掉。
图中 Eden 和 Survivor From 变成了虚线状态，意思是它们原来的内容已经不再作为有效对象保留
从 From 里已经存活过的，年龄会再加 1 到 To
所以新生代适合复制算法，因为大部分对象都是垃圾，真正需要复制的存活对象不多，所以速度快。
交换 Survivor 区角色，这里只是改动一下指针，Survivor From 指向之前的 Survivor To，Survivor To 指向之前的 Survivor From。
如果一个对象经历多次 Minor GC 之后还活着，它的年龄会不断增加。当年龄达到一定阈值后，对象会晋升到老年代。如果 Survivor 区放不下，部分对象也会直接进入老年代
对象年龄最大为 15，因为对象头中用于记录年龄的空间是 4 bit
如果出现新生代放不下新对象且老年代也紧张，会先尝试 Minor GC，不行就再 Full GC，还不行就抛异常

关于 Eden 还有一些小细节，如果有多个线程同时想创建对象，那么都要申请 Eden 区，是不是需要考虑同步问题？是不是速度就慢了，所以 Eden 分为多个 TLAB(线程本地分配缓冲区)，以及一个共享 Eden 区，线程要分配对象时，先向 Eden 申请一块 TLAB，然后在这个上面去创建对象，如果申请失败，再在共享 Eden 区去分配，这个时候就要考虑同步，比如用 CAS 或加锁。如果共享 Eden 还无法分配对象，就 Minor GC 了。
TLAB 大小、数量都不是固定的。

Eden 区垃圾回收的时候，是不是还需要考虑跨代引用？老年区对象里面的某个对象类型的成员变量引用也可能指向 Eden 区对象，那为了知道 Eden 区到底被哪些引用来判断是否存活，岂不是要把老年代的也都扫描一遍才可以，速度又很慢。所以 JVM 引入了卡表，JVM 把老年代划分成很多 Card，如果老年代对象的引用字段被修改过，通过写屏障把对应 Card 标记为脏，Minor GC 只扫描这些脏卡，找出其中指向年轻代的引用。

{% note warning no-icon %}

新生代为什么适合复制算法？

Minor GC 暂停时间一般比较短，因为新生代的对象一般生命周期短，拷贝的次数少，大部分都是垃圾，需要回收

为什么 GC 时要暂停？

因为 GC 时会发生对象复制和移动，引用关系会发生变化，如果用户线程还在同时运行，可能一边访问旧地址，一边 GC 移动对象，引用关系就会乱。

怎么进入的老年代？

超过阈值：这个移动发生在 Minor GC 复制阶段，原本应该复制到 Survivor To，但对象年龄够大了，于是直接放到老年代
Minor GC 后活下来的对象太多，Survivor To 装不下：也就是 Eden + Survivor From 的对象太多了，光 Survivor To 放不下，这时一部分对象会直接进入老年代。
大对象可能直接进入老年代：有些对象特别大，比如 50MB 的数组，这种对象如果新生代放不下，或者 JVM 判断它不适合在新生代反复复制，可能会直接进入老年代。先记住有这个就行
{% endnote %}

{% note danger %}

即使老年代满了，Survivor To 放不开刚整理的 Eden + Survivor From，也不会把这些对象放到 Eden。Eden 在整理后必须是空的，流程如下

txt 复制代码

Eden 满了
  ↓
触发 Minor GC
  ↓
扫描 Eden + Survivor From
  ↓
存活对象尝试复制到 Survivor To
  ↓
Survivor To 放得下？
  ├─ 放得下：进 Survivor To
  └─ 放不下：尝试晋升老年代
              ↓
              老年代放得下？
              ├─ 放得下：进老年代
              └─ 放不下：触发 Full GC
                            ↓
                            Full GC 后还放不下？
                            ├─ 放得下：进老年代
                            └─ 放不下：OOM

为啥这样呢？因为 Eden 是给新对象分配用的，如果把存活对象又放回 Eden

Eden 清不干净，下次新对象还是没地方放
下次 Minor GC 又要重新扫描这些老对象
无法体现"对象多次存活后逐渐晋升"的分代思想

所以 Minor GC 后，Eden 中原来的对象要么被回收，要么被转移出去。

{% endnote %}

配置项	JVM 参数	默认值 / 常见值	说明
堆初始大小	`-Xms<size>`	物理内存的一定比例，和 JVM/机器有关	设置 Java 堆初始大小
堆最大大小	`-Xmx<size>` 或 `-XX:MaxHeapSize=<size>`	物理内存的一定比例，和 JVM/机器有关	设置 Java 堆最大大小
固定新生代大小	`-Xmn<size>`	不固定，和堆大小、GC 策略有关	直接固定新生代大小，等价于同时设置 `NewSize` 和 `MaxNewSize` 为同一个值
新生代初始大小	`-XX:NewSize=<size>`	不固定，和堆大小、GC 策略有关	设置新生代初始大小
新生代最大大小	`-XX:MaxNewSize=<size>`	不固定，和堆大小、GC 策略有关	设置新生代最大大小
Eden 与 Survivor 比例	`-XX:SurvivorRatio=<ratio>`	常见默认值是 `8`	设置 `Eden : SurvivorFrom : SurvivorTo = ratio : 1 : 1`
动态 Survivor 初始比例	`-XX:InitialSurvivorRatio=<ratio>`	常见默认值是 `8`	配合 `-XX:+UseAdaptiveSizePolicy` 使用，表示 Survivor 区初始比例
自适应大小策略	`-XX:+UseAdaptiveSizePolicy`	很多收集器下默认开启	允许 JVM 根据运行情况动态调整 Eden、Survivor、新生代等大小
晋升阈值	`-XX:MaxTenuringThreshold=<threshold>`	常见最大值是 `15`	设置对象晋升老年代的年龄阈值
晋升详情	`-XX:+PrintTenuringDistribution`	默认关闭	打印对象年龄分布和晋升信息
GC 详情	`-XX:+PrintGCDetails`	默认关闭	打印 GC 详细日志
GC 简要日志	`-verbose:gc`	默认关闭	打印 GC 基本信息
Full GC 前先 Minor GC	`-XX:+ScavengeBeforeFullGC`	默认通常开启	Full GC 前先尝试执行一次 Minor GC

GC 分析

参考下面代码，设置参数并运行。其中参数 -XX:+UserSerialGC 是将垃圾回收器设置为UserSerialGC，这种垃圾回收器的幸存区不会进行自动调整，有助于我们观察现象。

java 复制代码

public class Demo2_1 {

    // -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc -XX:-ScavengeBeforeFullGC
    public static void main(String[] args) throws InterruptedException {

    }
}

直接跑上面这个代码

可以看到我们分配的新生代的内存是 10M，但是却显示 total 9216K，因为默认情况下 SurvivorTo 一直是空的，所以认为这一块不算总大小。tenured generation 就是老年代，大小是 10M

{% note info %}

Java 堆大小 = 新生代大小 + 老年代大小，所以我们虽然只设置了堆大小和新生代大小，但是老年代大小也就知道了

{% endnote %}

新生代 Eden 区只有 8M 内存，其中 28% 被占用了，我们新增如下代码

java 复制代码

public static void main(String[] args) throws InterruptedException {
    ArrayList<byte[]> list = new ArrayList<>();
    list.add(new byte[_7MB]);
}

可以看到是出发了一次 GC 的，这个 GC 就是 Minor GC，这里面 1877K->364K(9216K) 分别代表回收前占用内存大小和回收后占用内存大小以及总大小，这个前面的是新生代的，后面的 1877K->364K(19456K) 代表整个堆的。最后 real=0.01 secs 代表本次垃圾回收的时间

再加 512KB

java 复制代码

ArrayList<byte[]> list = new ArrayList<>();
list.add(new byte[_7MB]);
list.add(new byte[_512KB]);

可以看到是能再放 512KB 的，因为只发生了一次 GC，再加 512KB 的时候没有触发第二次 GC

{% note warning %}

其实你多运行几次，会发现每次结果都有点不一样，一会是 100%，一会是 98%。

{% endnote %}

再加 512KB

java 复制代码

ArrayList<byte[]> list = new ArrayList<>();
list.add(new byte[_7MB]);
list.add(new byte[_512KB]);
list.add(new byte[_512KB]);

加不上了，触发一次 Mionr GC。你可以看到其实 From 用了很多，是因为一次 GC 之后，是先把对象都复制到 To，然后 To 转换到 From。

{% note info %}

总结一下这个流程，第一次要分配 7MB 对象时，Eden 空间不够了，所以触发了一次 Minor GC，这次 GC 处理的是创建 7MB 对象之前已有的对象，存活对象复制到 To，然后 From/To 交换，之后 Eden 被清出空间，放下这 7MB 对象，再然后又要 512KB 内存，Eden 能放下，无事发生，不触发 GC，所以除了 Eden 区域其他地方无变化，之后又要加 512KB，放不下了，触发 Minor GC，但是此时 Eden + From 区域对象 To 区域放不下，所以尝试晋升老年代，这里可以看到把这个 7MB 对象放到老年代了(70% used，也就是 7MB)

{% endnote %}

{% note danger no-icon %}

Eden清空后放入到 7MB 对象，为什么不是刚好占用 7/8=0.875，也就是 87% 呢？为什么会出现多次运行上下浮动的原因呢？

待解决

{% endnote %}

思考另外一个问题，就是如果一个非主线程的其他线程发生内存溢出，会导致整个 Java 进程退出吗？

java 复制代码

new Thread(() -> {
    ArrayList<byte[]> list = new ArrayList<>();
    list.add(new byte[_8MB]);
    list.add(new byte[_8MB]);
}).start();

System.out.println("sleep....");
Thread.sleep(1000L);

其实并不会，堆内存是所有线程共享的，所以内存不足这件事和整个进程都有关系。因为某个子线程把堆吃满后，其他线程如果也要创建对象，也可能分配失败。但是 OutOfMemoryError 是在哪个线程分配对象失败，就抛给哪个线程。如果这个错误没有被捕获，默认只会导致当前线程结束，不会直接杀死整个 JVM 进程。

垃圾回收器

大多数 JVM 都需要使用两种不同的 GC 算法，一种清理年轻代，一种清理老年代。

三类垃圾回收器，其实是三种年轻代 GC 算法和老年代 GC 算法的组合

串行

单线程
适用于堆内存较小，个人电脑

吞吐量优先

多线程
适用于堆内存较大，多核 cpu
让单位时间内，STW 的时间最短 0.2 0.2 = 0.4，垃圾回收时间占比最低，这样就称吞吐量高

响应时间优先

多线程
适用于堆内存较大，多核 cpu
尽可能让单次 STW 的时间最短 0.1 0.1 0.1 0.1 0.1 = 0.5(虽然可能次数多，但是每次都很快)

串行

也就是 Serial 收集器

-XX:+UseSerialGC = Serial + SerialOld

Serial 工作在新生代，采用的回收算法是复制

SerialOld 工作在老年代，采用的是标记整理算法

当某个线程分配对象时发现内存不足，会触发 GC 请求。JVM 会让所有用户线程运行到安全点并暂停，也就是发生 STW。随后由 JVM 的 GC 线程执行垃圾回收。

在 -XX:+UseSerialGC 下：

新生代空间不足时，触发 Minor GC，STW 后使用 Serial 收集器；--> Full GC 的时候也会用这个收集器
老年代空间不足或晋升失败、System.gc() 等原因触发 Full GC 时，STW 用 Serial 收集器回收新生代，用 SerialOld 收集器回收老年代

可以看到，不管有多少 CPU 内核，JVM 在垃圾收集时都只能用一个核心，比较适合几百 MB 堆内存的 JVM，而且是单核 CPU 时比较有用。一般服务器都是多个 CPU 内核，所以这个并不推荐使用，除非你需要限制 JVM 使用的资源。

吞吐量优先

{% note warning %}

Parallel 是"GC 线程并行工作"，不是用户线程和 GC 线程并发工作

{% endnote %}

开启 -XX:+UseParallelGC 可以使用吞吐量优先的垃圾回收器。在 JDK 8 中，它通常对应新生代使用 Parallel Scavenge，老年代使用 Parallel Old。新生代仍然使用复制算法，老年代使用标记-整理算法。它的特点是：垃圾回收前会发生 STW，所有用户线程暂停；垃圾回收时会启动多个 GC 线程并行执行回收任务，因此可以充分利用多核 CPU，提高吞吐量(CPU占用会飙升至 100%)。因为是多个 GC 线程并行垃圾回收，所以 GC 时间会大幅度减少。

执行过程

新生代内存不足时触发 Minor GC --> 用 Parallel Scavenge 回收新生代
老年代内存不足时触发 Full GC --> 用 Parallel Scavenge 回收新生代 + Parallel Old 回收老年代
可以使用 -XX:ParallelGCThreads=<n> 指定并行 GC 线程数量。
-XX:+UseAdaptiveSizePolicy 表示开启自适应大小策略，JVM 会根据运行情况动态调整堆、新生代、Eden、Survivor 等区域大小。
-XX:GCTimeRatio=<n> 用于设置吞吐量目标。GC 时间占比约为 1 / (1 + n)。例如 -XX:GCTimeRatio=19，表示 GC 时间约占 5%；默认值通常是 99，表示 GC 时间约占 1%。
-XX:MaxGCPauseMillis=<ms> 用于设置最大 GC 停顿时间目标。例如 -XX:MaxGCPauseMillis=200，表示 JVM 会尽量将单次 GC 停顿控制在 200ms 左右。

GCTimeRatio 和 MaxGCPauseMillis 之间存在取舍：

如果追求更高吞吐量，JVM 可能会增大堆空间，减少 GC 次数，但单次 GC 停顿可能变长；
如果追求更短停顿，JVM 可能会减小每次 GC 处理的内存量，但 GC 次数可能增加，吞吐量下降。

txt 复制代码

# 常见参数如下
-XX:+UseParallelGC
-XX:+UseParallelOldGC
-XX:+UseAdaptiveSizePolicy
-XX:ParallelGCThreads=4
-XX:GCTimeRatio=99
-XX:MaxGCPauseMillis=200

响应时间优先

CMS，全称 Concurrent Mark Sweep ，是工作在老年代的垃圾回收器。

开启参数：

text 复制代码

-XX:+UseConcMarkSweepGC

CMS 属于响应时间优先 的垃圾回收器，它采用的垃圾回收算法主要是标记-清除算法 。其中 Conc 表示并发，意思是 CMS 在某些阶段可以让垃圾回收线程和用户线程同时执行。这样有利于减少 STW 时间，提高程序的响应性能。但是因为 GC 线程会和用户线程抢占 CPU，所以也会牺牲一定的吞吐量。

CMS 并不是所有阶段都并发执行，它仍然有一些阶段需要 STW。CMS 通常和新生代垃圾回收器 ParNewGC 配合使用：

text 复制代码

新生代：ParNewGC --> -XX:+UseParNewGC
老年代：CMS

不过，CMS 垃圾回收器有时会发生并发失败 ，也就是 Concurrent Mode Failure 。这时 JVM 会采取补救措施，退化为一次更重的 Full GC，可能使用 Serial Old 对老年代进行回收和整理，从而导致较长时间的 STW。

CMS 的回收流程

CMS 的回收过程主要分为四个阶段：

初始标记：需要 STW
并发标记：不需要 STW
重新标记：需要 STW
并发清除：不需要 STW
初始标记

在老年代使用率达到一定阈值时，CMS 会开始进行垃圾回收。首先进入初始标记阶段 。这个阶段需要 STW，也就是会暂停其他用户线程。初始标记阶段主要做的事情是：标记 GC Roots 直接关联的对象，也包括年轻代指向老年代的(不是标记所有可达对象，而是只标记 GC Roots 直接引用到的对象 )。因此这个过程很短。

例如：

text 复制代码

GC Roots → A → B → C

初始标记阶段主要标记的是 A，不会继续完整扫描 B 和 C。

并发标记

初始标记结束后，用户线程恢复执行，同时垃圾回收线程进入并发标记阶段。这个阶段 GC 线程会和用户线程并发执行。GC 线程会从初始标记阶段找到的对象开始，继续沿着引用链向下扫描，标记所有存活对象。没有被标记到的对象，最后才会被认为是垃圾对象并被清理。并发标记阶段的优点是用户线程不用长时间暂停。但是缺点是 GC 线程会占用 CPU 资源，因此会降低系统吞吐量。

重新标记

在并发标记结束后，会进入重新标记阶段。这个阶段也需要 STW。重新标记的作用是：修正并发标记期间，由于用户线程继续运行而导致的对象引用关系变化(重新标记不是因为对象地址发生变化，而是因为对象引用关系发生变化)

因为 CMS 使用的是标记-清除算法，大多数情况下不会移动对象地址。

真正需要重新标记的原因是：并发标记期间用户线程还在运行，对象之间的引用关系可能会发生变化。

{% note info %}

并发标记阶段，JVM 通过写屏障记录引用写入，然后把相关的区域标记为 dirty，这样重新标记阶段，只需要扫描这些 dirty 区域，修正并发标记阶段可能漏掉的对象就可以了。

{% endnote %}

例如原来是

text 复制代码

A → B

后来用户线程执行代码后变成

text 复制代码

A → C

所以 CMS 需要在重新标记阶段暂停用户线程，修正这部分变化。

并发清除

重新标记结束后，用户线程又可以继续执行，垃圾回收线程进入并发清除阶段 。并发清除阶段中，GC 线程和用户线程并发执行。GC 线程会清理那些没有被标记到的垃圾对象。因为 CMS 使用的是标记-清除算法 ，所以它只清除垃圾对象，不会整理内存，也不会移动存活对象。因此清理后可能会留下很多内存碎片。

内存碎片过多时，可能会导致虽然老年代总剩余空间足够，但是找不到一块连续的大空间来存放大对象。

参数

并行 GC 的线程数量，控制 STW 阶段 的 GC 线程数。作用在 初始标记、重新标记、Young GC 阶段

text 复制代码

-XX:ParallelGCThreads

并发 GC 线程数，控制 CMS 并发阶段 的 GC 线程数。作用在：并发标记、并发清除。一般来说，并发线程数会少于并行线程数，避免 GC 线程过多抢占 CPU。

text 复制代码

-XX:ConcGCThreads

常见经验
ConcGCThreads ≈ ParallelGCThreads / 4

CMS 触发阈值，设置老年代使用率达到多少时触发 CMS。CMS 需要提前触发，不能等老年代满了再回收，因为并发回收期间用户线程还会继续分配对象，并且会产生浮动垃圾。不能像原来那样满了才去收，因为是现在是并发去收，如果回收垃圾慢，产生快，明明内存够用，只不过是垃圾还没回收完导致 OOM，就不应该了，所以提前去收垃圾。

text 复制代码

-XX:CMSInitiatingOccupancyFraction=<percent>

-XX:CMSInitiatingOccupancyFraction=70  # 老年代使用率达到 70% 左右时触发 CMS

固定触发阈值，让 JVM 按照 CMSInitiatingOccupancyFraction 设置的阈值触发 CMS。如果不加，JVM 可能会根据运行情况动态调整触发时机。和前面这个配置搭配着用

text 复制代码

-XX:+UseCMSInitiatingOccupancyOnly

重新标记前触发 Young GC，作用是在 CMS 重新标记前 先触发一次 Young GC。为什么呢？原因是虽然 CMS 回收的是老年代，但是新生代对象也可能引用老年代对象，所以判断老年代对象是否存活时，还需要考虑新生代中是否存在指向老年代的引用。

text 复制代码

-XX:+CMSScavengeBeforeRemark

CMS 的并发标记阶段，用户线程还在运行，因此对象引用关系可能一直在变化，例如：

新生代对象可能创建
新生代对象可能死亡
新生代对象可能引用老年代对象
老年代对象之间的引用也可能变化

目的

减少新生代对象数量
降低重新标记阶段的扫描压力
减少 remark 阶段 STW 时间

CMS 常见问题

抢占 CPU，降低吞吐量

CMS 的并发标记、并发清除阶段，GC 线程会和用户线程一起运行。所以 CMS 虽然减少了 STW 时间，但会抢占 CPU，降低系统吞吐量。
浮动垃圾

CMS 并发清理时，用户线程仍然运行。这期间新产生的垃圾，本轮 CMS 可能无法清理，只能等下一次 GC。这类垃圾称为：浮动垃圾。所以 CMS 必须提前触发，给浮动垃圾和用户线程继续分配对象预留空间。
内存碎片

CMS 使用 标记-清除算法 。它只清理垃圾对象，不整理内存，也不移动存活对象。因此回收后可能出现很多不连续的空闲空间，也就是内存碎片。

结果可能是：老年代总剩余空间足够但是找不到连续的大空间，从而导致大对象分配失败。

所以之前会有相关参数配置 -XX:+UseCMSCompactAtFullCollection 意思是在 Full GC 时进行内存整理，比如用 Serial Old，缺点就是 STW 时间长
Concurrent Mode Failure

如果 CMS 并发清理过程中，用户线程一直申请堆空间导致老年代空间不足，就可能发生：Concurrent Mode Failure

常见原因：
text 复制代码
```
1. CMS 触发太晚
2. 用户线程分配对象太快
3. 新生代对象大量晋升到老年代
4. 老年代内存碎片过多
5. CMS 还没清理完，老年代空间就不够了
```
发生后，JVM 会退化为一次更重的 Full GC，可能使用 Serial Old 对老年代进行回收和整理。所以会造成较长时间停顿(单线程，STW)。

和内存碎片有点像，不同的是内存碎片是因为空间不连续导致的，后者是 CMS 回收速度赶不上老年代消耗速度。

{% note info %}

CMS 学了这么久，可以扔一边了，因为现在一般用更好的 G1 垃圾回收器。

{% endnote %}

G1

定义：Garbage First

2004 论文发布
2009 JDK 6u14 体验
2012 JDK 7u4 官方支持
2017 JDK 9 把G1作为默认垃圾回收器，并且废弃了 CMS 垃圾回收器

G1 最主要的设计目标是：将 STW 停顿的时间和分布变成可预期以及可配置的。事实上, G1 是一款软实时垃圾收集器, 也就是说可以为其设置某项特定的性能指标。可以指定: 在任意 xx 毫秒的时间范围内, STW 停顿不得超过 x 毫秒。如: 任意 1 秒暂停时间不得超过 5 毫秒. Garbage First GC 会尽力达成这个目标(有很大的概率会满足, 但并不完全确定)。

适用场景

同时注重吞吐量（Throughput）和低延迟（Low latency），默认的暂停目标是 200 ms
超大堆内存，会将堆划分为多个大小相等的 Region(性能上堆内存小的时候，CMS 和 G1 差不多，堆内存大的时候 G1 优势更大)

G1主要通过 Evacuation(转移) 回收空间：把选中区域里的存活对象复制到新的区域，并且这个过程中完成压缩(减少碎片)

每个 Region 可以是 Eden、Survivor、Old、Free、Humongous 任何一个区域(Humongous 专门用来存储大文件)

G1 垃圾回收阶段

三个阶段 Young Collection --> Young Collection + CM --> Mixed Collection

分别对应

新生代空间不足
老年代空间不足
混合收集

Young Collection

把堆划分成了一个个 Region，每个 Region 都可以作为 Eden，Survivor，老年代。
图里面的 E 代表 Eden，白色的部分代表空闲区域
Eden 区域也会设置大小，当超过这个区域大小上限后会触发 STW，采用多个 GC 线程并行回收

会以复制的算法把 Eden 中存活的对象去拷贝到幸存区

如果幸存区满了，或者该晋升了，会把幸存区中存活对象的拷贝到老年区，同时把 Eden 和幸存区中 Survivor From 的存活对象放到 Survivor To，然后交换 From 和 To

Young Collection + CM

Concurrent Start Young Collection --> CM 是并发标记

当老年代占用堆空间比例达到阈值时，会启动一次并发标记周期，由下面的 JVM 参数决定
-XX:InitiatingHeapOccupancyPercent=percent （默认 45%）老年代占用堆空间 45% 时触发，回收流程如下
- 先来一次 Young Collection，这次和之前的还不一样，它会顺带做初始标记(STW)
- STW 结束，用户线程恢复，后台开始 Concurrent Mark 并发标记
- 最终标记（Remark）会 STW --> 并发标记阶段可能会漏掉一些对象(并行的)
- Cleanup 统计 Region 回收价值，为 Mixed Collection 做准备

Mixed Collection

会对 E、S、O 进行全面垃圾回收

并发标记结束后，G1 就知道哪些 Old Region 垃圾多，回收收益高，然后进入 Mixed Collection 阶段

拷贝存活（Evacuation）会 STW --> 也就是开始清理了(并行执行的)

{% note info %}

图中黑色线代表复制算法，红色线是标记整理算法

{% endnote %}

-XX:MaxGCPauseMillis=ms 最大 GC 暂停时间，为了满足这个时间限制，会选择老年代里面回收价值最高的 Region 进行回收，这也是为什么叫 Garbage First 的原因。

{% note info %}

混合收集目标是收集整个新生代以及部分老年代的垃圾收集。目前只有 G1 收集器有这种行为。

{% endnote %}

整体流程

Young GC (完全 STW)

Eden Region 满了，触发 Young GC

→ STW

→ 回收年轻代 Region: Eden + Survivor

→ 存活对象复制到 Survivor / Old Region

→ 原来的 Eden / Survivor Region 清空
Young GC + Initial Mark (完全 STW)

堆占用达到 InitiatingHeapOccupancyPercent=percent 阈值，触发一次带 Initial Mark 的 Young GC

→ STW

→ 在这次暂停中同时做两件事：
1. 正常回收年轻代 Region
2. 完成 Initial Mark，标记从 GC Roots 直接可达的对象
→ 为后续 Concurrent Mark 做准备
Concurrent Mark (并发标记)

STW 结束，用户线程恢复

→ GC 线程和用户线程并发运行

→ GC 线程从 Initial Mark 标记到的对象继续沿引用链扫描

→ 标记堆中可达对象，并统计各个 Region 的存活率

→ 重点找出哪些 Old Region 垃圾比例高，适合作为后续 Mixed GC 的候选 Region
Remark (重新标记) STW

→ 短暂 STW

→ 修正并完成最终标记结果
Cleanup (短暂 STW，部分并发)

有一部分是并发的: 例如空堆区的回收,还有大部分的存活率计算

→ 短暂 STW，后续部分清理可并发进行

→ 统计 Region 存活率和回收价值

→ 回收完全空的 Region

→ 筛选出垃圾较多、值得回收的 Old Region，作为 Mixed GC 候选 Region
Mixed GC (完全 STW)

→ STW

→ 回收全部年轻代 + 一部分垃圾多的老年代 Region

→ Evacuation：把活对象复制到新 Region

→ 原 Region 清空
回到 Young GC

→ 重新，如果 Eden Region 满才开始 Young GC，堆占用达到 IHOP 阈值，开启新一轮的操作

Full GC

SerialGC
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足发生的垃圾收集 - full gc
ParallelGC
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足发生的垃圾收集 - full gc
CMS
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足 - 正常情况下只有 major GC，老年代回收，并发收集慢时退化为 full gc
G1
- 新生代内存不足发生的垃圾收集 - minor gc
- 老年代内存不足 - 正常是 mixed gc(全部年轻代+部分老年代)，如果 G1 来不及回收(产生对象速度大于垃圾回收速度)，或没有足够空 Region 让对象复制/晋升，退化为一次 STW 的 full gc

《Java hotspot G1 GC 的一些关键技术》--美团技术团队

Young Collection 跨代引用

新生代回收的时候，需要注意可能有些老年代会引用到新生代，所以还需要检查扫描老年代来确定根对象，逐层向下才能知道新生代到底还是否可达。但是如果每次全量扫描又很耗时，所以有了卡表和 RSet(Remembered Set)。

卡表是说把 Region(不止老年代) 划分成大小相同的 Card，每个大小默认是512B，每个 Region 都有一个自己的 RSet，RSet 是一个 HashTable，Key 是别的 Region 的起始地址，Value 是一个集合，里面的元素是 Card Table 的 Index 集合。比如下面 Region2 的 RSet 中的一条记录就是 Region1 --> { #2 } (这个记录也可以是 Region1 --> { #2, #5, #8 }，因为一个 Region 可能有多个 Card 指向我)

假如说引用关系发生了变化，比如 (Region1)oldObj.field = youngObj(Region2)。那么G1以后 Young GC Region2 的时候，就必须知道 Region1 里有人引用了 Region2，不然就可能误回收 youngObj。当发生引用写入之后，JVM会自动帮我们在这个后面插入一个额外逻辑，post-write barrier，判断两个是不是一个 Region，如果是跨 Region，那么就需要记录 Region1 里有 Card 可能引用了 Region2。假设 oldObj 在 Region1 的第二个 Card，那么 post-write barrier 就会记住 Region1 #2 脏了，标记一下。但是这个时候 JVM 只知道这个 Card 发生过引用写入，但是具体是哪个它不知道，随后把这个 dirty Card 放到脏卡队列。

{% note warning %}

注意：oldObj.field = youngObj 这个赋值操作是已经发生了的，因为我知道对象地址，改引用值还是要改的，RSet 只是在辅助垃圾回收

{% endnote %}

处理脏卡队列 --> Concurrent Refinement Threads 线程来处理(因为引用改的比较频繁，如果每次都更新RSet影响业务了)

取出来一个脏卡
需要遍历这个卡里面所有的对象，看看它的引用指向哪个 Region
更新这些 Region 的 RSet

Young GC 用 RSet --> 假设要回收 Region2

如果没有 RSet，就需要扫描整个老年代，找有没有对象引用 Region2，但是有了 RSet，只需要扫描那些引用它的 Region 的那些卡就可以了

{% note warning %}

但是此时也只知道其他的 Region 的哪些卡引用了 Region2，所以还需要扫描那些卡中哪些对象引用了 Region2 的哪些对象，来判断要不要回收。所以 RSet 只是相当于帮忙缩小了扫描范围。并且 RSet 是记录别的 Region 里有没有对象引用了我(不止老年代)，不需要记录自身，因为 GC 的时候本身也会扫描自己的活对象。

{% endnote %}

{% note danger no-icon %}

String 对象的根对象是 String.class 吗？

不是，String.class 是 Class 对象，也是一种根对象，但是它并不会指向自己的实例(这样 String 对象就不会被释放了)，String 对象头里面的 klass pointer 会指向 String.class，也就是说实例知道自己是哪个类，但是类不知道自己有多少实例。

普通 String 对象靠什么活着？

线程栈引用，比如线程栈的局部变量
java 复制代码
```
public void test(){
    String s = new String("a");
}
```

静态字段引用

java 复制代码

class Holder {
    static String name = new String("a");
}

这个时候引用链就是

text 复制代码

GC Root: Holder.class
        |
        v
static field name
        |
        v
String 对象

老年代对象引用新生代，比如

java 复制代码

static List<String> list = new ArrayList<>(); // 如果 list 已经进入老年代

list.add(new String("abc"));

字符串常量池
{% endnote %}

Remark

重新标记阶段

本节抄自《深入理解Java虚拟机》

前置知识: 三色标记

白色：表示对象尚未被垃圾收集器访问过。
黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

最后扫描完应该只剩下黑色和白色，白色就是垃圾

并发标记阶段可能出现的问题由重新标记来解决。收集器在标记的时候，同时用户线程也在修改引用关系。那就可能出现两种情况

一种是把原本消亡的对象错误标记为存活(比如 A -> B，B 被标记完黑色了，但是之后用户线程又改了引用 A 不指向 B 了，但是 B 对象此时还是标记为存活，实际已经没了，这种不会出错，顶多这次垃圾回收不了了，下次再回收)
另一种是把原本存活的对象错误标记为已消亡，这就是非常致命的后果了，程序肯定会因此发生错误

也就是说，当且仅当以下两个条件同时满足时，会产生"对象消失"的问题，即原本应该是黑色的对象被误标为白色：

赋值器插入了一条或多条从黑色对象到白色对象的新引用；
赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

因此，我们要解决并发扫描时的对象消失问题，只需破坏这两个条件的任意一个即可。由此分别产生了两种解决方案：{% label 增量更新 orange %}（Incremental Update）和{% label 原始快照 orange %}（Snapshot At The Beginning，SATB）。

增量更新要破坏的是第一个条件，当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。

原始快照要破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。这也可以简化理解为，无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。

举例倒数第二个图中，黑色为 A，灰色为 B，白色为 C，当灰色指向白色的被删除的时候，会把 C 保存起来，表示已标记，之后就不会清空了！！！也就是说无论有没有 A 指向 C 都会保留下来。这个时候 C 属于浮动垃圾，下一回合再回收。相当于按照并发标记开始时的对象图快照来判断存活。

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。在HotSpot虚拟机中，增量更新和原始快照这两种解决方案都有实际应用，譬如，CMS是基于增量更新来做并发标记的，G1、Shenandoah则是用原始快照来实现。

对 G1 的优化

JDK 8u20 字符串去重

优点：节省大量内存

缺点：略微多占用了 cpu 时间，新生代回收时间略微增加

java 复制代码

String s1 = new String(new char[]{'h','e','l','l','o'});
String s2 = new String(new char[]{'h','e','l','l','o'});

-XX:+UseStringDeduplication 进行开启

JDK 8u20 的 G1 字符串去重不是在 String 创建时立刻执行，而是在 GC 过程中，G1 扫描存活对象时发现某些"值得去重"的 String，比如已经存活过几次 GC、可能进入老年代的字符串，就把这些 String 对象的引用放入 JVM 内部的去重队列。之后后台的去重线程从队列中取出字符串，计算它内部 char[] 的哈希值，并到字符串去重表中查找是否已有相同内容的字符数组。如果没有，就把当前 char[] 记录到表中，作为后续共享的候选；如果有相同哈希的数组，还会逐字符比较(因为可能会哈希冲突，相当于 equals 比较)，确认内容完全一致后，把当前 String 的 value 属性指向表中已有的那个 char[]。这样多个不同的 String 对象仍然是不同对象，但它们底层可以共享同一个字符数组，原来多余的 char[] 失去引用后会在后续 GC 中被回收，从而节省内存。

注意：与 String.intern() 不一样

String.intern() 关注的是字符串对象，让相同内容的字符串使用同一个引用
而字符串去重关注的是 char[]，不同的 String 还是不同的引用，但是指向的 char[] 是同一份
在 JVM 内部，使用了不同的字符串表 --> 这个也会存一个字符数组表，为了理解，可以记为 Map<Integer, List<char[]>> dedupTable，哈希值作为键，字符数组作为值(注意，可能有哈希冲突，所以可能存多个字符数组)

JDK 8u40 并发标记类卸载

JDK 8u40 之后，G1 支持在并发标记结束后进行类卸载。并发标记会找出堆中所有存活对象，同时追踪这些对象对应的类和类加载器；如果某个类加载器已经不可达，那么它加载的所有类也可以被认为不再使用，并在 Remark 阶段进行卸载，释放对应的 Metaspace 元数据。这个机制主要对自定义类加载器、动态生成类、热部署等场景有意义，因为系统类加载器、启动类加载器通常会一直存活到 JVM 退出。-XX:+ClassUnloadingWithConcurrentMark 默认开启；

🐯 条件比较苛刻

JDK 8u60 回收巨型对象

其实除了 Eden、Survivor、Old 三种 Region 之外，还有一个 Humongous Region 用来存储巨型对象(一个对象大于 Region 的一半)，从逻辑上 Humongous 属于老年代

巨型对象是大小达到或超过一个 G1 Region 一半的对象。它不会进入普通 Eden，而是直接分配到老年代的一组连续 Humongous Region 中；如果对象很大，就可能占用多个连续 Region。G1 对普通对象回收时通常会采用复制/转移，但对巨型对象不会搬动，只判断它是否还存活；如果不可达，就直接回收它占用的整段 Region。因为巨型对象占用空间大，回收收益高，所以 G1 会尽量优先识别可回收的巨型对象。通常情况下，巨型对象会在并发标记结束后的 Cleanup 阶段，或者 Full GC 时被回收；但从 JDK 8u60 起，G1 也可以在 Young GC 时尝试提前回收某些巨型对象，特别是没有或几乎没有有效 incoming references 的巨型对象。这里的 incoming references 是指 G1 通过 remembered set 等结构判断是否还有其他区域、GC Roots 等地方引用这个巨型对象；如果确认没有有效引用，就可以在 Young GC 时直接回收它。

{% note warning %}

都有谁可能指向一个对象？？？

存放在栈里面的局部变量，或者是堆里的对象的字段。所以前面说的可能有老年代对象指向新生代，是指可能老年代中有对象的一个属性指向这个新生代对象。

静态变量、JNI 引用、JVM 内部引用不属于普通 Java 方法栈。它们作为 GC Roots，也间接或直接指向堆中的对象。

{% endnote %}

JDK 9 并发标记起始时间的调整

G1 的并发标记必须在堆空间耗尽前完成，因为只有标记完成后，G1 才知道哪些老年代 Region 垃圾多，后面才能通过 Mixed GC 回收老年代空间。JDK 9 之前，G1 主要通过 -XX:InitiatingHeapOccupancyPercent 设置固定阈值，默认约 45%，阈值太低会导致并发标记过早、浪费 CPU，阈值太高又可能导致标记还没完成堆就满了，从而退化成 Full GC。JDK 9 开始引入 Adaptive IHOP，InitiatingHeapOccupancyPercent 更多作为初始值，G1 会根据历史数据采样，比如并发标记耗时、标记期间老年代分配速度等，动态调整下次并发标记的启动阈值，尽量保证并发标记和后续 Mixed GC 能在堆被占满前及时发生。

也就是什么呢，比如我有 1000MB 空间，预计标记期间会增加 200MB，JVM 又留了 100MB 安全空间，这样就是在使用了 70% 的时候来触发。

GC 调优

类加载与字节码技术

类文件结构

执行 javac -parameters HelloWorld.java，编译为 HelloWorld.class 后是这样的

-parameters 意思是编译时把方法参数名也保存到 .class 文件里，如果不加，你的 name, age 变量名可能就是 arg0, arg1

根据 JVM 规范，类文件结构如下

text 复制代码

ClassFile {
    u4             magic;
    u2             minor_version;
    u2             major_version;
    u2             constant_pool_count;
    cp_info        constant_pool[constant_pool_count-1];
    u2             access_flags;
    u2             this_class;
    u2             super_class;
    u2             interfaces_count;
    u2             interfaces[interfaces_count];
    u2             fields_count;
    field_info     fields[fields_count];
    u2             methods_count;
    method_info    methods[methods_count];
    u2             attributes_count;
    attribute_info attributes[attributes_count];
}

uX 的 X 代表占用几个字节

魔数

0~3 字节，表示它是否是【class】类型文件

0000000 ca fe ba be 00 00 00 34 00 1f 0a 00 06 00 11 09

不同的文件有不同的魔数，Java 的 class 文件的魔数是 ca fe ba be(咖啡宝贝)

版本

0000000 ca fe ba be 00 00 00 34 00 1f 0a 00 06 00 11 09，

00 00 是 minor version，是 0

00 3D 是 major version，是 61，代表 Java 17。00 34(52) 代表 Java 8

常量池

常量池长度

8～9 字节，表示常量池长度，00 1f（31）表示常量池有 #1~#30 项，其中 #0 项不计入，也没有值

常量池 cp_info

常量池的项目类型

tag 值	常量类型	结构	总字节数
`1`	`CONSTANT_Utf8`	`tag + length + bytes`	`1 + 2 + N`
`3`	`CONSTANT_Integer`	`tag + bytes`	`1 + 4`
`4`	`CONSTANT_Float`	`tag + bytes`	`1 + 4`
`5`	`CONSTANT_Long`	`tag + high_bytes + low_bytes`	`1 + 4 + 4`
`6`	`CONSTANT_Double`	`tag + high_bytes + low_bytes`	`1 + 4 + 4`
`7`	`CONSTANT_Class`	`tag + name_index`	`1 + 2`
`8`	`CONSTANT_String`	`tag + string_index`	`1 + 2`
`9`	`CONSTANT_Fieldref`	`tag + class_index + name_and_type_index`	`1 + 2 + 2`
`10`	`CONSTANT_Methodref`	`tag + class_index + name_and_type_index`	`1 + 2 + 2`
`11`	`CONSTANT_InterfaceMethodref`	`tag + class_index + name_and_type_index`	`1 + 2 + 2`
`12`	`CONSTANT_NameAndType`	`tag + name_index + descriptor_index`	`1 + 2 + 2`
`15`	`CONSTANT_MethodHandle`	`tag + reference_kind + reference_index`	`1 + 1 + 2`
`16`	`CONSTANT_MethodType`	`tag + descriptor_index`	`1 + 2`
`17`	`CONSTANT_Dynamic`	`tag + bootstrap_method_attr_index + name_and_type_index`	`1 + 2 + 2`
`18`	`CONSTANT_InvokeDynamic`	`tag + bootstrap_method_attr_index + name_and_type_index`	`1 + 2 + 2`
`19`	`CONSTANT_Module`	`tag + name_index`	`1 + 2`
`20`	`CONSTANT_Package`	`tag + name_index`	`1 + 2`

解释哈，就是在常量池长度后面紧跟着的就是常量池的信息，结构就是 #1, #2, #3 这种顺序，但是每个常量占用的字节不一样，所以根据 tag 值来判断下面紧接着会有几个字符属于这个常量的信息

0000000 ca fe ba be 00 00 00 34 00 1f 0a 00 06 00 11 09

第 #1 项 0a(对应 CONSTANT_Methodref) 表示一个 Method 引用，00 06(6) 和 00 11(17) 表示它引用了常量池中的 #6 和 #17 项来获得这个方法的【所属类】和【方法名和方法描述符】

0000000 ca fe ba be 00 00 00 34 00 1f 0a 00 06 00 11 09

第 #2 项 09 表示一个 Field 引用，00 12 #18 表示【所属类】00 13 #19 表示【字段名和字段描述符】

0000000 ca fe ba be 00 00 00 34 00 1f 0a 00 06 00 11 09