(1)垃圾回收器分类

有三类垃圾回收器。

1、串行垃圾回收器

  • 单线程
  • 适合堆内存较小场景，适合个人电脑。

2、吞吐量优先

  • 多线程
  • 适合堆内存较大场景，需要多核CPU支持
  • 让单位时间内，SWT时间最短

3、响应时间优先

  • 多线程
  • 适合堆内存较大场景，需要多核CPU支持
  • 尽可能使单次响应SWT时间最少

注：吞吐量优先追求的是单位时间的STW时间最短，响应时间优先是追求每次响应的速度最快。举例如下，算法1：0.2s/次 * 2次 =0.4s，算法2：0.1s/次 * 5次 =0.5s，算法1进行垃圾回收的总时间最短，吞吐量更大。算法2的单次垃圾回收时间更短，响应速度更快。

(2)串行垃圾回收器

使用-XX:+UseSerialGC = Serial + SerialOld可以开启串行垃圾回收器。其中新生代采用的算法是复制算法，老年代采用的是标记整理算法。在垃圾回收线程运行前，会先阻塞其他线程。

图片说明

(3)吞吐量优先

开启-XX:+UseParrallelGC或者-XX:+UseParrallelGC(开启一个另外一个会自动开启)使用吞吐量优先的垃圾回收器，其新生代算法仍为复制算法，老年代算法仍为标记整理算法。不过其特别之处在于：在垃圾回收前，用户线程会暂停，但是垃圾回收时会开启多个线程同时执行垃圾回收操作，开启的线程数量与cpu核数相同。当然，我们也可以使用-XX:ParallelGCThreads=n来指定进行垃圾回收的线程数量。参数-XX:+UseAdaptiveSizePolicy可以使用自适应的策略来调整堆的大小，这里主要是新生代空间的调整。XX:GCTimeRatio=n用于设置除垃圾回收时间外的时间占比，假设-XX:GCTimeRatio=19 ，则垃圾收集时间为1/(1+19),默认值为99，即1%时间用于垃圾收集。-XX:ParrallelGCMills=ms用于调整每一次垃圾回收的暂停时间。但是XX:GCTimeRatio=n和

-XX:ParrallelGCMills=ms这两个参数其实是有冲突的。当GCTimeRatio设置的更大，就要调整堆使堆更大，以增加吞吐量，而堆更大则每次垃圾回收的暂停时间就会更长。两者要进行合理取舍。(注：JVM的堆大小有起始值和最大值，堆在这个范围内进行大小调节)

图片说明

(4)响应时间优先

ConcMarkSweepGC是工作在老年代的垃圾回收器。望文生义，响应时间优先垃圾回收器采取的垃圾回收策略是标记清除法(快，无需内存移动)。其中Con是concurrent的缩写，这表示响应时间优先的垃圾回收器在某些阶段采用的是并发策略(在某些阶段仍需STW)：垃圾回收线程和其他用户线程并行执行，这样显然有利于提高程序的响应性能，但是也会牺牲吞吐量，与CMS垃圾回收器配合的垃圾回收器为ParNewGC。不过，CMS垃圾回收器有时会并发失败，这时会采取补救措施，将CMS退化为SerialOld。

在老年代快满时，将会阻塞其他线程，然后由垃圾回收线程对于GC Root进行快速的标记，由于只标记GC Root，这个过程很短。然后其他线程就可以恢复执行了，同时垃圾回收与其他用户线程并发执行，垃圾回收并发标记除根对象外的其他要被回收的对象。在并发标记结束后再次STW，然后重新标记，防止由于用户线程的活动导致对象的地址发生变化。重新标记结束后用户线程又可以执行了，垃圾回收线程进行并发清理。

可以设置并行线程数和并发线程数，并行线程数一般与cpu的核数相同，一般建议将并发线程数设置为并发线程数的1/4，即垃圾回收线程与用户线程按照1：3来抢占cpu，并发执行。

在进行并发清理的过程中，不能把这个过程新产生的垃圾清理掉，这些垃圾需要下一次垃圾回收时进行清理，称为浮动垃圾。因为清理是并发的，可能还没有清理出足够的空间存放这部分浮动垃圾，因此不能够像其它垃圾回收器一样，等到堆内存不足了再进行垃圾回收，必须为他们预留空间，参数-XX:CMSInitiatingOccupancyFraction=percent可以用来设置执行垃圾回收的时机：当内存的占比达到设置值就执行垃圾回收。

有可能新生代的对象引用老年代的对象，在进行重新标记时，要对整个堆的对象进行扫描，包括新生代的对象，然后根据这个新生代的对象扫描整个老年区的对象，做可达性的分析。这样无疑会消耗时间。使用参数-XX:CMSScanvengeBeforeRemark会先使用ParNewGC对新生代进行扫描，将其中可以回收的对象进行回收。

标记清除可能会导致垃圾碎片过多，导致并发失败，CMS会退化为SerialOld，进行一次全面的垃圾整理。这无疑会造成很多的时间消耗，这也时CMS存在的一个问题。

图片说明