java性能优化

时间:2022-09-27 我犟不过你人气:0

前言

我们今天一起来聊一聊关于垃圾收集的细节问题。垃圾收集是通过何种方式减少stop the world？这将是垃圾回收的重点内容。

什么是分代回收，初次接触的同学肯定是很懵的。还记得我们前面在介绍使用jvisualvm工具的时候，从它给我们反馈的视图上看到，有几个不同的数据块，且是动态的，如下图红圈的部分：

从左到右分别是：

到目前为止，市面上常见的垃圾收集器，都是按照这种分代回收的方式进行垃圾回收的，但是其内部的实现方式却有很大的差别。

本章我们的重点是老年代和年轻代。

通过上图我们发现，年轻代有三部分组成：

绝大部分的对象，它们的生命周期非常短暂，甚至绝大多数都是临时对象，垃圾收集器的设计需要适应这种情况。

我们都知道对象创建，存放在堆中，而不论是老年代还是年轻代都是堆中的一部分。

当对象被创建后，会被分配至年轻代，随着对象的增加，年轻代会被占满，此时将会停止全部的应用线程，并进行垃圾回收，没有被使用的对象会被回收，仍然被使用的对象将会被移动到其他的地方。这种操作就是MinorGC，年轻代回收。

使用分代算法的最根本原因，是为了尽量的减少垃圾回收造成的停顿，我们可以从下面两个方面考虑：

新生代是堆的一部分，仅处理一部分空间，一定比整个堆空间的时间要短，停顿时间也就短。但是我们一定会想到，停顿的频率增加了。
年轻代的空间分配方式，对性能有影响。年轻代中，eden占据大部分空间，而S0和S1平分剩余空间。对象首次创建会在Eden中，经过一次垃圾回收时，Eden被清空，未使用的对象被回收，仍然使用的对象进入Survior或老年代。Eden区的清空操作，相当于进行了一次压缩整理。

即使是年轻代的回收，仍然存在时空停顿。

前面提到，除了在Eden可能将对象移动到老年代当中，对于在Survior当中没有被回收的对象，最终也会移动到老年代当中。当老年代被占满时，会停止所有的应用线程，找到不再使用的对象进行垃圾回收。这个过程将会停顿很长时间，我们称之为Full GC。

前面的描述其实都是较为简单的垃圾收集器，在停止应用线程后去发现不再使用的对象，进行回收。

然而实际上，通过一些定制，和复杂的计算，我们可以在应用线程运行时去找到不再使用的对象。在前一篇文章一笔带过的CMS和G1收集器，就是如此。他们不需要停止应用线程就可以找到不再使用的对象，所以它们也叫做concurrent垃圾收集器。

垃圾在查找的时候将会占用很多时间，当然查找算法将是下一章节我们需要学习的内容。然而concurrent垃圾收集器可以尽可能的减少应用的停顿时间，它们也可以称为低停顿收集器。

这种垃圾收集器缩减应用的停顿时间，其代价是占用更多的CPU。即使是G1和CMS也会遇到长时间的Full GC，这将是我们需要针对实际环境调优的方向。

前面简单描述了不同垃圾收集器的垃圾收集方式，以及造成的影响。但是在我们选择垃圾收集器的过程中还是需要一定的权衡，才能使其发挥最佳的性能。

我们需要考虑的重点就是：

加载全部内容