JVM垃圾收集器

 垃圾收集算法是内存回收的方法论，垃圾收集器是内存回收的具体实现。

并发与并行（垃圾回收器）

• 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个 CPU上。

垃圾回收器分类

• 串行回收，Serial回收器，单线程回收，全程“Stop The World”。
• 并行回收，名称以Parallel开头的回收器，多线程回收，全程“Stop The World”。
• 并发回收，cms与G1，多线程分阶段回收，只有某阶段会“Stop The World”。

Serial收集器

 Serial是一个单线程的垃圾收集器。采用“复制”算法，适用于新生代特点如下：

• “Stop The World”，它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。在用户不可见的情况下把用户正常工作的线程全部停掉。
• 使用场景：多用于桌面应用，Client端的垃圾回收器。
• 桌面应用内存小，进行垃圾回收的时间比较短，只要不频繁发生停顿就可以接受。

Serial old垃圾收集器

 它是一个单线程收集器，适用于老年代，使用"标记--整理"算法。

ParNew垃圾收集器

 ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数（例如：-XX: SurvivorRatio、-XX: PretenureSize' Threshold、-XX: HandlePromotionFailure 等）、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。特点如下：

• ParNew 收集器除了多线程收集之外，其他与 Serial 收集器相比并没有太多创新之处，但它却是许多运行在 Server 模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了 Serial 收集器外，目前只有它能与 CMS 收集器配合工作。

使用-XX: ParallelGCThreads 参数来限制垃圾收集的线程数
多线程操作存在上下文切换的问题，如果设置太多的话就会产生上下文切换消耗
。
所以建议将-XX: ParallelGCThreads设置成和CPU核数相同

Parallel Scavenge垃圾收集器

 Parallel Scavenge 收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
 由于与吞吐量关系密切，Parallel Scavenge 收集器也经常称为“吞吐量优先”收集器。

吞吐量是什么？
	CPU用于运行用户代码的时间与CPU总时间的比值
	99%时间执行用户线程，1%时间回收垃圾 ，这时候吞吐量就是99%

特点
 Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间。（停顿时间短，但是停顿频繁，吞吐量不一定高，只是每次垃圾收集时停顿较短而已）。
 而Parallel Scavenge 收集器的目标则是达到个可控制的吞吐（Throughput）。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99% 。

• 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。
• 而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

-XX:MaxGCPauseMillis参数GC停顿时间相关：这个参数配置太小的话会发生频繁GC，因为垃圾收集时间越短，所能收集的垃圾就越小。
-XX:GCTimeRatio参数，99%：这个值并不是越大越好，需要适中，才能发挥最理想的性能。

Parallel old垃圾收集器

 Parallel old垃圾收集器是Parallel Scavenge垃圾收集器的老年代版本，使用多线程 + “标记整理”算法。

CMS垃圾收集器

 CMS (Concurrent Mark Sweep）收集器是-种以获取最短回收停顿时间为目标的收集器。CMS 收集器是基于“标记-清除”算法实现的。
 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

CMS垃圾收集器步骤流程

1. 初始标记（CMS initial mark) -----标记一下 GC Roots 能直接关联到的对象，速度很快。
2. 并发标记（CMS concurrent mark) --------并发标记阶段就是进行 GC RootsTracing 的过程：JVM中对内存进行回收时，需要判断对象是否仍在使用中，可以通过GC Roots Tracing辨别。
3. 重新标记（CMS remark) -----------为了修正并发标记期间因用户程序导致标记产生变动的标记记录。
4. 并发清除（CMS concurrent sweep)。

CMS垃圾收集器缺点

• 对CPU资源非常敏感。
• 无法处理浮动垃圾，程序在进行并发清除阶段，用户线程所产生的新垃圾。
• CMS采用的是“标记-清除”算法：因此会产生内存碎片（内存可用空间不连续）。

G1垃圾收集器

 G1是一款面向服务端应用的垃圾收集器。
 G1中每个Region都有一个与之对应的Remembered Set，当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏 检查Reference引用的对象是否处于不同的Region。

G1垃圾收集器步骤流程

1. 初始标记（Initial Marking） --标记一下 GC Roots 能直接关联到的对象。
2. 并发标记（Concurrent Marking）---从GC Root 开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
3. 最终标记（Final Marking) ---为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录。虚拟机将这段时间对象变化记录在线程 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs的数据合并到 Remembered Set 中
4. 筛选回收（Live Data Counting and Evacuation)。Remembered Set可保证不对全堆扫描也不会有遗漏 ，大幅度提高回收的性能，比CMS回收的时间短。

G1的优势

• 空间整合：基于“标记一整理”算法实现为主和Region之间采用复制算法实现的垃圾收集。有效的避免CMS垃圾收集器造成的内存碎片的问题。
• 可预测的停顿：这是 G1 相对于 CMS 的另一大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，可以预测每个region的执行时间，region执行时间是可以预测的。G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Regions 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region（这也就是 Garbage- Firsti 名称的来由）。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高。
• 在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。使用 G1 收集器时，Java 堆的内存布局就与其他收集器有很大差别，它将整个 Java 堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分 Region（不需要连续）的集合。