（最新）JVM（HotSpot虚拟机）各种垃圾收集器优缺点

JVM中各种垃圾收集器优缺点

收集器名称	优点	缺点	备注
Serial/Serial Old	1、所有收集器中内存消耗最小的 2、相比于其他收集器的单个线程开说，更简单高效	1、单线程工作收集器，垃圾收集时必须暂停其他所有工作线程，且暂停时间不可控	Serial收集器对于运行在客户端模式下、微小型服务或单线程服务的虚拟机来说是一个很好的选择。
ParNew	1、是Serial的多线程并发版本 2、目前除了Serial只有它可以与CMS垃圾收集器配合使用	1、单核环境下不会比Serial更好 2、默认开启的收集线程数与处理器核心数相同
Parallel Scavenge	1、Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（处理器用于运行用户代码的时间与处理器总消耗时间的比值：运行用户代码时间/运行用户代码时间+运行垃圾收集时间）。 2、可以精确配置吞吐量，或自动调整吞吐量（自适应调节策略）	1、可能造成竞争时间片时间增加，抑或垃圾回收不全面等问题，导致程序运行过程中付出的整体 GC 时间较长。	主要适合在后台运算而不需要太多交互的分析任务。
Parallel Old	1、Parallel Scavenge的老年代版本，可以与Parallel Scavenge组成吞吐量优先的垃圾收集组合		在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合。
CMS	1、并发收集 2、低停顿	1、对处理器资源敏感，降低吞吐量，当处理器数少于四个时，影响会很大。 2、无法处理浮动垃圾，有可能引发Full GC 3、采用标记清楚算法，会产生大量碎片空间	目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。
G1（Garbage First）	1、开创了收集器面向局部收集的设计思路和基于Region的内存布局形式 2、不再局限于分代收集：衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。 3、可以配置允许的收集停顿时间 4、优先处理回收价值大的Region	1、内存占用和额外执行负载都比CMS要高	1、主要面向服务器端的垃圾收集器 2、目前在小内存应用上CMS的表现大概率仍然要会优于G1，而在大内存应用上G1则大多能发挥其优势，
Shenandoah	1、支持并发整理算法，可以与用户线程并发 2、默认不使用分代 3、Shenandoah摒弃了在G1中耗费大量内存和计算资源去维护的记忆集，改用名为“连接矩阵”（Connection Matrix）的全局数据结构来记录跨Region的引用关系，降低了处理跨代指针时的记忆集维护消耗，也降低了伪共享问题的发生概率。	1、不由oracle开发和维护
ZGC（JDK11）	1、和Shenandoah高度相似且由Oracle研发 2、在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。 3、使用了读屏障、染色指针和内存多重映射等技术实现可并发的标记整理算法
Epsilon	1、自动内存管理子系统	1、不做任何回收行为	如果应用只要运行数分钟甚至数秒，只要Java虚拟机能正确分配内存，在堆耗尽之前就会退出，那显然运行负载极小、没有任何回收行为的Epsilon便是很恰当的选择。