JVM - 垃圾回收机制

JVM的垃圾回收机制(简称GC)

        JVM的垃圾回收机制非常强大，是JVM的一个很重要的功能，而且这也是跟对象实例息息相关的，如果对象实例不用了要怎么清除呢？

如何判断对象已经没用了

当JVM认为一个对像已经没用了，就会把这个对象判定为是垃圾，就会去回收它的空间，有两个方法判断一个对像是否已经没用了

1、引用计数法：记录指向该对象的引用数，当该数值为零时就将该对象判定为垃圾

这个方法实现简单，判定效率也高，不过它有个致命的问题，它无法解决相互对象之间相互循环引用的问题，看下面这个例子

​
public class Test {
	public Object object = null;
	public static void main(String[] args) {
		Test a = new Test();//对象1
		Test b = new Test();//对象2
		
		a.object = b;
		b.object = a;

		a = null;
		b = null;
	}
}

​

此时对象1和对象2除了对方指向自己的引用外，没有其他的引用了，这个时候，无论是对象1还是对象2，我们认为都已经没用了，因为程序是找不到它俩的，但是引用计数法无法将它们判定为垃圾，因为它们的被引用数不是为零

正是因为这个缺点，主流的java虚拟机都不会使用该判定方法

2、可达性分析：

选定一些满足特定条件的对象作为根对象（GC Roots），那些与跟对象存在直接或间接引用关系的就是有用的对象，而与根对象没有任何关联的对象，就是垃圾对象（如下图）

可达性分析是当今主流的判定机制

GC的分类

Minor GC是新生代GC，指的是发生在新生代的垃圾收集动作。由于java对象大都是朝生夕死的，所以Minor GC非常频繁，一般回收速度也比较快。

Major GC是老年代GC，指的是发生在老年代的GC，通常执行Major GC会连着Minor GC一起执行。Major GC的速度要比Minor GC慢的多。

Full GC是清理整个堆空间，包括年轻代和老年代（Minor GC和Major GC一起执行就是Full GC）

GC和分代的关系

那么现在我们就知道了为什么要分代了：

对象实例一般会首先分配到新生代当中，当新生代当中的空间不够用的时候，就会触发Minor GC，这个时候就会有一些没用的对象实例被清除掉，而有些就会留下来，那些能够挺过一定次数Minor GC的对象，最后就会进入到老年代当中，如果老年代中的空间也不够用了，那么就会进行Major GC

回收算法

我们上面说到GC会对垃圾进行回收，那具体要这么回收呢？这个就是回收算法，目前有三种回收算法，分别是：标记-清除、标记-复制、标记-整理

标记-清除

看下面的示意图，这个代表堆中的某块空间（可以是年轻代或老年代），每个紫色方块就是一个对象，上面我们说，JVM的对象是否存活的判定方法是可达性分析，所有那些没被GC Root引用的就要给标记成垃圾对象，标记完后再统一进行回收，这会造成内存空间碎片化的问题

 

标记-复制

将堆区分为两块区域，先只在其中一块区域创建对象，垃圾回收的时候，先标记出那些不要被回收的对象，然后将其复制到另外一块区域中，然后清空原本那块区域，新生代使用的就是标记-复制算法，新生代分为一块较大的Eden空间和两块较小的 Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。这里存在一个问题，当存活的对象的总大小大于那块Survivor空间，那就会造成溢出，而那些溢出的对象，会直接进入老年代，这叫分配担保

 标记-整理

标记-复制算法存在需要额外空间进行分配担保的问题，新生代有老年代做分配担保，那老年代没人做分配担保就没办法使用标记-整理算法，要使用标记-整理算法，同样是先进行标记，不过不马上进行回收，而是让所有的存活对象都向内存空间一端移动，然后直接清理掉边界以外的堆空间

标记-整理存在一个弊端，在整理的过程中，必须全程暂停用户应用程序，这个被形象地称为“Stop The World”，实际上只要对象的存储地址发生了改变，就会“Stop The World”，所以标记-复制算法也会“Stop The World”

 

垃圾收集器

垃圾回收算法是理论层面，真正的垃圾回收执行者是垃圾收集器，关于垃圾收集器我整理了另外一篇博客，地址：http://t.csdn.cn/2ypGh