深入理解Java虚拟机--垃圾回收器

在讨论垃圾回收器的语境中：

并行：多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态

并发：用户线程与垃圾回收线程同时执行(但不一定是并行，可能会交替执行)

1.Serial收集器

        最基本、历史最悠久的收集器

        单线程收集器，只能使用一个CPU或一条收集线程去完成收集任务，而且期间必须暂停其他所有的工作线程

        简单而高效(相比于其他收集器的单线程)，无线程交互的开销，专心做垃圾回收自然会提高单线程收集效率。

        Client模式下的默认新生代收集器。

        新生代采用复制算法

2.ParNew收集器

        为Serial收集器的多线程版本，其余方面与Serial收集器无太大差别

        Server模式下首选的新生代收集器

        新生代采用复制算法，老年代采用标记——整理算法

3.Parallel Scavenge收集器

        新生代收集器，新生代采用复制算法，并行的多线程收集器(看上去和ParNew一样)

        关注点不同：CMS等收集器关注尽可能缩短垃圾收集时用户线程的停顿时间(适合多交互程序，可提高响应速度，提升用户体验)，而Parallel Scavenge收集器关注达到一个可控制的吞吐量(CPU运行于用户代码的时间/CPU总消耗时间，最高效率的利用CPU时间，尽快完成任务，适合后台运算而无需太多交互)。

       吞吐量优先收集器

4.Serial Old收集器

       Serial收集器的老年代版本，单线程收集器，采用标记——整理算法

5.Parallel Old收集器

       Parallel Scavenge收集器老年代版本使用多线程和标记——整理算法

6.CMS收集器

       以获取最短回收停顿时间为目标

       标记——清除算法

       四个步骤：

• 初始标记：需要Stop The World，标记下GC Roots能直接关联到的对象
• 并发标记：进行GC Roots Tracing
• 重新标记：修正并发标记期间，因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录
• 并发清除：

        缺点：

        对CPU敏感，执行期间占用CPU会导致应用程序变慢

        无法处理浮动垃圾(CMS并发清理期间，由于用户线程运行导致的新垃圾的产生，在标记过程之后，只能在下一次GC时处理)

        基于标记——清除算法，产生大量空间碎片  

7.G1收集器

        相较CMS有两点改进：

        基于标记——整理算法，不会产生空间碎片

        精准控制停顿

        可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，因为它极力避免了全区域的垃圾回收，之前垃圾回收的范围都是整个新生代或者老年代，而G1将整个java堆划分为多个大小固定的独立区间，并根据各区间的垃圾堆积程度，优先回收垃圾最多的区域