快速扫盲：JVM 内存结构

首先需要区分清楚 JVM 结构 和 JVM 内存结构 与 Java 内存模型。网上很多文章并没有明确区分它们，很容易弄混！JVM 结构指的是 The Structure of the Java Virtual Machine，JVM 内存结构通常指的是 JVM 中 Runtime Data Area（运行时数据区）， 而 Java 内存模型指的是 Memory Model

JVM 结构

JVM 整体分为 5 个部分：

• 类加载器（Class Loader）：加载字节码文件到内存；
• 运行时数据区（Runtime Date Area）：JVM 的核心内存空间；
• 执行引擎（Execution Engine）：对 JVM 指令进行解析，翻译成机器码，解析完成后提交到操作系统中；
• 本地方法接口（Native Method Interface）：供 Java 调用的融合了不同开发语言的原生库；
• 本地方法库（Native Method Library）：Java 本地方法的具体实现。

Java 虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程一一对应的数据区域会随着线程开始和结束而创建和销毁。

• 线程私有：程序计数器、虚拟机栈、本地方法区
• 线程共享：堆、方法区, 堆外内存（Java7的永久代或JDK8的元空间、代码缓存）

运行时数据区的变化

• JDK 1.6：有持久代（永久代），静态变量 存放在 持久代 中；
• JDK 1.7：有持久代，但 字符串常量池、静态变量 存放在 堆 中；
• JDK 1.8：移除持久代，运行时常量池、类常量池 存放在 元空间 中，但 字符串常量池 仍在 堆 中。

程序计数器

程序计数器（Program Counter Register），Register 的命名源于 CPU 的寄存器，寄存器存储指令相关的线程信息，CPU 只有把数据装载到寄存器才能允许

程序计数器 并非广义上的物理寄存器，而是 JVM 中对物理寄存器的一种抽象模拟

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的 行号指示器

作用

1. 指令的顺序执行：程序计数器用于跟踪指令的执行顺序。在指令的执行期间，程序计数器存储着下一条将要执行的指令的地址，使得 CPU 能够按照顺序依次执行指令
2. 分支跳转和函数调用：当程序遇到分支指令（如条件分支、无条件跳转等）或者函数调用指令时，程序计数器用于存储跳转目标的地址。这样，CPU 就能够在执行完当前指令后跳转到指定的目标地址继续执行
3. 线程上下文切换：在多线程环境下，每个线程都有自己独立的程序计数器。当发生线程切换时，操作系统会保存当前线程的程序计数器状态，并加载下一个线程的程序计数器状态，以便 CPU 继续执行下一个线程的指令
4. 异常处理：在发生异常（如中断、陷阱、错误等）时，程序计数器用于存储异常处理程序的入口地址。这样，CPU 在处理完异常后能够恢复到原先的执行状态继续执行程序

总的来说，程序计数器用于存储和跟踪指令的执行地址，保证指令的顺序执行、分支跳转和函数调用的正确性，以及实现线程切换和异常处理等功能

特点

• 程序计数器为线程私有，每个线程都独立计算，不会互相影响
• 占用很小的内存空间，几乎可以忽略不计，也是运行速度最快的存储区域
• 在 JVM 规范中，每个线程都有自己的程序计数器，生命周期与线程的生命周期一致
• 任何时间一个线程都有且仅有一个方法在执行，也称之为 当前方法，如果当前线程执行的是 Java 方法，程序计数器记录的是 JVM 字节码指令地址，如果执行 Native 方法，则是未指定值（undefined）
• 程序执行过程中的分支、循环、跳转、异常、线程恢复等基础功能都依赖程序计数器来完成
• 字节码解释器工作时就是通过改变这个程序计数器的值来选取下一条需要执行的字节码指令
• 程序计数器是 JVM 规范中唯一一个没有规定任何 OutOfMemoryError 情况的区域

虚拟机栈

虚拟机栈（Virtual Machine Stack）早期也叫 Java 栈

虚拟机栈是 JVM 中一种内存区域。每个线程在创建的时候都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次 Java 方法的调用。虚拟机栈为线程私有，生命周期与线程一致。

作用

1. 方法调用和执行：当一个方法被调用时，虚拟机会为该方法创建一个栈帧，并将该栈帧压入到当前线程的虚拟机栈顶。栈帧包含了方法的局部变量、操作数栈、动态链接、返回地址等信息，用于支持方法的执行过程
2. 方法的嵌套调用：虚拟机栈支持方法的嵌套调用。当一个方法内部调用另一个方法时，新方法的栈帧会被压入到虚拟机栈的顶部，形成方法调用链。当方法执行完成时，对应的栈帧会被弹出，控制权会返回到调用者方法的栈帧上
3. 局部变量的存储：虚拟机栈中的栈帧包含了方法的局部变量表，用于存储方法的参数和局部变量。这些局部变量在方法的执行过程中被使用，可以是基本数据类型或对象的引用
4. 异常处理：虚拟机栈也用于支持异常的处理。当发生异常时，虚拟机会在当前线程的虚拟机栈中查找对应的异常处理器，如果找到合适的异常处理器，则会跳转到异常处理器所有的栈帧执行相应的异常处理代码

特点

• 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器
• JVM 直接对虚拟机栈的操作只有两个：每个方法执行，伴随着入栈，方法执行结束出栈
• 栈不存在垃圾回收问题
• JVM 规范允许虚拟机栈的大小是动态或者固定不变的
  • 如果采用固定大小的虚拟机栈，那每个线程的虚拟机栈的容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过虚拟机栈允许的最大容量，JVM 将会抛出一个 StackOverflowError 异常
  • 如果虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那么 JVM 将会抛出一个 OutofMemoryError 异常
• 可以通过 -Xss 来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度

HotSpot JVM 采用的是固定大小的虚拟机栈，所以 HotSpot JVM 不会由于虚拟机栈无法扩展而抛出 OutofMemoryError，只有在创建线程时无法申请到足够的内存才会导致 OutofMemoryError

栈的存储单位

• 每个线程都有自己的栈，栈中的数据都是以 栈帧（Stack Frame）的格式存在
• 在这个线程上正在执行的 每个方法都有各自对应的一个栈帧
• 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息

栈运行原理

• JVM 直接对 Java 栈的操作只有两个，对栈帧的 压栈（入栈） 和 出栈，遵循 FILO/LIFO（先进后出/后进先出）的原则
• 在一个活动线程中，一个时间点上只有有一个活动栈帧，即：只有当前 正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为 当前栈帧（Current Frame），与当前栈帧对应的方法就是 当前方法（Current Method），定义这个方法的类就是 当前类（Current Class）
• 执行引擎所运行的所有字节码指令只针对当前栈帧进行操作
• 如果该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈顶，成为新的当前栈帧
• 不同线程中所包含的栈帧是不允许相互引用的，即不可能在一个栈帧中引用另一个线程的栈帧
• 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着 JVM 会丢弃当前栈帧，使得前一个栈帧成为当前栈帧
• Java 中有两个返回函数的方式，一种是正常函数返回，使用 return 指令，另一种是抛出异常，不管哪种方式，都会导致栈帧被弹出

栈帧的内部结构

每个栈帧中存储着：

• 局部变量表（Local Variables）：局部变量表用于存储方法中的参数和局部变量。它是一个数组结构，每个元素用于存储一个参数或者局部变量的值。局部变量表中的元素可以存储各种类型的数据，包括基本数据类型和对象引用
• 操作数栈（Operand Stack）：操作数栈用于执行方法中的操作和计算。它是一个栈结构，用于存储方法执行过程中的临时数据和中间结果。操作数栈中的元素通常用于执行算术运算、逻辑运算、方法调用等操作
• 动态链接（Dynamic Linking）：动态链接用于支持方法调用的动态绑定和多态特性。它包含了方法在运行时所属类的引用以及方法在运行时常量池的索引。动态链接在方法调用时用于确定方法的真实地址
• 返回地址（Return Address）：返回地址用于存储方法返回时的目标地址。当一个方法被调用时，返回地址会被压入栈帧中，用于指示方法执行完成后返回的位置
• 其他辅助信息：栈帧中可能还包含一些其他的辅助信息，如异常处理信息、调试信息等

局部变量表

• 局部变量表也被称为局部变量数组或者本地变量表
• 局部变量表是建立在线程的栈上，是线程的私有数据，因此 不存在数据安全问题
• 局部变量表所需的 空间大小是编译期确定 下来的，并保存在方法的 Code 属性的 maximum local variables 数据项中，在方法运行期间是不会改变局部变量表的大小的
• 方法嵌套调用的次数由栈的大小决定，栈越大，意味着方法嵌套调用次数越大。对一个函数而言，它的参数和局部变量越多，使得局部变量表越膨胀，它的栈帧也就越大，进而导致函数调用就会占用更多的栈空间，也就导致其嵌套调用的次数就会减少
• 局部变量表中的变量只有在当前方法调用中有效。在方法执行时，JVM 通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁

槽（Slot）

• Slot（槽）是局部变量表最基本的存储单元

• 在局部变量表中，32 位以内的类型只占用一个 Slot，64 位的类型（long、double）占用连个连续的 Slot

  • byte、short、char 在存储前被转换为 int，boolean 也被转换为 int（0-false，1-true）
  • long、double 则占据两个 Slot

• JVM 会为局部变量表中每个 Slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值，索引值的范围从 0 开始到局部变量表最大的 Slot 数量

• 当一个实例方法被调用时，它的方法参数和方法体内定义的局部变量将会 按照顺序被复制 到局部变量表中的每一个 Slot 上

• 如果需要访问局部变量表中一个 64bite 的局部变量值时，只需要使用前一个索引即可

• 如果当前栈帧是由构造方法或者实例方法创建的，那么该对象的引用 this 将会被放在 index 为 0 的 Slot 处，其余的参数按照参数表的顺序继续排列

为什么静态方法中不可以引用 this，就是因为 this 变量不存在这个静态方法的局部变量表中

• Slot 是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后，新申明的局部变量就很有可能复用过期的局部变量 Slot，从而达到节省资源的目的
• 在栈帧中，与性能调优关系最为密切的就是局部变量表，合理的使用局部变量可以提高方法执行效率和内存利用率

常见的局部变量表性能调优方法：

• 避免创建过多的局部变量，尽量使用局部变量进行多次重用，以减少局部变量表的大小
• 避免在循环内部创建大量的局部变量，尤其是在性能敏感的代码中，可以将变量的声明放到循环外部，减少重复对象创建的开销
• 根据变量的实际使用情况选择合适的数据类型，避免使用过大或过小的数据类型，以减少内存占用和提高访问效率
• 对于数值类型的变量，尽量使用 int 或 long 类型，避免使用 float 或 double 类型，除非需要高精度计算
• 如果方法的参数较多，可以考虑将部分参数封装成对象，以减少局部变量表中参数的数量
• 对于频繁调用的方法，可以将参数封装成对象，并将对象作为参数传递，减少参数的个数

• 只要被局部变量表直接或间接引用的对象都不会被垃圾回收

操作数栈

操作数栈（Operand Stack）是用于执行方法操作和计算的临时存储区域，它具有 FILO 的结构，用于存储方法执行过程中的临时数据和中间结果

• 操作数栈就是一个 JVM 执行引擎的一个工作区，当一个方法刚开始执行时，一个新的栈帧也随之被创建出来，此时这个方法的操作数栈是空的
• 每个操作数栈都会拥有一个明确的栈深，用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的 Code 属性的 max_stack 数据项中
• 操作数栈中任何一个元素都可以是任意的 Java 数据类型
  • 32bit 的类型占用一个栈单位深度
  • 64bit 的类型占用两个栈单位深度
• 操作数栈并非采用索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一个数据的访问
• 如果被调用的方法带有返回值的话，其 返回值将会被压入当前栈帧的操作数栈中，并更新程序计数器中下一条需要执行的字节码指令
• 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类校验阶段的数据流分析阶段会再次验证
• JVM 的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈

栈顶缓存

HotSpot 的执行引擎并非是基于寄存器的架构，但这并不代表 HotSpot VM 的实现并没有间接利用到寄存器资源。寄存器是物理 CPU 中的组成部分之一，它同时也是 CPU 中非常重要的高速存储资源。一般来说，寄存器的读/写速度非常迅速，甚至可以比内存的读/写速度快上几十倍不止，不过寄存器资源却非常有限，不同平台下的 CPU 寄存器数量是不同和不规律的。寄存器主要用于缓存本地机器指令、数值和下一条需要被执行的指令地址等数据

基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数和内存读/写次数。由于操作数是存储在内存中的，因此频繁的执行内存读/写操作必然会影响执行速度

栈顶缓存（Top of Stack Cache，简称 TOS）是一种优化技术，用于提高 JVM 中操作数栈的访问速度。它位于 CPU 内部，用于存储常用的操作数栈栈顶元素，以减少对内存的访问次数，从而提高指令的执行效率。

栈顶缓存的容量通常很小，一般只能存储一个或少数几个操作数栈顶元素。栈顶缓存通常由硬件实现，存储在 CPU 内部特定的寄存器中，以提高访问速度。

动态链接

每一个栈帧的内部都包含一个指向运行时常量池中该栈帧所属方法的引用，这个引用的目的是为了支持当前方法的代码能够实现动态链接（Dynamic Linking）

在 Java 源文件被编译到字节码文件中时，所有的变量和方法引用都作为 符号引用（Symbolic Reference） 保存在 Class 文件的常量池中。如：描述一个方法调用了另一个方法时，就是通过常量池中指向方法的符号引用来表示的，动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用

方法的调用

方法调用不同于方法执行，方法调用阶段的唯一任务就是确定被调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。Class 文件的编译过程中不包括传统编译器中的连接步骤，一切方法调用在 Class文件里面存储的都是 符号引用，而不是方法在实际运行时内存布局中的入口地址（直接引用），也就是需要在类加载阶段，甚至到运行期才能确定目标方法的直接引用

TODO：这一块内容，除了方法调用，还包括解析、分派（静态分派、动态分派、单分派与多分派），暂不深入了解

在 JVM 中，将符号引用转换为调用方法的直接引用与方法的绑定机制有关

• 静态链接：当一个字节码文件被装载进 JVM 内部时，如果被调用的 目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
• 动态链接：如果被调用的方法在编译期无法被确定下来，也就是说，只能在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接

对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次

• 早期绑定：早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用
• 晚期绑定：如果被调用的方法在编译器无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式就被称为晚期绑定

虚方法与非虚方法

虚方法

• 虚方法指的是通过对象的引用调用的方法，在运行时根据对象的实际类型来确定调用的方法。在 Java 中，除了 final 方法、private 方法和 static 方法外，其他所有的实例方法都是虚方法
• 虚方法调用通过方法表（Method Table）来实现。每个对象都有一个指向方法表的指针，方法表中存储了对象实际类型的所有方法的引用。当调用虚方法时，JVM 会根据对象的实际类型在方法表中查找方法的地址，并调用实际类型对应的方法

非虚方法

• 非虚方法指的是通过类名调用的方法，或者通过 super 关键字调用的方法。在编译期间就可以确定调用的方法，不需要在运行时根据对象的实际类型来确定
• 非虚方法调用通过静态绑定（Static Binding）来实现。在编译期间就确定了调用的方法，不需要在运行时进行查找和解析

总的来说，虚方法是通过对象引用调用的方法，需要在运行时根据对象的实际类型确定调用的方法；而非虚方法是通过类名调用的方法，或者通过 super 关键字调用的方法，在编译期间就可以确定调用的方法，不需要在运行时进行查找

虚方法表

在面向对象编程中，会频繁的使用到动态分派，如果每次动态分派都要重新在类的方法元数据中搜索合适的目标有可能会影响到执行效率。为了提高性能，JVM 采用在类的方法区建立一个虚方法表（virtual method table），使用索引表来代替查找。非虚方法不会出现在表中

每个类中都有一个虚方法表，表中存放着各个方法的实际入口

虚方法表会在类加载的连接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM 会把该类的方法表也初始化完毕

虚方法表是实现 Java 中多态特性的重要机制之一，它使得方法调用可以根据对象的实际类型动态确定，从而实现了方法的动态绑定和多态性

方法返回地址

方法返回地址（Return Address）用来存放调用该方法的程序计数器的值。

一个方法的结束方式有两种：

• 执行引擎遇到任意一个方法返回的字节码指令，会有返回值传递给上层的方法调用者，简称 正常完成出口。一个方法的正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定。在字节码指令中，返回指令包含 ireturn(当返回值是 boolean、byte、char、short 和 int 类型时使用)、lreturn、freturn、dreturn 以及 areturn，另外还有一个 return 指令供声明为 void 的方法、实例初始化方法、类和接口的初始化方法使用
• 在方法执行的过程中遇到了异常，并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称 异常完成出口。方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码

无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的程序计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过 异常表 来确定的，栈帧中一般不会保存 这部分信息

异常表（Exception Table）是一种用于处理异常的数据结构，它存储了方法中可能抛出的异常信息以及对应的异常处理逻辑。异常表通常包含在方法的字节码中，用于指导 JVM 在方法执行过程中如何处理异常情况，异常表通常包含以下几个字段：

1. 起始地址（Start PC）：表示异常处理代码的起始地址，在方法字节码中的偏移量
2. 结束地址（End PC）：表示异常处理代码的结束地址，在方法字节码中的偏移量
3. 处理代码块地址（Handler PC）：表示异常处理器的地址，在方法字节码中的偏移量
4. 异常类（Catch Type）：表示异常处理器要捕获的异常类型。可以是具体的异常类（如 java.lang.Exception）或其子类，也可以是 null 表示捕获所有异常

本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复下层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。

附加信息

栈帧中还允许携带与 Java 虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息，但这些信息取决于具体的虚拟机实现

本地方法栈

本地方法栈（Native Method Stack）主要用于执行 Java 程序中调用的本地方法（Native Method）。本地方法是用本地语音（如 C 或 C++）编写的方法，通过 JNI（Java Native Interface）与 Java 代码进行交互

本地方法接口

JNI 是 Java 平台的一种编程框架，它允许 Java 代码与本地代码进行交互。JNI 提供了一组标准的接口和协议，使得 Java 程序可以像调用 Java 接口一样的调用本地方法

作用

1. 调用本地方法：当 Java 代码调用本地方法时，JVM 将会在本地方法栈中为改方法创建一个帧（Frame），并执行该方法，本地方法的执行完全由本地方法栈负责管理
2. 存储本地方法的参数与局部变量：本地方法栈中的帧用于存储本地方法的参数与局部变量，这些参数和变量的生命周期与本地方法的调用周期相同
3. 异常处理：本地方法栈也用于处理本地方法中的异常，当本地方法抛出异常时，异常信息会在本地方法栈中传播，直到被合适的异常处理程序捕获或传播至 Java 代码层

特点

• 本地方法栈为线程私有
• 允许线程固定或动态扩展内存
  • 如果线程请求分配的栈容量超过本地方法栈所允许的最大容量，Java 虚拟机会抛出 StatckOverflowError 异常
  • 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存区创建对应的本地方法栈，那么 JVM 会抛出 OutofMemoryError 异常
• 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区，它甚至可以直接使用本地处理器中的寄存器，直接从本地内存的堆中分配任意数量的内存
• 并不是所有的 JVM 都支持本地方法，因为 JVM 规范中并没有明确要求本地方法栈使用的语言、具体实现方式、数据结构等。如果 JVM 产品不打算支持 native 方法，也可以无需实现本地方法栈
• 在 Hotsport JVM 中，直接将本地方法栈与虚拟机栈合二为一

堆内存

JVM 的堆内存是用于存储 Java 应用程序运行时创建对象实例和数组的内存区域。堆内存是 JVM 管理的最大一块内存区域之一，它在 JVM 启动时就被分配，并且在运行时动态地增长和收缩，以满足应用程序的需求

为了进行高效的垃圾回收，JVM 将堆内存 在逻辑上 划分为三块区域

• Young Gen（新生代）：新对象和没有达到一定年龄的对象都在新生代，里面还分为：Eden（伊甸区）、Survivor0（From）、Survivor1（To）
• Old Gen（老年代）：被长时间使用的对象，一般是从新生代晋升过来的对象
• Perm/Metaspace（持久代/元空间）：jdk1.8 之前为持久代，用于储存类的元数据信息，如类名、方法、常量池等，占用堆内存；jdk1.8及以后被元空间取代，直接使用物理内存

JVM 规范规定，Heap 可以处于处理上不连续的内存空间中，只要逻辑上连续即可，像磁盘空间一样。实现时，既可以是固定大小，也可以是可扩展的，主流虚拟机都是可扩展的，如果堆中没有完成实例分配，并且堆无法再扩展时，就会抛出 OutofMemoryError 异常

新生代

新生代是大部分新对象创建的地方。新生代被划分为三个部分——Eden（伊甸区）和两个 Survivor（幸存区，也被称为 from/to 或 s0/s1），默认比例是 8:1:1。当 Eden 被填满时，会触发垃圾回收 Minor GC

• 大多数新创建的对象都位于 Eden 内存空间中
• 当 Eden 空间被对象填满时，执行 Minor GC，并将所有幸存者对象移动到一个新存在空间中
• Minor GC 检查幸存者对象，并将它们移动到另一个幸存者空间，所以每次都会有一个幸存者空间是空的
• 经过多次 Minor GC 循环后存活下来的对象会被移动到老年代。可以通过 -XX:MaxTenuringThreshold 参数指定对象经过多少次垃圾回收后，任然存活，就将其晋升到老年代（默认 15 次）

老年代

除了上面所讲的，对象在新生代中达到一定年龄后进入老年代的情况外，大对象会直接被分配到老年代，而不是在新生代进行复制。 这样做的原因是避免在新生代进行复制时可能导致的性能问题 。

可以通过 -XX:PretenureSizeThreshold 配置大对象的阈值（此参数仅适用于 Serial 和 ParNew 两款新生代收集器）

另外，HotSPot 并不会一定严格按照设置的年龄阈值进行筛选进入老年代的对象，满足以下条件也能直接进入老年代：

1. Survivor 区中，年龄从 1 到 N 的对象大小之和超过 Survivor 区空间的 50%
2. 新生代中年龄大于等于 N 的对象

如果在Survivor空间中相同年龄所有对象大小的总和大于 Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到-XX： MaxTenuringThreshold中要求的年龄。 ——《深入理解 java 虚拟机》

这里对象大小总和是按年龄从小到大累加的，并不是同龄对象

这里的 50% 是可以通过参数配置的：-XX:TargetSurvivorRatio

元空间

不管是 jdk1.8 之前的永久代，还是 jdk1.8 及以后的元空间，都可以看作是 JVM 规范中方法区的实现

较大的区别就是，jdk1.8 之前的永久代在堆内存中，而 jdk1.8 及以后的元空间是在物理内存中的

虽然 JVM 规范把方法区描述为堆的一个逻辑部分，但是它缺有一个别名叫 Non-Heap（非堆），目的是与堆区分开来。所以元空间放到方法区部分具体来讲

堆内存相关配置

• -Xms：堆内存初始大小，默认为物理内存的 1/64
• -Xmx：堆内存最大大小，默认为物理内存的 1/4
• -XX:newsize：新生代初始大小
• -XX:Maxnewsize：新生代最大大小
• -Xmn：新生代的大小，默认为堆内存的 1/3 或 1/4，等于 -XX:Newsize 等于 -XX:Maxnewsize
• -XX:NewRatio：新生代与老年代的比例，默认为 2，表示老年代是新生代的 2倍，即新生代占堆内存的 1/3。-Xmn 的优先级高于 -XX:NewRatio
• -XX:Survivorratio：新生代中 Eden 区与 Survivor 区的比例，默认为 8，表示 Eden 区是 Survivor 区的 8倍，即 Eden 区与 Survivor 区的比例为：8:1:1
• -XX:PermSize（jdk1.8 之前）：永久代的初始大小
• -XX:MaxPermSize（jdk1.8 之前）：永久代的最大大小

垃圾回收简介

JVM 在进行 GC 时，并非每次都对堆内存（新生代、老年代；方法区）区域一起回收的，大部分时候回收的都是新生代

针对 HotSpot VM 的实现，它里面的 GC 按照回收区域又分为两大类：部分收集（Partial GC），整堆收集（Full GC）

• 部分收集
  • 新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集
  • 老年代收集（Major GC/Old GC）：只是老年代的垃圾收集（仅 CMS GC 会单独收集老年代）
• 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集（仅 G1 GC 会混合收集）
• 整堆收集（Full GC）：收集整个 Java 堆和方法区的垃圾

大多数时候 Major GC 会和 Full GC 混合使用，需要具体分辨是老年代回收还是整堆回收

TLAB

TLAB（Thread-Local Allocation Buffer，线程本地分配缓冲区）是用于提高多线程并发情况下对象分配效率的一种技术

问题

• 堆内存是线程共享的，任何线程都可以随时访问到堆中的共享数据
• 由于对象实例的创建在 JVM 中十分频繁，因此在并发环境下从堆中划分内存空间是线程不安全的
• 为避免多个线程同时操作同一地址，需要加锁等机制，影响分配速度

解决

JVM 在 Eden 区中为每个线程一个私有的、专属于该线程的小型内存区域——TLAB，用于存放该线程在堆中分配的对象。这样做的目的是避免多线程并发情况下的锁竞争，从而提高对象分配的性能

当一个线程需要分配对象时，它可以直接在自己的 TLAB 中进行分配，而无需竞争全局的分配锁。这样可以大大减少线程间的竞争，并且减少了分配操作的开销，因为对象的分配是在私有的 TLAB 中进行的，不需要进行额外的同步操作

可以通过参数 -XX:UseTLAB 配置是否开启 TLAB

默认情况下，TLAB 占用的内存非常小，仅占整个 Eden 区的 1%，不过可以通过参数 -XX:TLABWasteTargetPercent 设置 TLAB 空间占 Eden 空间的百分比大小

一旦对象在 TLAB 空间分配内存失败时，JVM 就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在 Eden 空间中分配内存

尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选

逃逸分析

随着 JIT 编译期的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么「绝对」了 ——《深入理解 Java 虚拟机》

逃逸分析（Escape Analysis）是一种编译器优化技术，用于确定对象的生命周期以及是否可以被限定在方法或线程范围内而不需要在堆上分配。逃逸分析的目标是识别那些可以在栈上分配而不需要在堆上分配的对象，从而减少堆内存的使用和垃圾回收的压力，提高程序的性能。

逃逸分析的基本行为就是分析对象动态作用域：

• 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸
• 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。（如作为调用参数传递到其他地方）

e.g.

public static StringBuffer craeteStringBuffer(String s1, String s2) {
   StringBuffer sb = new StringBuffer();
   sb.append(s1);
   sb.append(s2);
   return sb;
}

StringBuffer sb 是一个方法内部变量，上述代码中直接将 sb 返回，这样这个 StringBuffer 有可能被其他方法所改变，这样它的作用域就不只是在方法内部，虽然它是一个局部变量，但是其逃逸到了方法外部。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸

上述代码如果想要 StringBuffer sb 不逃出方法，可以这样写：

public static String createStringBuffer(String s1, String s2) {
   StringBuffer sb = new StringBuffer();
   sb.append(s1);
   sb.append(s2);
   return sb.toString();
}

不直接返回 StringBuffer，那么 StringBuffer 将不会逃逸出方法

作用

逃逸分析通常结合即时编译器（Just-In-Time Compiler，JIT）使用，以便在运行时动态地进行分析和优化。一些现代的即时编译器可以利用逃逸分析的结果来进行优化，例如将对象分配在栈上、进行标量替换等

使用逃逸分析，编译器可以对代码做优化：

• 栈上分配：将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配
• 同步省略：如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步
• 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而存储在 CPU 寄存器

JIT 编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无需进行垃圾回收了。

常见栈上分配的场景：成员变量赋值、方法返回值、实例引用传递

配置

• 在 JDK 6u23 版本之后，HotSpot 中默认就已经开启了逃逸分析
• 如果使用较早版本，可以通过 -XX"+DoEscapeAnalysis 显式开启

栈上分配

我们通过 JVM 内存分配可以知道 JAVA 中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠 GC 进行回收内存，如果对象数量较多的时候，会给 GC 带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数量，JVM 通过逃逸分析确定该对象不会被外部访问。那就通过标量替换将该对象分解在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力

同步省略

线程同步的代价是相当高的，同步的后果是降低并发性和性能

在动态编译同步块的时候，JIT 编译器可以借助逃逸分析来判断同步块所使用的锁对象是否能够被一个线程访问而没有被发布到其他线程。如果没有，那么 JIT 编译器在编译这个同步块的时候就会取消对这个代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫做 同步省略，也叫锁消除

public void keep() {
  Object keeper = new Object();
  synchronized(keeper) {
    System.out.println(keeper);
  }
}

如上代码，代码中对 keeper 这个对象进行加锁，但是 keeper 对象的生命周期只在 keep() 方法中，并不会被其他线程所访问到，所以在 JIT 编译阶段就会被优化掉。优化成：

public void keep() {
  Object keeper = new Object();
  System.out.println(keeper);
}

标量替换

标量（Scalar）是指一个无法再分解成更小的数据的数据。Java 中的原始数据类型就是标量

相对的，那些的还可以分解的数据叫做聚合量（Aggregate），Java 中的对象就是聚合量，因为其还可以分解成其他聚合量和标量

在 JIT 阶段，通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM 不会创建该对象，而会将该对象成员变量分解若干个被这个方法使用的成员变量所代替。这些代替的成员变量在栈帧或寄存器上分配空间。这个过程就是 标量替换

通过 -XX:+EliminateAllocations 可以开启标量替换，-XX:+PrintEliminateAllocations 查看标量替换情况

public static void main(String[] args) {
   alloc();
}

private static void alloc() {
   Point point = new Point(1,2);
   System.out.println("point.x=" + point.x + "; point.y=" + point.y);
}

class Point {
    private int x;
    private int y;
}

以上代码中，point 对象并没有逃逸出 alloc()，并且 point 对象是可以拆解成标量的。那么，JIT 就不会直接创建 Point 对象，而是直接使用两个标量 int x ，int y 来替代 Point 对象

private static void alloc() {
   int x = 1;
   int y = 2;
   System.out.println("point.x=" + x + "; point.y=" + y);
}

关于逃逸分析的论文在1999年就已经发表了，但直到JDK 1.6才有实现，而且这项技术到如今也并不是十分成熟的

其根本原因就是 无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程

一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了

虽然这项技术并不十分成熟，但是他也是即时编译器优化技术中一个十分重要的手段

方法区

方法区（Method Area）与堆一样，是 所有线程共享的内存区域，它用于存放已被 JVM 加载的类信息、常量、静态变量以及 JIT 编译器编译后的代码等数据。

结构

• 运行时常量池：每个加载的类型（类或接口）都有一个常量池，它存储了类中定义的常量以及对其他类、方法、字段的引用
• 类型信息：这包括类的名称、父类的名称、方法和字段的信息、以及修饰符
• 字段和方法数据：包括字段和方法的名称、类型、修饰符等信息
• 方法的字节码：类中方法的实现代码，以字节码的形式存储

常量池

每个有效的字节码文件中都包含一个常量池（常量池表，Constant Pool Table），常量池（表）主要包括：

• 数量值
• 字符串值
• 类引用
• 字段引用
• 方法引用

JVM 根据常量池（表）找到要执行的类名、方法名、参数类型、字面量等

常量池（表）会在类加载到 JVM 后放入到方法区的运行时常量池中

运行时常量池

• 在加载类和结构到虚拟机后，就会创建对应的运行时常量池
• 常量池（表）是 Class 文件的一部分，用于存储编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
• JVM 为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的
• 运行时常量池中包含各种不同的常量，包括编译器就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或字段引用。此时不再是常量池中的符号地址了，这里换为真实地址
• 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则 JVM 会抛出 OutOfMemoryError 异常

运行时常量池相较于常量池（表）的一个重要特征是——动态性，Java 并不要求常量一定只在编译期产生，运行期也可以将新的常量放入池中，String 的 intern() 方法就是如此

虽然每个类都有自己的常量池，但这些常量池的内容在内存中是共享的，以提高内存利用率和减少重复数据的存储

持久代与元空间

需要注意的是，方法区只是 JVM 规范中定义的一个概念，用于存储类信息、常量池、静态变量、JIT 编译后的代码等数据，并没有规定如何去实现它，不同的厂商有不同的实现方式。而 持久代（PermGen）是 Hotspot VM 特有的概念，并在 Java8 中被元空间取代，所以持久代和元空间都可以理解为方法区的实现

持久代与元空间比较大的区别在于：

• 持久代是堆的一部分，受垃圾回收器的管理，而 元空间是物理内存，不受垃圾回收器的管理
• 持久代中存储类的元数据、静态变量、字符串常量池，而 元空间存储类的元数据，静态变量与字符串常量池在堆中
• 持久代中的类信息是与类加载器实例相关联的，当一个类加载器实例被回收时，其加载的类信息也会被卸载，元空间中的类元数据信息不再与类加载器实例相关联，而是与运行时数据区的其他部分一样，由操作系统的本地内存管理器来管理。这意味着，即使类加载器实例被回收，其加载的类信息也不会被立即卸载，只有当没有引用指向该类时，类的元数据信息才会被释放

移除永久代的原因

• 永久代的空间大小难以确定

  在某些场景下，如果动态加载类过多，容易产生 Perm 区的 OOM。如果某个实际 Web 工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现 OOM

• 对永久代进行调优较困难

• （整合 JRockit 和 HotSpot）

元空间的分配

元空间的分配与类加载器耦合在一起

元空间通过 mmap 来从操作系统申请内存，申请的内存会被分成一个个 Metachunk，以 Metachunk 为单位将内存分配给类加载器，每个 Metachunk 对应唯一一个类加载器，一个类加载器可以有多个 Metachunk

JVM 中每个类加载器都有一个 ClassLoaderData 的数据结构，ClassLoaderData 内部有管理内存的 Metaspace，Metaspace 在 initialize 的时候会调用 get_initialization_chunk 分配第一块 Metachunk，类加载器在加载类的时候是以 Metablock 为单位来使用 Metachunk

• used：chunk 中已经使用的 block 内存，这些 block 中都加载了类的数据
• capacity：在使用的 chunk 内存
• commited：所有已分配的 chunk 内存，这里 包含空闲可再利用的
• reserved：一共可使用的内存大小

当加载一个类并准备在 JVM 中运行时，其 类加载器会分配元空间来存储该类的元数据

垃圾回收

有些人认为方法区（如 Hotspot 虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java 虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如 JDK11 时期的 zGC 收集器就不支持类卸载）

持久代的垃圾回收

在 JDK1.8 之前的版本中，持久代用于存储类的元数据信息、静态变量、常量池等。持久代的垃圾回收是由 JVM 的垃圾回收器来执行的，但是持久代的垃圾回收器并不像新生代和老年代的垃圾回收器那样频繁执行垃圾回收。持久代的垃圾回收通常在以下情况下触发：

• 类加载器的卸载：当一个类加载器实例被回收时，与其相关的类信息也会被卸载，从而释放持久代中的空间
• Full GC：在进行Full GC时，持久代也会被扫描和清理，但是持久代的垃圾回收并不像新生代和老年代那样频繁

元空间的垃圾回收

与其说元空间的垃圾回收，更贴切的说应该是 类和接口的卸载（Unloading of Classes and Interfaces)

JDK1.8 及之后的版本中引入了元空间来取代持久代。元空间中的类元数据信息不再受到 JVM 的垃圾回收器的管理，而是由操作系统的本地内存管理器进行管理。因此元空间中的垃圾回收与持久代有着根本上的不同

在元空间中，类的元数据信息会根据需要动态分配和释放，不再依赖于 JVM 的垃圾回收器来进行管理。当类加载器实例被回收时，其加载的类信息也不会立即被释放，只有当没有引用指向该类时，类的元数据信息才会被释放，这样可以避免持久代中可能出现的内存溢出问题

方法区的垃圾回收主要涉及两部分：

• 常量池中废弃的常量
  • 字面量：文本字符串、final 常量等
  • 符号引用
    • 类和接口的全限定名
    • 字段的名称和描述符
    • 方法的名称和描述符
• 不再使用的类
  • 该类所有的实例都被回收，即堆中没有该类及其派生类的实例
  • 该类的累加器被回收（除非是经过精心设计过的可替换类加载器的场景，如 OSGi、JSP 的重载等，否则一般很难达成）
  • 该类对应的 Class 对象没有在任何地方被引用，即无法在任何地方通过反射访问该类的方法

元空间内存的释放并不一定意味着将内存归还给操作系统

全部或部分内存可能保留在 JVM 中，它可能被重用于加载新的类

Java 虚拟机被允许堆满足上述三个条件的无用类进行回收，这里说的仅仅是「被允许」，而并不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot 虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class 以及 -XX:+TraceClassLoading 、-XX:+TraceClassUnLoading 查看类加载和卸载信息

在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出

元空间调优

-XX:MaxMetaspaceSize 和 -XX:CompressedClassSpaceSize 是控制元空间大小的两个重要参数

• MaxMetaspaceSize：这是对已提交的元空间大小的最大值限制。它包括 非类空间 和 类空间。从技术上讲，这是一个「软」限制，因为只是希望有一个限制，没有必要的技术原因。这是可选的，默认情况下是关闭的
• CompressedClassSpaceSize：这是对 压缩类空间 的虚拟大小的限制。需要在虚拟机启动时指定它，并且不能更改，因此它是「硬」限制，默认为 1G

上图红色部分是元空间已提交部分的总和，包括 非类空间 和一个巨大的 类空间。这个总和受到 -XX:MaxMetaspaceSize 的限制。当尝试提交的内存超过 -XX:MaxMetaspaceSize 将导致 OutOfMemoryEror: Metaspace 异常

-XX:MaxMetaspaceSize 的目的很简单，就是为已提交的元空间大小设置一个最大限制，让它不要超过这个点

另方面，-XX:CompressedClassSpaceSize 决定了那个巨大的 类空间 的大小。它包括已提交部分（红色）和未提交部分（蓝色），如果超过限制将导致 OutOfMemoryError: Compressed Class Space 异常

可以通过 -XX:UseCompressedClassPointers 开关控制是否使用 压缩指针，默认情况下是打开的，如果关闭将不会有压缩空间，那么元空间的大小仅受 -XX:MaxMetaspaceSize 的限制

当加载一个 Java 类时，它需要来自 类空间 和 非类空间 的内存，前者始终受限，即使 -XX:MaxMetaspaceSize 没有限制，但实际上也受限于内存大小

这个限制的触发取决于加载类的大小，这决定了类空间和非类空间的使用比例

假设每个类的类空间和非类空间的合理比例为 1:5，这意味着当 -XX:CompressedClassSpaceSize 为默认值 1G 时，元空间的限制将为 6G，1G 的类空间和 5G 的非类空间

类空间与非类空间

对于每个加载的类，都会从类空间和非类空间中分配内存

类空间中，klass 结构被分配固定大小，接着是两个变量：vtable 和 itable，前者的大小随方法数量的增加而增长，后者的大小随实现方法或继承方法数量的增加而增长。而后是一个描述 Java 类中对象引用的成员位置的映射，即非静态 Oopmap，尽管这个结构通常非常小，但也是可变大小的

vtable 和 itable 通常很小，但是对于异常大的类来说，可以增长到巨大的规模。一个具有 30000 个方法的类的 vtable 大小将近 240k，而这个类的派生类的 itable 大小也将如此

在非类空间中，里面有许多东西，其中主要是：

• 常量池，可变大小的
• 任何类方法的元数据：ConstMethod 结构以及与之关联的大量嵌入式结构，如方法字节码、局部变量表、异常表、参数信息、签名等
• 用于控制 JIT 的运行时方法数据
• 注解

这里暂时可以理解为非类空间是元空间中具体实现方法区的部分

下面是来自 Thomas Stüfe 在一个 WildFly 服务器中所统计的元空间使用情况

类加载器	类的数量	非类空间大小（平均每个类）	类空间大小（平均每个类）	非类空间与类空间的比例
ALL	11503	60381k(5.25k)	9957k(0.86k)	6.0 : 1
Bootstrap	2819	16720k(5.93k)	1768k(0.62k)	9.5 : 1
App	185	1320k(7.13k)	136k(0.74k)	9.7 : 1
Anonymous	869	1013k(1.16k)	475k(0.55k)	2.1 : 1

对于标准类（假设 BootstrapClassLoader 和 AppClassLoader 加载的类视为标准），平均每个类约有 5-7k 的非类空间和 600-900B 的类空间

匿名（Anonymous）类要小得多，这并不奇怪，但有趣的是，类空间和非类空间的比例也发生了扭曲，相对于非类空间，我们需要更多的类空间。因为 Lambda 类非常小，但是 Klass 结构的开销不能缩小到小于 Klass 结构本身的大小，因此，我们大约需要 1k 的非类空间，0.5k 的类空间

元空间默认大小

如果不对元空间进行任何限制，它可以容纳多少个类？

默认情况下 MaxMetaspaceSize 是不限制的，CompressClassSpaceSize 为 1G。这意味着唯一的限制来自 CompressClassSpaceSize

按上面的统计（5-7k 的非类空间，600-900B 的类空间），理想情况下（如果没有碎片，没有浪费），我们可以容纳大概 100万 到 150万 个类，然后会在压缩类空间中遇到 OutOfMemoryError。这是十分多的元数据，肯定是过度的

然后，CompressClassSpaceSize 只是保留空间，而不是已提交的空间。因此，它「并不会造成太大影响」，实际上我们只使用了类空间的已提交部分而已

限制元空间大小

相较于堆内存，我们可以在一定范围内增加或减少堆内存，而不影响程序的主要功能，但元空间中没有这种灵活性

那为什么要限制元空间大小呢？

• 作为一个告警系统，一个「合理的封装」，以便知道元空间的消耗是否比应该的大，以及是否应该进行检查
• 虚拟内存大小可能会导致虚拟进程达到配额，所以需要限制

JDK 版本的依赖性：JDK1.8 中的元空间受到碎片化的影响比 JDK11 或更高版本更严重。记住这一点，并在旧版本的 JDK 上添加一个健康的余量

如果想限制元空间大小以获得一个「合理的封装」，并且不关心虚拟进程的大小，最好只设置 MaxMetaspaceSize 并保持 CompressedClassSpaceSize 不变。

除此之外，减少 CompressedClassSpaceSize 的唯一理由就是为了减少虚拟进程的虚拟内存大小。但请记住，如果将 CompressedClassSpaceSize 设置得太低，可能会在使用完 MaxMetaspaceSize 之前填满压缩类空间。也就是说，1:2（CompressedClassSpaceSize = MaxMetaspaceSize * 2）的比率对于大多数情况来说应该是安全的

那么，您应该将 MaxMetaspaceSize 设置为多大呢？首先计算平均预期的元空间使用量。作为一个初步的指导，您可以使用上面给出的数字，并加上一个安全边际——每个类约1K的类空间，每个类约 8k 的非类空间 - 然后将这些数字乘以您期望加载的类的数量

因此，例如，如果您的应用程序计划加载 10000 个类，理论上您只需要 10M 的类空间，80M 的非类空间

现在您需要考虑一个安全边际。对于大多数情况来说，2倍 的因子是一个安全的限制。当然，您也可以选择更低的倍数并尝试您的运气，但要准备好通过修改代码或增加 MaxMetaspaceSize 来处理元空间的 OOM

2倍 的因子将我们带到 20M 的类空间，160M 的非类空间，这样总的元空间大小就是 180M。因此，-XX:MaxMetaspaceSize=180M 将是一个很好的第一次近似值

压缩类空间

在 64 位的平台上，HotSpot 使用「压缩对象指针」（CompressedOops）和「压缩类指针」（Compressed Class Pointers）的优化技术。（二者都是相同事物的变体）

压缩指针是一种引用数据的方式，使得堆中的对象或元空间中的元数据 即使在 64 位平台上也使用 32 位引用

这有许多优点，例如，较小的指针大小可以 减少内存占用 和 更好的利用缓存，并且在某些平台上还可以使用更多的寄存器

关于压缩对象指针的详细解释可以在这里找到：JVM Anatomy Quark #23: Compressed References

此外，类似的动机也推动了 Linux x32 abi

由于最终需要 64 位地址来访问对象，这个 32 位的「指针」实际上只是一个偏移量（到具有已知公共基地址区域的位移）

对于元空间，我们不关心压缩对象指针，只关注压缩类指针

每个 Java 对象的头部都有一个引用，用来指向堆之外的一个本机结构，即元空间的 Klass

当使用压缩类指针时，这个引用是一个 32 位的值。为了找了实际 64 位的地址，会将一个已知的公共基地址加到上面，还可能左移三位

压缩类指针对分配这些 Klass 结构的位置有技术限制：

每个 Klass 结构的可能位置必须落在一个 4G（未左移模式）| 32G（左移模式）的范围内，以便通过与公共基址的 32 位偏移量来访问

原文：Each possible location of a Klass structure must fall within a range of 4G (unshifted mode)|32G(shifted mode), to be reachable with a 32bit offset from a common base

这两个限制意味着我们需要将元空间分配为一个连续的区域

通过系统 API（如 malloc(3) 或 mmap(3)）从系统中分配内存时，地址由系统选择，可以是适合类型范围的任何值。因此，在 64 位平台上，不能保证后续分配的地址在范围限制内。如一个 mmap(3) 调用可能映射到 0x0000000700000000，另一个可能在 0x0000000f00000000

因此，我们必须使用单个 mmap() 调用来建立用于 Klass 对象的区域。所以，我们需要预先知道此区域的大小，它不能大于 32G，由于结束后的地址范围可能已被占中，导致它永远无法可靠地扩展

虽然这些限制是严格的，但它们实际上只对 Klass 结构有所要求，而不对其他元数据有所要求。目前只有 Klass 实例使用压缩引用进行寻址，其他元数据使用 64 位指针进行寻址，从而可以放在任何位置

因此决定将元空间分为两个部分：「类空间」与「非类空间」

• 类空间：包含 Klass 结构，必须作为一个连续的区域分配，其大小不能超过 32G
• 非类空间：包含其他所有内容，没有连续内存限制

类空间也被称为「压缩类空间」，尽管有点用词不当，因为 Klass 结构本身并没有被压缩，只是指向它们的指针被压缩

压缩类空间（类空间）的大小由 -XX:CompressedClassSpaceSize 决定。除非我们需要预先知道类空间的大小，否则默认为 1G

然而令人困惑的是，HotSpot 将 CompressedClassSpaceSize 的最大值限制在 3G（不知道为什么这样做）。所以除了 32G 的技术限制外，还有一个人为的 3G 限制

由于一个 Klass 结构的平均大小约为 1k，所以一个具有 1G 默认大小的压缩类空间将能容纳大于 100万 个 Klass 结构，这也将是我们 可以加载的类的数量限制。

还要注意，在我们没有开启压缩对象指针的情况下，压缩类指针会被禁用。

-XX:+UseCompressedOops 启用压缩对象指针

-XX:+UseCompressedClassPointers 启用压缩类指针

两者默认情况下都是打开的，但可以手动关闭

如果关闭压缩类指针，那么压缩类空间的配置 -XX:CompressedClassSpaceSize 将被忽略

-XX:+UseCompressedClassPointers 需要 -XX:+UseCompressedOops，但反之不然，可以在没有压缩类指针的情况下使用压缩对象指针，这种有助于在某些病态的极端情况下减少元空间的内存占用。一般来说，建议保留这些

要注意的是，压缩对象指针需要堆内存小于 32G，否则将被关闭，也将连带关闭压缩类指针

Thanks

JVM基础-JVM 内存结构

一文讲清 JVM 内存结构 | 极客视点

JVM内存模型总结，有各版本JDK对比、有元空间OOM监控案例、有Java版虚拟机，综合学习更容易！

什么是元空间

调整元空间

什么是压缩类空间