JVM源码

这里需要用attach到一个java进程，

利用jps可以查看到相关指令

将进程号输入进去，我这里换了一个程序，进程号不同

会看到运行的Java Thread

查看main线程的调用栈

实操：
```java
public class Hello {

    public static void main(String[] args) {
        int[] a = new int[] {1,2,3};
        Hello[] hello = new Hello[2];
        Hello h = new Hello();

        while(true);
    }
}
```
利用HSDB查看main线程的调用栈，由于栈的规则是先进后出，也就是说意味着，当前方法栈的栈底存放的是当前方法的参数args,其次是int数组，Hello对象数组，我们可以查看它们的内存地址中都包含了哪些内容

基本数据类型的klass模型,还可以看到数组的内容

引用类型数组的klass模型，我们在代码中创建的Hello数组对象引用都是空的

引用类型的klass模型

也就是_java_mirror，这里c++上的注解也是说明了这个InstanceMirroKlass的存在

加载
1.通过类的全限定名获取存储该类的class文件(没有指明必须从哪获取)
2.解析成运行时数据，即instanceKlass实例，存放在方法去
3.在堆区生成该类的Class对象，即instanceMirrorKlass实例

程序随便你怎么写，随便你用什么语言，只要能达到这个效果即可。就是说你可以改写openjdk源码，你写的程序能达到这三个效果即可。
预加载:包装类、String、Thread
因为没有指明必须从哪获取class文件，脑洞大开的工程师们开发了这些:
1.从压缩包中读取。如jar、war
2.从网络中获取，如Web Applet
3.动态生成,如动态代理、CGLIB
4.由其他文件生成，如JSP
5.从数据库读取
6.从加密文件中读取

验证
1.文件格式验证。如验证class文件中是否包含魔数(CAFE BABE)、主次版本号是否在当前虚拟机处理范围之内
2.元数据验证。如这个类是否有父类、这个类的父类是否继承了不允许被继承的类(如被final修饰的类)
3.字节码验证。整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析确定程序语义是合法的，如保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况:在操作数栈放置了一个int类型的数据，使用时却按long类型来加载如本地变量表中
4.符号引用验证。最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看作是堆类自身以外的(常量池中的各种符号引用)的信息匹配性校验，如符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用中的类和字段一级方法的访问性是否可以被当前类访问(比如调用静态方法，检查调用的方法是否可以被当前类调用)

准备
为静态变量分配内存、赋初值。实例变量是在创建对象的时候完成赋值的，没有赋初值这一说。如果是被final修饰，在编译的时候会给属性添加ConstantValue属性，准备阶段直接完成赋值，即没有赋初值这一步

解析
将常量池中的符号引用转为直接引用。解析后的信息存储在ConstantPoolCache类实例中。其中会涉及到如下:
1.类或接口的解析
2.字段解析
3.方法解析
4.接口方法解析

符号引用(Symbolic References):符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。可以理解为静态常量池的索引
直接引用(Direct References): 直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的.某个变量的内存地址

解析的时机？
1.加载阶段解析常量池时(类加载以后马上解析 resolve的参数需要改为 => true)
2.用的时候
解析什么？只要是直接引用都需要解析
1.继承的类、实现的接口
2.属性
3.方法
如何避免重复解析:
借助缓存，ConstantPoolCache(运行时常量池的缓存) if (klass -> is_resolved()) {}如图所示
常量池缓存:
key: 常量池的索引 2
value: String -> ConstantPoolEntry
静态属性是存储在堆区中的，
静态属性的访问:
1.去缓存中去找，如果有直接返回
2.如果没有就触发解析
底层实现:
1.会找到直接引用
2.会存储到常量池缓存中

openjdk是第二种思路，在执行特定的字节码指令之前进行解析:anewarray、checkcase、getfield、instanceof、invokeddynamic、invokeinterface、invokesepcial、invokestatic、invokevirtual、ldc、ldc_w、ldc2_w、multianewarray、new、putfield.

初始化
执行静态代码块，完成静态变量的赋值。类初始化阶段时类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制，到了初始化阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，变量已经赋过一次系统要求的初始值,而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度表达:初始化阶段时执行类构造器<clinit>()方法的过程。
1.<clinit>()方法时由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，可以在前面的静态语句块中赋值，但是不能访问，如图所示
2.<clinit>()方法与类的构造函数(或者说实例构造器<init>()方法)不同，它不需要显示地调用父类构造器，虚拟机会保证在子类地<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object
3.由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
4.<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法
5.虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞(需要注意的是，其他线程虽然会被阻塞，但如果执行<clinit>()方法的那条线程退出<clinit>()方法后，其他线程唤醒之后不会再次进入<clinit>()方法。同一个类加载器下，一个类型只会初始化一次)。

何时初始化?主动使用时
1.new、getstatic、putstatic、invokestatic
2.反射
3.初始化一个类的子类会去加载其父类
4.启动类(main函数所在类)
5.当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic、REF_put_static、REF_invoke_Static的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先触发其初始化。

卸载
判定一个类是否是"无用的类"的条件相对一个实例对象或者"废弃常量"要苛刻很多。类需要同时满足下面3个条件才能算是"无用的类":
1.该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2.加载该类的ClassLoader已经被回收
3.该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
虚拟机可以堆满足上述3个条件的无用类进行回收，这里说的仅仅是"可以"，而并不是和对象一样，不使用了，就必然会回收。
这也造成了很多人认为方法区(或者HotSpot虚拟机中的永久代)是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区中实现垃圾收集，而且在方法区中进行垃圾收集"性价比"一般比较低:在队中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70~95%的空间，而永久代的垃圾收集效率远低于此

Test_1_A
静态变量str的值存放在StringTable中，镜像类中存放的是字符串的指针

Test_1_B
str是类Test_1_A的静态属性，可以看到不会存储子类Test_1_B的镜像类中。

可以猜得到，通过子类Test_1_B访问父类Test_1_A的静态字段有两种实现方式:
1.先去Test_1_B的镜像类中去取，如果有直接返回;如果没有，会沿着继承链将请求上跑。很明显,这种算法的性能随继承链的depth而上升，算法复杂度为O(n).
2.借助另外的数据结构实现，使用K-V的格式存储，查询性能为O(1)
Hotspot就是使用的第二种方式，借助另外的数据结构ConstantPoolCache,常量池类ConstantPool中有个属性_cache指向了这个结构。每一条数据对应一个类ConstantPoolCacheEntry.
ConstantPoolCacheEntry在哪儿？在CosntantPoolCache对象后面，代码位置/openjdk/hotspot/src/share/vm/oops/cpCache.hpp，代码如图所示。这个公式的意思是ConstantPoolCache对象的地址加上ConstantPoolCache对象的内存大小

ConstantPoolCache
常量池缓存是为常量池预留的运行时数据结构。保证所有字段访问和调用字节码的解释器运行时信息。缓存是在类被积极使用之前创建和初始化的。每个缓存项在解析时被填充。从图中的代码可以看出，是直接去获取ConstantPoolCacheEntry

1.魔数验证

2.版本号验证

3.解析常量池、访问权限等等

4.解析类的接口信息、方法信息、属性信息、父类信息

5.创建位于方法区的InstanceKlass对象

6.创建位于堆中的InstanceMirrorClass对象

启动类加载器
因为启动类加载器是由C++编写的，通过Java程序去查看显示的是NULL,因此，启动类加载器无法被Java程序调用，启动类加载器不像其他类加载器有实体，它是没有实体的，JVM将C++处理类加载的一套逻辑定义为启动类加载器，加载的jar包如图所示。也可以通过-Xbootclasspath指定

扩展类加载器

应用类加载器

自定义类加载器

当我们再进一步查看的话，会发现看不到它的实现，这可能和C++的写法有关系，

它这里的方法实现其实是要到jvm.cpp文件中才能看到，具体的写法我也不是很清楚，但是可以看到，最后生成关键的一步是find_instance_or_array_klass这个方法

find_instance_or_array_klass方法中又调用了find(),我们再跟进去

我们可以发现，当查找加载过的类时，它是把类信息放到了一个hashtable里面，先通过class_name和类加载器loader计算出一个d_index，然后再通过这个索引去查找

如果在Dictionary字典里面找到了这个classname对应的类，则返回，没有则返回null，可以看到，查找加载过的类时，并不是直接拿着classname去找的，而是classname + classloader组合起来查找的.也就是key=>类的全限定名+类加载器 ->index    value: Metadata:klass

我们知道JVM启动时会执行JavaMain,之后会执行JVM的相关初始化工作，这里先不谈，先看类加载器创建链。然后执行loadMainClass

获取LauncherHelper，它这个动作其实是让Bootstrap类加载器进行加载的

如何打破双亲委派？为什么要打破双亲委派机制？当前文件中搜索"Tomcat为什么要打破双亲委派机制"
因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件，以Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如mysql的就写了MySQL Connector，那么问题就来了，DriverManager(也由jdk提供)要加载各个实现了DriverManager接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能加载JAVA_HOME的lib目录下的文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派机制。类似这样的情况就需要打破双亲委派。打破双亲委派的意思其实就是不委派、向下委派。

线程上下文类加载器
1.是什么?一种特殊的类加载器，可以通过Thread获取，基于此可实现逆向委托加载
2.为什么？为了解决双亲委派的缺陷而生
3.怎么做？如图所示

SPI机制
它是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制。Tomcat/Spring就是这样类似的机制

沙箱安全
比如定义了一个类名为String所在包为java.lang,因为这个类本身是属于jdk的，如果没有沙箱安全机制的话，这个类将会污染到我所有的String，但是由于沙箱安全机制，所以就委托顶层的bootstrap加载器查找这个类，如果没有的话就委托extension,extension没有就到appclassloader,但是由于String就是jdk的源代码，所在bootstrap哪里就加载到了，先找到先使用，所以就使用bootstrap里面的String后面的一概不能使用，这就保证了不被恶意代码污染

String变量的最大长度为多少?
String变量在常量池中表示的结构是Constant_String_info结构，其中它的index指向了字符串字面量的索引，而字符串字面量的表示结构为Constant_Utf8_info,其中length字段表示UTF-8编码的字符串的长度，由两个字节组成表示的最大长度为2^16 -1 = 65535，但是Java虚拟机还需要1个字节的指令作为结束，所以其实真正的有效范围是65534，记住这是编译器的限制，运行期还是受制于int类型

为什么Java虚拟机还需要1个字节的指令作为结束？程序异常处理的有限范围解释
start_pc和end_pc两项的值表明了异常处理器在code[]数组中的有效范围。start_pc必须是对当前code[]数组中的某一指令的操作码的有效索引，end_pc要么是对当前code[]数组中某一指令的操作码的有效索引，要么等于code_length的值，即当前code数组的长度。start_pc的值必须比end_pc小。当程序计数器范围[start_pc,end_pc)内时，，异常处理器就将生效。即设x为异常句柄的有效范围内的值，x满足:start_pc<=x<end_pc.
实际上，end_pc值本身不属于异常处理器的有效范围，这点属于Java虚拟机历史上的一个设计缺陷:如果Java虚拟机中的一个方法的code属性的长度刚好是65535个字节，并且以一个字节长度的指令结束，那么这条指令将不能被异常处理器所处理。不过编译器可以通过限制任何方法、实例初始化方法或类初始化方法的code[]数组最大长度为65534，这样可以间接弥补这个BUG

Constsant_Uff8_info中为什么要存储字符串长度?
C++中因为存储了字符串的'\0'，但是Java没有把这个\0编译进字节码文件中，C++要根据这个\0字符可以判断一个字符串的结束，java则是通过String的长度来判断一个字符串的结束

常量池中的0号索引是this指针，具体是什么想法不得而知。

字节码中最难解析的是方法结构

常量池其实只有三种数据结构类型，String比较特殊，还有就是4字节类型和8字节类型。如FieldI_info类型，它的结构如下:
class index:22 
nameAndType index:33
用一个short来存储 2个字节 :0xffff
22 << 16   0x2200
0x2200 | 0x33
4个字节合起来就是0x00220033拼起来存储的

什么是描述符，具体解释见"字节码中的数据结构"

field_info
在Java字节码中，field_info结构是用来描述类或接口中的字段(成员变量的)。每个field_info结构对应类文件中的一个字段。其中它的组成部分包括如下：
1.access_flags:访问标志,表示字段的访问级别(如public, private, protected, static等)和其他属性(如final volatile等)
2.name_index:字段名的索引，它是一个指向常量池的索引，常量池中的对应条目包含字段的名称
3.descriptor_index:字段描述符的索引，它也是指向常量池的索引，描述符用来表示字段的类型(如int,float, java.lang.String等)
4.attribute_count:属性数量，表示接下来跟随的属性表中的属性数量。
5.attributes:属性表，包含了对字段的额外描述信息，如常量值(ConstantValue)、字段签名(Signature)、Synthetic标记等。

例如，有这样一个类文件,代码如下:
```java
public class MyClass {
      private int myField;
}
```
对应的field_info结构将包含如下信息:
1.access_flags:表示private访问权限
2.name_index:指向常量池中包含myField字符串的条目
3.descritptor_index:指向常量池中包含"I"(表示Int类型)的条目
4.attributes_count:通常为0，除非字段有额外的属性，如ConstantValue

method_info、Code_attribute
在Java字节码中，method_info结构用于描述类或接口中的方法。每个method_info结构对应类文件中的一个方法。以下是method_info结构的组成部分:
1.acess_flags:访问标志,表示方法的访问级别(如public,private，protected, static等)和其他属性(如abstract. final，synchronized，native,strictfp等)
2.name_index:方法名的索引，这是一个指向常量池的索引，常量池中的对应条目包含方法的蒙城
3.descriptor_index:方法描述符的索引，这也是一个指向常量池中的索引，描述符用来表示方法的参数类型、返回值类型以及可能抛出的异常类型
4.attributes_count:属性数量，表示接下来跟随的属性表中的属性数量
5.attributes:属性表，包含了对方法的额外描述信息，如方法的代码(Code)、异常表(Exceptions)、方法签名(Signature)、注解(Annotation)等
例如，有这样一个类文件，代码如下:
```java
public class MyClass {
    public void myMethod(int param) {
       // Method body ...
     }
}
```
对应的method_info结构将包含以下信息:
1.access_flags:表示public访问权限
2.name_index:指向常量池中包含myMethod字符串的条目
3.descriptor_index:指向常量池中包含(I)V(表示一个int参数且没有返回值)的条目
4.attributes_count:通常至少为1，因为大多数方法都会有一个Code属性，它包含方法的字节码指令

Code属性是method_info结构中最常见的属性，它包含以下字段:
1.max_stack:操作数栈的最大深度
2.max_locals:局部变量表所需的存储空间，单位是槽位(slot)，每个槽位可以存储一个32位的数据类型
3.code_length:字节码指令的数量
4.code:实际的方法字节码指令序列
5.exception_table_length:异常表中的条目数量
6.exception_table:异常处理的信息
7.exception_table:异常处理的信息
8.attributes_count：Code属性中的属性数量
9.attributes:Code属性中的属性表

LineNumberTable和Code结构之间的关系是什么？
LineNumberTable是Code属性中的一个可选属性，它提供了源代码行号与字节码指令之间的映射关系。这样，当异常被抛出或者在调试程序时，可以更准确地定位到源代码中的具体行。
1.Code属性时method_info结构中的一个属性，它包含了方法的实际字节码指令、局部变量表大小、操作数栈大小等信息
2.LineNumberTable属性:是Code属性中的一个可选属性，它位于Code属性的attributes数组中，如果存在，它允许调试器和其他工具将执行的字节码指令与源代码中的行号关联起来

LocalVariableTable是Code属性中的一个可选属性，它提供了方法执行期间局部变量与局部变量表槽位之间的关系。这个映射允许调试器和其他工具在运行时查看和修改变量的值，并且可以用于在异常堆栈跟踪中显示变量名
1.Code属性:code属性包含方法的字节码指令、局部变量表大小、操作数栈等信息。它还包含一个属性表attributes,可以包含多个属性，比如LineNumberTalbe、LocalVariableTable等
2.LocalVariableTable属性:LocalVariableTable是Code属性中的一个属性，位于attributes数组中。如果存在，它描述了方法中的每个局部变量及其在局部变量表中的位置、生命周期和类型
3.LocalVariableTable中的每个条目都描述了一个局部变量，包括它的名字、类型、在局部变量表中的槽位索引以及它在字节码中的上明周期(开始和结束的偏移量)
4.LocalVariableTable提供了调试器在执行期间识别和访问局部变量的能力，这对于断点调试和异常堆栈跟踪非常有用
5.在编译时，编译器可以选择生成或不生成LocalVariableTable。如果生成了这个表，它会使得调试更加方便，但如果为了减小类文件大小或出于其他原因，这个表可能会被忽略

C++中Hotspot是如何将Klass对象放到方法区的？
C++有个技术叫做操作符重写，/vm/memory/allocation.hpp，操作符重写:new可以指定这个对象存在哪里

局部变量表
局部变量表存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型，它不等同于对象本身，可能是一个指向对象的起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot)，其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间时完全确定的，在方法运行期间不会改变局部变量表的大小。

在Java虚拟机规范中，对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展(当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈)，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常

局部变量表(Local Variable Table)是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。在Java程序编译为Class文件时，就在方法的Code属性的max_locals数据项中确定了该方法所需要分配的局部变量表的最大容量。
局部变量表的容量以变量槽(Variable Slot，下称Slot)为最小单位，虚拟机规范中并没有明确指明一个Slot应占用的内存空间大小，只是很有导向性地说到每个Slot都应该能存放一个boolean、byte、char、short、int、float、reference或returnAddress累心地数据，这8种苏韩剧类型，都可以用32位或更小地物理内存来存放，但这种描述与明确指出"每个Slot占用32位长度地内存空间"是有一些差别地，它允许Slot的长度可以随着处理器、操作系统或虚拟机的不同而发生变化。只要保证即使在64位虚拟机中使用了64位的物理内存空间区实现一个Slot，虚拟机仍要使用对齐和补白的方式让Slot在外观上看起来与32位虚拟机中的一致。

既然前面提到了Java虚拟机的数据类型，在此再简单介绍一下他们。一个Slot可以存放一个32位以内的数据类型，Java中占用32位以内的数据类型有boolean、byte、char、short、int、float、reference(Java虚拟机规范中没有明确规定reference类型的长度，它的长度与实际使用32还是64位u虚拟机有关，如果是64位虚拟机，还与是否开启某些对象指针压缩的优化有关，这里暂且只取32位虚拟机的reference长度)和returnAddress8种类型。前面6中不需要多家解释，可以按照Java语言中对应数据类型的概念区理解它们(仅是这样理解而已，Java语言与Java虚拟机中的基本数据类型是存在本质差别的)，而第7种reference类型表示对一个对象实例的引用，虚拟机规范既没有说明它的长度，也没有明确指出这种引用应有怎样的结构。但一般来说，虚拟机实现至少都应当能通过这个引用做到两点:
1.从此引用直接或间接地查找到对象在堆中的数据存放的起始地址索引
2.此引用中直接或间接地查找到对象所属数据类型在方法去中的存储的类型信息，否则无法实现Java语言规范中定义的语法约束
(并不是所有语言的对象引用都能满足这两点，例如C++语言，默认情况下(不开启RTTI支持的其概况)，就之只能满足第一点，而不满足第二点。这也是为何C++中提供Java语言里很常见的反射的根本原因)
对于64位的数据类型，虚拟机会以高位对齐的方式为其分配两个连续的Slot空间，Java语言中明确的(reference类型则可能是32位也可能是64位)64位的数据类型只有long和double两种。值得一提的是，这里把long和double数据类型分割存储的做法与"long和double的非原子性协定"中把一次long和double数据类型读写分割位两次32位读写的做法有些类似。不过局部变量表建立在线程的堆栈上，是线程私有的数据，无论读写两个连续的Slot是否为原子操作，都不会引起数据安全问题。
虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从0开始至局部变量表最大的Slot数量。如果访问的是32位数据类型的变量，索引n就代表了使用第n个Slot,如果是64位数据类型的变量，则说明会同时使用n和n+1两个Slot。对于两个相邻的共同存放一个64位数据的两个Slot，不允许采用任何方式单独访问其中的某一个，Java虚拟机规范中明确要求了如果遇到进行这种操作的字节码序列，虚拟机应该在类加载器的校验阶段抛出异常。

编译优化:方法内部代码块中的变量是不会写到字节码文件中的

操作数栈
操作数栈(Operand Stack)也常称为操作栈，他是一个后入先出(Last In First Out, LIFO)栈。同局部变量表一样，操作数栈的最大深度也在编译的时候写入到Code属性的max_stacks数据项中。操作数栈的每一个元素可以是任意的Java数据类型，包括long和double.32位数据类型所占的栈容量为1，64位数据类型所占的栈容量为。在方法执行的任何时候，操作数栈的深度都不会超过max_stacks数据项中设定的最大值。
当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的，在方法的执行过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈/入栈操作。例如，在做算术运算的时候是通过操作数栈来进行的，又或者在调用其他方法的时候是通过操作数栈来进行参数传递(A方法的返回值作为B方法的入参这种)。
举个例子，整数加法的字节码指令iadd在运行的时候操作数栈中最接近栈顶的两个元素已经存入了两个int类型的数值，当执行这个指令的时候，会将这两个int值出栈并相加，然后将相加的结果入栈。
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，在编译程序代码的时候，编译器要严格保证这一点，在类校验阶段的数据流分析中还要再次验证这一点。再以上面的iadd指令为例，这个指令用于整型数假发，它在执行时，最接近栈顶的两个元素的数据类型必须为int类型，不能出现一个long和一个float使用iadd命令相加的情况。
另外，在概念模型中，两个栈帧作为虚拟机栈的元素，是完全相互独立的。但在大多数虚拟机的实现里都会做一些优化处理，令两个栈帧出现一部分重叠。让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样在进行方法调用时就可以公用一部分数据，无需进行额外的参数复制传递，重叠的过程如图所示。Java虚拟机的解释执行引擎称为"基于栈的执行引擎"，其中所指的"栈"就是操作数栈。

动态链接
每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。我们知道Class文件的常量池中有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用作为参数。这些符号引用一部分会在类加载阶段或者第一次使用的时候就转化为直接引用，这种转化称为静态解析。另外一部分将在每一次运行期间转化为直接引用，这部分称为动态连接

方法返回地址
当一个方法开始执行后，只有两种方式可以退出这个方法。第一种方式是执行引擎遇到任意一个方法返回的字节码指令，这死后可能会有返回值传递给上层的方法调用者(调用当前方法的方法称为调用者)，是否有返回值和返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法的方式称为正常完成出口(Normal Method Invocation Completion)。另外一种退出方式是，在方法执行过程中遇到了异常，并且这个异常没有在方法体内得到处理，无论是Java虚拟机内部产生的异常，还是代码中使用athrow字节码指令产生的异常，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为异常完成出口(Abrupt Method Invocation Completion)。一个方法使用异常完成出口的方式退出，是不会给它的上层调用者产生任何返回值的。
无论采用何种退出方式，在方法退出之后，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法正常退出时，调用者的PC计数器的值可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中一般不会保存这部分信息。
方法退出的过程实际上就等同于把当前栈帧出栈，因此退出时可以能执行的操作有:恢复上层方法的局部变量表和操作数栈，把返回值(如果有的话)压入调用者栈帧的操作数栈中，调整PC计数器的值以指向方法调用指令后面的一条指令等。

附加信息
虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息到栈帧之中，例如与调试相关的信息，这部分信息完全取决于具体的虚拟机实现，在实际开发中，一般会把动态链接、方法返回地址与其他附加信息全部归为一类称为栈帧信息

对象的创建
DCL中单例对象的创建为什么要加volatile?
如果在ns级别的超高并发是需要加volatile关键字的，这个关键字会禁止指令重排，因为CPU是会乱序执行这些指令的。如下指令
接下来我们看下一个对象的创建流程
0 new #2
1.堆区申请了内存(不完全对象)构造方法还未执行
2.内存地址压入栈
3 dup duplicate
1.赋值栈顶元素

为什么要复制？
因为接下来调用init非静态方法，但是this指针还是空的，所以需要把栈顶元素弹出去，给this指针赋值，然后再把元素压入栈
2.再次压入栈
4 invokespecial #3 <init>方法
this指针
this = null

执行方法分为两步:
1.构建环境会涉及到创建栈帧、传参、保存现场。给this指针赋值，记录方法的执行之前的位置
2.执行

7 astore_1
1.pop出元素:对象的指针
2.赋值给index=1的位置的变量(局部变量)

对象的创建
Java是一门面向对象的编程语言，在Java程序运行过程中无时无刻都有对象被创建出来。在语言层面上，创建对象(例如克隆、反序列化)通常仅仅是一个new关键字而已，而在虚拟机中，对象(引用类型的对象)的创建又是一个怎样的过程呢？
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号一弄，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那必须先执行响应的类加载过程。
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。假设Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针想空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为"指针碰撞"(Bump the Pointer)。如果Java堆中的内存并不是规整的，已使用内存和空闲的内存相互交错，那就没有办法简单进行指针碰撞了，虚拟机就必须维护一个列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为"空闲列表"(Free List).选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，在使用Serial、ParNew等带Compact过程的收集器时，系统采用的分配算法时指针碰撞，而使用CMS这种基于Mark-Sweep算法的收集器时，通常采用空闲列表
(内存分配算法也跟对象的存活周期有关，新生代大部分对象都朝生夕死，复制算法进行GC完之后，内存就是规整的，而老年代，存活对象相比新生代来说存活率要高，内存不太容易规整，如果不带整理的话，使用指针碰撞失败的概率会高很多。所以老年代采用空闲列表)
除如何划分可用空间之外，还有另外一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案，一种是堆分配内存空间的动作进行同步处理——实际上迅即采用CAS配上失败重试的方式保证更新操作的原子性；另外一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB)。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用了TLAB,可以通过-XX:+/-UseTLAB参数来设定

内存分配完成之后，虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头)，如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

接下来，虚拟机要对对象进行必要的设置，例如这个对象时哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头(Object Header)之中。根据虚拟机当前的运行状态不同，如是否启用偏向锁等，对象头会有不同的设置方式。

在上面的工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从Java程序的视角来看，对象创建才刚刚开始——<init>方法还没有执行，所有的字段都还为0，所以，一般来说(由字节码中是否跟随invokespecial指令所决定)，执行new指令之后会接着执行<init>方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全生成出来

AQS 管程思想

JVM内存模型的设计与GC收集器有很大关系。
HotSpot源码中是根据垃圾收集器的类型来创建不同的对象内存模型的
G1之前是新生代 + 老年代
之后划分2048个块，每个块大小为2M,基于Region模型
新生代中在一轮GC之后，90~95%的对象都会被回收，采用复制的话，避免了内存整理，操作比较简单。
分代+复制算法：为了保证内存使用的高效性
标记-清楚算法: 会有碎片化问题
标记-整理算法:整理算法 内存合并算法 耗费CPU，

字符串常量池位置
JDK1.6及之前:有永久代，运行时常量池在永久代，运行时常量池包含字符串常量池，Perm区域只有4m,一旦常量池大量使用intern很容易发生永久代的OOM
JDK1.7:有永久代，但已经逐步"去永久代",字符串常量池从永久代里的运行时常量池分离到堆里
JDK1.8及之后，无永久代，运行时常量池在元空间，字符串常量池依然在堆里

字符串常量池的设计思想:
1.字符串的分配，和其他的对象分配一样，耗费高昂的时间与空间代价，作为最基础的数据类型，大量频繁的创建字符串，极大程度地影响程序地性能
2.JVM为了提高性能和减少内存开销，在实例化字符串常量的时候进行了一些优化
2.1 为字符串开辟一个字符串常量池，类似于缓存区
2.2 创建字符串常量时，首先查询字符串常量池是否存在该字符串
2.3 存在该字符串，返回引用实例，不存在，实例化该字符串并放入池中

字符串常量池设计原理
字符串常量池底层时HotSpot的C++实现的。底层类似一个Hashtable，保存的本质上是字符串对象的引用，来看一道比较常见的案例，图中的代码创建了多少个String对象
// JDK6:false 创建了6个对象
// JDK7及以上:true  创建了5个对象

为什么输出会有这些变化呢？主要还是字符串从永久代中脱离、移入堆区的原因，intern()方法也相应发生了变化
同时也解释了JDK1.6中字符串溢出会抛出OutOfMemoryError:PermGen Space.而在JDK1.7及以上版本会抛出OutOfMemoryError:Java heap space

key的生成方式
1.通过String的内容 + 长度生成hash值
2.将hash值转为key

value的生成方式
将Java的String类的实例InstanceOopDesc封装成HashtableEntry

jdk8:底层是一个char[]数组
jdk9及之后:底层是一个byte[]数组

一个中文占两个字节，一个char占两个字节，一个byte占一个字节
Jdk9及之后的版本中，多了一个code属性，这个属性标记是告诉调用者按几个字节来取的问题，
如果按byte存储的话，存不是什么问题，问题是如何取呢？
String在9版本之后是根据code属性来区分的：
如果是英文则按照LATIN编码格式，1个字节1个字节地取
如果是中文则按照UTF16两个字节来取

JDK9的字符串去重:
G1：经历了三次GC,-XX:+UseG1GC -XX:+UseStringDeduplication
底层原理:用== 判断不是同一个字符串，内容是否相等
优缺点:它是一个CPU密集型的

String类重写了hashCode方法.
可以看出String的hashcode与String的内容是有关系的

String类也重写了equals方法

双引号
这种方式创建的字符串对象，只会在常量池中。因为"11"这个字面量，创建对象s1的时候，JVM会先去常量池中通过equals(key)方法，判断是否有相同的对象。
如果有，则直接返回该对象在常量池中的引用；
如果没有，则会在常量池中创建一个新对象，再返回引用

new String
这种方式会保证字符串常量池和堆中都有这个对象，没有就创建，最后返回堆内存中的对象印象。
步骤大致如下:
因为有"11"这个字面量，所以会先检查字符串常量池中是否存在字符串"11"
不存在，先在字符串常量池里创建一个字符串对象；再去堆内存中创建一个字符串对象"11";
存在的话，就直接去堆内存中创建一个字符串对象"11";
最后，将堆内存中的引用返回

两个双引号

两个new String

双引号 + 双引号

双引号 + new String

1.空闲列表
OS把不常用的内存写到硬盘上，如果有进程需要读取引发缺页异常，进而会去硬盘上读

2.指针碰撞(CAS)
如图所示，bottom指向内存区域的头部，end指向内存区域的尾部，top指针开始指向头部(可用内存的起始位置)。如果new_top = top(当前top) + 对象大小满足这个等式，则分配成功，并top=new_top

JVM中的内存分配策略为什么不使用空闲列表的方式而是采用指针碰撞

3.TLAB线程私有堆(新生代)
JVM里面如果用锁来控制对象内存的分配的话，会比较繁琐，它是堆中某一块私有内存区域，如果用完了再还给JVM，重新盛情一块更大的内存

4.PLAB(TLAB的老年代)

对象头的布局结构
1.锁标志位(lock):区分锁状态,11表示对象待GC回收状态，只有最后两位锁标识11有效
2.biased_lock:是否偏向锁，由于无锁和偏向锁的锁标识都是01，没办法区分，这里引入一位的偏向锁标识
3.分代年龄(age):标识对象存活的次数，当该次数达到阈值的时候，对象就会转移到老年代
4.对象的hashcode:运行期间调用System.identityHashCode()来计算，延迟计算，并把结果赋值到这里。当对象加锁后，计算的结果31位不够标识，在偏向锁、轻量锁、重量锁，hashcode会被转移到ObjectMonitor中
5.偏向锁的线程ID(JavaThread):偏向模式的时候，当某个线程持有对象的时候，对象这里就会被设置位该线程的ID，在后面的操作中，就无需再次进行尝试获取锁的动作
6.epoch:偏向锁在CAS锁操作的过程中，偏向性标识，标识对象更偏向哪个锁
7.ptr_to_lock_record:轻量级锁状态下，指向栈中所记录的指针。当锁获取是无竞争的时候，JVM使用原子操作，而不是OS Mutex互斥。这种技术称为轻量级锁定。在轻量级锁状态下，JVM通过CAS操作在对象的Mark Word中设置指向所记录的指针
8.ptr_to_heavyweight_monitor:重量级锁状态下，指向对象监视器ObjectMonitor的指针。如果两个不同的线程同时在同一个对象上竞争，则必须将轻量级锁升级到Monitor以管理等待的线程，在重量级锁的情况下，JVM在对象的ptr_to_heavyweight_monitor设置指向Monitor的指针

没有属性的对象
MarkWord:(64位)8B
类型指针:(默认是开启指针压缩的)4B
由于8B+4B=12B,不够被8整除，所以对齐填充4B
对象大小:8B+4B+4B=16B

有属性的对象
Mark Word:8B
类型指针:4B
实例数据:4B+4B
对象大小

数组对象
Mark Word:8B
类型指针:注意这里的数组类型是int类型,也就是说它的OopDesc是TypeArrayOopDesc，4B
数组长度:4B
实例数据:4B+4B+4B
8B+4B+4B+4B+4B+4B=28B，还是不能被8整除，所以对齐填充需要补4B
8B+4B+4B+4B+4B+4B+4B=32B

关闭指针压缩的情况下

开启指针压缩的情况下

上面的情况分析如下:
跟C/C++中的一个联合体有关联
union u {
int i;  // 4B
void p; // 8B
}
该联合体所占大小由最大字节数决定
比如说类型指针:0xffffffff，数组长度为0x00000003，当开启指针压缩时，由于只使用了联合体中的4B,但是联合体本身还是占8B,于是就出现了4B的浪费情况，数组长度占4B,那么把两者拼在一起，就可以节省8B的开销，把数组长度填充到前4B里面,相当于0x0003ffff。

为什么数组对象在关闭指针压缩的情况下有两段填充?不仅要站在学习者的角度去思考问题，更要以设计者的角度去思考

1.在开启指针压缩的情况下:
类型指针0xffffffff 8B
数组长度:0xffff 4B
用一个8B就存储下了
2.那么在关闭指针压缩的情况下
类型指针0xffffffff 8B
数组长度: 0x0000ffff
由于数组长度只占4B,根据8字节对齐的规范，对于一行内存地址来说，这里就出现了4字节的空间，那么我们知道，数组长度的下一个数据区域就是实例数据，如果说实例数据中正好有一个int类型，那么ok，正好填补到前面的4个字节里面，那如果不是int类型呢？是char类型的呢？虽然说可以存进去，但是作为设计者如何知道这个数据区域存储的实例数据是char类型还是int类型呢？所以说，存进去的话，会比较麻烦，于是需要在对象头的尾部进行对齐填充

指针压缩的底层原理？这个技术能被开发出来归根结底是来自"所有对象大小都必须能被8整除"这条规则。
8字节对齐的言外之意 8(1 000)
如图所示，现在有三个对象
test1:16B
test2:32B
test3:24B

test1的起始地址: 0B
test2的起始地址:16B
test3的起始地址:48B
他们分别对应的二进制:
test1: 0 000
test2:10 000
test3:110 000
可以看到后三位永远是0，那么JVM在存储的时候，就可以这样存储，向右移3位。>>3
也就是说只存储
test1: 0
test2: 10
test3: 110
然后在使用的时候可以左移3位， << 3,再把它还原回去
根本原因在于"8字节对齐"这条规则

实战:亿级流量系统实战
1.如果每个用户平均访问20个商品详情页，那访客数约定于500w(一亿/20)
2.如果按转化率10%来算，那日均订单约等于50w(500w * 10%)
3.如果30%的订单是在秒杀前两分钟完成的，那么每秒产生1200笔订单(50w*30%/120s)
4.订单支付又涉及到发起支付流程、物流、优惠券、推荐、积分等环节，导致产生大量对象，这里我们假设整个支付流程生成的对象为20K,那么每秒在Eden区生成的对象约等于20M(1200笔 * 20K)
5.在生产环境中，订单模块还涉及到百万商家查询订单、改价、包邮、发货等其他操作，又会产生大量对象，我们放大10倍，即每秒在Eden区生成的对象约等于200M(其实这里就是在大并发时刻可以考虑服务降级的地方，架构其实就是取舍)
假设响应一个请求的时间为3s(包括付款、扣减库存)
这里的假设数据都是大部分电商系统的通用概率，是有一定代表性的.如果你作为这个系统的架构师，面对这样的场景，你会如何做JVM调优呢？即将运行该系统的JVM堆区设置成多大呢？

分析:
1.每秒产生200M对象，Eden区的大小为2.2G,相当于11s就会触发YGC(11 x 200 = 2200M对象)，由于假设一个请求响应时间为3s，所以发生GC的时候，会有600M(200M * 3 = 600M)对象回收不掉。GC回收的是标记不到的对象，而S0、S1只有270M，放不下这600M对象，进而触发老年代空间担保机制，放入老年代。对于老年代而言，大小为5400M->9次YGC->触发一次FGC.9x11=99s，触发一次FC，这样的频率8G内存不适合的
2.怎么做调优？加内存？怎么加？
S0、S1的内存区域要大于600M，这样，假设S0/S1都为600M,Eden区为4800M(600 x 8 = 4800)，约等于6G,那老年代为12G(6G x 2 = 12G),内存加起来的话，12G+6G=18G，但是内存一般都取2的n次幂，所以取16G即可。

如果不调优，则会出现一直触发FGC，又回收不到可用的内存，进而导致JVM发生崩溃

1.堆到底设置成多大比较合适？堆越大越好吗？
如果堆设置的很小-> GC频率可能很高，GC时间也比较短
设置的很大->GC频率会低，但是GC的时长却增加了
调优不是一蹴而就的，需要逐步调整，并观察JVM的GC情况
2.什么样的系统可以进行JVM调优？
首先要区分出是OLAP(在线分析)系统还是OLTP(在线事务查询)系统，如果是OLAP(在线分析)系统，是没有多大调优空间的，因为一次性要查询大量对象，这个是没有办法做调优的，只能加大内存
3.正常GC单次时长100ms，前端和后端的平衡，不能让前端感到明显卡顿

```java
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

public class MetaspaceOverFlowTest {

    /**
     * 模拟CGLIB向元空间写入数据
     */
    public static void main(String[] args) {
        while (true) {
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            Enhancer enhancer = new Enhancer();

            enhancer.setSuperclass(MetaspaceOverFlowTest.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                    return methodProxy.invokeSuper(o, args);
                }
            });

            System.out.println("running ....");

            enhancer.create();
        }
    }
}
```
模拟OOM

查看方法区使用情况
在配置Java环境的情况下，直接打开命令行输入jvisualvm命令即可打开
```bash
C:\Users\87766>jvisualvm
```
然后在左边找到我们的程序，右边是查看图形

查看GC情况需要安装一个插件Visual GC，左上方工具栏安装即可

GC日志
[GC (Metadata GC Threshold) [PSYoungGen: 9003K->672K(64512K)] 16030K->9067K(236544K), 0.0038284 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Metadata GC Threshold) [PSYoungGen: 672K->0K(64512K)] [ParOldGen: 8395K->8858K(74752K)] 9067K->8858K(139264K), [Metaspace: 20138K->20138K(32768K)], 0.0648738 secs] [Times: user=0.02 sys=0.00, real=0.07 secs]

调优参数
```bash
-XX:MetaspaceSize=20M -XX:MaxMetaspaceSize=20M -XX:+PrintGCDetails
```
原则:最大、最小设置成一样大，避免因内存分配不足而引发扩容
程序运行起来后，通过VisualVM、Arthas查看占用了多少内存，向上调优，预留20%以上的空间

```java
public class HeapOverFlowTest1 {

    int[] intArr = new int[10];

    public static void main(String[] args) {
        List<HeapOverFlowTest1> list = new ArrayList<HeapOverFlowTest1>();

        for (;;) {
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            list.add(new HeapOverFlowTest1());
        }

    }
}
```
模拟OOM

调优vm参数
```java
-Xms10m -Xmx10m -XX:+PrintGCDetails
```

jvisualvm查看gc情况

gc日志
```bash
[GC (Allocation Failure) [PSYoungGen: 1120K->469K(2048K)] 7372K->6786K(9216K), 0.0021594 secs] [Times: user=0.00 sys=0.02, real=0.01 secs]
[GC类型(GC原因)[新生代收集器:gc前新生代的内存使用情况->gc后新生代的内存使用情况(新生代总内存)]gc前堆内存的使用情况->gc后堆内存的使用情况(堆总内存), gc耗时][TImes:gc阶段用户空间耗时 gc阶段内核空间耗时，gc阶段实际耗时]

[Full GC (Ergonomics) [PSYoungGen: 469K->0K(2048K)] [ParOldGen: 6316K->5603K(7168K)] 6786K->5603K(9216K), [Metaspace: 9480K->9410K(1058816K)], 0.0488684 secs] [Times: user=0.08 sys=0.02, real=0.05 secs]
[GC类型(GC原因)[新生代垃圾收集器:gc前新生代的内存使用情况->gc后新生代的内存使用情况(新生代总内存)][老年代垃圾收集器:gc前老年代的内存使用情况->gc后老年代的内存使用情况(老年代总内存)]gc前堆内存的使用情况-> gc后堆内存的使用情况(堆总内存)，[Metaspace:gc前元空间的内存使用情况-> gc后元空间的内存使用情况(元空间总内存)]， gc耗时][Times:gc阶段用户空间耗时 gc阶段内核空间耗时，gc阶段实际耗时]
```

调优原则:
1.预留30%以上的空间
2.周期性看日志，重点关注Full GC频率

```java
public class StackOverFlowTest {

    private int val = 0;

    public void test() {
        val++;

        test();
    }

    public static void main(String[] args) {
        StackOverFlowTest test = new StackOverFlowTest();

        try {
            test.test();
        } catch (Throwable e) {
            e.printStackTrace();

            System.out.println(test.val);
        }
    }
}
```
模拟OOM

调优参数
-Xss200k 默认1M

模拟OOM，可以看到触发了操作系统的SIGKILL信号机制(signal 9:SIGKILL),但是这个日志怎么查看呢

如何查看Linux内核日志呢？
```bash
dmesg -T
```

-q:只显示Java进程的ID

-m:输出Java进程的ID + main函数所在类的名字 + 传递给main函数的参数

-l:输出Java进程的ID+main函数所在类的全限定名(包名+类名)

-v:输出Java进程的ID+main函数所在类的名称+传递给JVM的参数
应用：可以通过次方式快速查看JVM参数是否设置成功

jps源码的位置/openjdk/jdk/src/share/classes/sun/tools/jps

如何识别的Java进程？jps输出的信息全是Java进程的信息，是如何做到的？
Java进程在创建的时候，会生成相应的文件，进程相关的信息会写入该文件中。Windows下默认路径是：C:\Users\username\AppData\Local\Temp\hsperfdata_username

PerfData文件
1.文件创建
每启动一个Java进程，/tmp/hsperfdata_username就会生成进程号的一个文件，这个文件是一个内存映射文件。有时候不会生成，受参数的影响，
-XX:-/+UsePerfData默认是开启的，它是通过attach到Java进程中去，它属于寄生在Java进程当中，可以读取Java进程的内存。
-XX:-/+PerfDisableSharedMem(禁用共享内存)默认是关闭的，即支持内存共享。如果金庸了，依赖于PerfData文件的工具就无法正常进行了
2.文件删除
正常情况下:默认情况下随Java进程的结束而销毁
非正常退出:下一次去读目录的时候会检测进程是否存在， 用kill -0 去检测进程是否存活，不存货就会删除该进程号文件，不然就会留下垃圾文件
3.文件更新
-XX:PerfDataSamplingInterval=50，即内存与PerfData文件的数据延迟为50ms

OOM killer
dmesg -T 日志查看内核日志

堆OOM
会生成日志，分配内存new的执行流程

元空间OOM
会生成日志，解析类、类加载器、动态字节码 cglib

直接内存OOM
unsafe bytbuffer
都不会生成日志，JVM进程的堆(OS知道)

栈OOM，为什么没有听说过这个地方发生OOM
开发阶段就会知道栈帧是否会发生OOM了

引用类型
无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否存活都与"引用"有关。在JDK1.2以前，Java中的引用的定义很传统:如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。这种定义很纯粹，但是太过于狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态，对于如何描述一些"食之无味，弃之可惜"的对象就显得无能为力。我们希望能描述这样一类对象:当内存空间还足够时，则能保留在内存之中;如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。
在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)4种，这4种引用强度依次逐渐减弱。
1.强引用
是指在程序代码之中普遍存在的，类似"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
2.软引用
是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用
3.弱引用
也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用，如ThreadLocal
4.虚引用
也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用

对象的生存还是死亡
即使在可达性分析算法种不可达的对象，也并非是"非死不可"的，这时候他们暂时处于"缓刑"阶段，要真正宣告一个对象死亡，至少要经历两次标记过程:如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为"没有必要执行"

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它，这里所谓的"执行"是指虚拟机会触发这个方法，但并不会承诺会等待它运行结束。这样做的原因是，如果一个对象在finalize()方法种执行缓慢，或者发生了死循环(更极端情况)，将很可能导致F-Queue队列种其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将会对F-Queue种的对象进行第二次小规模的标记，如果对象要在finalize()种成功拯救自己——只要重写与引用链上的任何一个对象建立关联即可，比如把自己(this关键字)复制给某个类变量或者对象的成员变量，那在第二次标记是它将被移除"即将回收"的集合;如果对象这时候还没有逃脱。那么基本上它就真被回收了

标记-清除算法
最基础的收集算法是"标记-清除"(Mark-Sweep)算法，如同它的名字一样，算法分为"标记"和"清楚"两个阶段:首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。
它的主要不足有两个:
1.效率问题，标记和清楚两个过程的效率都不高;
2.空间问题，标记清楚之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

复制算法
为了解决效率问题，一种称为"复制"(Copying)的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一般，未免太高了了一点。
现代的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代的对象98%是"朝生夕死"的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor.最后清理掉Eden和刚才用过的Survivor空间。HoSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的内存会被浪费.当然98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存(这里指老年代)进行分配担保(Handle Promotion).
内存的分配担保机制就好比我们去银行借款，如果我们信誉很好，在98%的情况下东鞥按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。内存的分配担保也一样，如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代

标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的时，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。因为没有多余的内存区域为老年代做担保，即便有，仍然需要有一块区域考虑到不能担保的情况。
根据老年代的特点，有人提出了另外一种"标记-整理"(Mark-Compact)算法，标记过程仍然与"标记-清楚"算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界意外的内存。

缺点:内存整理是CPU密集型的，比较耗费CPU

分代收集算法
当前商业虚拟机的垃圾收集都采用"分代收集"(Generational Collection)算法。这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外对他进行分配担保，就必须使用"标记-清除"或"标记-整理"算法来进行回收

三色标记与读写屏障
所有的垃圾回收算法都要经历标记阶段。如果GC线程在标记的时候暂停所有用户线程(STW)，那就没三色标记什么事儿了，但是这样会有一个问题，用户线程需要等到GC线程标记完才能运行，给用户的感觉就是很卡，用户体验很差。
现在主流的垃圾收集器都支持并发标记。什么是并发标记呢？就是标记的时候不暂停或少暂停用户线程，一起运行。这势必会带来三个问题:多标、少标、漏标。垃圾收集器是如何解决这个问题的呢？三色标记+读写屏障

记忆集(Remembered Set)、卡表(Card Table)
我们知道在G1垃圾收集器中，它是把Java堆分为多个Region，那么垃圾收集是否就真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在:Region不可能是鼓励的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象所引用，而是可以与整个Java堆任意的对象发生引用关系。那在做可达性分析确定对象是否存活的时候，岂不是还得扫描整个Java堆才能保证准确性？这个问题起始并非在G1中才有，只是在G1中更加突出。在CMS垃圾收集器中，也会存在这样的引用关系:新生代->新生代(没问题，对象要么都存活要么都死亡)、新生代->老年代(也是没问题的，无非新生代的对象存活的时间久点)、老年代->老年代(也没问题，同生共死)、老年代-> 新生代(有问题，万一新生代被回收了，会发生空指针异常)。那么如何解决这个问题的呢？
答案就是利用卡表
在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中的每个Region都有一个与之对应的Remembered Set都有一个与之对应的Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象)，如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remebered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

Serial收集器
串行收集器,即GC线程与用户线程先后运行，即GC时需要STW(暂停所有用户线程)，直至GC结束才恢复用户线程的运行。专注于收集年轻代，底层时赋值算法，相关参数:-XX:+UseSerialGC

ParNew收集器
Serial收集器的多线程版本，唯一能与CMS收集器搭配使用的新生代收集器。
相关参数：
-XX:+UseConctMarkSweepGC:指定使用CMS后，会默认使用ParNew作为新生代收集器
-XX:+UseParNewGC:强制指定使用ParNew
-XX:ParallelGCThreads:指定垃圾收集的线程数量，ParNew默认开启的收集器线程与CPU的数量相同

Parallel收集器
关注吞吐量的收集器。吞吐量 = 运行用户代码时间/ (运行用户代码时间 + 垃圾收集时间)
相关参数:
-XX:MaxGCPauseMills:是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍微小一点就能使得系统地垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁游戏额，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿的时间的确在下降，但吞吐量也降下来了。
-XX:GCTimeRatio:一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%(即1/(1+19)),默认值为99，就是允许最大1%(1/(1+99))的垃圾收集时间
-XX:+UseAdaptiveSizePolicy:一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、今生老年代年龄(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略(GC Ergonomics)

SerialOld
Serial收集器的老年代版本。基于标记-整理算法
有两个用途:
1.与Serial收集器、Parallel收集器搭配使用
2.作为CMS收集器的后备方案

Parallel Old收集器
Parallel收集器的老年代版本。基于标记-整理算法

CMS收集器(并发)
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java引用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户较好的体验，CMS收集器就非常符合这类应用的需求
聚焦低延迟。基于标记-清除算法实现。由于CMS收集器是并发收集器，即再运行阶段用户线程依然在运行，会产生对象，所以CMS收集器不能等到老年代满了才触发，而是要提前触发，这个阈值是92%。这个阈值可以通过参数-XX:CMSInitiatingOccupancyFraction设置

CMS的工作过程可以分为4个步骤
1.初始标记(CMS initial mark)
仍然需要STW,初始标记仅仅是标记以下GC Roots能直接关联到的对象，速度很快
2.并发标记(CMS concurrent mark)
不会STW.GC线程与用户线程并发运行.进行GC Roots Tracing的过程
3.重新标记(CMS remark)
会STW.为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间段
4.并发清除(CMS concurrent sweep)
GC线程与用户线程并发运行，清理未被标记到的对象。默认启动的回收线程数= (处理器核心数 + 3 ) / 4

CMS的缺点：
显然CMS收集器依然不是完美的，不然后面就不会出现G1、ZGC等
1.运行期间会与用户线程抢夺CPu资源。当然这是所有并发收集器的缺点
2.无法处理浮动垃圾(标记结束后创建的对象)
3.内存碎片

G1收集器(Garbage First, 低延迟)
G1收集器与之前的所有收集器都不一样，它将堆分成了一个一个Region，这些Region用的时候才被赋予角色:Eden、From、To、Humongous。一个Region只能是一个角色，不存在一个Region即是Eden又是From.如果这次Region内的对象被回收，那么它的角色可以跟之前的不一样。每个Region的大小可通过参数-XX:G1HeapRegionSize设置，取值范围是2-32M.一个对象的大小超过Region的一半则被认定为大对象，会用N个连续的Region来存储。Region个数在源码当中是一个常量2048

ZGC收集器(Z Garbage Collector,全并发、超低延迟 10ms)
ZGC是一款JDK11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于Azul System公司开发的C4(Concurrent Continuously Compacting Collector)收集器


参考文章：https://wiki.openjdk.java.net/display/zgc/Main
http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf

如何选择垃圾收集器
1.优先调整堆的大小让服务器自己来选择
2.如果内存小于100M,使用串行收集器
3.如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
4.如果允许停顿时间超过1秒，选择并行或者JVM自己选
5.如果响应时间最重要，并且不能超过1秒，使用并发收集器
6.4G以下可以用parallel,4-8G可以用ParNew + CMS,8G以上可以用G1,几百G以上用ZGC

CMS垃圾收集器
1.如果第一轮GC还没有完成，而此时由于用户线程的继续执行导致又触发了新的GC请求，那么第二轮GC不会立即执行，而是需要等待第一轮GC完成后才会开始
2.GC触发机制
当队中的老年代使用量达到一定阈值时，会触发CMS GC以回收内存。如果在一次CMS GC还没有完成时，用户线程继续分配对象，导致老年代再次达到触发阈值，理论上需要再次进行GC
2.CMS GC 重入性
CMS垃圾收集器本身并不支持"重入性"，即它同时进行多次垃圾收集。CMS的设计中，一次GCGC需要完成它的所有阶段后，才能开始新的GC。
因此，如果在一次CMS GC还没完成时，用户线程的内存分配再次触发了GC请求，那么新的GC请求将会背延迟，直到当前的CMS GC完成
3.并发模式失败(Concurrent Mode Failure)
如果在CMS执行的过程中，用户线程分配内存速度过快，导致老年代空间不足，无法等待CMS完成，此时JVM会触发"并发模式失败"(Concurrent Mode Failure)
这种情况下，JVM会切换到一个单线程的"Searial Old" GC执行一次Stop-The-World(STW)全堆回收，以保证系统能够继续运行，Searial Old GC是一种较慢但确保回收的垃圾收集方式

G1垃圾收集器
G1收集器在一次GC尚未完成时，如果又触发了新的GC请求，第二次GC不会打断第一次GC，而是会在第一次GC完成后开始。这一点与CMS类似，但G1的优势在于它的设计更灵活，能够更好地控制GC暂停时间并减少进入Full GC的概率。

ZGC垃圾收集器
1.如果在ZGC正在进行一次垃圾回收时(例如正在进行并发标记或并发重定位)，用户线程分配新对象的速度很快，导致需要再次进行垃圾回收，ZGC不会因为新的GC请求而停止当前的GC操作。相反，他会继续完成当前的GC操作，同事计划和开始新的GC周期
2.由于ZGC的设计理念是"全并发"，因此它能够非常灵活地处理多个垃圾回收周期的重叠情况。新的GC周期可以与旧的GC周期重叠执行，而不会导致显著的暂停时间增加

枚举根节点
从可达性分析中从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项工作必须在一个能确保一致性的快照中进行——这里"一致性"的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对应引用关系还在不断变化的情况。该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有Java执行线程(Sun将这件事称为"Stop The World")的其中一个重要原因，即使时在号称(几乎)不会发生停顿的CMS收集器中，枚举根节点也是必须要停顿的。
由于目前的主流Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

例如
```bash
[Verified Entry Point]
0x026eb730: mov $eax,-0x8000(%esp)
....
0x026eb7a9: call 0x026e83e0; OopMap{ebx=Oop [16]=Oop off=142}
0x026eb7ae: push $0x83c5c18
0x026eb7b3: call 0x026eb7b8
0x026eb7b8: pusha
0x026eb7b9: call 0x0822bec0
0x026eb7be: hlt
```
上面代码时HotSpot Client VM生成的一段String.hashCode()方法的本地代码，可以看到在0x026eb7a9处的call指令有OopMap记录，它指明了EBX寄存器和栈中偏移量为16的内存区域处各有一个普通对象指针(Ordinary Object Pointer)的引用，有效范围为从call指令开始知道0x026eb730(指令流的起始位置)+142(OopMap记录的偏移量)=0x026eb7be,即hlt指令为止

准确式GC
早之前的Exact VM版本因为使用准确式内存管理(Exact Memory Management也可以叫Non-Conservative/Accurate Memory Management)而得名，即虚拟机可以知道内存中某个位置的数据具体是什么类型。比如内存中有一个32位的整数123456，它到底是一个reference类型指向123456的内存地址还是一个数值位123456的整数。虚拟机将有能力分辨出来，这样才能在GC的时候准确判断堆上的数据是否还可能被使用。由于使用了准确式内存管理,Exact VM可以摒弃以前Classic VM基于handler的对象查找方式(原因是进行GC后对象将可能会被移动位置。如果将地址为123456的对象移动到654321，在没有明确信息表明内存中哪些数据是reference的前提下，虚拟机是不敢把内存中所有为123456的值改成654321，所以要使用句柄来保持reference值的稳定)，这样每次定位对象都少了一次间接查找的开销，提升执行性能

安全点(如果线程随便哪个位置都可以停下来，这个问题就会简单很多)
在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实地问题随之而来：可能导致引用关系变化，或者说OopMap内容变化地指令非常多，如果为每一条指令都生成OopMap，那将需要大量的额外空间，这样GC的空间成本将会变得很高。
实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在"特定位置"记录了这些信息，这些位置称为安全点(Safepoint)，即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。Safepoint的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时的负荷。所以,安全点的选定基本上是以程序"是否具有让程序长时间执行的特征"为标准进行选定的——因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，"长时间执行"的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等。所以具有这些功能的指令才会产生Safepoint.

对于Safepoint.另一个需要考虑的问题是如何在GC发生时让线程(这里不包括执行JNI调用的线程)都"跑"到最近的安全点上再停顿下来。这里有两种方案可供选择:抢先式中断(Preemptive Suspension)和主动式中断(Voluntary Suspension)。其中抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它"跑"到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志位真时就自己中断挂起，轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

例如
```bash
0x01b6d627:call  0x01b2b210; OopMap{[60]=OOp off=460}
0x01b6d62c:nop
0x01b6d62d:test  %eax,0x160100
0x01b6d633:mov   0x50(%esp),%esi
0x01b6d637:cmp   %eax,%esi
```
下面代码中的test指令是HotSpot生成的轮询指令，当需要暂停线程时，虚拟机把0下0x60100的内存页设置为不可读，线程执行到test指令时就会产生一个自陷异常信号，在预先注册的异常处理器中暂停线程实现等待，这样一条指令便完成安全点轮询和触发线程中断


安全点同时解决了STW(暂停的位置)和更新OopMap(更新对象引用关系的位置)的问题

从Linux层面来说，可以调用API来暂停线程，代码量会比较大，JIT还要把它转成硬编码，难度也大。安全点现在的解决方案：
通过内存中断实现，内存页memory page 可读可写可执行，JIT需要这几个属性，如果想要安全性更高，需要把可执行禁掉。Mac上JIT是不工作的，在合适安全点的地方插入一段代码 test %eax,os_poling_page.安全点到达实际就是用户执行到test指令的实际，这条指令会改变状态寄存器状态，使得内存页变得不可读不可写，触发段异常，SIGSEGV内核捕获之后暂停线程

安全区域
使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际情况却并不一定，Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint.但是，程序"不执行"的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，"走"到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域(Safe Region)来解决。安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始的GC都是安全的。我们也可以把Safe Region看作是被扩展了的Safepoint。
在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region,那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举(或者是整个GC过程)，如果完成了，那线程就继续执行，否则它就必须等待知道收到可以安全离开Safe Region的信号为止。

在Java虚拟机(JVM)中，执行引擎(Execution Engine)是负责执行Java字节码的核心组件。执行引擎的作用是将Java字节码转换成计算机可以执行的机器码,并实际执行这些机器码。以下是JVM执行引擎的主要职责和组成部分:

主要职责:
1.加载和验证字节码:执行引擎确保加载的类文件符合JVM规范，并进行验证
2.执行字节码:执行引擎逐条执行Java字节码指令
3.优化执行:在运行时，执行引擎可能会对字节码进行优化以提高性能
4.内存管理:执行引擎负责管理JVM运行时的内存，包括堆(Heap)、栈(Stacks)、方法区(Method Area)等

执行引擎的组成部分:
解释器(Interpreter):
1.解释器是执行引擎的一部分，它逐条读取和执行Java字节码
2.解释执行的特点是启动速度块，但执行速度相对较慢，因为它需要逐条解释和执行字节码

即时编译器(Just-In-Time Compiler, JIT)
1.JIT编译器将Java字节码编译成本地机器码，这样可以直接在硬件上执行，从而提高执行效率
2.JIT编译器在运行时进行编译，可以针对程序的运行特性进行优化

垃圾回收器(Garbage Collector, GC)
1.虽然垃圾回收器主要负责内存管理，但它也是执行引擎的一部分，因为它在执行过程中负责清理不再使用的对象

本地方法接口(Natvie Method Interface, JNI)
1.JNI允许Java代码调用其他语言编写的本地(Native)方法，这些方法通常用C/C++编写

本地方法库(Native Method Libraries)
1.本地方法库时执行引擎调用的本地方法所在的库，这些库提供了Java程序可以调用的本地函数

执行引擎的工作流程大致如下:
1.类加载器将.class文件加载到JVM中
2.字节码验证其确保加载的字节码是有效的
3.解释器开始逐条执行字节码
4.在运行过程中，JIT编译器可能会识别出热点代码(执行频率高的代码)，并将这些字节码编译成本地机器码以加速执行
5.如果程序调用了本地方法，JNI会负责调用相应的本地方法库中的函数

执行引擎的设计和实现因不同的JVM实现而异，但他们都遵循Java虚拟机规范，以确保Java程序在不同的JVM上能够一致地运行

JVM的三种执行模式
解释模式
1.通过解释器(Bytecode Interpreter)解释执行
特点是:启动快(不需要编译),执行慢
可通过:-Xint参数执行为纯解释模式
2.编译模式
由JIT(Just In Time Compiler)编译为本地代码(C语言代码)主席那个
特点:启动慢(编译过程慢),执行快
可通过-Xcomp参数指定为纯编译模式
3.混合模式
混合使用解释器(Bytecode Compiler) + 热点代码编译(Just In Time Compiler)
起始阶段采用解释执行
热点代码检测(HotSpot)，默认-XX:CompileThreshold=10000
多次被调用的方法(方法计数器:监测方法执行频率)
多次被调用的循环(循环计数器，监测循环执行频率)
对热点代码进行编译
默认采用这种模式，可通过-Xmixed指定

在JDK9及更高的版本中，JVM引入了AOT(Ahead-Of-Time)编译器。AOT编译允许在程序执行之前将Java字节码提前编译为机器码，从而避免或减少运行时的解释和即时编译。这种方式与传统的JIT不同，因为它在程序启动之前就完成了编译

AOT
提前编译是相对于即时编译的概念，提前编译能带来的最大好处是Java虚拟机加载这些已经预编译成二进制库之后就能够直接调用，而无须再等待即时编译器在运行时将其编译成二进制机器码。理论上，提前编译可以减少即时编译带来的预热时间，减少Java应用长期给人带来的“第一次运行慢"的不良体验，可以放心地进行很多全程序的分析行为，可以使用时间压力更大的优化措施。但是提前编译的坏处也很明显，它破坏了Java"—次编写，到处运行"的承诺，必须为每个不同的硬件、操作系统去编译对应的发行包；也显著降低了Java链接过程的动态性，必须要求加载的代码在编译期就是全部已知的，而不能在运行期才确定，否则就只能舍弃掉己经提前编译好的版本，退回到原来的即时编译执行状态。

AOT的优点

在程序运行前编译，可以避免在运行时的编译性能消耗和内存消耗
可以在程序运行初期就达到最高性能，程序启动速度快
运行产物只有机器码，打包体积小
AOT的缺点

由于是静态提前编译，不能根据硬件情况或程序运行情况择优选择机器指令序列，理论峰值性能不如JIT
没有动态能力
同一份产物不能跨平台运行

参考文章https://cloud.tencent.com/developer/article/2228910

Java被称为"半编译半解释型"语言，主要是因为它的编译和执行过程结合了编译和解释两种方式。这个特点使得Java既可以保持一定的执行效率，又具备良好的跨平台特性。
具体来说，Java的编译和执行过程如下:
1.源代码编译:Java程序员编写的Javaa源代码文件(.java文件)首先由Java编译器(javac)编译，生成字节码文件(.class文件).这个过程类似于其他编译型语言的编译步骤。
字节码是一种中间形式的代码,它并不是机器码，而是一种中间表示形式，主要是为Java虚拟机(JVM)准备的
2.字节码解释:编译后的字节码不是直接由操作系统执行的，而是由Java虚拟机(JVM)解释执行。JVM是一个虚拟的计算机，负责将字节码解释为特定平台的机器码，从而使得
Java程序得以运行。这种解释的方式使得Java程序可以在不同的操作系统上运行，只要改系统上有相应的JVM
3.即时编译(JIT):为了提高程序执行的效率，JVM还采用了即使编译技术(Just-In-Time Compiler, JIT)。当JVM执行字节码时，它会将某些频繁执行的字节码动态编译成机器码，
以提高执行效率。这种即时编译进一步缩短了程序的执行时间，接近于纯编译型语言的性能

总结来说,Java的"半编译半解释"指的是:
1.编译部分:Java源代码被编译成字节码，这一步类似于编译型语言的过程
2.解释部分:字节码由JVM解释执行，或在运行时通过JIT编译为机器码，这使得Java具备跨平台的能力,同事保证了较高的执行效率
这种设计使得Java既可以保证跨平台型，又能在执行效率上达到较好的平衡

字节码解释器
做的事情是:Java字节码->C++代码->硬编码，比如说一条_new指令，字节码解释器bytecodeInterpreter
C++代码中有很多跟new指令无关的才能到目标代码，好比你要执行一条字节码指令_new，字节码解释器需要执行很多操作，比如说要读取字节码文件对应索引的指令，才能到真正这条字节码需要做的事情，比较繁琐。一个字节码指令占一个字节，2^8-1=255，所以最多只能有255个

模板解释器
做的事情是Java字节码->硬编码
```c++
void TemplateTable::_new() {
  transition(vtos, atos);

  Label slow_case;
  Label done;
  Label initialize_header;
  Label initialize_object;  // including clearing the fields

  Register RallocatedObject = Otos_i;
  Register RinstanceKlass = O1;
  Register Roffset = O3;
  Register Rscratch = O4;

  __ get_2_byte_integer_at_bcp(1, Rscratch, Roffset, InterpreterMacroAssembler::Unsigned);
  __ get_cpool_and_tags(Rscratch, G3_scratch);
  // make sure the class we're about to instantiate has been resolved
  // This is done before loading InstanceKlass to be consistent with the order
  // how Constant Pool is updated (see ConstantPool::klass_at_put)
  __ add(G3_scratch, Array<u1>::base_offset_in_bytes(), G3_scratch);
  __ ldub(G3_scratch, Roffset, G3_scratch);
  __ cmp(G3_scratch, JVM_CONSTANT_Class);
  __ br(Assembler::notEqual, false, Assembler::pn, slow_case);
……
```
内部维护了一个执行流数组RunStream[] arr = new RunStream[255];
arr[187] = {

0x55, // pushq %rbp
0x48,0x89,0xe5 // movq %rsp, %rbp
0xb8, 0x0b, 0x00,0x00,0x00 // movl $0xb, %eax
0x5d, // popq %rbp
0xc3 // retq
}
这种行为就叫硬编码编织，比C++执行效率要高，怎么理解呢？编织技术一种精细化的构造，使用的内存消耗小于原生的内存分配.
JIT底层实现(找到硬编码)
1.申请一块内存(可读可写可执行权限)，线性地址用来存储代码
2.调用函数指针
3.硬编码写入

malloc申请的内存区域是可读可写的。模板解释器可以省区哪些没有意义的汇编代码

-Xint

-Xcomp

-Xmixed

为什么没有用纯编译模式？
首次启动的时候要生成所有执行流，可能是担心生成执行流的时间比较长，用mixed的话，可以字节码解释器一边运行一边用热点代码编译

Client Compiler架构设计
对于Client Compiler来说，它是一个简单快速的三段式编译器，主要的关注点在于局部性的哟话，而放弃了许多耗时较长的全局优化手段。
1.在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码标识(High-Level Intermediate Representation, HIR).HIR使用静态单分配(Static Single Assignment, SSA)的形式来代表代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。
2.在第二个阶段，一个平台相关的后端从IHR中产生低级中间代码标识(Low-Level Intermediate Representation, LIR)，而再次之前会在HIR上完成另外一些优化，如空值检查消除、范围检查消除等，以便在HIR达到更高效的代码表示形式
3.最后阶段是在平台相关的后端使用线性扫描算法(LInear Scan Register Allocation)在LIR上做窥孔(Peephole)优化，然后产生机器代码

Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数的优化强度，它会执行所有经典的优化动作，如无用代码消除(Dead Code Elimination)、循环展开(Loop Unrolling)、循环表达式外提(Loop Expressin Hoisting)、消除公共子表达式(Common Subexpression Elimination)、常量传播(Constant Propagation)、基本块重排序(Basic Block Reordering)等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查消除(Range Check Elimination)、空值检查消除(Null Check Elimination，不过并非所有的空值检查消除都是依赖编译器优化的，有一些是在代码运行过程中自动优化了)等。另外，还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的基金优化，如守护内联(Guarded Inlining)、分支频率预测(Branch Frequency Prediction)等。

Server Compiler的寄存器分配是一个全局着色分配器，它可以充分利用某些处理器架构(如RISC)上的大寄存器集合。以即时编译的标准来看，Server Compiler无疑是比较缓慢的。但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用Server模式的虚拟机运行

JIT编译过程本来就是一个虚拟机中最体现技术水平也是最复杂的部分，不可能以较短的篇幅就介绍得很详细，另外，这个过程对Java开发来说是透明的，程序员平时无法感知它的存在。

方法调用计数器触发即时编译

查看及分析即时编译结果(需要开启VM 参数-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining)
```java
public class JITTest {


    public static final int NUM = 15000;

    public static int doubleValue(int i) {
        // 这个空循环用于后面演示JIT代码优化过程
        for (int i1 = 0; i1 < 100000; i1++);
        return i * 2;
    }

    public static long calcSum() {
        long sum = 0;
        for (int i = 0; i < 100000; i++) {
            sum += doubleValue(i);
        }

        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++) {
            calcSum();
        }
    }
}
```
带%的输出说明是由回边计数器触发的即时编译，可以看到calcSum()和doubleValue()方法都已经被即时编译，并且还看到了doubleValue方法已经被内联编译到calcSum()方法中

开始栈上分配，创建100w个对象，HSDB查看对象的数量，只有11w个对象

关闭栈上分配

常量池项内容如图所示，我们可以看到它是把double类型分割成了高低位

byte++和i++哪个效率更高?
int++只对应了一句字节码指令，而byte++对应了五句字节码指令。性能会有5倍的差异。

iinc指令拓宽
Intel CPU是怎么解决指令集不够用的问题呢？最开始其实也只有一个字节，后面扩展成二级指令，现在已经到三级指令了。所以其实你的知识面越底层，真正的理解底层，你就能预测出未来可能到来的变化:比如这里说的，JVM当前的以及指令不够用了，它也要引入二级指令。这就是阿里P8的硬要求之一:技术前瞻性。

iinc指令
不管是i++还是i--操作，编译后对应的字节码指令都是iinc指令。如图所示，iinc字节码结构如图所示。
1.IINC:对应的是字节码指令
2.Slot Index对应的是这个指令作用的局部变量在局部变量表中的索引
3.step 一次加多少。固定值为1，如果这个值不存在特殊考虑，这个字节可以节省下来。这个要看JDK后面会不会有这个计划

超级加倍
不知道大家有没有发现一个问题，iinc指令的第一个参数，即代表slot index这个参数，只有一个字节，这就是i++、i--存在的约束。这个约束就是如果局部变量的索引超过128，就只能走byte++那种复杂的逻辑。那么JVM是怎么做的呢？JVM做了指令拓宽，增加了一个字节位

1.常量池中会有一项:JVM_COnstant_InvokeDynamic_info

2.类属性里面会有一项:BootstrapMethods

3.常量池中还会出现两个JVM_CONSTANT_MethodHandle,一个JVM_CONSTANT_MethodType

4.还会多出一个方法。这个方法是编译器自动生成的。所以可以这样说，Lambda表达式的实现，是编译系统与运行系统互相配合实现的

5.Lambda表达式的调用指令是invokedynamic

1.通过indy后面后面的操作数，拿到常量池中的信息:JVM_CONSTANT_InvokeDynamic.大家有没有注意到，我们Java代码中的run方法返回类型是void,编译之后却是CustomLambda。言外之意，这一步执行完会创建CustomerLambda的实现对象。

2.从常量池项JVM_CONSTANT_InvokeDynamic中拿到BootstrapMethods的索引。即我们目前调用的是第几个BootstrapMethod

3.BootstrapMethod结构中的Bootstrap方法，对应的常量池项是MethodHandle.JVM就是通过执行LambdaMetafactory.metafactory创建出CallSite，进而创建出Lambda表达式对应的对象的。BootstrapMethod结构中的其他信息，都是一些辅助信息，是调用mefafactory方法需要传的参数
<java/lang/invoke/LambdaMetafactory.metafactory : (Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;>

4.JVM也是通过执行LambdaMetafactory.metafactory完成Lambda表达式对应的函数式接口与具体实现中的代码的关联。背后的实现原理就是通过字节码，我们可以使用-Djdk.internal.lambda.dumpProxyClasses可以将生成的类保存到文件中。看下生成的文件内容

总结来说就是JVM通过BootstrapMethod找到LambdaMetafactory.metafactory并执行，完成Lambda表达式对应的函数式接口与具体实现中的代码的关联，默认的，在内存中会生成一个新的类，并返回这个类的实例，所以，可以这样调用run方法
```java
obj.run(1);
```

自实现的JVM如何支持Lambda表达式
我们想要的是如何能够生成MethodHandles.Lookup,本能的会想到，MethodHandles.lookup(TestLambda.class)，但是没有这样的API实现，我们需要用MethodHandle + 反射来实现

Lambda底层是由MethodHandles生成，然后生成动态调用点，在内存中生成一个TestLambda$$Lambda$类似的实现类文件

实现Lambda表达式的一个细节
最开始的
Method fun = obj.getClass().getMethod(methodName, paramsClass);
改过之后:
Class<?> clazz = Class.forName(className.replace('/','.'));
反射生成的TestLambda$$Lambda$1

GC的发展
1.内存结构的发展
一开始是一块整堆，
2.GC算法的发展，由于Java是自动垃圾回收，所以回收算法效率会很重要
标记-清除:容易发生碎片化
标记-整理:它虽然解决了碎片化问题，但是它是一个CPU密集型，耗时长短和堆大小有关。
标记-复制:所以后面内存结构就划分为了两半，采用复制的方式来转移存活对象，但是发现内存空间浪费太严重，于是有人根据对象的存活周期和统计学理论划分除了新生代与老年代。也就有了新生代8:1:1的划分

Region模型的由来
G1如果想要做到可预测停顿的话，那么内存空间就不能太大，如果不重新设计模型，当扫描大块的内存空间时将会耗费很长时间，所以它必须重新规划堆区，这也就有了Region模型，每个Region固定大小2M

再想提升效率，那么将就得多开几个线程来解决
比如串行回收调整成并行回收
再到后面再调整成并发回收

GC的过程可以划分为三个:标记、清除、复制

三色标记算法
黑色:新产生的对象，已经扫描完引用关系的对象
灰色:当前对象已扫描完，还没扫描引用关系
白色:所有没有被扫描到的对象或待清理对象

标记
1.首先要扫描出根据对象GC Roots(这个阶段需要STW，因为要确保不会产生新对象，不会出现引用关系的变动)，大概需要花费50-100ms
那么哪些对象可以作为GC Roots呢？
栈中指向堆中的对象、静态属性、字符串常量池这些
2.接下来要扫描根对象引用的其他对象，这个属于并发标记，可以和用户线程一起执行。这个阶段的耗时跟堆的大小成正比。
a.会产生新对象(多标)
对于新产生的对象三色标记算法中是将其视为黑色，留到下次GC时清理,不会在程序中引起报错，就是占用堆空间而已
b.黑色对象使用完之后，已经不在被其他对象使用，也会留到下次GC时清理(少标)
c.会发生引用关系的变动(漏标问题)
漏标分为两种情况:
1.灰色对象断开了白色的引用。
记录引用关系变动之前的关系图 原始快照(写前屏障 G1)
2.黑色对象建立了对白色的引用
记录引用关系变动之后的关系图 增量更新(写后屏障 CMS)

还有一个问题就是原始快照、增量更新产生的这些引用关系变动的记录会放到哪里呢？
CMS:会放到一个脏页当中
G1会将oop放入到一个队列中

最终标记:对并发标记中引用关系发生变动的记录做进一步处理，这个阶段需要STW

STW底层实现原理
1.JVM得知道什么时候需要STW
启用安全点的方式
SafepointSyncrhonize::begin()

那么如何激活安全点的呢？
-poling_page属性改为NONE(不可读不可写)
2.所有的线程是如何感知到启用了安全点
a.安全点插入的位置，取决于让程序长时间运行的可能代码，一般常见于
大的循环里面或者方法结束的位置|
在一个大的循环里面需要wide_vectors才会启用，对于像int类型的循环不会，long类型才会。还有一个是方法结束的时候

插入的内容就是
test %eax os::_polling_page
这段汇编代码会有两个效果
对于正常执行情况下，可读可写的时候，不会产生任何效果
对于GC情况下，不可读不可写的时候，就会触发段异常 SIGSEGV
安全点的实现就是基于段异常来实现的，利用的是Linux的信号处理机制，我们可以用kill -l 查看信号类型

JVM会注册这个SIGSEGV这个信号，设置一段回调函数
register(SIGSEGV, () {
    执行STW逻辑
})
HotSpot通过JVM_handle_linux_signal这个函数进行注册的，来拦截默认的Linux信号处理。JVM是不希望Linux系统来处理这个逻辑，所以进行了拦截


但是呢？JVM操作空指针也会出现段异常，那么JVM是怎么识别是_poling_page触发的还是空指针触发的呢？

if (sig == SIGSEGV && os::is_poll_address((address)info->si_addr)) {

poling_page是什么呢？
// Allocate a single page and mark it as readable for safepoint polling
  address polling_page = (address) ::mmap(NULL, Linux::page_size(), PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
  guarantee( polling_page != MAP_FAILED, "os::init_2: failed to allocate polling page" );

  os::set_polling_page( polling_page );
3.JVM是如何找到所有的线程的？Linux是没有API能够返回当前进程的所有线程呢？其实是JVM自己保存的
Threads
Thread又分JavaThread、WatcherThread
4.所有的线程是如何暂停的？在哪里暂停的
遍历线程单链表逐个Park

HotSPot STW源码
信号处理:JVM_handle_linux_signal
申请poling_page:os:init_2
更改poling_page
make_poling_page_unreadable
make_poling_page_readable

test指令就是都内存，在手写时，如果写C++代码，翻译成汇编需要很多很多的指令，所以可以直接读/写 polling_page即可(汇编也是对应的test指令)

OopMap的作用
在Java虚拟机中，OopMap(ObjectOops Map)是一个重要的数据结构，它用于在垃圾回收(特别是Stop-The-World垃圾回收)期间，帮助虚拟机确定堆栈上对象引用的位置。以下是OopMap的主要作用:
1.确定GC Roots:在垃圾回收过程中，JVM需要找出所有的根集合，即直接或间接引用堆中对象的地方。这包括全局变量、活跃线程的栈帧中的局部变量和操作数栈上的引用、静态变量、常量
2.减少扫描范围:如果没有OOpMap，JVM在垃圾回收时需要扫描整个栈来查找所有的引用，这会非常低效。OopMap允许JVM只关注那些可能可能包含对象引用的栈帧部分，从而减少扫描的工作量
3.支持精确的垃圾回收:有了OopMap,JVM可以执行精确的垃圾回收，即准确知道哪些对象是存活的，哪些是垃圾。这有助于实现CMS、G1等现代垃圾回收算法
4.优化停顿时间:由于OopMap的存在，JVM可以在Stop-The-World时间发生时快速地完成根集合的扫描，从而减少应用程序的停顿时间
5.处理栈上变化：当JVM执行代码时，它会在特定的安全点(safepoints)更新OopMap.这些安全点时代码执行的特定位置，在这个位置上，JVM可以安全地暂停线程并更新OopMap，以反映栈和寄存器中的最新状态
6.协助调试和诊断:在调试和诊断虚拟机问题时，OopMap提供的信息可以帮助开发者理解对象的引用关系，以及它们在特定时间点的状态

GC标记的核心
区分出活跃对象和非活跃对象，GC Roots就是一批活跃的对象。以栈中的对象为例，栈中的对象是直接存放数值还是内存地址？
我们可以设想出两种方案:
1.全部封装成一个对象，里面标识这个位置是什么类型
2.直接放数据(JVM的做法，不是很理解)

在面对栈中的0x7fddd这样的一个字面量时，JVM如何知道它的类型是一个引用地址还是数值呢？于是GC又分为两类:
保守式GC 不能识别指针与非指针的GC
准确式GC 精准识别
HotSpot版本的虚拟机实现是准确式GC,它是通过借助第三方数据结构——栈图来实现的。在手写JVM的Java版本中是每个数据都会封装成一个对象(StackValue)，里面有个标识，标识这个对象是什么类型。伪代码如下
```java
StackValue v = new StackValue(T_INT, 1);
// 遍历所有线程
for (Thread t : threads) {
// 遍历线程的栈帧
   for (StackValuie v : t.frame()) {
// 如果是引用类型，并且被GC Roots引用，则加入到OopMap当中
        if (T_OOP) {
            OopMap.insert(v);
         }
    }
}
```

栈图是什么？
对于基本类型和引用类型，将它们的值保存在局部变量数组和操作数栈中的助记符是不同的。基本类型的助记符是istore_1，而引用类型的助记符是astore_2.
HotSpotVM利用字节码的类型信息，来创建发生GC时栈帧的栈图。顾名思义，栈图就是表示将引用类型保存在局部变量数组和操作数栈上什么位置的地图。实际的栈图是以00100这样的比特序列表示的。比特序列中值为1的比特，表示它所对应的局部变量(或操作数栈)中保存的引用类型的值

抽象解释器
栈图是由抽象解释器创建出来的。简单地说，抽象解释器就是只记录类型信息的解释器。抽象解释器只记录保存在局部变量和操作数栈中的值的类型，并不关心实际保存的值。如代码示例，来比较一下抽象解释器和普通解释器的行为
```java
BasicBlock#0
pc( 0): locals = 'r  ', stack = ''   // iconst_1
pc( 1): locals = 'r  ', stack = 'v'  // istore_1
pc( 2): locals = 'rv ', stack = ''   // new #2
pc( 5): locals = 'rv ', stack = 'r'  // dup
pc( 6): locals = 'rv ', stack = 'rr' // invokespecial #1
pc( 9): locals = 'rvr', stack = 'r'  // astore_2
pc(10): locals = 'rvr', stack= ''     // return
```
抽象解释器的执行流程很好写，如上所示。locals是局部变量数组，stack是操作数栈。请将局部变量数组或操作数栈中的r(reference)当作引用类型，把v(value)当作基本类型。
抽象解释器会记录某个命令集被执行前的局部变量数组和操作数栈的类型信息。例如在pc0处，他会记录iconst_1被执行前的类型信息。因此，局部变量数组(locals)中只有表示参数args的类型r将被记录下来。接下来，在pc1处执行完iconst_1后，操作数栈(stack)中表示1的类型v将被记录下来。
抽象解释器就是像这样毫不关心实际值，只记录类型信息的。接着，HotSpotVM就会根据抽象解释器记录下的对应了一次字节码执行的类型信息创建栈图

下一步则是通过栈图找到GC Roots，然后让如OopMap中

没执行一条字节码指令都需要操作下栈图

当一个对象及其引用关系被遍历完之后，会OopMap中放入到black table(黑色对象集合当中)
而当一个对象仅仅本身被扫描完，则会从OopMap中放入到gray table中