JVM学习记录3--垃圾收集器

贴个图

• Serial收集器

  最简单的收集器，单线程，收集器会暂停用户线程，称为"stop the world"。

• ParNew收集器

  Serial收集器的多线程版本，其它类似。默认线程数为CPU线程数，通过-XX:ParallelGCThreads=? 可以指定线程数

• Parallel Scavenge收集器

  复制算法，多线程收集器。与ParNew的区别在于，该收集器关注系统吞吐量（吞吐量=用户运行时间/(用户运行时间+垃圾回收时间)）。通过-XX:MaxGCPauseMillis 设置垃圾回收时间，数组太小将导致垃圾回收不完全，从而GC频率变高。通关-XX:GCTimeRatio 设置垃圾回收时间和运行时间之比，默认值为99，即允许1%（1/(1+99)）。

• Serial Old 收集器

  Serial 收集器的老生代版本，才用标记-整理算法。

• Parallel Old收集器

  Parallel Scavenge的老生代版本，采用标记-整理算法。

• CMS（Concurrent Mark Sweep）

  CMS是一种获取最短时间停顿为目标的收集器。采用标记-整理算法，但是比上述的更为复杂。

  • 初始标记（CMS initial mark）
  • 并发标记（CMS concurrent mark）
  • 重新标记（CMS remark）
  • 并发清除（CMS concurrent sweep）

  CMS是一个优秀的垃圾收集器，并发收集，低停顿。但是也有3个显著的缺点：

  • CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户进程停顿，但还是会占用部分CPU，导致吞吐量变低。CMS默认启动的回收线程数为（CPU数量+3）/4，
  • CMS无法清理浮动垃圾，简单说就是在并发阶段，用户程序产生的新的垃圾无法被回收。这因为如此，所以在进行垃圾清理时，内存必须还留有空间给用户线程使用，在默认情况下，CMS收集器会在老生代使用了68%的空间后被激活。可以通过-XX:CMSInitiatingOccupancyFraction 来设置这个值。假如CMS回收期间，预留空间无法满足使用，则会引发“concurrent mode failure”，这时虚拟机会启动备案：临时使用Serial来收集垃圾，这会让停顿时间更长。
  • CMS是基于标记-清理算法的，所以会导致大量的内存碎片。

• G1收集器

  ​ G1收集器是当前最厉害的垃圾收集器，简单来说就是Parallel Scavenge的升级版。

  G1收集器采用标记-整理算法，不会产生内存碎片。而且G1收集器可以精确的控制停顿，能让使用者设置一个M毫秒的时间段，垃圾回收时间一定会在M毫秒内。

  ​ G1收集器可以实现在基本不牺牲吞吐量的前提下低停顿完成垃圾回收，是因为它能够极力地避免全区域的垃圾回收。G1收集器将堆（包括新生代，老生代）划分为多个区块，并生成一个优先级列表，优先回收垃圾最多的区块。