vlambda博客
学习文章列表

图5 分代垃圾回收

分代回收仅考虑了对象的生命周期，无法控制GC回收的大小。因此分区回收算法应时而生，将整个堆划分成连续的小区间，每个小区间独立使用和回收，GC时可以控制要回收区间的数量，从而控制GC产生的停顿时间，分区间采用复制算法，效率更高。

图6 分区垃圾回收

有了垃圾回收算法，对应的程序实现就是垃圾回收器。但即便基于相同的算法原理，回收器也会有不一样的实现，呈现出来的性能效果也各有倾向。

而考量一个垃圾回收器是否适用主要有两个指标：吞吐量、最大暂停时间。

·吞吐量

负责GC的线程会和应用程序线程争用当前可用CPU的时钟周期。应用程序线程用时占程序总用时的比例即为吞吐量。吞吐量越高越好。

·最大暂停时间

GC时会出现应用程序线程挂起，仅GC线程运行的场景。出现此现象最长的一次的时间就是最大暂停时间。暂停时间越短越好。

但吞吐量和最大暂停时间是相互矛盾的，吞吐量大意味着GC次数少，而GC少则意味着一次GC会有更多的垃圾需要处理，暂停时间就会变长。因此，若是交互式的应用，注重用户体验，则选择暂停时间更短的垃圾回收器；若应用追求短时间完成任务，则选择吞吐量更高的回收器。

回收器的发展可以分成三个阶段：串行、并行、并发。同时从算法层面又主要分为分代收集与分区收集。

串行回收器简单高效，无线程切换的开销，适合单核环境、内存较小的场景。主要实现由Serial和Serial Old回收器，采用分代收集。

但如今计算机内存至少G级别，并行计算能力也更强，因此在串行回收器上进一步改进，实现并行回收器，仍然独占CPU，但多线程处理速度更快，暂停时间更短。主要实现有ParNew、Parallel Scavenge和Parallel Old，同样采用分代收集。

并行回收器虽然采用多线程的方法缩短了暂停时间，但整个GC过程仍然是独占CPU的，进一步改进，采用多线程并发回收。并发回收器的回收流程中仅小部分环节是独占CPU，会产生暂停时间，其余环节则与应用线程并发执行，进一步缩短暂停时间。CMS与G1是当前应用最广泛的并发回收器。

图7 收集器

回到文章开头提到的服务下线的问题，可以考虑G1来替换CMS来提升性能，但口说无凭，实践对比。

首先是JVM参数配置，根据服务器的内存来分配，测试机内存8G，考虑其他应用占用，JVM配置4G。

图8 参数配置

从配置参数上就能看出明显差异，CMS需要配置多达9个参数，G1因为具有自适应的特性，则只需配置一个参数，极大减轻开发人员学习成本，将更多精力放在功能开发上。

基于同一段代码，测试CMS与G1，代码中会不断生成小对象，并间断的生成4M大对象。CMS与G1的表现如下图所示。

图9 使用CMS垃圾回收器

图10 使用G1垃圾回收器

从CPU占用率以及停顿时间方面对比，G1表现都要更优秀。后续又对CMS进行简单调优后，较好的表现是新生代收集45次，耗时7.74秒，老年代收集8次，耗时0.74秒。相比之前性能好了许多，但相比G1仍然要差。

因此，如果是新系统或者系统使用CMS后出现过内存回收引起的溢出等问题，推荐使用G1回收器，但G1更适合大内存的服务使用。如果服务器内存较小，应用内存吃紧，始终需进行整个堆的回收，G1的工作量并不少，甚至因为算法更复杂，性能更差，不推荐改用G1。

前文提到垃圾回收器的评价指标主要为吞吐量与最大暂停时间。未来垃圾回收器的发展趋势主要是缩短暂停时间，这其实也与当前软件更注重用户体验的趋势一致。

还有其他的一些收集器，比如Azul 的 Zing JVM使用的 C4（Concurrent Continuously Compacting Collector）收集器 、用于分布式垃圾回收的DGC。篇幅原因，不再一一介绍。

垃圾回收的内容有非常多，本文只是引子。各位同事有兴趣的话，可以继续深耕。