JVM-GC设计思路分析

傷城~ 2022-08-20 02:19 204阅读 0赞

JAVA中将内存的控制交给JVM来实现，方便了JAVA程序猿，当然牺牲了一部分效率，不过总体来看是值得的。那么JVM中是如何设计GC的呢，本文从几个问题入手，然后分析了一下设计思路，如果有理解错误的地方，请批评指正！主要参考了《深入理解JAVA虚拟机》这本书，图是盗来的，图的内容和书上一样。

在JVM的内存模型中，堆内存是JAVA内存区域中最大的一部分，GC主要就是发生在堆中，用来回收那些无用的对象。这样直接就引申出了第一个问题：什么样的对象需要被回收？判断条件是什么？如何判断？

先谈谈什么对象需要被回收，OK，我们自己想一想，肯定是没用的对象需要被回收，对吧？那么如何判断哪些对象还有用，哪些没用了呢？一个对象被创建，如果被引用了，那这个对象肯定是有用的对吧，如果引用全失效了，那就是没用的对象了，需要被回收。基于这个思想，引用计数法诞生了。

*  引用计数算法：这个非常容易理解，给每个对象添加一个引用计数器，对象每被引用一次，引用计数器就+1，引用失效时就-1。那么判断一个对象是否有用的条件就变成了对这个计数器值得判断了，如果为0，那么被回收，如果为>0，那么保留。但是这种方式会产生一个问题，就是对象之间的循环引用无法被识别，即使这两个对象不能被访问，但是它们之间互相引用着对方，故而计数器肯定>0，那么就不能被回收。JVM中并没有使用引用计数算法，而是使用了根搜索算法。
 *  根搜索算法：这个算法也不难理解，通过条件，选择一系列的对象成为“GC Roots"对象，然后将”GC Roots"对象作为起始点开始向下搜索，搜索所有走过的路径成为“引用链”。在这个引用链上的对象就保留，而如果一个或多个互相引用的对象不在这个引用链上，或者说对象到“GC Roots"不可达，那么这些就是无用的对象，都需要被回收。

![20160125231332483][]

注：Java语言中，可作为GC Roots的对象包括下面几种：

1) 虚拟机栈(栈帧中的本地变量表)中引用的对象

2) 方法区中类静态属性引用的对象

3) 方法区中常量引用的对象

4) 本地方法栈中JNI(即一般说的Native方法)引用的对象

既然根搜索算法需要考虑到对象之间的引用，那么就要说一下JAVA中对象的引用类型了：

从JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用，这四种引用的强度依次减弱

1) 强引用就是指在程序代码之中普遍存在的，类似 “Object obj = new Object()” 这类的引用，只要强引用还存在，垃圾回收器永远不会回收被引用的对象。我们也正是利用这个原理来重现了OOM异常。

2) 软引用（SoftReference类）是用来描述一些还有用但并非需要的对象，对于软引用关联着的对象，在系统将要发生内存异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存异常

3) 弱引用（WeakReference类）也是用来描述非必需对象的，被弱引用关联的对象只能生存到下一次GC发生之前，当垃圾收集器工作时，无论当前内存释放足够，都会回收掉只被弱引用关联的对象

4) 虚引用（PhantomReference类）也称为幽灵引用或者幻影引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例，对一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

那么上述内容看完之后想必都知道了什么样的对象会被GC了吧，那么JVM又是通过什么方式来回收这些内存的呢？下面就需要了解一下垃圾的回收算法了。

*  标记-清除算法
    
        试着想一想，如果要你要设计一个算法清除满足收集条件的对象来释放内存的时候你该怎么做呢？最简单的是不是就是把需要回收的对象标记一下，然后直接全部回收就行了？照着这个思路就是”标记-清除算法”的思想了，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。想法很简单，实际也就是这么做的。但是呢，这种方式是不是最好的？有什么缺陷？

想到这里，就需要分析一下了。一个个的标记然后清除，效率高吗？当然不。看看下图的标记-清除算法的示意图，可以发现，标记-清除之后会产生大量的内存碎片，如果碎片太多，当程序运行没有足够连续的内存空间来存放大对象的时候，就会不得不提前触发一次GC。概括来说就是有两个缺点：效率不高；内存碎片可能导致提前发生GC。

学习算法的童鞋应该都很清楚，效率是很重要的，有时候需要使用空间来换时间提高效率，那么就需要了解一下第二种回收算法了——复制算法。

![20160125231804396][]

*  复制算法

复制算法呢？它的思想就是空间换时间，将内存容量划分成相等的两块，当这一块的内存用完了，就将还存活的内存复制到另一块上，然后再把使用过的内存空间一次性清理干净。这样每次都是对其中的一块的内存进行回收，也就不需要考虑内存碎片等复杂情况了，只需要移动堆顶指针，然后按照顺序分配即可，实现简单，运行高效。但是缺点也很明显：内存变成一半了.......下图就是复制算法的示意图：

![20160125231849211][]

我们知道，在JVM中堆内存的新生代(new )中的对象存活率较低，采用复制算法每次需要复制的对象也不是很多，效率较高，空间换时间值得的。现在的商业虚拟机都是采用复制算法来回收新生代，IBM的专门研究表明：新生代中对象98%是朝生夕死，所以并不需要按照1:1的比例来划分空间来实现复制算法，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中一个Survivor空间。当发生GC的时候，将Eden空间和Survivor空间中还存活的对象拷贝到另一个没使用的Survivor空间中，然后再清理掉Eden和刚刚使用的Survivor空间。Hotspot虚拟机默认Eden和Survivor的大小比例是8:1，也就是新生代每次可以使用的内存空间是整个新生代的90%，只有10%的空间会被浪费。

OK，通过上述的分析，我们知道了在JVM中对于新生带的垃圾回收使用的复制算法（此时发生的GC成为young gc），效率高，我们也就只牺牲了10%的内存空间，挺不错的。请注意这里提到的young gc，后面会提到full gc。但是虽然IBM研究表明一般情况下有98%的对象是朝生夕死，需要回收的，但是不能保证每次回收的时候对象的存活率都低于10%啊，是不是？一旦超过了10%，那么空闲的survivor空间就不够用了，此时就必须依赖老年代的空间来进行分配担保（就相当于A找B借钱，C替A做担保，保证如果A换不起就自己来还，C就是担保人，映射到内存中老年代所占内存就是担保人）。如果空闲的Survivor空间无法存放上次GC之后的存活对象，那么这些对象就会通过分配担保机制进入老年代。

老年代呢，里面保存的都是生存周期较长的对象（老年代里面的对象都是经过了新生代，然后多次存活下来的对象），而复制算法在应对这种存活率极高的内存区域的对象回收时，需要执行较多的复制操作，效率将会变低。关键的还是如果不想浪费50%的空间，那么就需要分配担保机制（参考新生代的设计），但是并没有额外的空间来担保了。所以对于老年代的特性，有人提出了一种“标记-整理算法”，看到这里肯定就想到了前面提到的“标记-清除算法“了，OK，这两个算法标记的过程都是一样的，就在于”标记-整理算法”不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，示意图如下图所示。

很明显，这种”标记-整理算法“的效率不高，所以如果老年代发生GC，那么效率也就不高了，并且一旦老年代发生GC，那么发生的必然是Full GC ,Full GC 会同时对老年代和新生代进行GC操作，顺便也会回收一下perm gen中的内存，所以相比较young gc来说很慢，我们在JVM调优的时候需要避免JVM频繁发生full gc。full gc的速度比young gc要慢10倍。

![20160125231909695][]

*  分代收集算法

通过上述的分析呢，就知道了对于堆中的新生代和老年代会采用不同的垃圾回收算法来回收“死亡”的对象，这种分代回收对象的方法称为“分代收集算法”。这个分代收集算法根据各个年代的特点采用适当的收集算法。在新生代中，每次GC的时候都发现大批的对象死去，只有少量存活，自然选用复制算法；而对于老年代这种存活率高、没有额外担保空间的，就必须使用“标记-清除算法”或者“标记-整理算法“了。

GC设计的理论基础就是这些了，其实原理还是比较容易理解的。GC的具体实现就是垃圾收集器，目前尚没有一个垃圾收集器是完美的，需要配合使用。下面插上一副堆内存划分图。

注：本文写的比较片面，如果想更深入了解，推荐这篇博文：http://jbutton.iteye.com/blog/1569746

![20160125231922992][]

[20160125231332483]: /images/20220731/b23e3891bfc644dba1861120b794bb0c.png
[20160125231804396]: /images/20220731/5df1c65124ed4f39956e226c07c8a77d.png
[20160125231849211]: /images/20220731/f0b0b151b14b46f2a86623df83dec393.png
[20160125231909695]: /images/20220731/2fdf864fa8564959ac6ced04294eef08.png
[20160125231922992]: /images/20220731/d4d5d2e202144ff2841043a978c55d4b.png