万字长篇，图文并茂！一篇与面试官和蔼交流的深入了解JVM（JDK8）果断收藏了！

文章目录

面试系列

1、类加载机制

类加载过程分为 加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

1、加载 在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的main()方法，new对象
等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

2、验证 校验字节码文件的正确性
3、准备 给类的静态变量分配内存，并赋予默认值

4、解析 将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据
所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程
序运行期间完成的将符号引用替换为直接引用5、初始化 对类的静态变量初始化为指定的值，执行静态代码块

2、双亲委派机制(先找父亲加载，不行再由儿子自己加载)
2.1、类加载器

1、根类加载器（Bootstrap
classLoader）：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
2、扩展类加载器（ExtClassLoader）：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
3、应用加载器（AppClassLoader）：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类,负责加载用户自定义路径下的类包

2.2、加载器初始化过程

类运行加载全过程会创建JVM启动器实例sun.misc.Launcher。sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例来加载我们的应用程序。

2.3、双亲委派机制

应用程序类加载器AppClassLoader加载类的双亲委派机制源码，AppClassLoader的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：
首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name,
false);）.或者是调用bootstrap类加载器来加载。
如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的findClass方法来完成类加载。

2.4、为什么要设计双亲委派机制？

1、沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改
2、避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性

2.5、全盘负责委托机制

“全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入

2.6、自定义类加载器示例

自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是loadClass(String,
boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。

3、tomcat怎么破解类加载机制

1、commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；

2、catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；

3、sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；

4、WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的类，
每个war包应用都有自己的WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本，这样实现就能加载各自的spring版本；

5、模拟实现Tomcat的JasperLoader热加载

原理：后台启动线程监听jsp文件变化，如果变化了找到该jsp对应的servlet类的加载器引用
(gcroot)，重新生成新的JasperLoader加载器赋值给引用，然后加载新的jsp对应的servlet类，之前的那个加载器因为没有gcroot引用了，下一次gc的时候会被销毁

=>总结：每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制。

4、内存模型
4.1、线程私有区域

程序计数器：是当前线程所执行的字节码的行号指示器，无OOM
虚拟机栈：是描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack
Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

栈帧（ Frame）是用来存储数据和部分过程结果的数据结构，同时也被用来处理动态链接(Dynamic Linking)、
方法返回值和异常分派（ Dispatch
Exception）。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异常）都算作方法结束。
本地方法栈：和 Java Stack 作用类似, 区别是虚拟机栈为执行 Java 方法服务, 而本地方法栈则为Native 方法服务,
如果一个 VM 实现使用 C-linkage 模型来支持 Native 调用, 那么该栈将会是一个 C 栈，但 HotSpot VM
直接就把本地方法栈和虚拟机栈合二为一。

4.2、线程共享区域

堆-运行时数据区：是被线程共享的一块内存区域，创建的对象和数组都保存在 Java
堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代 VM 采用分代收集算法, 因此 Java 堆从 GC 的角度还可以细分为:
新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代

方法区/永久代（1.8之后元空间）：用于存储被 JVM 加载的类信息**、常量、静态变量、**即时编译器编译后的代码等数据. HotSpot
VM把GC分代收集扩展至方法区, 即使用Java堆的永久代来实现方法区, 这样 HotSpot 的垃圾收集器就可以像管理 Java
堆一样管理这部分内存, 而不必为方法区开发专门的内存管理器(永久带的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)。

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class
文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool
Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

直接内存

jdk1.4后加入NIO（New
Input/Output）类，引入了一种基于通道与缓冲区的I/O方式，它可以使用native函数库直接分配堆外内存，然后通过一个存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。可以避免在Java堆和Native堆中来回复制数据
直接内存的分配不会受到Java堆大小的限制.避免大于物理内存的情况

5、对象的创建

1、类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等
2、分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类 加载完成后便可完全确定，为对象分配空间的任务等同于把
一块确定大小的内存从Java堆中划分出来。 //如何划分内存？ 1、“指针碰撞”（Bump the Pointer）(默认用指针碰撞)
如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
2、“空闲列表”（Free List）
如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。
//解决并发问题的方法 1、CAS（compare and swap）
虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。 2、本地线程分配缓冲（Thread Local
Allocation Buffer,TLAB）
把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。通过­XX:+/­UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启XX:+UseTLAB)，­XX:TLABSize指定TLAB大小。
3.初始化

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

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object
Header之中。 在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（Header）、 实例数据（Instance
Data）和对齐填充（Padding）。 HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，
如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时
间戳等。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

5.执行方法

执行方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。

5.1、对象大小与指针压缩
5.1.1、对象大小

对象大小可以用jol­-core包查看

5.1.2、什么是java对象的指针压缩？

jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩
jvm配置参数:UseCompressedOops，compressed­­压缩、oop(ordinary object
pointer)­­对象指针
启用指针压缩:­XX:+UseCompressedOops(默认开启)，禁止指针压缩:­XX:­UseCompressedOops

5.1.3、为什么要进行指针压缩？

1.在64位平台的HotSpot中使用32位指针，内存使用会多出1.5倍左右，使用较大指针在主内存和缓存之间移动数据，占用较大宽带，同时GC也会承受较大压力
2.为了减少64位平台下内存的消耗，启用指针压缩功能
3.在jvm中，32位地址最大支持4G内存(2的32次方)，可以通过对对象指针的压缩编码、解码方式进行优化，使得jvm 只用32位地址就可以支持更大的内存配置(小于等于32G)
4.堆内存小于4G时，不需要启用指针压缩，jvm会直接去除高32位地址，即使用低虚拟地址空间
5.堆内存大于32G时，压缩指针会失效，会强制使用64位(即8字节)来对java对象寻址，这就会出现1的问题，所以堆内存不要大于32G为好

6、对象的分配过程

6.1、栈上分配

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

==对象逃逸分析：==就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中。

很显然test1方法中的user对象被返回了，这个对象的作用域范围不确定，test2方法中的user对象我们可以确定当方法结束这个对象就可以认为是无效对象了，对于这样的对象我们其实可以将其分配在栈内存里，让其在方法结束时跟随栈内存一起被回收掉。
JVM对于这种情况可以通过开启逃逸分析参数(-XX:+DoEscapeAnalysis)来优化对象内存分配位置，使其通过标量替换优先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，如果要关闭使用参数(-XX:-DoEscapeAnalysis)
==标量替换：==通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间，这样就不会因为没有一大块连续空间导致对象内存不够分配。开启标量替换参数(-XX:+EliminateAllocations)，JDK7之后默认开启。
==标量与聚合量：==标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一步分解的聚合量。

结论：栈上分配依赖于逃逸分析和标量替换

6.2、对象在Eden区分配(大部分情况，当 Eden 区没有足够空间进行分配时，出现Young GC)

大量的对象被分配在eden区，eden区满了后会触发Young
GC，可能会有99%以上的对象成为垃圾被回收掉，剩余存活的对象会被挪到s0区，下一次eden区满了后又会触发Young
GC，把eden区和s0区垃圾对象回收，把剩余存活的对象一次性挪动到另外一块为空的s1区，因为新生代的对象都是朝生夕死的，存活时间很短，所以JVM默认的8:1:1的比例是很合适的，让eden区尽量的大，survivor区够用即可，JVM默认有这个参数-XX:+UseAdaptiveSizePolicy(默认开启)，会导致这个8:1:1比例自动变化，如果不想这个比例有变化可以设置参数-XX:-UseAdaptiveSizePolicy

6.3、大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold
可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。
比如设置JVM参数：-XX:PretenureSizeThreshold=1000000 (单位是字节) -XX:+UseSerialGC
，再执行下上面的第一个程序会发现大对象直接进了老年代

为什么要这样呢？ 为了避免为大对象分配内存时的复制操作而降低效率。

6.4、长期存活的对象将进入老年代

虚拟机给每个对象一个对象年龄（Age）计数器。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被
Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次
MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数
-XX:MaxTenuringThreshold 来设置。

6.5、对象动态年龄判断

当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年龄判断机制一般是在young
gc之后触发的。

6.6、老年代空间分配担保机制）

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间 如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)
就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了) 的参数是否设置了
如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。
如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full
gc，对老年代和年轻代一起回收一次垃圾，如果回收完还是没有足够空间存放新的对象就会发生"OOM"。

当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，full
gc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”

7、如何判断一个类是无用的类

该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。 加载该类的 ClassLoader 已经被回收。 该类对应的
java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

8、finalize()方法最终判定对象是否存活

1. 第一次标记并进行一次筛选。

筛选的条件是此对象是否有必要执行finalize()方法。

当对象没有覆盖finalize方法，对象将直接被回收。

2. 第二次标记

如果这个对象覆盖了finalize方法，finalize方法是对象脱逃死亡命运的最后一次机会，如果对象要在finalize()中成功拯救
自己，只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第
二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次。

9、常见引用类型(四大引用)

1、强引用：普通的变量引用

2、软引用（SoftReference）：将对象用SoftReference软引用类型的对象包裹，正常情况不会被回收，但是GC做完后发现释放不出空间存放新的对象，则会把这些软引用的对象回收掉。软引用可用来实现内存敏感的高速缓存。

使用场景：浏览器的后退按钮
3、弱引用（WeakReference）：将对象用WeakReference软引用类型的对象包裹，弱引用跟没引用差不多，GC会直接回收掉，很少用

4、虚引用：虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系，几乎不用

10、对象回收

什么叫对象回收？

堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。

10.1、引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。
缺点：循环引用问题

10.2、可达性分析算法（gcroot）

点击此处免费领取Java全套学习资料：包含2021最新完整面试题及答案（都整理成文档），有很多干货，包含mysql，netty，spring，线程，spring cloud、JVM、源码、算法等详细讲解，也有详细的学习规划图，面试题整理等学习资料！感谢阅读！三连是最大的支持！谢谢！

12、常见oom

1、java.lang.StackOverflowError:

报这个错误一般是由于方法深层次的调用，默认的线程栈空间大小一般与具体的硬件平台有关。栈内存为线程私有的空间，每个线程都会创建私有的栈内存。栈空间内存设置过大，创建线程数量较多时会出现栈内存溢出StackOverflowError。同时，栈内存也决定方法调用的深度，栈内存过小则会导致方法调用的深度较小，如递归调用的次数较少。

2、java.lang.OutOfMemoryError: Java heap space

Heap size 设置
JVM堆的设置是指：java程序执行过程中JVM能够调配使用的内存空间的设置。JVM在启动的时候会自己主动设置Heap
size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。能够利用JVM提供的-Xmn -Xms
-Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。

3、java.lang.OutOfMemoryError：GC overhead limit exceeded

GC回收时间过长时会抛出的OutOfMemory。过长是指，超过98%的时间都在用来做GC并且回收了不到2%的堆内存。连续多次的GC，都回收了不到2%的极端情况下才会抛出。假如不抛出GC
overhead limit
错误会发生什么事情呢？那就是GC清理出来的一点内存很快又会被再次填满，强迫GC再次执行，这样造成恶性循环，CPU的使用率一直很高，但是GC没有任何的进展。

4、java.lang.OutOfMemoryError：Direct buffer memory

写NIO程序经常使用到ByteBuffer来读取或者写入数据，这是一种基于通道与缓冲区的I/O方式。它可以使用Native函数库直接分配堆外内存，然后通过一个存储在java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中提高性能，因为避免了java堆和Native堆中来回复制数据。

ByteBuffer.allocate(capability)
：这种方式是分配JVM堆内存，属于GC管辖范围之内。由于需要拷贝，所以速度相对较慢；
ByteBuffer.allocateDirect(capability)：这种方式是直接分配OS本地内存，不属于GC管辖范围之内，由于不需要内存拷贝所以速度相对较快。
但是如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行GC,DirectByteBuffer对象就不会被回收。这时候堆内存充足，但是本地内存已经用光了，再次尝试分配的时候就会出现OutOfMemoryError，那么程序就直接崩溃了。

5、java.lang.OutOfMemoryError：unable to create new native thread

准确的说，这一个异常是和程序运行的平台相关的。导致的原因：

创建了太多的线程，一个应用创建多个线程，超过系统承载极限；
服务器不允许应用程序创建这么多的线程，Linux系统默认的允许单个进程可以创建的线程数量是1024个，当创建多
线程数量多于这个数字的时候就会抛出此异常 如何解决呢？

想办法减少应用程序创建的线程的数量，分析应用是否真的需要创建这么多的线程。如果不是，改变代码将线程数量降到最低；
对于有的应用，确实需要创建很多的线程，远超过Linux限制的1024个
限制，那么可以通过修改Linux服务器的配置，扩大Linux的默认限制。
6、java.lang.OutOfMemoryError：MetaSpace

元空间的本质和永久代类似，都是对JVM规范中的方法区的实现。不过元空间与永久代之间最大的区别在于：元空间不在虚拟机中，而是使用的本地内存。因此，默认情况下，元空间的大小仅仅受到本地内存的限制
。

元空间存放了以下的内容：

虚拟机加载的类信息； 常量池； 静态变量； 即时编译后的代码
模拟MetaSpace空间溢出，我们不断生成类往元空间里灌，类占据的空间总是会超过MetaSpace指定的空间大小的

查看元空间的大小：java -XX:+PrintFlagsInitial

13.1.1、运作过程(5大步骤)

1、初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。 2、并发标记： 并发标记阶段就是从GC
Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程，
可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。 3、重新标记：
重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到增量更新算法做重新标记。
4、并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为三色标记法里面的黑色不做任何处理
5、并发重置：重置本次GC过程中的标记数据。

主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

对CPU资源敏感（会和服务抢资源）； 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数==-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理==
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full
gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial
old垃圾收集器来回收 CMS的相关核心参数

-XX:+UseConcMarkSweepGC：启用cms
-XX:ConcGCThreads：并发的GC线程数
-XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
-XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
-XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
-XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
-XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

13.1.2、三色标记法

13.1.3、concurrent model failure（浮动垃圾）

在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

13.1.4、background/foreground collector

-XX:ConcGCThreads=4和-XX:+ExplicitGCInvokesConcurrent开启foreground CMS GC，CMS gc 有两种模式，background和foreground，正常的cms
gc使用background模式，就是我们平时说的cms gc；当并发收集失败或者调用了System.gc()的时候，就会导致一次full
gc，这个fullgc是不是cms回收，而是Serial单线程回收器，加入了参数-XX:ConcGCThreads=4后，执行full
gc的时候，就变成了CMS foreground gc，它是并行full gc，只会执行cms中stop the
world阶段的操作，效率比单线程Serial full
GC要高；需要注意的是它只会回收old，因为cms收集器是老年代收集器；而正常的Serial收集是包含整个堆的，加入了参数==-XX:+ExplicitGCInvokesConcurrent==,代表永久带也会被cms收集；

13.1.5、为什么G1用SATB？CMS用增量更新？

SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

13.1.6、漏标-读写屏障(解决方案)
13.1.6.1、增量更新(Incremental Update)+写屏障

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

13.2.1、运作流程

G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。
一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。
G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。
默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100个，s1对应100个。
一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能
可能会动态变化。G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。 Full
GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

G1收集器一次GC的运作过程大致分为以下4个步骤：

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

并发标记（Concurrent Marking）：同CMS的并发标记

最终标记（Remark，STW）：同CMS的重新标记

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的==回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数
-XX:MaxGCPauseMillis指定)来制定回收计划，==比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection
Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

==G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。==这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1
除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。
毫无疑问， 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间，
可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过， 这里设置的“期望值”必须是符合实际的， 不能异想天开，
毕竟G1是要冻结用户线程来复制对象的， 这个停顿时间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒， 一般来说，
回收阶段占到几十到一百甚至接近两百毫秒都很正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒，
很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度，
导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发Full
GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

13.3.2、color poin（颜色指针）










17、逃逸分析

逃逸分析是指在某个方法之内创建的对象，除了在方法体之内被引用之外，还在方法体之外被其它变量引用到；这样带来的后果是在该方法执行完毕之后，该方法中创建的对象将无法被GC回收，由于其被其它变量引用。正常的方法调用中，方法体中创建的对象将在执行完毕之后，将回收其中创建的对象；故由于无法回收，即成为逃逸。

点击此处免费领取Java全套学习资料：包含2021最新完整面试题及答案（都整理成文档），有很多干货，包含mysql，netty，spring，线程，spring cloud、JVM、源码、算法等详细讲解，也有详细的学习规划图，面试题整理等学习资料！感谢阅读！三连是最大的支持！谢谢！