垃圾回收算法记录
垃圾回收算法的选择依据
- 单个请求会受停顿时间的影响——不过其受Full GC的影响更大。如果目标要求尽可能地缩短响应时间，那么选择使用Concurrent收集器更合适。
- 如果平均响应时间比最大响应时间更重要，采用Throughput收集器通常可以满足需求
- 使用Concurrent收集器来避免长时间的停顿也有其代价，这回消耗额外的CPU资源
- 如果CPU还可以的话，使用Concurrent收集器可以避免发生Full GU停顿可以让任务运行地更快。
- 如果CPUT有限的话，那么Concurrent收集器额外的CPU消耗会使得批量任务消耗更多的CPU时间。
关于所有的垃圾回收算法的共性
- 所有的垃圾回收算法都将堆划分成了新生代和老年代
- 所有的GC算法在清理新生代对象时，都会发生“stop the world”,但是通常这是一个能较快完成的操作。
四种GC器的使用场景
Serial收集器
作为应用运行在client虚拟机上的默认垃圾回收器，其使用单线程的方式进行垃圾回收，在其进行垃圾回收时，所有的线程都要停止下来。进行FullGC时，它还会对老年代的对象进行压缩整理。
如果不想应用程序使用默认的Serial垃圾收集器，那么需要显示的指定一种垃圾收集器。
Throughput垃圾收集器
是Server级虚拟机的默认垃圾回收器。使用多线程回收新生代空间，MinorGC的速度比Serial的速度快的多。
由于其使用多线程来进行垃圾回收，因此其也被称为Parallel收集器。在MinorGC和FullGC时会暂停所有的应用线程，同时在FullGC过程中会对老年代对象进行压缩整理。由于在大多数适用的场景，其已经是默认的收集器。所以不需要显示地指定它作为收集器。、
CMS收集器
其设计初衷是为了消除Throughput收集器和Serial收集器FullGC 周期中的长时间停顿。CMS收集器在MinorGC会暂停所有的应用线程，并使用多线程的方式进行垃圾回收。
但是CMS收集器不会在Full GC时暂停所有的应用线程，而是使用若干个后台线程定期的对老年代空间进行扫描，及时回收其中不在使用的对象。这种算法帮助CMS成为一个低延迟的收集器：应用程序只在MinorGC以及后台线程扫描老年代时发生极其短暂的停顿。
这里需要额外付出逇代价是更高的CPU使用，必须有足够的CPU资源用於运行后台的垃圾收集程序，在应用程序进行扫描的同时扫描堆的使用情况。如果CMS收集器的后台线程无法获得他们任务所需要的CPU资源，或者如果堆变得过度碎片化以至于无法找到连续的空间分配对象，CMS就蜕化到Serial收集器的行为：暂停所有的线程，使用单线程回收，整理老年化空间。这之后有恢复到冰法运行，再次启动后台线程。
G1回收器
它设计初衷：尽量缩短处理超大堆时产生的停顿。G1拉经济收集算法将堆划分为若干个区域，不过其依然还是属于分代的垃圾回收算法。G1收集器属于并发收集器：老年代的垃圾收集工作由后台线程完成，大多数的工作不需要暂停应用程序。G1回收器在垃圾回收的过程中就完成了碎片的整理工作。
