之前我们介绍了HotSpot虚拟机是如何去发起内存回收的问题， 但是虚拟机如何具体的进行内存回收动作仍未涉及，因为内存回收如何进行是由虚拟机所采用的 GC 收集器决定的， 而通常虚拟机往往不止有一种 GC 收集器， 下面来看看 HotSpot 中有哪些GC 收集器。
3.5 垃圾收集器
如果说收集算法是内存回收的方法论， 那么垃圾收集器就是内存回收的具体实现。
Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，所有不同的厂商、 不同版本的虚拟机所提供的垃圾收集器可能会有很大差别。 主要讨论的收集器基于 JDK 1.7 Update 14之后的 HotSpot 虚拟机
图中展示了 7 种作用与不同分代的收集器，如果两个收集器之间存在连线，就说明它可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。
接下来将逐一介绍这些收集器的特性、基本原理和使用场景，并重点分析 CMS 和 Gl 这两种相对复杂的收集器， 了解他们的部分运作细节。
一句重要的话： 没有最好的收集器，只有合适的收集器。
5.1 Serial 收集器
最基本、发展历史最悠久的收集器， 这个收集器是一个单线程的收集器，但它的“ 单线程” 的意义并不仅仅说明它只会使用一个 CPU 或一条收集线程去完成垃圾收集工作， 更重要的是在它进行垃圾收集时， 必须暂停其他所有的工作线程， 直到它收集结束。
这一点就注定它会给用户带来不良体验，但是也能理解，如果垃圾的产生和结束一直是动态的， 那要怎么收集呢？
Serial收集器的优点： 简单而高效（与其他收集器的单线程比）， 对于限定单个CPU的环境来说， Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大， 收集几十兆甚至一两个百兆的新生代(仅仅是新生代使用的内存，桌面应用基本上不会再大了）， 停顿时间完全可以控制在几十毫秒最多一百多毫秒以内， 只要不是频繁发生，这点停顿是可以接受的。
3.5.2 ParNew 收集器
在 Serial 之后， 更新的版本 ParNew 收集器出现， ParNew 收集器其实就是 Serial 收集器的多线程版本， 除了使用多条线程进行垃圾收集之外， 其余行为包括 Serial 收集器可用的所有控制参数、收集算法、 Stop The World 、 对象分配规则和回收策略等都与 Serial 收集器完全一样。 在实现上，这两种收集器也共用了相当多的代码。 parNew 收集器的工作过程如下图所示：
ParNew 收集器除了多线程收集之外， 其他与 Serial收集器相比并没有太多创新之处， 但它却是许多运行在 Server模式下的虚拟机中首选的新生代收集器。其中有一个与性能无关但很重要的原因是，除了 Serial收集器外， 目前只有它能与 CMS 收集器配合工作。
注意：
并发和并行这两个词在垃圾收集器的上下文解释为：
- 并行（Parallel）: 指多条垃圾收集线程并行工作， 但此时用户线程仍然处于等待状态
- 并发（Concurrent) : 指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个 CPU上。
3.5.3 Parallel Scavenge 收集器
Parallel Scavenge 收集器是一个新生代收集器， 它也是使用复制算法的收集器， 又是并行的多线程收集器。
Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同， CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，
而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值， 即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间）。 虚拟机总共运行了100 分钟， 其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。
停顿时间越短就越适合与用户交互的程序（让用户等是一种很差的体验）， 良好的响应速度能提升用户体验。
而高吞吐量则可以高效率地利用CPU时间， 尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量， 分别是控制最大垃圾收集停顿时间的 -XX: MaxGCPauseMillis 参数以及直接设置吞吐量大小的 -XX: GCTimeRatio 参数。
MAXGCPauseMillis 参数允许的值是一个大于 0 的毫秒数， 收集器将尽可能地保证内存回收花费的时间不超过设定值。
GCTimeRatio参数的值应当是一个大于 0 且小于 100 的整数， 也就是垃圾收集时间占总时间比率，相当于吞吐量的倒数。 默认值为 99 ， 即允许最大 1 %的垃圾收集时间。
由于与吞吐量关系密切， Parallel Scavenge 收集器也经常称为“吞吐量优先” 收集器。
Parallel Scavenge 收集器还有一个参数： -XX: + UseAdaptiveSizePolicy ，这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小， Eden 与 Survivor 区的比例、晋升老年代对象年龄等细节参数了， 虚拟机会根据当前系统的运行情况收集性能监控信息， 动态调整这些参数以提供最合适的停顿时间或者最大吞吐量，这种调节方式称为GC 自适应的调节策略（GC Ergonomics）.
如果读者对于收集器运作原来不太了解，手工优化存在困难时， 使用Parallel Scavenge 收集器配合自适应调节策略， 把内存管理的调优任务交给虚拟机去完成是一个不错的选择。
3.5.4 Serial Old收集器
Serial Old 是 Serial 收集器的老年代版本，它同样是一个单线程收集器， 使用 “标记—整理算法” ，这个收集器的主要意义也是在于给 Client 模式下的虚拟机使用， 如果在 Server模式下， 那么它主要有两大用途：
- 一种用途是在 JDK 1.5 以及之前的版本中与 Parallel Scavenge 收集器搭配使用。
- 另一种用途就是作为 CMS 收集器的后备预案， 在并发收集发生 Concurrent Mode Failure 时使用。 这两点都将在后面的内容中详细讲解。 Serial Old 收集器的工作过程如下所示；
3.5.5 Parallel Old 收集器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本， 使用多线程和 “标记—整理” 算法， 这个收集器是在 JDK 1.6 才开始提供的， 在此之前， 新生代的 Parallel Scavenge 收集器一直处于比较尴尬的状态，因为如果新生代选择了 Parallel Scavenge 收集器， 老年代除了 Serial Old(PS MarkSweep) 收集器外别无选择， 因为 Parallel Scavenge 收集器无法与 CMS收集器配合工作， 但老年代 Serial Old 收集器在服务端应用性能上的“ 拖累” ，使用了 Parallel Scavenge 收集器也未必能在整体应用上获得吞吐量最大化的效果。
由于单线程的老年代收集中无法充分利用服务器多 CPU的处理能力， 在老年代很大而且硬件比较高级的环境下，这种组合的吞吐量甚至还不一定有 ParNew 加 CMS 的组合给力。
这时， Parallel Old 收集器出现后， “吞吐量优先” 收集器终于有了比较名副其实的应用组合， 在注重吞吐量以及CPU资源敏感的场合， 都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器、
3.5.6 CMS收集器——系统停顿时间短
CMS（Concurrent Mark Sweep） 收集器是一种以获取最短回收停顿时间为目标的收集器。 目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务的影响速度，希望系统停顿时间最短， 以给用户带来较好的体验， CMS收集器就非常符合这类应用的要求。
从名字可以看出， CMS收集器是基于 “标记—清除” 算法实现的， 它的运作过程相对于前面几种收集器来说更复杂一些， 整个过程分为 4 个步骤，包括；
- 初始标记（CMS intial mark）
- 并发标记（CMS concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS concurrent sweep）
其中，初始标记、重新标记这两个步骤仍然需要 “Stop The World” 。
初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快。
并发标记阶段时进行GC Roots Tracing 的过程，
重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以，从总体来说， CMS收集器的内存回收过程是与用户线程一起并发执行的。 通过下图可以比较清楚地看到 CMS收集器的运作步骤中并发呵呵需要停顿的时间。
CMS是一款优秀的收集器， 它的主要优点在名字上已经体现出来了： 并发收集、低停顿， 但是它也有缺点：
- CMS收集器对 CPU 资源非常敏感， 其实，面向并发设计的程序都对 CPU资源比较敏感， 在并发阶段， 它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源） 而导致应用程序变慢， 总吞吐量会降低。
CMS默认启动的回收线程数是（CPU数量 + 3）/ 4 ， 也就是当 CPU在 4个以上时， 并发回收时垃圾收集线程不少于 25% 的CPU资源，并且随着CPU数量的增加而下降，但是当 CPU不足 4 个时， CMS对用户程序的影响就可能变得很大， 如果本来 CPU负载就比较大，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了 50%， 其实也让人无法接受。
为了应付这种情况， 虚拟机提供了一种称为“ 增量式并发收集器”（Incremental Concurrent Mark Sweep/ i-CMS ）的CMS收集器变种， 所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想一样，就是在并发标记、清理的时候让GC线程、用户线程交替进行，尽量减少GC线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得少一些，也就是速度下降没有那么明显。实践证明，增量时的 CMS收集器效果很一般，在目前版本。 i-CMS已经不再提倡使用。
- CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生， 由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然还会有新的垃圾不断产生， 这一部分出现在标记过程之后，CMS无法在当次收集中处理掉他们 。 只好留待下一次GC时再清理掉。 这一部分称为“浮动垃圾”。
也是由于在垃圾收集阶段用户线程还需要进行，那也就还需要有预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，因为需要预留一部分空间提供并发收集时的程序运作使用。 - 还有最后一个缺点， CMS是一块基于“标记-清除”算法实现的收集器， 收集结束时会有大量空间碎片产生， 空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代还有很大空间剩余， 但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次 FullGC。
3.5.7 G1 收集器
G1 收集器是目前收集器技术发展的最前沿成果之一，首先来看看它和其他收集器的不同之处：
- 并行与并发： G1能充分利用多个CPU、多核环境下的硬件优势，使用多个CPU来缩短 Stop-The-World 停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作， G1收集器仍然可以通过并发的方式让Java程序继续执行。
- 分代收集：与其他收集器一样，分代概念在G1中得以保留，虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
- 空间整合： 与CMS的“标记-清理”算法不同，G1 从整体来看是基于“标记- 整理” 算法实现的收集器， 从局部（两个 Region 之间）上来看是基于“复制” 算法实现的， 但无论如何， 这两种算法都以为这 G1 运作期间不会产生内存空间碎片， 收集后能提供规整的可用内存。
- 可预测的停顿：这是G1 相对于 CMS 的另一大优势，降低停顿时间是 G1 和 CMS共同的关注点， 但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型， 能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒，这几乎是实时Java（RTSJ)的垃圾收集器的特征了。
在G1 之前的其他收集器进行收集的范围都是整个新生代或者老年代，但是G1 不再是这样， 使用 G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region(不需要连续）的集合。
G1收集器之所以能够建立预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集， G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值）， 在后台维护一个优先列表。每次根据允许的收集时间， 优先回收价值最大的Region（这也就是 Garbage-First名称的来由。这种使用 Region划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。
G1 把内存“化整为零” 的思路， 理解起来似乎很容易，但其中的细节远远没有想象中那么简单。
在G1 收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用 Remembered Set 来避免全堆扫描的，G1 中每个 Region 都有一个与之对应的 Remembered Set ,虚拟机发现程序在对 Reference 类型的数据进行写操作时，会产生一个 Write Barrier 暂时中断写操作。检查 Reference 引用的对象是否处于不同的 Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代的对象），如果是， 便通过 CardTable 把相关引用信息记录到被引用对象所属的 Region 的Rememberd Set 之中。 当进行内存回收时， 在GC根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏。
如果不计算维护 Remembered Set的操作，G1 收集器的运作大致可以划分为以下几个步骤：
- 初始标记
- 并发标记
- 最终标记
- 筛选回收
初始标记阶段仅仅只是标记以下 GC Roots能直接关联到的对象，并且修改TAMS（next Top at Mark Start） 的值，让下一阶段用户程序并发运行时， 能在正确可用的 Region中创建新对象。这个阶段需要停顿线程，但耗时很短。
并发标记阶段时从 GC Root 开始对堆中对象进行可达性分析， 找出存活的对象， 这阶段耗时较长， 但可与用户程序并发执行。
最终标记则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录； 虚拟机将这段时间对象变化记录在线程 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中，这阶段需要停顿线程， 但是可并行执行。
最后在筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的GC 停顿时间来指定回收计划， 这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region， 时间是用户可控制的， 而且停顿用户线程将大幅提高收集效率。 
理解GC日志
阅读GC日志是处理Java虚拟机内存问题的基础技能，它只是一些人为确定的规则，没有太多技术含量。
每一种收集器的日志形式都是由它自身的实现所决定的， 完全可以更个性化，但是虚拟机设计者为了方便用户阅读， 将各个收集器的日志都维持一定的共性。
CPU时间和墙钟时间的区别是： 墙钟时间包括非运算的等待耗时， 例如等待磁盘 I/O、等待线程阻塞。 而CPU时间不包括这些耗时， 但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间。
最前面的数字“33.125：” 和“ 100.667 :”代表了 GC发生的时间，这个数字的含义是从 java虚拟机启动以来经过的描述。
GC 日志开头的 “[GC” 和 “[ Full GC” 说明了这次垃圾收集的停顿类型， 而不是用来区分新生代 GC还是 老年代 GC 的。 如果有 “Full” ，说明这次GC 是发生了 Stop-The-World 的，例如下面这段新生代收集器 ParNew 的日志也会出现 “ [Full GC” （这一般是因为出现了分配担保失败之类的问题，所以才导致 STW）。 如果是调用 System.gc() 方法所触发的收集，那么这里将显示“[Full GC (System)”。
接下来的 “ [DefNew”、 “[Tenured” 、 “[Perm” 表示 GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的， 例如上面样例所使用的 Serial 收集器中的新生代名为“Default New Generation”,所以显示的是 “[DefNew”。 如果是 ParNew 收集器，新生代名称就会变为 “[ParNew” ,意为“Parallel New Generation” 。如果采用 Parallel Scavenge收集器， 那它配套的新生代称为 " PSYoungGen", 老年代和永久代同理， 名称也是由收集器决定的。
后面方括号内部的 “ 3324K -> 152K(3712K)” 含义是“GC前该内存区域已使用容量 -> GC后该内存区域已使用容量（该内存区域总容量）”。而在方括号以外的 “3324K -> 152K(11904K)” 表示“GC前Java堆已使用容量 -> GC后Java堆已使用容量（Java堆总容量）” 。
再往后， “0.0025925 secs”表示该内存区域GC 所占用的时间，单位是秒。 有的收集器会给出更具体的时间数据， 如“[TImes : user = 0.01 sys = 0.00, real = 0.02 secs”， 这里面的 user、 sys 和 real 分别代表用户态消耗的CPU时间、内核态消耗的CPU时间和操作从开始到结束所经过的墙中时间。
