GC历史

image.png

1.Serial收集器

​ 单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。

2.ParNew收集器

​ ParNew收集器就是Serial的多线程版本，除了使用多条收集线程外，其余行为包括算法、STW、对象分配规则、回收策略等都与Serial收集器一摸一样。对应的这种收集器是虚拟机运行在Server模式的默认新生代收集器，在单CPU的环境中，ParNew收集器并不会比Serial收集器有更好的效果。

3.Parallel Scavenge收集器

​ Parallel Scavenge收集器（下称PS收集器）也是一个多线程收集器，也是使用复制算法，但它的对象分配规则与回收策略都与ParNew收集器有所不同，它是以吞吐量最大化（即GC时间占总运行时间最小）为目标的收集器实现，它允许较长时间的STW换取总吞吐量最大化。

4.Serial Old收集器

​ Serial Old是单线程收集器，使用标记－整理算法，是老年代的收集器，上面三种都是使用在新生代收集器。

5.Parallel Old收集器

​ 老年代版本吞吐量优先收集器，使用多线程和标记－整理算法，JVM 1.6提供，在此之前，新生代使用了PS收集器的话，老年代除Serial Old外别无选择，因为PS无法与CMS收集器配合工作。

6.CMS（Concurrent Mark Sweep）收集器

​ CMS是一种以最短停顿时间为目标的收集器，使用CMS并不能达到GC效率最高（总体GC时间最小），但它能尽可能降低GC时服务的停顿时间，这一点对于实时或者高交互性应用（譬如证券交易）来说至关重要，这类应用对于长时间STW一般是不可容忍的。CMS收集器使用的是标记－清除算法，也就是说它在运行期间会产生空间碎片，所以虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。

GC发展历史

​ DefNewGeneration是default new generation ParNewGeneration是parallel new generation 原本HotSpot VM里没有并行GC，当时就只有NewGeneration；后来准备要加入young gen的并行GC，就把原本的NewGeneration改名为DefNewGeneration，然后把新加的并行版叫做ParNewGeneration。

​ 这些XXXGeneration都在HotSpot VM的“分代式GC框架”内。本来HotSpot VM鼓励开发者尽量在这个框架内开发GC，但后来有个开发就是不愿意被这框架憋着，自己硬写了个没有使用已有框架的新并行GC，并拉拢性能测试团队用这个并行GC来跑分，成绩也还不错，于是这个GC就放进HotSpot VM里了。这就是我们现在看到的ParallelScavenge。（结果就是HotSpot GC组不得不维护两个功能几乎一样、但各种具体细节不同的并行GC。其实是件很头疼的事情嗯）

​ Scavenge或者叫scavenging GC，其实就是copying GC的另一种叫法而已。HotSpot VM里的GC都是在minor GC收集器里用scavenging的，DefNew、ParNew和ParallelScavenge都是，只不过DefNew是串行的copying GC，而后两者是并行的copying GC。由此名字就可以知道，“ParallelScavenge”的初衷就是把“scavenge”给并行化。换句话说就是把minor GC并行化。

​ 至于full GC，那不是当初关注的重点。 把GC并行化的目的是想提高GC速度，也就是提高吞吐量（throughput）。所以其实ParNew与ParallelScavenge都可叫做Throughput GC。 但是在HotSpot VM的术语里“Throughput（吞吐量） GC”通常特指“ParallelScavenge”。

​ ParallelScavenge和ParNew都是并行GC，主要是并行收集young gen，目的和性能其实都差不多。最明显的区别有下面几点：

​ 1、PS以前是广度优先顺序来遍历对象图的，JDK6的时候改为默认用深度优先顺序遍历，并留有一个UseDepthFirstScavengeOrder参数来选择是用深度还是广度优先。在JDK6u18之后这个参数被去掉，PS变为只用深度优先遍历。ParNew则是一直都只用广度优先顺序来遍历

​ 2、PS完整实现了adaptive size policy，而ParNew及“分代式GC框架”内的其它GC都没有实现完（倒不是不能实现，就是麻烦+没人力资源去做）。所以千万千万别在用ParNew+CMS的组合下用UseAdaptiveSizePolicy，请只在使用UseParallelGC或UseParallelOldGC的时候用它。

​ 3、由于在“分代式GC框架”内，ParNew可以跟CMS搭配使用，而ParallelScavenge不能。当时ParNew GC被从Exact VM移植到HotSpot VM的最大原因就是为了跟CMS搭配使用。

​ 4、在PS成为主要的throughput GC之后，它还实现了针对NUMA的优化；而ParNew一直没有得到NUMA优化的实现。

​ 还有一点要注意：上面说ParallelScavenge并行收集young gen，那old/perm gen呢？ 其实最初的ParallelScavenge的目标只是并行收集young gen，而full GC的实际实现还是跟serial GC一样。只不过因为它没有用HotSpot VM的generational GC framework，自己实现了一个CollectedHeap的子类ParallelScavengeHeap，里面都弄了独立的一套接口，而跟HotSpot当时其它几个GC不兼容。其实真的有用的代码大部分就在PSScavenge（＝“ParallelScavenge的Scavenge”）里，也就是负责minor GC的收集器；而负责full GC的收集器叫做PSMarkSweep（＝“ParallelScavenge的MarkSweep”），其实只是在serial GC的核心外面套了层皮而已，骨子里是一样的LISP2算法的mark-compact收集器（别被名字骗了，它并不是一个mark-sweep收集器）。

​ 当启用-XX:+UseParallelGC时，用的就是PSScavenge+PSMarkSweep的组合。 这是名副其实的“ParallelScavenge”——只并行化了“scavenge”。 所以其实非要说对应关系的话，PSScavenge才是真的跟ParNew对等的东西；ParallelScavenge这个名字既指代整套新GC，也可指代其真正卖点的PSScavenge。 不知道后来什么原因导致full GC的并行化并没有在原本的generational GC framework上进行，而只在ParallelScavenge系上进行了。其成果就是使用了LISP2算法的并行版的full GC收集器，名为PSCompact（＝“ParallelScavenge-MarkCompact”），收集整个GC堆。

​ 当启用-XX:+UseParallelOldGC时，用的就是PSScavenge+PSCompact的组合。 此时ParallelScavenge其实已经名不符实了——它不只并行化了“scavenge”（minor GC），也并行化了“mark-compact”（full GC）。