GC垃圾回收原理

GC垃圾回收原理

2.1 如何判断对象是垃圾 ? 

有二种经典的判断方法，借用网友的图(文中最后有给出链接)：

引用计数法，思路很简单，但是如果出现循环引用，即：A引用B，B又引用A，这种情况下就不好办了，所以JVM中使用了另一种称为“可达性分析”的判断方法：

还是刚才的循环引用问题（也是某些公司面试官可能会问到的问题)，如果A引用B，B又引用A，这2个对象是否能被GC回收？ 答案：关键不是在于A,B之间是否有引用，而是A,B是否可以一直向上追溯到GC Roots。如果与GC Roots没有关联，则会被回收，否则将继续存活。

上图是一个用“可达性分析”标记垃圾对象的示例图，灰色的对象表示不可达对象，将等待回收。

 

2.2 哪些内存区域需要GC ?

在第一部分JVM内存布局中，我们知道了thread独享的区域：PC Regiester、JVM Stack、Native Method Stack，其生命周期都与线程相同（即：与线程共生死），所以无需GC。线程共享的Heap区、Method Area则是GC关注的重点对象。

 

2.3 常用的GC算法：

a. mark-sweep 标记清除法

如上图，黑色区域表示待清理的垃圾对象，标记出来后直接清空。该方法很简单快速，但是缺点也很明显，会产生很多内存碎片。

 

b. mark-copy 标记复制法

思路也很简单，将内存对半分，总是保留一块空着（上图中的右侧），将左侧存活的对象(浅灰色区域)复制到右侧，然后左侧全部清空。避免了内存碎片问题，但是内存浪费很严重，相当于只能使用50%的内存。

 

c. mark-compact 标记-整理(也称标记-压缩)法

避免了上述二种算法的缺点，将垃圾对象清理掉后，同时将剩下的存活对象进行整理挪动（类似于windows的磁盘碎片整理），保证它们占用的空间连续，这样就避免了内存碎片问题，但是整理过程也会降低GC的效率。

 

d. generation-collect 分代收集算法

上述三种算法，每种都有各自的优缺点，都不完美。在现代JVM中，往往是综合使用的，经过大量实际分析，发现内存中的对象，大致可以分为二类：有些生命周期很短，比如一些局部变量/临时对象，而另一些则会存活很久（典型的，比如websocket长连接中的connection对象)，如下图：

纵向y轴可以理解分配内存的字节数，横向x轴理解为随着时间流逝(伴随着GC），可以发现大部分对象其实相当短命，很少有对象能在GC后活下来。因此诞生了分代的思想，以Hotspot为例(JDK 7)：

将内存分成了三大块： 年青代(Young Genaration），老年代(Old Generation）,永久代(Permanent Generation），其中Young Genaration更是又细为分eden，S0, S1三个区。

结合我们经常使用的一些jvm调优参数后，一些参数能影响的各区域内存大小值，示意图如下：

注：jdk8开始，用MetaSpace区取代了Perm区(永久代)，所以相应的jvm参数变成-XX:MetaspaceSize 及 -XX:MaxMetaspaceSize 

以Hotspot为例，我们来分析下GC的主要过程：

刚开始时，对象分配在eden区，s0(即:from)及s1(即:to)区，几乎是空着

随着应用的运行，越来越多的对象被分配到eden区

当eden区放不下时，就会发生minor GC(也被称为young GC)，第1步当然是要先标识出不可达垃圾对象(即：下图中的黄色块)，然后将可达对象，移动到s0区(即：4个淡蓝色的方块挪到s0区)，然后将黄色的垃圾块清理掉，这一轮过后，eden区就成空的了。--注：这里其实已经综合运用了“【标记-清理eden】 + 【标记-复制 eden->s0】”算法。

随着时间推移，eden如果又满了，再次触发minor GC，同样还是先做标记，这时eden和s0区可能都有垃圾对象了(下图中的黄色块)，注意：这时s1(即：to）区是空的，s0区和eden区的存活对象，将直接搬到s1区。然后将eden和s0区的垃圾清理掉，这一轮minor GC后，eden和s0区就变成了空的了。

继续，随着对象的不断分配，eden空可能又满了，这时会重复刚才的minor GC过程，不过要注意的是，这时候s0是空的，所以s0与s1的角色其实会互换，即：存活的对象，会从eden和s1区，向s0区移动。然后再把eden和s1区中的垃圾清除，这一轮完成后，eden与s1区变成空的。（如下图）

对于那些比较“长寿”的对象一直在s0与s1中挪来挪去，一来很占地方，而且也会造成一定开销，降低gc效率，于是有了“代龄(age)”及“晋升”，对象在年青代的3个区(edge,s0,s1)之间，每次从1个区移到另1区，年龄+1，在young区达到一定的年龄阈值后，将晋升到老年代（下图中是8，即：挪动8次后，如果还活着，下次minor GC时，将移动到Tenured区）

 

注意：长期存活的对象将进入老年代，默认15岁，-XX:MaxTenuringThreshold调整

动态对象年龄判定，为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

 

下图是晋升的主要过程：对象先分配在年青代，经过多次Young GC后，如果对象还活着，晋升到老年代。

 

如果老年代，最终也放满了，就会发生major GC(即Full GC)，由于老年代的的对象通常会比较多，因为标记-清理-整理(压缩)的耗时通常会比较长，会让应用出现卡顿的现象，这也是为什么很多应用要优化，尽量避免或减少Full GC的原因。

 注：上面的过程主要来自oracle官网的资料，但是有一个细节官网没有提到，如果分配的新对象比较大，eden区放不下，但是old区可以放下时，会直接分配到old区（即没有晋升这一过程，直接到老年代了）。