>> 垃圾回收器
如果说收集算法是内存回收的方法论，那垃圾收集器就是内存回收的实践者。
各款经典垃圾收集器之间的关系如下图所示。
(这个关系不是一成不变的，由于维护和兼容性测试的版本，在JDK8时将Serial+CMS， ParNew+Serial Old这两对组合声明为废弃，并在JDK9中完全取消了这些组合的支持。)
1、新生代垃圾回收器
1.1Serial(复制算法)
- Serial收集器是最基础、历史最悠久的收集器，曾经**(在JDK1.3.1之前)是HotSpot虚拟机新生代收集器的唯一选择，只看名字就能够猜到，这个收集器是一个单线程**工作的收集器，但它的’单线程’意义并不仅仅是说明
它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调它在进行垃圾收集时，必须暂停其他所有工作线程(STW)，直到它收集结束。 - ”Stop The World“这个词语听起来可能很酷，
但这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可知、不可控的情况下把用户的正常工作的线程全部停掉，这对于很多应用来说都是不能接受的。 - Serial使用的是
复制算法回收新生代，Serial的老年代版本Serial Old使用的是标记整理算法回收老年代 - 迄今为止，Seial仍然是HotSpot虚拟机运行在
客户端模式下的默认新生代垃圾收集器，有着优于其他收集器的地方，那就是简单而且高效(与其他收集器的单线程相比)，对于内存资源受限的环境，它是所有收集器里额外内存消耗(Memory Footprint)最小的，对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得更高的单线程收集效率。所以Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。
Serial / Serial Old收集器运行示意图。
1.2ParNew(复制算法)
1.2.1基本介绍
ParNew收集器实际上是Serial收集器的多线程并行版本除了同时使用多条线程进行垃圾回收之外，其余的行为包括Serial收集器可用的所有控制参数，其收集算法**(也是采用复制算法)**、Stop The World、对象分配规则，回收策略等都与Serial收集器完全一致。
ParNew / Serial Old收集器运行示意图
1.2.2历史渊源
ParNew收集器除了支持多线程并行收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是不少运行在服务端模式下的HotSpot虚拟机，尤其是JDK7之前的遗留系统中首选的新生代垃圾收集器，其中有一个与功能、性能无关的但其实是很重要的原因：除了Serial收集器外，只有它可以与CMS收集器配合工作。
在JDK5发布时，HotSpot推出了一款在强交互应用下几乎可称为具有划时代意义的垃圾收集器——CMS收集器，CMS是HotSpot虚拟机中第一款真正意义上支持并发的垃圾收集器，它首次实现了让垃圾收集线程与用户线程同时工作
可以说直到CMS的出现才巩固了ParNew的历史地位，但成也萧何败也萧何，随着垃圾收集器技术的不断改进，更先进的G1收集器带着CMS继承者和替代者的光环登场，G1是一个面向全堆的收集器，不需要其他新生代收集器的配合使用。所以从JDK9开始，ParNew+CMS收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了，官方希望它能完全被G1所取代，甚至还取消了ParNew+Serial Old 以及Serial + CMS这两组收集器组合的支持。这意味着ParNew和CMS从此只能互相搭配使用，再也没有其他收集器能够和他们配合了，也可以理解从此以后，ParNew并入CMS，成为它专门处理新生代的组成部分，ParNew可以说是HotSpot虚拟机中第一款退出历史舞台的垃圾收集器。
1.2.3关于并发和并行
从ParNew收集器开始，后面还会接触到若干款涉及"并发"和"并行"概念的收集器，在大家可能产生疑惑之前，有必要先解释清除这两个名次，并发和并行都是并发编程中的专业名词，在谈论垃圾收集器的上下文语境中，他们可以理解为：
- 并行 ： 并行描述的是
多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线程在协同工作，通常默认此时用户线程是处于等待状态。 - 并发： 并发描述的是
垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行，由于用户线程未被冻结，所以程序仍然能响应服务请求，但由于垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。
1.3Parallel Scavenge(复制算法)
Parallel Scavenge收集器也是一款新生代收集器，它同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器。。。Parallel Scavenge的诸多特性从表面上看和ParNew非常相似，那它有什么特别之处呢？
Parallel Scavenge收集器的特点是它的关注点和其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)，所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值。即：
吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 运行垃圾收集时间)
如果虚拟机完成某个任务，用户代码加上垃圾收集总共耗费了100min，其中垃圾收集花掉了1分钟，那吞吐量就是99%，停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序，良好的响应速度能提升用户体验，而高吞吐量则可以最高效率地利用处理资源，净快完成程序的运算任务，主要适合在后台运算而不需要太多交互的分析任务。
Parallel Scavenge收集器提供了两个参数用于精准控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及用于精准控制吞吐量大小的-XX:GCTimeRatio参数
由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称作"吞吐量优先收集器"
除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy值得我们关注。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。这种调节方式称为垃圾收集的自适应的调节策略（GC Ergonomics）。
2、老年代垃圾回收器
2.1Serial Old(标记整理)
Serial Old收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法，这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。
如果在服务端模式下，他也可能有两种用途，一种是在JDK5以及之前的版本中与Parallel Scavenge收集器搭配使用，另外一种就是作为CMS收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用
Parallel Scavenge收集器架构中本身有PS MarkSweep收集器来进行老年代收集，并非直接调用Serial Old收集器，但是这个PS MarkSweep收集器与Serial Old的实现几乎是一样的，所以在官方的许多资料中都是直接以Serial Old代替PS MarkSweep。
2.2Parallel Old(标记-整理)
Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并行收集，基于标记整理算法实现。
这个收集器是直到JDK6时才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于相当尴尬的状态，原因是如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old(PS MarkSweep)收集器别无选择。其他表现良好的老年代收集器，如CMS无法与他配合工作。
由于老年代Serial Old收集器在服务端性能上的拖累，使用Parallel Scavenge收集器也未必能在整体上获得吞吐量最大化的效果。同样，由于单线程的老年代收集中无法充分利用服务器多处理器的并行处理能力，在老年代内存空间很大而且硬件规格比较高级的运行环境中，这种组合的总吞吐量甚至不一定比ParNew加CMS的组合来得优秀。
直到Parallel Old收集器出现后，"吞吐量优先"收集器Parallel Scavenge终于有了比较名副其实的搭配组合，在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合.
2.3CMS(标记-清除)
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器，目前很大一部分的Java应该集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验，CMS收集器就非常符合这类应用的需求。
运行过程
从名字(包含 “Mark Sweep”)上就能看出CMS收集器是基于标记-清除算法实现的，它的运作过程相对于前面集中收集器来说更要复杂一些，整个过程分为四个步骤，包括
1、初始标记(CMS inital mark)
2、并发标记(CMS concurrent mark)
3、重新标记(CMS remark)
4、并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤仍然需要STW
- 初始标记：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要
STW - 并发标记：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起
并发运行 - 重新标记：为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短，需要
STW。 - 并发清除：清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时
并发的。
整个过程耗时最长的并发标记和并发清除阶段，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的，通过下图可以清晰的看出CMS收集器的运作步骤中并发和需要停顿的阶段。
CMS的缺点
1、CMS收集器对于处理器资源非常敏感，事实上，面向并发设计的程序对处理器资源都非常敏感，在并发阶段，他虽然不会导致用户线程停顿，但却会因为占用了一部分线程(准确来说是处理器的计算能力)而导致应用程序变慢，降低吞吐量。
2、CMS收集器无法处理浮动垃圾(Floating Garbage)，运行时预留的内存无法满足程序分配新对象的需求，有可能出现**“Concurrent Mode Failure”**失败从而导致另一次完全的STW的Full GC的产生。
浮动垃圾
– 在CMS的并发标记和并发清除阶段，用户线程还是继续运作的，程序在运行自然就会伴随着新的垃圾对象的不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们。只好留到下一次垃圾收集时再清理掉。这一部分垃圾就称为浮动垃圾
同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了在进行收集，必须预留一部分空间供并发收集时的程序运作使用。JDK5默认当老年代使用了68%的空间后就会被激活，JDK6时，CMS收集器的启动阈值就被提升到了92%，但是这又会面临一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次"并发失败(Concurrent Mode Failure)"，这时候虚拟机将不得不启动后备预案–>冻结用户线程的执行，临时启动Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。
3、CMS是基于标记清除算法实现的收集器，这意味着收集结束时会产生大量的空间碎片产生。空间碎片过多时，就会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找打足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC。
为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection的参数(默认是开启的，此参数从JDK9开始废弃)，用于在CMS不得不进行Full GC时开启内存碎片的合并整理过程。由于内存整理必须移动存活对象，(在Shenandoah和ZGC出现前)是无法并发的。这样空间碎片的问题是解决了，但是停顿时间又会变长。
因此虚拟机设计者们还提供了另外一个参数-XX: CMSFullGCsBefore-Compaction(JDK9废弃),这个参数的作用是要求CMS在执行若干次(数量由参数值决定)不整理空间的Full GC后，下一次进入Full GC前会先进行碎片整理(默认值是0，每次进入Full GC时都进行碎片整理)
3、全能垃圾回收器-G1
3.1G1概述
Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思想和基于Region的内存布局形式
到了JDK 8 Update40之后，G1提供并发的类卸载的支持，补全了其计划功能的最后一块拼图，这个版本以后的G1收集器才被Oracle官方称为"全功能的垃圾收集器(Fully-Featured Garbage Collector)"
G1是一款面向服务端应用的垃圾收集器，HotSpot最初赋予他的期望是未来可以替换掉JDK5中发布的CMS收集器，JDK9发布时，G1宣告取代Parallel Scavenge + Parallel Old组合，成为服务器端模式下的默认垃圾收集器，而CMS则沦落至被声明为不推荐使用，
作为CMS收集器的替代者和继承人，设计者们希望做出一款能够建立起"停顿时间模型(Pause Prediction Model)"的收集器，停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集的时间大概率不超过N毫秒这样的目标，这几乎已经是实时Java(RTSJ)的中软实时垃圾收集器特征了。
那具体要怎么做才能实现这个目标呢？ 首先要有一个思想上的改变，在G1收集器出现之前的所有其他收集器，包括CMS在内，垃圾收集的目标范围要么是整个新生代(Minor GC)，要么就是整个老年代(Major GC)，在要么就是这个Java堆(Full GC), 而G1跳出了这个樊笼，它可以面向堆内存任何部分来组成回收集(Collection Set 一般简称为CSet)进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量越多，回收效益越大，这就是G1收集器的Mixed GC模式
G1开创的基于Region的堆内存布局是它能够实现这个目标的关键，虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域(Region)，每一个Region都可以根据需要，扮演新生代的Eden区间、Survivor空间、或者老年代空间。 收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间，熬过多次收集的旧对象，都能获取很好的收集效果。
Region中还有一类特殊的Humongous区域，专门用来存储大对象，G1认为只要大小超过了一个Region容量一半的对象即判定为大对象，每个Region的大小可以通过参数-XX:G1HeqpRegionSize设定，取值范围为1MB~32MB，且应为2的N次幂，而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。
虽然G1仍然保留新生代与老年代的概念，但新生代和老年代不再是固定的了，他们都是一系列区域(不需要连续)的动态集合，G1收集器之所以能建立可预测的停顿时间模型，是因为它将Region作为单次回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集，更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的"价值"大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护维护一个优先级列表，每次根据用户设定允许的收集停顿时间(使用参数-XX:MaxGCPauseMillis指定，默认值是200ms)，优先处理回收价值收益最大的那些Region，这也就是Garbage first名字的由来，这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1收集器在有限的时间内获取尽可能高的收集效率。
G1收集器Region分区示意图
3.2运行过程
如果我们不去计算用户线程运行过程中的动作(如使用写屏障维护记忆集的的操作)，G1收集器的运作过程大致可划分为以下四个步骤
初始标记(Initial Marking)：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象，这个阶段需要停顿线程，但是耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。并发标记(Concurrent Marking)：从GC Roots开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时比较长，但可与用户程序并发执行，当对象图扫描完成以后，还要重新处理STAB记录下的在并发时有引用变动的对象最终标记(Final Marking): 对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的STAB记录筛选回收(Live Data counting and Evacuation)： 负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，在清理掉整个旧的Region的全部空间，这里的操作涉及存活对象的移动，是必须暂停用户程序，有多条收集器线程并行完成的。
从上述阶段的描述可以看出，G1收集器除了并发标记外，其余阶段也是要完全暂停用户线程的，换言之，它并非纯粹的追求低延迟，官方给它设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才能担当起"全功能收集器"的重任与期望。
毫无疑问，可以由用户指定的停顿时间是G1收集器很强大的一个功能
工作过程
