Garbage Collection

男娘i 2022-09-28 11:39 4阅读 0赞

JVM的自动垃圾收集（Garbage Collection）使得开发人员无需关注垃圾收集的细节，不过，当内存问题成为系统瓶颈的时候，我们就需要了解一下JVM的垃圾收集机制了。

应用程序中生成的对象绝大部分都是临时对象，属于那种生的快死的快的，来也匆匆，去也匆匆，当然也有伴随应用程序的生命周期而存在的对象，鉴于对象 的生命周期的不同，JVM的内存是分代（Generation）管理的。如果把JVM看作一个战场，把各个对象看作士兵，那么大部分的士兵刚投入战场不久 就英勇就义，只有少部分的士兵能够在战场中摸爬滚打能够坚持一段时间。（史上最残忍的战场，阿弥陀佛，善哉！善哉！）。分代情况如下图所示：

![0_130101606457E9.gif][]

其中，**年轻代（Young Generation）** 包含伊甸园（Eden）和2段幸存者空间（Survivor Spaces），伊甸园当然是新生对象的乐园（只在乎曾经拥有，不在乎天长地久。也许看作前线战场更为合适：）（也有部分大对象直接分配在年老代）。而幸 存者空间是用来保存上次GC之后依然存活的对象，经过战事的洗礼，能够存活下来实属不易，说明你是一个优秀的士兵，特此晋升一下，并且分配给你一间前线作 战指挥所。2段空间保持其中一个为空，后面再详细说明缘由和作用。

**年老代（Tunured Generation）** 中存放的是那些从幸存者空间经过多次GC依然存活的对象，他们是由年轻的军官经过许多战事的磨砺而来，已经成为老一辈的无产阶级革命家。

**永久代（Permanent Generation）** 是保存VM描述对象的数据，比如类定义，方法定义的信息。这里属于战争的大后方。

当一个对象不再被引用时，该对象就是一个不可达的对象，dead的了，战死沙场了，就成为garbage了（汗一个）。GC就是通过一定的[算法][Link 1]，判 断一个对象可达与否，通常是遍历所有可达的对象，剩下的对象就是认为是garbage，然后销毁这些garbage，释放内存。

既然内存是分代管理的，GC也就自然而然是分代收集的。

由于年轻代进进出出的人多而频繁，所以年轻代的GC也就频繁一点，但涉及范围也就年轻代这点弹丸之地内的对象，其特点就是少量，多次，但快速，称之为**minor collection** 。 当年轻代的内存使用达到一定的阀值时，minor collection就被触发，Eden及某一Survior space（from space）之内存活的的对象被移到另一个空的Survior space（to space）中，然后from space和to space角色对调。当一个对象在两个survivor space之间移动过一定次数（达到预设的阀值）时，它就足够old了，够资格呆在年老代了。当然，如果survivor space比较小不足以容下所有live objects时，部分live objects也会直接晋升到年老代。

Survior spaces可以看作是Eden和年老代之间的缓冲，通过该缓冲可以检验一个对象生命周期是否足够的长，因为某些对象虽然逃过了一次minor collection，并不能说明其生命周期足够长，说不定在下一次minor collection之前就挂了。给一个士兵晋升是要有一定的考察期的:)。这样一定程度上确保了进入年老代的对象是货真价实的，减少了年老代空间使用的 增长速度，也就降低年老代GC的频率。

当年老代或者永久代的内存使用达到一定阀值时，一次基于所有代的GC就触发了，其特定是涉及范围广（量大），耗费的时间相对较长（较慢），但是频率比较低（次数少），称之为**major collection** (**full collection** )。通常，首先使用针对年轻代的GC算法进行年轻代的GC，然后使用针对年老代的GC算法对年老代和永久代进行GC。

常用的garbage collectors：

*  ***serial collector** *：针对young generation的串行垃圾收集器，使用stop-the-world（就是暂停整个应用程序的执行）的形式，利用单线程通过复制live objects到survivor space或tenured generation的方法来进行垃圾收集。
 *  ***parallel scavenge collector** *：针对young generation的并行垃圾收集器，利用多个GC线程来进行垃圾收集，每个线程的GC方法和serial collector一样。
 *  ***parallel  new collector** *：针对young generation的增强的并行垃圾收集器，以便可以和CMS一起使用。
 *  ***serial old collector** *：针对tenured generation的串行垃圾收集器，使用stop-the-world形式，利用单线程通过mark-sweep-compact的方法进行垃圾收集。
 *  ***parallel old collector** *：针对tenured generation的并行垃圾收集器，利用多线程进行垃圾收集，方法和serial old collector一样。
 *  ***parallel compacting collector** *：对于young generation使用和parallel new collector一样的算法，对于tenured generation使用了新的算法（mark-summary-compact），该收集器用来替代parallel new collector和parallel old collector。
 *  ***concurrent mark-sweep collector** *：对于young generation使用和parallel new collector一样的算法，对于tenured generation使用跟应用程序并发的方式，收集期间也有引起stop-the-world的暂停Mark阶段，也有伴随着应用程序运行的并发 Mark和并发Sweep阶段，降低了应用程序暂停的时间。

可以看出这些垃圾收集器分为3种类型：串行，并行，并发；串行的就是单线程的，并行的就是多线程的，串行并行都是stop-the-world的，而并发是多线程的，但不完全是stop-the-world。

**算法：**

纵观垃圾收集器的算法思想，不外乎标记（Mark）、清扫（Sweep）、复制（Copy）、压缩（Compact）等几个基本的步骤。通过这篇文章总结一下目前所了解到的GC的一些基本算法。

**引用计数（Reference Counting）**

每个对象都有一个计数器，记录了指向该对象的引用数目。当创建了一个指向该对象的引用时，该对象的引用计数+1，反之，当该对象的某一个引用销毁时，引用计数-1。当对象的引用计数为0时，回收该对象占用的内存。

但是当存在循环引用时，就会出现漏网之鱼。因为循环引用内的对象的引用计数都不为0，如果从循环外面不可达，那么他们应该也是dead objects。

**标记（Marking）**

标记所有live objects（没标记的就是dead objects），标记过后就可以清扫heap，回收dead objects。

初始化一个root set作为开始标记的集合，root set包含全局变量，当前被调用方法的局部变量和参数等等；

对root set内的每一个对象进行标记。

标记时先检查该对象是否已经标记为live，如果已标记则返回；如果没有标记则标记为live。

然后对该对象所引用的所有对象递归调用上述标记过程。

伪代码如下：

foreach object in rootSet\{

mark(object);

void mark(obj) \{

if(isLive(obj)) \{

return;

setLive(obj);

foreach object in referencesFrom(obj)\{

mark(object);

**清扫（Sweep）**

遍历堆中的对象，如果标记为live的，则清除标记，否则回收该对象占用的内存。

foreach object in heap\{

if(isLive(object)) \{

unmark(object);

\} else \{

free(object);

**三色标记（Tri-colour marking）**

三色标记算法分为四步：

1.创建三种集合，表示不同类型的对象集合，分别称为white set，grey set，black set。white set是进行内存回收的候选对象集

合，black set是没有引用white set中对象的对象集合，剩下的对象属于grey set，它们可能引用了white set中的对象，也可能没有引用white set中的对象。

2.从grey set中取出一个对象，将其直接引用的white set中的对象标记为grey（相当于移到了grey set中），将该对象标记为black（相当于移至black set中）。

3.重复2直至grey set为空。

4.当grey set为空时，所有white set中的对象就是不可达的对象，释放其占用的内存空间。

**复制（Copying）**

复制算法中堆分为old space和new space，对于old space中标记为live的对象，将其复制到new space，并在旧的对象中保存新对象的地址，然后遍历new space中的对象，将该对象中的引用指向其引用对象的新地址。

**压缩（Compacting）**

压缩算法将所有的live objects移至heap的一端，对于每一个live object，首先计算它在heap中的新地址，再将所有对该对象的引用指向新的地址，然后将该对象移至新的地址。

当然，垃圾收集器也在不断的改进中，这其中会改进现有算法，添加新的算法。

比如压缩算法中，如果在heap的底端附近有很小的dead object，按照简单的压缩算法，就可能会为了达到压缩的目的，而移动后面很多的live object，这样做显然是不值得的。所以，一个改进就是直接跳过。

再比如有些垃圾收集器运行过程中可能会进行多次对象的遍历，这就延长的垃圾收集的时间，所以如果在一两次遍历之中顺便汇总一下以后需要的信息，以避免在后续的处理中再次遍历heap。

在[Java SE][] 6 update 14中引入了一种新的垃圾收集器G1(Garbage First)，目前是体验版，据说在[Java ][Java]SE 7中会成为正式成员。

G1的目标是多线程并行收集，和应用程序并发进行，分代的，可压缩的，时间可预测的。

其中并行和并发，压缩都有前辈实现过。分代的实现跟以往不一样，年轻代和年老代不再明确划分，heap被分为很多区域（region），G1动态选 择垃圾多的区域作为下次GC的年轻代。对于可预测性，G1会通过预测GC时间来选测适量的区域进行GC，以便达到预期的GC时间设置。

**性能调整：**

GC的性能调整实在是一个很高深的问题，不仅需要对GC技术广度的了解，更需要深度的理解。我本人也仅仅实践过屈指可数的几次，如果要我来说一些指 导性的方案的话，也只怕是误人子弟。作此文章，权当是对自己所了解到的GC性能调整的总结，一方面做备忘之用，一方面作为需要之人的参考。

首先要说的是大部分情况下并不需要去做GC调整，除非出现内存溢出导致应用程序崩溃，或者应用程序由于GC暂停时间太长导致不好的用户体验，或者有其他的性能要求。

要进行性能调整，不妨先了解一下几个衡量GC性能的标准：

*  Throughput：吞吐量，非GC时间（近似于应用程序执行时间）占总时间的比例，吞吐量越高说明花费在GC上的时间越少，系统的使用的效率越高；
 *  Garbage collection overahead：GC开销，GC时间占总时间比例，和吞吐量互补；
 *  Pause time：暂停时间，在GC时应用程序暂停执行的时间；
 *  Frequency of collection：GC频率；
 *  Footprint：这个概念我还没完全理解，官方说是“a measure of size, such as heap size.” 我的理解是，GC时所要遍历的内存空间的大小。footprint越小一定程度上说明GC性能越高；
 *  Promptness：灵敏度，表示从对象成为垃圾到该对象占用的内存被释放之间的时间，灵敏度越高（时间间隔越小）说明垃圾能够尽早的被收集，但同时也可能GC频率越高，需要权衡考虑。

满足一定的标准是我们做GC调整的最终目标，可以看出前3个测量标准是一致的，都属于GC暂停时间一类，这也是大部分GC调整所关心的测量标准。

为了能够观察到GC的执行情况，可以使用下面[Java][Java SE] options

*  \-Xloggc:log/gc.log 打印GC信息到指定文件
 *  \-XX:+PrintGCDetails 打印更详细的GC信息
 *  \-XX:+PrintGCTimeStamps 打印GC时间戳，相对于应用程序启动的时间。

我觉得GC性能调整可以分为三个阶段：堆和代大小的调整、垃圾收集器的选择、进阶调整。

**堆和代大小的调整**

我们在调试应用程序时经常会出现OutOfMemory：PermGen space之类的错误，这就是因为服务器永久代设置太小引起的，通常通过增加永久代大小就可以减少甚至避免这类情况的出现。堆和代大小的调整可以通过下面一些参数来设置：

*  –Xms*n* heap的初始大小；
 *  –Xmx*n* heap的最大尺寸；
 *  –XX:NewSize=*n* 年轻代（Young Generation）的初始大小；
 *  –XX:NewRatio=*n* 表示年轻代和年老代的比率，例如n=3，表示年轻代大小和年老代大小之比是1:3；
 *  –XX:SurvivorRatio=*n* 表示survivor和eden空间的比率，如果n=8，表示每个survivor空间大小是年轻代的1/10，因为有2个survivor空间；
 *  \-XX:PermSize=*n *永久代（Permenent Generation）的初始大小；
 *  –XX:MaxPermSize=*n* 永久代的最大尺寸。

通过增加堆和代的大小可以减少GC的频率，但同时也会增加每次GC的时间及footprint。所以堆和代的大小不是越大越好（GC的性能调整会遇 到很多需要权衡利弊考虑的情况，需要找出折中方案）。具体方法可以通过模拟[测试][Link 2]并观察gc log里的记录来设置，如果年轻代设置的太小，那么年轻代的GC就会很频繁，通过适当增加年轻代的大小，减少GC的频率。由于堆或代大小的扩展都会引起性 能的降低，所以设置一个合适的堆和代的初始大小，可以避免频繁的扩展，而这个合适的大小也可以通过gc log里的数据来推算，根据模拟测试中系统处于稳定时期的内存占用情况来设置。

**垃圾收集器的选择**

不同的垃圾收集器可以使用下面的参数来选择：

*  –XX:+UseSerialGC
 *  –XX:+UseParallelGC
 *  –XX:+UseParallelOldGC
 *  –XX:+UseConcMarkSweepGC

如果程序运行在单CPU的机器上，没有多少性能要求，那就是用SerialGC;如果运行在多CPU的机器上，那就不妨使用Parallel和 ParallelOld来减少stop-the-world时间。利用多线程进行gc可以缩短gc时间，提高系统的吞吐量和相应速度。

**进阶调整**

除了上面的参数外，还可以通过一些参数来调整GC的行为。

*  \-XX:MaxTenuringThreshold=n 通过该参数可以设置存活对象在survivor spaces之间复制的次数，超过这个次数，对象就被移到tenured generation。通过这个参数可以保持tenured space的稳定性，避免一些寿命不是很长的对象占据该空间（当然，也可以适当增加young generation的大小，尽量让寿命不长的对象die在young generation）；
 *  \-XX:MaxHeapFreeRatio=70，-XX:MinHeapFreeRatio=40 设置堆的最大/最小空闲空间的比例，70%，40%是默认值，可以避免堆空间频繁的伸缩；
 *  \-XX:+UseCMSCompactAtFullCollection，-XX:CMSFullGCsBeforeCompaction=n 在 使用–XX:+UseConcMarkSweepGC时有引起一定的内存碎片问题，可以通过UseCMSCompactAtFullCollection 在full gc之后进行压缩，CMSFullGCsBeforeCompaction=n表示，在进行n次full gc之后进行压缩，因为开始的一两次full gc引起的内存碎片可能并不是很多，这样可以减少压缩次数，提高gc效率。

当然，还有其他参数，这里只是比较常用的一部分。要想真正搞懂GC，实践是必不可少的，实践出真知，多多分析gc log，不断调整，才能理解如何进行GC性能的调整。

对于应用程序的性能来说，GC的调整是一部分，而代码的质量也是很重要的一部分，代码质量的高，就可以避免不必要的GC调整。比如减少不必要的对象 的创建，能在循环外new的对象放在循环外new，对象保存的上下文保持最小范围原则，在显示批量数据时不必要的字段信息不要获取，等等。在保证代码质量 的基础上，如果出现性能问题，再进行GC调整

[0_130101606457E9.gif]: /images/20220708/71454230c49e4c5c9c175f91945b0a1a.png
[Link 1]: http://lib.csdn.net/base/datastructure
[Java SE]: http://lib.csdn.net/base/javase
[Java]: http://lib.csdn.net/base/java
[Link 2]: http://lib.csdn.net/base/softwaretest