对象引用
1、引用计数法（Reference Counting）
基本原理：在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；
当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。
优点：原理简单，判定效率很高
缺点：要占用一点空间用于计数
例子：
微软COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言
以及在游戏脚本领域得到许多应用的Squirrel
但是，在Java领域，至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存，主要原因是，这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。
eg：
public class ReferenceCountingGC {
public Object instance = null;
public static void main(String[] args) {
ReferenceCountingGC A = new ReferenceCountingGC();
ReferenceCountingGC B = new ReferenceCountingGC();
A.instance = B;
B.instance = A;
A = null;
B = null;
// 假设在这行发生GC，objA和objB是否能被回收？
System.gc();
}
}
结果：
即虚拟机并没有因为相互引用就放弃回收，也就说明虚拟机不是通过引用计数法判断对象是否存活的
要想在控制台输出GC日志，要在VM options中配置-XX:+PrintGCDetails，
idea中可在RUN——>Edit Configurations——>选择当前要输出日志的程序——>添加
如果没有VM options，可点击Modify options选择ADD VM options
2、可达性分析算法
基本原理：通过一系列称为“GC Roots”的根对象作为起始节点集，
从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），
如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象
不可达时，则证明此对象是不可能再被使用的。
简单的理解就是，能从根节点走得到的对象，就还是存活的对象。
Java中，可以作为GC Roots根对象的有：
在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如
NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
方法区中常量引用的对象
等等，书里其实介绍还有几个，但我觉得目前知道没啥用
引用的分类
按上述来讲，引用要么只有被引用和未被引用两种，但如此是不全面，比如使用缓存的时候，因此对于这种对象，引用的概念进行了扩充，将引用分为4种：
1、强引用（Strongly Re-ference）
普遍存在的引用赋值，即类似“Objectobj=new Object()”，只要强引用关系存在，就永远不回收
2、软引用（Soft Reference）
描述一些还有用，但非必须的对象。软引用对象，在系统将要发生内存溢出异常前，会把这些对象
列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常
3、弱引用（Weak Reference）
也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，
被弱引用关联的对象只能生存到下一次垃圾收集发生为止。
4、虚引用（Phantom Reference）
虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。
虚引用回收时要配合引用队列使用
垃圾回收步骤
可达性分析算法中判定为不可达的对象，至少要经历两次标记过程：
1、如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记，
随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。
假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。
2、第二次标记则表示该对象确定要被回收
这部分其实没什么意义，感觉实际开发中不会有人这么做。
只是知道一下：在垃圾回收时，可以重写finalize()方法，在finalize()中给要回收的对象添加引用，
那么此次的垃圾回收就会跳过
回收方法区
方法区的垃圾收集主要回收两部分内容：废弃的常量和不再使用的类型。
知道就是，记太多记不住，需要再去细看
垃圾收集算法
首先，判断对象是否可回收有引用计数法和可达性分析法，所以对应的垃圾收集算法可以划分为“引用计数式垃圾收集”（ReferenceCounting GC）和“追踪式垃圾收集”（Tracing GC）两大类，这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。
因为Java虚拟机使用的是可达性分析算法，所以垃圾收集算法讲的也就是追踪式垃圾收集
分代收集理论
当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”（Generational Collection）的理论进行设计。
其建立在两个分代假说之上：
1）弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。
2）强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消亡。
因此垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄
（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。
在Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或者某些部分的区域——因而才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分；也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法——因而发展出了“标记-复制算法”“标记-清除算法”“标记-整理算法”等针对性的垃圾收集算法。
现在的商用Java虚拟机里，设计者一般至少会把Java堆划分为新生代（Young Generation）和老年代（Old Generation）
两个区域
----------------------------
现在有个问题是：如果在新生代中进行一次Minor GC ，但新生代的对象可能会被老年代的对象所引用，为了
找出这个对象是否也可以被回收，那么就不得不遍历一遍老年代。那么就会有额外的内存负担。
反过来，如果老年代中的对象被新生代的所引用，那么老年代在回收的时候也得扫描一遍新生代。
为了减少这个额外的内存负担，分代收集理论又多加了另一分代假说：
跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。
此假说避免扫描整个老年代，所以在新生代上建立一个全局的数据结构（该结构被称为“记忆集”，Remembered Set），
这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。
之后对于夸代引用的对象只需扫描这个记忆集即可。
新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。请注意“Major GC”这个说法现在有点混淆，在不同资料上常有不同所指，需按上下文区分到底是指老年代的收集还是整堆收集。
整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。
标记-清除（Mark-Sweep）算法
最早出现也是最基础的垃圾收集算法是标记-清除算法，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。
优点：思路清晰，实现比较简单
缺点：
由于系统分配的内存时间不同，回收的先后顺序也是不同的，这时就会导致剩余空闲空间并不是连续的，出现了内存碎片现象。
效率不稳定，执行效率得看要标记的对象数量多于少
由于产生内存碎片，再次分配对象时，不满足新对象大小的碎片将无法利用，增加计算内存的负担，如果内存碎片过多，新对象过大，总的剩余内存虽然满足对象分配需求，但因为碎片的原因，会造成分配失败：
标记-清除示意（来源：https://juejin.cn/post/7194781956389732389）
标记-复制算法
标记-复制算法常被简称为复制算法。为了解决标记-清除算法面对大量可回收对象时执行效率低的问题。
实现：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，
就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
优点：分配内存时不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可
缺点：
如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销。
将可用内存缩小为了原来的一半，空间浪费未免太多了一点。
复制算法示意 来源：https://blog.csdn.net/qq_39514033/article/details/106167297
算法优化
IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此并不需要按照1∶1的比例来划分新生代的内存空间。
在1989年，Andrew Appel针对具备“朝生夕灭”特点的对象，提出了一种更优化的半区复制分代策略，现在称为“Appel式回收”。HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局
Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。
HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也即每次新生代中可用内存空间为整个新生代容量
的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会被“浪费”的。
然而，实际上没人能保证每次回收完，10%的Survivor空间能不能容纳下剩下的存活对象。所以此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor GC之后存活的对象时，就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。
分配担保：
如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，
这些对象便将通过分配担保机制直接进入老年代，这对虚拟机来说就是安全的。
标记-整理（Mark-Compact）算法
标记-复制算法在对象存活率较高时就要进行较多的复制操作，效率将会降低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选标记-复制算法。
标记整理算法清除逻辑和标记清除算法基本相似不过进行了优化，会在清除结束之后讲活着的空间进行整理向一端移动，同时清理掉内存的边界。
Stop The World
移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行。
对于是否一定要移动对象的问题
如果使用标记清除算法，那么就不用移动，但会产生大量的碎片。
内存分配问题会依赖更为复杂的内存分配器和内存访问器来解决。却内存访问频繁，如果在分配内存环节耗时过多，则会影响应用程序的吞吐量。
所以是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更复杂。
从垃圾收集的停顿时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，
但是从整个程序的吞吐量来看，移动对象会更划算。
所以按需选择
另外还有一个折中办法是：
让虚拟机平时多数时间都采用标记-清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经
大到影响对象分配时，再采用标记-整理算法收集一次，以获得规整的内存空间。基于标记-清除算法的
CMS收集器面临空间碎片过多时采用的就是这种处理办法。
HotSpot的算法细节实现
确实很枯燥的说
根节点枚举
前言：可达性分析算法是从GC Roots集合找引用链，以判断哪些对象是否存活
那么GC Roots集合中的内容如何得出便是根节点枚举做的事。
所有收集器在根节点枚举这一步骤时都是必须暂停用户线程的，目的是为了防止在分析过程中，根节点集合的对象引用关系还在不断变化的情况。
但虚拟机并不需要逐一遍历可以作为GC Roots的常量等。虚拟机是有办法直接得到哪些地方存放着对象引用的。在HotSpot的解决方案里，是使用一组称为OopMap的数据结构来达到这个目的。
安全点
在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举，但问题是，如果为每一条指令都生成OopMap，那么会需要很大的额外存储空间。
所以，只是在“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint）。 而用户程序在执行时，如果想进行垃圾收集，强制要求必须执行到达安全点后才能够暂停。因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太过频繁以至于过分增大运行时的内存负荷。安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的
“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转
等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。
如何在垃圾收集发生时让所有线程都跑到最近的安全点，然后停顿下来。这里有两种方案可供选择：
抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension）
抢先式中断指垃圾收集发生时，立即中断线程，如果线程不在安全点上，恢复执行，到了安全点后中断。
主动式中断指的是：当垃圾收集要开始时，会设置一个标识，这个标识的位置和安全点重合，线程不断轮询
这个标识一旦为真，线程就在离自己最近的安全点停下
安全区域
想要程序能到达安全点，那么程序得是在运行的，如果程序不执行就是没有分配处理器时间，就无法跑到安全点，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间。对于这种情况，就必须引入安全区域（Safe Region）来解决。
安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化
当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那么虚拟机在发生垃圾收集
时就不会管处于安全区域的线程。但当线程想离开安全区域时，要检查虚拟机是否已完成根节点枚举，
完成了就可以离开，否则需要一直等待
记忆集与卡表
为解决对象跨代引用所带来的问题，垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免把整个老年代加进GC Roots扫描范围。
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。
**记忆集是一种抽象的数据结构，以下才是对其的具体实现。
------------------
记忆集有不同的精度记录
字长精度：每个记录精确到一个机器字长（就是处理器的寻址位数，如常见的32位或64位，这个
精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。
对象精度：每个记录精确到一个对象，该对象里有字段含有跨代指针。
卡精度：每个记录精确到一块内存区域，该区域内有对象含有跨代指针。
卡精度所指的是用一种称为“卡表”（Card Table）的方式去实现记忆集，这也是目前最常用的一种记忆集实现形式，
卡表最简单的形式可以只是一个字节数组CARD_TABLE，CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”（Card Page）。
一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多）对象的字段存在着跨代
指针，那就将对应卡表的数组元素的值标识为1，称为这个元素变脏（Dirty），没有则标识为0。在垃
圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它
们加入GC Roots中一并扫描。
写屏障
卡表何时变脏？
有其他分代区域中对象引用了本区域对象时，其对应的卡表元素就应该变脏，
变脏时间点原则上应该发生在引用类型字段赋值的那一刻。
谁让卡表变脏？
在HotSpot虚拟机里是通过写屏障（Write Barrier）技术维护卡表状态。
写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个
环形（Around）通知，供程序执行额外的动作。
以实现在引用更新时进行卡表的修改
收集器在写屏障中增加了更新卡表操作，会产生开销，但和扫描整个老年代来说还是算小的
卡表在高并发场景下还面临着“伪共享”（False Sharing）问题。
伪共享是处理并发底层细节时一种经常需要考虑的问题，
现代中央处理器的缓存系统中是以缓存行（Cache Line）为单位存储的，当多线程修改互相独立的变量时，
如果这些变量恰好共享同一个缓存行，就会彼此影响（写回、无效化或者同步）而导致性能降低
为了避免伪共享问题，一种简单的解决方案是不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表元
素未被标记过时才将其标记为变脏。
不懂
并发的可达性分析
从GC Roots再继续往下遍历对象图（就是根节点枚举），这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了：堆越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长。
想解决或者降低用户线程的停顿，引入三色标记（Tri-color Marking）作为工具来辅助推导，把遍历对象图过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色：
白色：表示对象尚未被垃圾收集器访问过。若在分析结束的阶段，仍然是白色的对象，即代表不可达。
黑色：表示是安全存活的
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
根节点一开始是黑色，别的都是白色，扫描的过程是从黑色逐步渲染白色
但在扫描时，扫描的只是一个时间点上的引用关系，而后续如果引用关系发生改变，那么按已扫描到的进行垃圾回收，可能会造成存在引用的对象发生回收，这个现象被称为并发扫描时的对象消失问题。
导致出现对象消失的条件：
赋值器插入了一条或多条从黑色对象到白色对象的新引用；
赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。
为了解决这个问题，只要破坏会导致出现对象消失的两个条件之一即可，对应的解决方案有：
增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）
两种解决方案对应的分别是：
增量更新指在插入引用时记录下这个引用记录，并发扫描结束后重新扫描一次改变的引用
原始快照指的是在删除引用记录时，在并发扫描结束后重新扫描一次改变的引用
垃圾收集器
新生代收集器
Serial
ParNew
Parallel
老年代收集器
Serial Old
CMS
Parallel Old
新生代和老年代收集器
G1
其中Serial和Parallel有两个版本分别适用于新生代和老年代
垃圾回收器之间有连线表示，可以协作使用。
（图片来源网络）
Serial 和Serial Old收集器
Serial收集器
Serial收集器是最基础、历史最悠久的收集器，采用复制算法进行垃圾收集，曾经（在JDK 1.3.1之前）是HotSpot虚拟机新生代收集器的唯一选择。
这个收集器是一个单线程工作的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。（Stop The World）
Serial/Serial Old收集器运行示意图（来源《深入理解Java虚拟机第三版》）
Serial收集器依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器，有着优于其他收集器的地方，
那就是**简单而高效**（与其他收集器的单线程相比），对于内存资源受限的环境，它是所有收集器里额外内存
消耗（Memory Footprint）最小的；对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于
**没有线程交互的开销**，专心做垃圾收集自然可以获得最高的单线程收集效率。
Serial Old收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。
如果在服务端模式下，它也可能有两种用途：一种是在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用，另外一种就是作为CMS收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。
ParNew收集器
ParNew收集器实质上是Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致。
ParNew/Serial Old收集器运行示意图（来源《深入理解Java虚拟机第三版》）
ParNew收集器在单核心处理器的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程（Hyper-Threading）技术实现的伪双核处理器环境中都不能百分之百保证超越Serial收集器。
自JDK 9开始，ParNew加CMS收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了。
官方希望它能完全被G1所取代，甚至还取消了ParNew加Serial Old以及Serial加CMS这两组收集器组合的支持
，并直接取消了-XX：+UseParNewGC参数，这意味着ParNew和CMS从此只能互相搭配使用。
“并发”和“并行”垃圾收集器概念
并行（Parallel）：并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线
程在协同工作，通常默认此时用户线程是处于等待状态。
并发（Concurrent）：并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾
收集器线程与用户线程都在运行。由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于
垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。
Parallel Scavenge 和 Parallel Old收集器
Parallel Scavenge收集器
Parallel Scavenge收集器是一款新生代收集器，它同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器。
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值。
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis 参数 以及直接设置吞吐量大小的 -XX：GCTimeRatio 参数。
-XX：MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的
时间不超过用户设定值。垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价（减小新生代占比）换取的
-XX：GCTimeRatio参数的值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的
比率，相当于吞吐量的倒数。默认值为99，即允许最大1%（即1/(1+99)）的垃圾收集时间
Parallel Scavenge收集器被称作“吞吐量优先收集器”。除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。这种调节方式称为垃圾收集的自适应的调节策略（GC Ergonomics）
Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。
Parallel Scavenge/Parallel Old收集器运行示意图（来源《深入理解Java虚拟机第三版》）
在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组
合。
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。
CMS收集器是基于标记-清除算法实现的，它的运作过程分为四个步骤，包括：
初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
初始标记、重新标记这两个步骤仍然需要“Stop The World”。
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；
并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要
停顿用户线程
重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的
标记记录（增量更新的问题），这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记
阶段的时间短；
最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，
所以这个阶段也是可以与用户线程同时并发的。
Concurrent Mark Sweep收集器运行示意图（来源《深入理解Java虚拟机第三版》）
优势：
多线程收集，收集过程不停止用户线程，所以用户请求停顿时间短。
缺陷：
对处理器资源非常敏感
基于“标记-清除”算法，会有内存碎片，无法找到足够大的连续空间来分配当前对象，
而不得不提前触发一次Full GC的情况。但设计者设置CMS收集器在执行过若干次（数量
由参数值决定）不整理空间的Full GC之后，下一次才进入Full GC前会先进行碎片整理
有浮动垃圾，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，
必须预留一部分空间供并发收集时的程序运作使用
Garbage First收集器
G1是一款主要面向服务端应用的垃圾收集器。JDK 9发布之日，G1宣告取代Parallel Scavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器，而CMS则沦落至被声明为不推荐使用（Deprecate）的收集器。
G1面向堆内存任何部分来组成回收集（Collection Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。
G1也仍是遵循分代收集理论设计的，不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
简要点说就是，将Java堆进行切割多个相等的区域，每个区域可以作为新生代，老年代等等，G1收集器会根据它
扮演的角色采用不同的策略进行处理
Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。
每个Region的大小可以通过参数-XX：G1HeapRegionSize设定，取值范围为1MB～32MB，且应为2的N次幂。
而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待
优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来。
G1收集器Region分区示意图（来源《深入理解Java虚拟机第三版》）
G1收集器的运作过程大致可划分为以下四个步骤
初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象
并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，
重新处理原始快照记录下的在并发时有引用变动的对象。
最终标记（Final Marking）：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留
下来的最后那少量的SATB记录。
筛选回收（Live Data Counting and Evacuation）：负责更新Region的统计数据，对各个Region的回
收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划
G1收集器运行示意图（来源《深入理解Java虚拟机第三版》）
G1收集器除了并发标记外，其余阶段也是要完全暂停用户线程的，
换言之，它并非纯粹地追求低延迟，官方给它设定的目标是在延迟可控的情况下获得尽可能高的吞吐量
G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“标记-复制”算法实现，两种算法都意味着G1运作期间不会产生内存空间碎片。
低延迟垃圾收集器
Shenandoah收集器
ZGC收集器
垃圾收集器选择
要根据应用程序的关注点，譬如是关注结果的吞吐量还是用户体验的低延迟；硬件配置如何等
内存分配与回收策略
1、对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次
Minor GC。
2、大对象直接进入老年代
大对象就是指需要大量连续内存空间的Java对象，最典型的大对象便是那种很长的字符串，或者
元素数量很庞大的数组
3、长期存活的对象将进入老年代
对象通常在Eden区里诞生，如果经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，
该对象会被移动到Survivor空间中，并且将其对象年龄设为1岁。对象在Survivor区中每熬过一次
Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15），就会被晋升到老年代中。
对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。
4、动态对象年龄判定
HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX：MaxTenuringThreshold才能晋升老年代，
如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该
年龄的对象就可以直接进入老年代，无须等到-XX：MaxTenuringThreshold中要求的年龄。
5、 空间分配担保
在发生Minor GC之前，虚拟机必须先检查**老年代最大可用的连续空间**是否大于新生代所有对象总
空间（**老年代分配担保**），如果这个条件成立，那这一次Minor GC可以确保是安全的。如果不成立，
则虚拟机会先查看-XX：HandlePromotionFailure参数的设置值是否允许
担保失败（Handle Promotion Failure）；如果允许，那会继续检查老年代最大可用的连续空间是否大于
历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；
如果小于，或者-XX：HandlePromotionFailure设置不允许冒险，那这时就要改为进行一次Full GC。
之所以说的冒险，是因为进行一次Minor GC后，存活的对象所需总空间比老年代最大可用的连续空间
还大的话，那么就会担保失败，还要重新进行一次Full GC。如此所需的时间会更长。
但通常情况下都还是会将-XX：HandlePromotionFailure开关打开，避免Full GC过于频繁。