JVM知识点整理

常量池运行时加载到内存中，即运行时常量池

加载刚好是加载过程的一个阶段，二者意思不能混淆

通过一个类的全限定名获取定义此类的二进制字节流

将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构

在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口

验证

准备

解析

初始化阶段是执行类构造器方法<clinit>()的过程

此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来

构造器方法中指令按照语句在源文中出现的顺序执行

<clinit>()不同于类的构造器（关联：构造器是虚拟机视角下的<init>()）

若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。

解析阶段不一定，在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）

Java虚拟机规范严格规定了，有且只有六种情况，必须立即对类进行初始化

除了以上几种情况，其他使用类的方式被看做是对类的被动使用，都不会导致类的初始化

概念上，将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器

截图

对于用户来说，默认使用系统类加载器进行加载

Java的核心类库，使用引导类加载器进行加载

C/C++语言实现，嵌套JVM内部

用来加载Java核心类库，rt.jar,resources.jar,sun.boot.class.path路径下的内容

并不继承java.lang.ClassLoader，没有父加载器

加载扩展类和应用程序类加载器，并指定为他们的父类加载器

出于安全考虑，Bootstrap启动类加载器只加载包名为java\javax\sun等开头的类

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现

派生于ClassLoader类

父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库

Java语言编写，由sun.misc.Launcher$AppClassLoader实现

派生于ClassLoader类

父类加载器为扩展类加载器

负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

该类加载器是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载

通过ClassLoader#getSystemClassLoader（）方法可以后去到改类加载器

为什么要用自定义类加载器

实现步骤

是一个抽象类，除了启动类加载器，其他类加载器都继承自他

Java虚拟机对Class文件采用的是按需加载，而且加载class文件时，Java虚拟机使用的是双亲委派模式，即把请求交由父类处理，它是异种任务委派模式

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

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

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

避免类的重复加载

保护程序安全，防止核心API被篡改

保证对Java核心源代码的保护

类的完整类名必须一致，包括包名

加载这个类的ClassLoader必须相同

局部变量  vs  成员变量

基本数据类型   VS 引用类型变量（类，数组，接口）

每个方法执行，伴随着进栈（入栈，压栈）

执行结束的出栈

Java栈大小是动态或者固定不变的。如果是动态扩展，无法申请到足够内存OOM，如果是固定，线程请求的栈容量超过固定值，则StackOverflowError

截图

一种是正常的函数返回，使用return指令

另外一种是抛出异常，不管哪种方式，都会导致栈帧被弹出

定义为一个数字数组，主要用于存储方法参数，定义在方法体内部的局部变量，数据类型包括各类基本数据类型，对象引用，以及return address类型

局部变量表建立在线程的栈上，是线程私有的，因此不存在数据安全问题

局部变量表容量大小是在编译期确定下来的

局部变量表存放编译期可知的各种基本数据类型（8种），引用类型（reference）,return address 类型

最基本的存储单元是slot

局部变量表中的变量只有在当前方法调用中有效，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。

方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁

关于Slot的理解

静态变量与局部变量对比及小结

补充：

在方法执行的过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈/出栈

如果被调用方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新程序计数器中下一条需要执行的字节码指令

Java虚拟机的解释引擎是基于栈的执行引擎，其中栈就是操作数栈

主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间

当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的

每一个操作数栈会拥有一个明确的栈深度，用于存储数值，最大深度在编译期就定义好

栈中，32bit类型占用一个栈单位深度，64bit类型占用两个栈单位深度

操作数栈并非采用访问索引方式进行数据访问，而是只能通过标准的入栈、出栈操作完成一次数据访问

栈顶缓存技术

指向常量池的方法 引用

常量池、运行时常量池

存放调用该方法的pc寄存器的值

方法的结束

无论哪种方式退出，方法退出后，都会返回该方法被调用的位置。方法正常退出时，调用者的PC计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。

异常退出的，返回地址是通过异常表来确定，栈帧中一般不会保存这部分信息

执行引擎遇到任意一个方法返回的字节码指令（return）,会有返回值传递给上层的方法调用者，简称正常完成出口

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

正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值

允许携带与Java虚拟机实现相关的一些附加信息，例如对程序调试提供支持的信息。不确定有，可选情况

静态链接

动态链接

方法的绑定

Java中任何一个普通方法都具备虚函数的特征（运行期确认，具备晚期绑定的特点），C++中则使用关键字virtual来显式定义

如果在java程序中，不希望某个方法拥有虚函数的特征，则可以使用关键字final来标记这个方法

虚方法和非虚方法

方法调用指令

方法重写的本质

虚方法表

例如与操作系统底层或硬件交换信息时的情况

例如启动一个线程

Java7及之前

Java8及之后

约定

安装插件后可查看

可开启打印查看方法区实现

超过最大内存将抛出OOM

初始内存大小

最大内存大小

查看当前程序运行的进程

查看JVM在gc时的统计信息

-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3

-XX:SurvivorRatio调整这个空间比例

实际是6:1:1，因为有自适应机制

Eden放不了的大对象，直接进入老年代了。

-XX:MaxTenuringThreshold=N进行设置

针对幸存者s0，s1区的总结：复制之后有交换，谁空谁是to

频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间搜集

old区也放不下，需要FullGC（MajorGC），这两GC概念还是有区别的。下面详解

GC按照内存回收区域分为

当年轻代空间不足时，就会触发MinorGC，这里的年轻代指的是Eden代满，Survivor满不会触发GC。每次MinorGC会清理年轻代的内存

因为Java对象大多朝生夕灭，所以MinorGC非常频繁

MinorGC会引发STW

指发生在老年代的GC，对象从老年代消失，我们说“MajorGC”“FullGC”发生了

出现了MajorGC，经常会伴随至少一次MinorGC

MajorGC的速度比MinorGC慢10倍以上，STW的时间更长

如果MajorGC后，内存还不足，就报OOM了

1、调用System.gc()时，系统建议执行FullGC，但是不必然执行

2、老年代空间不足

3、方法区空间不足

4、通过MinorGC后进入老年代的平均大小，大于老年代的可用内存

5、由Eden区，Survivor 0区向Survivor 1区复制时，对象的大小大于ToSpace可用内存，则把改对象转存到老年代，且老年代的可用内存小于该对象的大小

FullGC是开发或调优中尽量要避免的，这样暂停时间会短一些。

-XX:MaxTenuringThreshold

尽量避免程序中出现过多的大对象

如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄

-XX:HandlePromotionFailure

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间，是否大于新生代所有对象的总空间

子主题

从内存模型而不是垃圾收集的角度，对Eden区域进行划分，JVM为每个线程分配了一个私有缓存区域，包含在Eden空间中

多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们将这种内存分配方式成为快速分配策略

openjdk衍生出来的JVM都提供了TLAB的设计

补充

单击打开博客

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

栈上分配

同步策略

分离对象或标量替换

元空间的本质和永久带类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存

根据Jvm规范，如果方法区无法满足新的内存分配需求，将抛出OOM异常

-XX:MaxPermSize

JDK7及以前

JDK8及以后

它用于存储已被虚拟机加载的类型信息，常量，静态变量，即时编译器编译后的代码缓存

jdk1.6及之前

jdk1.7

jdk1.8及之后

随着 JAVA8的到来，HotSpotVM中再也见不到永久代了，但是并不意味着类的元数据信息也消失了，这些数据被转移到了一个与堆不相连的本地内存区域，这个区域叫做元空间MetaSpace

由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统的可用内存空间

为永久代设置空间大小很难确定，在某些场景下，如果动态加载类过多，就容易产生OOM

而元空间并不在虚拟机中，而是使用本地内存，因此默认情况下，元空间的大小仅受本地内存限制

对永久代进行调优是很困难的

常量池中废弃的常量

不再使用的类型

在大量使用反射，动态代理，CGLib等字节码框架，动态生成JSP以及OSGI这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力

字面量

符号引用

new

Class的newInstance

Constructor的newInstance

使用clone

使用反序列化

第三方库Objenesis

1、判断对象对应的类是否加载、链接、初始化

2、为对象分配内存

3、处理并发安全问题

4、初始化分配到的空间

5、设置对象的对象头

6、执行init方法进行初始化

包含两部分

说明：如果是数组，还需要记录数组的长度

对象的实例数据部分，是对象的真正存储的有效信息，即我们在程序代码中定义的各种类型的字段内容，无论是父类继承下来，还是子类中定义的字段都要鸡柳下来。

1、这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。
2、分配策略参数-XX:FieldsAllocationStyle
3、HotSpot虚拟机默认的分配顺序为longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers）
4、从默认的分配策略中可以看出，相同宽度的字段总被分配到一起存放。
5、在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。
6、如果HotSpot虚拟机的+XX：CompactFields参数值为true（默认也是true），那么子类中较窄的变量也允许插入父类变量的空隙之间，以节省一点点空间。

对其填充，这并不是必然存在，没有特别的意义，它仅仅起着占位符的作用。

使用句柄，Java堆中将划出一块内存作为句柄池，reference中存储的就是对象的句柄地址，句柄包含对象实例数据与类型数据各自的具体信息。

使用指针，reference中存储的直接就是对象地址，如果访问对象本身，不需要多一次的间接访问的开销。

使用句柄最大好处是reference中存放的是稳定句柄地址，在对象被移动（垃圾搜集时会产生）时只改变句柄中实例数据指针，reference本身不用改变。

使用指针最大好处就是速度快，节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，所以积少成多也是一项可观的执行成本。

HotSpot主要是用指针，进行对象访问（例外情况，如果使用Shenandoah收集器的话，也会有一次额外的转发）。

1、执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。

2、每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址

3、当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息

JVM在执行Java代码的时候，通常会将解释执行与编译执行二者结合起来进行

各种采用二进制编码方式表示的指令，叫做机器指令码。机器语言。机器指令与CPU紧密相关，不同种类的CPU所对应的机器指令也就不同

由于机器码由01组成，可读性太差。于是人们发明了指令

指令就是把机器码特定的0和1序列，简化成对应的指令，一般为英文编写如mov，inc等，可读性稍好

由于不同的硬件平台，执行同一个操作，对应的机器码可能不同。所以不同的硬件平台的同一种指令，对应的机器码也可能不同

不同硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集

x86指令集，对应的x86架构的平台

ARM指令集，对应的是ARM架构的平台

由于指令的可读性太差，于是又有了汇编语言

汇编语言用助记符代替机器指令的操作码，用地址符号或标号，代替指令或操作数的地址。

汇编语言要翻译成机器指令码，计算机才能识别和执行

模板解释器将每一条字节码和一个模板函数相关联，模板函数直接产生这条字节码执行时的机器码，提高解释器的性能

Interpreter模块

Code模块

把.java文件转换为.class文件的过程

把字节码转为机器码的过程

Ahead of Time Compliler AOT，直接把.java文件编译器本地机器代码的过程

需要根据代码被调用执行的频率而定，需要被编译为本地代码的字节码，也称之为热点代码。

JIT编译器会在运行时针对频繁调用的热点代码做出深度优化，将其直接编译为对应平台的本地机器指令。以此提升Java程序的执行性能

一个被多次调用的方法，后者一个方法体内部循环次数较多的循环体，都可以被称之为热点代码

因此可以通过JIT编译器编译为本地机器指令，由于这种编译方法发生在方法的执行过程中，因此也被称之为栈上替换，OSR On Statck Replacement

一个方法调用都少次才能达到标准？这个依靠热点探测功能

client 

server

大多情况下简称C1,C2

-client：指定Java虚拟机在Client模式下，并使用C1编译器

-server：指定虚拟机在server模式下，并使用C2编译器

动机

简称不可变性

String的String pool是一个固定大小的HashTable，默认大小长度是1009，如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了，直接影响就是调用String.intern时性能会大幅下降

-XX:StringTableSize可设置StringTable的大小

JDK6固定1009，jdk7中StringTable默认的长度是60013,JDK8时默认是60013，1009是可设置的最小值

String的常量池比较特殊，主要使用方法有两种

调优时仅需调整堆大小就可以

永久代默认情况下比较小，大量字符串容易导致OOM。

永久代垃圾回收频率低，

截图

截图

截图

截图

拼接10万次，+号4000，append用了7毫秒，原因是+号每次循环创建一个StringBuilder，还要通过toString创建一个String对象

内存中由于创建了较多的对象，内存占用更大，如果需要GC需要花费额外的时间

改进空间：StringBuilder默认是16长度的char型数组，不够的时候会扩容，可以一次建一个比较大长度的数组。

截图

变形

newString("ab")会创建几个对象？

new String("a")+new String("b")?

jdk1.6中，将这个字符串对象放入串池

jdk1.7起，将这个字符串对象尝试放入串池

截图

大的网站平台，需要内存中存储大量的字符串，比如社交网站，很多人存储：北京市，海淀区等信息，这时候如果字符串调用intern方法，则会明显降低内存的大小

堆存货数据集合里面String对象占了25%

堆存活数据集合里面重复的String对象有13.5%

String对象的平均长度是45

需要单独的字段存储计数器，增加了存储空间的开销

每次赋值需要更新计数器，伴随加减法操作，增加了时间开销

无法处理循环引用的情况，致命缺陷，导致JAVA的垃圾回收器中没有使用这类算法

引用计数算法，是很多语言的资源回收选择，例如python，它更是同时支持引用计数和垃圾回收机制

是以根对象（GCRoots）为起始点，按照从上到下的方式搜索被根对象集合所连接的目标对象是否可达

使用可达性分析算法后，内存中存活的对象都被被根对象集合直接或间接连接着，搜索所走过的路径称为引用链

如果目标对象没有任何引用链相连，则是不可达的，意味着该对象已经死亡，可以标记为垃圾对象

在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活的对象

虚拟机栈中引用的对象

本地方法栈内JNI,引用的对象

方法区中静态属性引用的对象

方法区中常量引用的对象

所有被同步锁synchronized持有的对象

Java虚拟机内部的引用

反映java虚拟机内部情况的JMXBean,JVMTI中注册的回调，本地代码缓存等

除了固定的GC Roots集合之外，根据用户选择的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象临时性的加入，共同构成完整GCRoots集合，比如分代收集和局部回收

小技巧

如果需要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话，分析结果的准确性就无法保证。

这也是GC进行时必须STW的一个重要原因，即使是号称几乎不会发生停顿的CMS收集器中，枚举根节点也是必须要停顿的。

可触及的

可复活的

不可触及的

只有对象再不可触及时才可以被回收

判断一个对象ObjA是否可以被回收，至少需要经历两次标记过程

从引用根节点开始遍历，标记所有被引用的对象，一般是在对象Header中记录为可达对象

对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收

效率不算高

在GC的时候，，需要停止整个应用程序，导致用户体验差。

这种方式清理出来的空闲内存不连续，产生内存碎片，需要维护一个空闲列表

所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里，下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够就存放。

没有标记和清除的过程，实现简单高效

复制过去以后的保证空间的连续性，不会出现碎片的问题

需要两倍的内存空间

对于G1这种拆分为大量region的GC，复制而不是移动，意味着GC需要维护region之间的引用关系，不管是内存占用或者时间开销也不小。

如果系统中的垃圾对象很多，需要复制的存活对象数量并不会太大，或者非常低才行

消除了标记清除算法内存区域分散的缺点，

消除了复制算法中，内存减半代价

从效率上来讲，标记整理算法要低于复制算法

移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址

移动的过程中，需要全程暂停用户应用程序，即STW

年轻代

老年代

每次垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程，依次反复，直到垃圾收集完成

通过对线程间冲突的妥善管理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

缺点

为了控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理的回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的时间

分代算法是将对象按照生命周期长短划分为两个部分，分区算法是将整个堆划分为连续的不同的小区间

每一个小区间都独立使用，独立回收，这种算法的好处是可以控制一次回收多少个小区间

java 虚拟机的堆内存设置不够

代码创建大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

只有对象不再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄露

实际情况有一些疏忽导致对象的生命周期变的很长甚至OOM，宽泛意义上的内存泄露

举例

同一时间段内，几个程序都在同一个处理器上运行

一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互相不抢占资源，可以同时进行，我们称之为并行

并行因素取决于CPU的核心数量

并行

串行

程序执行并非在所有地方都能停顿下来开始GC，只有特定的位置才能停顿下来开始GC，这些位置称为安全点

如果太少，导致GC等待时间长，如果太多导致运行时性能问题，，大部分指令执行都比较短，通常会根据是否具有让程序长时间执行的特征为标准选择一些执行时间较长的指令作为安全点，比如方法调用，循环跳转和异常跳转等

抢先式中断

主动式中断

如果线程处于sleep或者blocked状态，这时候线程无法响应jvm中断请求，走到安全点去中断挂起。对于这种情况，就需要安全区域来解决

安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中任何位置开始GC都是安全的。

当线程运行到安全区域代码时，首先标志已经进入了安全区域，如果GC，JVM会忽略标识为安全区域状态的线程

当线程即将离开安全区域时，会检查JVM是否已经完成GC，如果完成了，则继续运行。否则线程必须等待直到收到可以安全离开安全区域的信号为止

按垃圾回收线程数

按照工作模式分

按照碎片处理方式

按个工作内存区间分

吞吐量

垃圾收集开销

暂停时间

收集频率

内存占用

快速

简单来说抓住两点，吞吐量和暂停时间

高吞吐量与低暂停时间，是一对互相竞争的。因为如果高吞吐量优先，必然需要降低内存回收的执行频率，导致GC需要更长的暂停时间来执行内存回收。

如果选择低延迟优先为原则，也只能频繁的执行内存回收，引起程序吞吐量的下降

现在的标准，在最大吞吐量优先的情况下，降低停顿时间

Serial GC

ParNew

Parallel GC和Concurrent Mark SweepGC

G1

Epsilon 垃圾回收器、ZGC，可伸缩低延迟垃圾回收器

Shenandoah GC：低停顿时间的GC，实验版

增强ZGC

删除CMS垃圾回收器，扩展ZGC在macOS和Windows上的应用

截图

截图

jdk8之前，可以用虚线参考关系

CMS下面的实线，是CMS回收失败的后备方案

JDK8中取消了红线的组合，标记为废弃的。如果要用也可以用。

JDK9中将红线做了remove

jdk14中弃用了绿线组合

jdk14中删除了CMSGC

JDK9默认G1

JDK8默认Parallel Scavenge 和Parallel old Gc

新生代用了Parallel Scavenge 则老年代自动触发用Parallel old

Parallel底层与ParNew底层不同，所以不能和CMS组合

-XX:+PrintCommandLineFlags

jinfo -flag 相关垃圾回收器参数 进程ID

截图

使用一个CPU或者一条收集线程去完成垃圾收集工作，在进行垃圾收集时，必须暂停其他所有工作线程

简单而高效，对于限定单个CPU的环境来说，由于没有线程交互的开销，可以获取最高的单线程收集效率

截图

-XX:+UseParallelGC

-XX:+UseParallelOldGC

-XX:ParallelGCThreads

-XX:MaxGCPauseMillis

-XX:GCTimeRatio

-XX:+UseAdaptiveSizePolicy

截图

初始标记：STW，仅仅只是标记GC Roots能直接关联的对象，一旦标记完成后就会恢复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里速度非常快

并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但是不需要停顿用户线程。可以与垃圾收集线程一起并发运行

重新标记：SWT，为了修正并发标记期间，因用户程序继续运作导致标记产生变动的那一部分对象的标记记录

并发清除：清理删除标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发

因为并发清除时，如果用压缩整理内存，原来的用户线程使用的内存就无法使用了。标记压缩更适合STW场景下使用

并发收集

低延迟

会产生内存碎片

对CPU资源非常敏感

无法处理浮动垃圾

-XX:+UseConcMarkSweepGC

-XX:CMSlnitiatingOccupanyFraction

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction

-XX:ParallelCMSThreads

如果想要最小化使用内存和并行开销，选择Serial GC

如果最大化应用程序的吞吐量，选择ParallelGC

如果想要最小化的GC的中断或停顿时间，选择CMS GC

jdk9标记为废弃的，jdk14已经删除了

就是在延迟可控的情况下，获得尽可能高的吞吐量，所以才担当起全功能收集器的重任和期望

G1是一个并行回收器，他把堆内存分割为很多不相关的区域（Region）（物理上不连续）

使用不同的region表示Eden，s0，s1，老年代等

G1跟踪各个region里面垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region

并行与并发

分代收集

空间整合

可预测的停顿时间模型

相较于CMS，G1不具备全方位，压倒性优势。比如用户程序运行中，G1无论是为了垃圾收集产生的内存占用，还是程序运行时的额外执行负载都要比CMS要高

经验上来说，小内存应用CMS表现大概率优于G1，在大内存上G1优势发挥更多，平衡点再6-8GB

-XX:+UseG1GC

-XX:G1HeapRegionSize

-XX:MaxGCPauseMillis

-XX:ParallelGCThread

-XX:ConcGCThreads

-XX:InitiatingHeapOccupancyPercent

第一步开启G1垃圾收集器

第二步，设置堆的最大内存

第三步，设置最大的停顿时间

G1提供了三种垃圾回收模式在不同的条件下触发

面向服务器端应用，针对具有大内存，多处理器的机器

最主要应用是需要低GC延迟

如：在堆大小约6GB或更大，可预测的暂停时间可以低于0.5s，G1每次清理一部分region来保证每次GC停顿时间不会过长

用来替换1.5中的CMS

所有region大小相同，且在JVM生命周期内不会改变

年轻代GC

老年代并发标记过程

混合回收

有可能fullGC

每个region对应一个记忆集

每次引用类型数据写操作时，会产生一个写屏障暂时中断操作

然后检查将要希尔的引用指向的对象是否和该引用对象类型数据在不同的region，如果不同就通过CardTable把相关的引用信息记录到引用指向对象所在的Region对应的记忆集中

当进行垃圾收集时，在GC根节点枚举范围加入记忆集，就可以保证不进行全局扫描，也不会有遗漏

1、扫描根

2、更新Rset

3、处理Rset

4、复制对象

5、处理引用

1、初始标记阶段STW

2、根区域扫描阶段

3、并发标记

4、再次标记

5、独占清理

6、并发清理阶段

当越来越多的对象晋升到老年代old region时，为了避免内存被耗尽，虚拟机会触发一次混合的垃圾收集器，该算法除了回收整个young region，还会回收一部分的old region。也要注意Mixed gc并不是fullgc

并发标记结束后，老年代中百分百为垃圾的内存分段被回收了。部分为垃圾的内存分段被计算出来了，默认情况下，这些老年代的内存分段会分8次被回收-XX:G1MixedGCCountTarget设置

混合回收的回收集包括八分之一的老年代，Eden区内存分段，Survivor区内存分段。

由于老年代中内存分段默认分8次回收，G1会优先回收垃圾多的内存分段，并且有一个阈值会决定内存分段是否被回收。-XX:G1MixedGCLiveThresholdPercent，默认为65%。意思是垃圾占比达到65%才会被回收。如果垃圾占比比较低，意味存活对象较高，复制的时候花更多时间。

混合回收不一定要进行8次，有一个阈值：-XX:G1HeapWastePercent

G1初衷就是要避免FULLGC，如果上述方式不能正常工作，G1会停止应用程序的执行。使用单线程的内存回收算法进行垃圾回收，性能非常差。应用程序停顿时间长

比如堆太小，当G1复制存活对象的时候没有空的内存分段可用，则会回退到FullGC

导致FullGC原因可能有两个

避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小

固定的年轻代大小会覆盖暂停时间目标

暂停时间目标不要太苛刻，太苛刻会影响吞吐量

强项

弱项

在尽可能堆吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾回收的停顿时间限制在10毫秒以内的低延迟

并发标记，并发预备重分配，并发重分配，并发重映射

除了初始标记是STW，其他地方几乎都是并发执行的

优点

缺点

地址、操作数

优点

缺点

典型应用是X86的二进制指令集，比如传统的PC以及安卓的Davlik虚拟机

大部分情况下，指令集往往以一地址指令，二地址指令和三地址指令为主。

-v输出附加信息

-l输出行号和本地变量表

-p显示所有类和成员

-c对代码进行反汇编

通过引导类加载器bootstrap class loader创建一个初始类来完成的，这个类是由虚拟机的具体实现指定的。

执行一个所谓的Java程序的时候，真正执行的是一个叫Java虚拟机的进程

程序正常执行结束

执行过程遇到异常或错误而异常终止

操作系统错误导致Java虚拟机进程终止

Runtime类或System类的exit方法、runtime类的halt方法，并且Java安全管理器允许这次exit或halt操作

JNI(Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时，Java虚拟机退出的情况

世界第一款商用Java虚拟机

JDK1.4时被淘汰

只提供了解释器

如果使用JIT编译器，就需要外挂，但是JIT和解释器不能配合工作

为了解决上一个虚拟机问题，JDK1.2时，sun提供了此虚拟机

Exact Memory Management：准确式内存管理

具有现代高性能虚拟机的雏形

只在Solaris平台短暂使用，其他平台还是Classic vm

最初由Longview  Technologies的小公司设计，1997年被sun公司收购，2009年sun公司被甲骨文收购

JDK1.3时，HotSpot VM成为默认虚拟机

绝对市场地位，称霸武林

HotSpot就是他的热点代码探测技术

BEA公司

专注服务器端应用

世界上最快的JVM

全面的Java运行时解决方案组合

2008年BEA被oracle收购

JDK8中，在HOTSPOT的基础上，移植JRockit的优秀特性

全称：IBM Technology for java Virtual Machine 简称IT4J，内部代号J9

市场定位与HotSpot接近，服务器端、桌面应用，嵌入式等多用途VM

广泛应用于IBM的各种Java产品

有影响力的三大商用虚拟机之一

2017开源，OPEN J9

JavaME产品线产品

与特定硬件平台绑定、软硬件配合的专有虚拟机

运行于Azul Systems公司的专有硬件Vega系统上的虚拟机

每个实例可以管理至少数十个CPU和数百GB内存的硬件资源，并提供在巨大内存范围内实现可控的GC时间的垃圾收集器，专有硬件优化的线程调度等优秀特性

2010年，发布自己的Zing JVM，可以在通用X86平台上提供接近于vega系统的特性

BEA公司开发的，运行在自家Hypervisor系统上

不需要操作系统支持，本身实现了一个专用操作系统的必要功能，如线程调度、文件系统、网络支持等

随着JRockit虚拟机终止开发，Liquid VM项目也停止了

JDK1.5,1.6兼容

IBM和Intel联合开发的开源JVM，2011年退役

Java类库代码吸纳进了Android SDK

只能在Windows平台运行，xp系统中不用了。

基于OpenJDK开发了自己的定制版本AlibabaJDK

深度定制且开源的高性能服务器版JAVA虚拟机

GCIH：GC invisible heap，将生命周期较长的Java对象从heap中已到heap之外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率

GCIH中的对象还能够在多个JAVA虚拟机进程中实现共享

使用crc32指令实现JVM intrinsic降低JNI的调用开销

针对大数据场景的ZenGC

在阿里产品上性能高，硬件严重依赖intel的CPU，损失了兼容性，但是提高了性能

淘宝、天猫上线，把oracle官方JVM版本全部替换

谷歌开发，应用于Android系统，安卓2.2提供了JIT，发展迅猛

只能称作虚拟机，不能称作Java虚拟机，没有遵循Java虚拟机规范

不能直接执行Java的Class文件

基于寄存器架构，不是jvm的栈架构

执行的是编译后的dex文件，执行效率比较高

安卓5.0使用支持提前编译AOT的ART VM替换Dalvik VM

2018年4月，Oracle labs公开了GraalVM。

跨语言全栈虚拟机，可以作为任何语言的运行平台使用