jvm：垃圾回收器GC搭配推荐及其常用调优参数

Mark笔记：

由于java11中ZGC的出现，希望大家别对GC调优的研究下太多功夫，对未来来说，这是贬值的

新生代垃圾收集器种类：

老年代垃圾回收器种类：

其中G1是概括了新生代和老年代，没有分的那么明显，也就是说，G1的新生代和老年代都是使用G1这个垃圾收集器

解释一下图中所说的在垃圾回收器中的并行和并发分别指的是什么

并行：  垃圾回收操作的多个线程同时进行

并发：进行垃圾回收操作的多个线程与程序的多线程同时进行

 

上述的垃圾收集器并非是可以随意搭配的，有搭配要求，详细搭配如下：

怎么看自己的垃圾回收器是哪一个？

java -XX：+PrintCommandLineFlags -version

-XX：+UseParallerlGC就是博主使用的GC垃圾收集器释义为：新生代使用ParallerGC，老年代使用Serial Old

 第一种：

执行   -XX:+UseSerialGC 如下：

新生代使用Serial老年代使用Serial Old

最古老的，单线程，独占式，成熟，适合单CPU  服务器，如果你的服务器是单核CPU，就这个想都不用想,速度一定是最快的，当然...排除java11中的ZGC

图中的Safepoint指的是一个安全点，并不是随便突然就强制停止线程，而是等待用户线程运行到某一个不会导致程序错误的点的时候，用户线程暂停下来，垃圾回收后再通知用户线程继续执行下去，这里我们不能直接去干预或者影响Safepoint，只需要了解有这么个东西即可

第二种：

执行  -XX:+UseParNewGC  如下：

新生代使用ParNew，老年代使用Serial Old

ParNew 是多线程的形式去清理，多cpu下使用，清理速度更快，且GC所导致的Stop The World时间更短，适合用于与用户交互的程序，例如web项目或者界面应用

第三种：

执行  -XX:+UseParallelGC  如下：

新生代使用ParallelScanvenge，老年代使用Serial Old

与ParNew类似，更关注吞吐量，但老年区仍然使用的是Serial Old单线程，考虑用第四种，

关注吞吐量的垃圾收集器，可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

第四种：

执行-XX:+UseParallerOldGC 如下

新生代使用ParallelScanvenge，老年代使用Parallel Old

相比第三种，对于吞吐量的关注延伸至老年代，并且老年代也采用多线程回收，是对面向吞吐量特性开发的组合，如果关注吞吐量推荐使用第四种

相关参数调整：

-XX:MaxGCPauseMills  ：参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。

-XX:GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值为99，就是允许最大1%（即1/（1+99））的垃圾收集时间。

-XX:+UseAdaptiveSizePolicy 当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。

如果对于收集器运作原来不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

第五种：

执行 XX:+UseConcMarkSweepGC 如下

表示新生代使用ParNew，老年代的用CMS

收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：

1. 初始标记-短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
2. 并发标记-和用户的应用程序同时进行，进行GC RootsTracing的过程
3. 重新标记-短暂，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
4. 并发清除

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。

同时用户的线程还在运行，需要给用户线程留下运行的内存空间。

-XX:CMSInitialOccupyFraction  ，因为以上两点，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK 早期版本的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数

-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK 1.6中，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX：CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。

-XX:+UseCMSCompactAtFullCollection为了解决这个问题，CMS收集器提供了一个这个开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。

-XX：CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入FullGC时都进行碎片整理）。

第六种：

执行-XX:+UseG1GC 如下：

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

内存布局：在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

1. 新生代GC

回收Eden区和survivor区，回收后，所有eden区被清空，存在一个survivor区保存了部分数据。老年代区域会增多，因为部分新生代的对象会晋升到老年代。

1. 并发标记周期

初始标记：短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，产生一个全局停顿，都伴随有一次新生代的GC。

根区域扫描：扫描survivor区可以直接到达的老年代区域。

并发标记阶段：扫描和查找整个堆的存活对象，并标记。

重新标记：会产生全局停顿，对并发标记阶段的结果进行修正。

独占清理：会产生全局停顿，对GC回收比例进行排序，供混合收集阶段使用

并发清理：识别并清理完全空闲的区域，并发进行

1. 混合收集

对含有垃圾比例较高的Region进行回收。

G1当出现内存不足的的情况，也可能进行的FullGC回收。

G1中重要的参数：

-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。

-XX:ParallerGCThreads：设置GC的工作线程数量

 

未来的垃圾回收

ZGC通过技术手段把stw（Stop The World）的情况控制在仅有一次，就是第一次的初始标记才会发生，这样也就不难理解为什么GC停顿时间不随着堆增大而上升了，再大我也是通过并发的时间去回收了

关键技术，大家可以自行去了解

1. 有色指针（Colored Pointers）
2. 加载屏障（Load Barrier）