JVM垃圾回收算法-I

一、JVM垃圾回收算法简介

　　Java语言出来之前，大家都在拼命的写C或者C++的程序，而此时存在一个很大的矛盾，C++等语言创建对象要不断的去开辟空间，不用的时候有需要不断的去释放空间，既要写构造函数，又要写析构函数，很多时候都在重复的allocated，然后不停的~析构。于是，有人就提出，能不能写一段程序在实现这块功能，每次创建，释放空间的时候复用这段代码，而无需重复的书写呢？
　　1960年 基于MIT的Lisp首先提出了垃圾回收的概念，用于处理C语言等不停的析构操作，而这时Java还没有出世呢！所以实际上GC并不是Java的专利，GC的历史远远大于Java的历史！
　　由于垃圾收集算法的实现涉及大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此本文不打算过多地讨论算法的实现，只是介绍几种算法的思想及其发展过程。

二、 标记-清除算法

　　首先，我们得知道根搜索算法，它可以解决我们应该回收哪些对象的问题，但是它显然还不能承担垃圾搜集的重任，因为我们在程序（程序也就是指我们运行在JVM上的JAVA程序）运行期间如果想进行垃圾回收，就必须让GC线程与程序当中的线程互相配合，才能在不影响程序运行的前提下，顺利的将垃圾进行回收。
　　为了达到这个目的，标记/清除算法就应运而生了。它的做法是当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。
　　
　　下面LZ具体解释一下标记和清除分别都会做些什么。
　　标记：标记的过程其实就是，遍历所有的GC Roots，然后将所有GC Roots可达的对象标记为存活的对象。
　　清除：清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。
　　其实这两个步骤并不是特别复杂，也很容易理解。用通俗的话解释一下标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。
　　下面我给各位制作了一组描述上面过程的图片，结合着图片，我们来直观的看下这一过程，首先是第一张图。

　　可以看到，按照根搜索算法，所有从root对象可达的对象就被标记为了存活的对象，此时已经完成了第一阶段标记。接下来，就要执行第二阶段清除了，那么清除完以后，剩下的对象以及对象的状态如下图所示。
可以看到，没有被标记的对象将会回收清除掉，而被标记的对象将会留下，并且会将标记位重新归0。接下来就不用说了，唤醒停止的程序线程，让程序继续运行即可。

　　其实这一过程并不复杂，甚至可以说非常简单，各位说对吗？不过其中有一点值得我一提，就是为什么非要停止程序的运行呢？
　　这个其实也不难理解，我举个最简单的例子，假设我们的程序与GC线程是一起运行的，各位试想这样一种场景。
　　假设我们刚标记完图中最右边的那个对象，暂且记为A，结果此时在程序当中又new了一个新对象B，且A对象可以到达B对象。但是由于此时A对象已经标记结束，B对象此时的标记位依然是0，因为它错过了标记阶段。因此当接下来轮到清除阶段的时候，新对象B将会被苦逼的清除掉。如此一来，不难想象结果，GC线程将会导致程序无法正常工作。
　　上面的结果当然令人无法接受，我们刚new了一个对象，结果经过一次GC，忽然变成null了，这还怎么玩耍？
　　
　　到此为止，标记/清除算法LZ已经介绍完了，下面我们来看下它的缺点，其实了解完它的算法原理，它的缺点就很好理解了。
　　1、首先，它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲，尤其对于交互式的应用程序来说简直是无法接受。试想一下，如果你玩一个网站，这个网站一个小时就挂五分钟，你还玩吗？
　　2、其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

三、 复制算法

我们首先一起来看一下复制算法的做法，复制算法将内存划分为两个区间，在任意时间点，所有动态分配的对象都只能分配在其中一个区间（称为活动区间），而另外一个区间（称为空闲区间）则是空闲的。
　　当有效内存空间耗尽时，JVM将暂停程序运行，开启复制算法GC线程。接下来GC线程会将活动区间内的存活对象，全部复制到空闲区间，且严格按照内存地址依次排列，与此同时，GC线程将更新存活对象的内存引用地址指向新的内存地址。
此时，空闲区间已经与活动区间交换，而垃圾对象现在已经全部留在了原来的活动区间，也就是现在的空闲区间。事实上，在活动区间转换为空间区间的同时，垃圾对象已经被一次性全部回收。
听起来复杂吗？
　　其实一点也不复杂，有了上一篇文章的基础，相信各位理解这个算法不会费太多力气。给各位绘制一幅图来说明问题，如下所示。

　其实这个图依然是上一篇文章的例子，只不过此时内存被复制算法分成了两部分，下面我们看下当复制算法的GC线程处理之后，两个区域会变成什么样子，如下所示。
　
　可以看到，1和4号对象被清除了，而2、3、5、6号对象则是规则的排列在刚才的空闲区间，也就是现在的活动区间之内。此时左半部分已经变成了空闲区间，不难想象，在下一次GC之后，左边将会再次变成活动区间。
　　很明显，复制算法弥补了标记/清除算法中，内存布局混乱的缺点。不过与此同时，它的缺点也是相当明显的。
　　1、它浪费了一半的内存，这太要命了。
　　2、如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。
　　所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。

四、 标记-清除算法

　标记/整理算法与标记/清除算法非常相似，它也是分为两个阶段：标记和整理。下面LZ给各位介绍一下这两个阶段都做了什么。
　　标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历GC Roots，然后将存活的对象标记。
　　整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。
　　它GC前后的图示与复制算法的图非常相似，只不过没有了活动区间和空闲区间的区别，而过程又与标记/清除算法非常相似，我们来看GC前内存中对象的状态与布局，如下图所示。
　　
　　　这张图其实与标记/清楚算法一模一样，只是LZ为了方便表示内存规则的连续排列，加了一个矩形表示内存区域。倘若此时GC线程开始工作，那么紧接着开始的就是标记阶段了。此阶段与标记/清除算法的标记阶段是一样一样的，我们看标记阶段过后对象的状态，如下图。
　　　
　　　　没什么可解释的，接下来，便应该是整理阶段了。我们来看当整理阶段处理完以后，内存的布局是如何的，如下图。
　　　　
　　　　可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
　　不难看出，标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价，可谓是一举两得，一箭双雕，一石两鸟啊！
　　不过任何算法都会有其缺点，标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。

五、 算法总结

这里博主给各位总结一下三个算法的共同点以及它们各自的优势劣势，让各位对比一下，想必会更加清晰。
　　它们的共同点主要有以下两点：
　　1、三个算法都基于根搜索算法去判断一个对象是否应该被回收，而支撑根搜索算法可以正常工作的理论依据，就是语法中变量作用域的相关内容。因此，要想防止内存泄露，最根本的办法就是掌握好变量作用域。
　　2、在GC线程开启时，或者说GC过程开始时，它们都要暂停应用程序（stop the world）。
　　它们的区别，我按照下面几点来给各位展示。（>表示前者要优于后者，=表示两者效果一样）
　　效率：复制算法>标记/整理算法>标记/清除算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
　　内存整齐度：复制算法=标记/整理算法>标记/清除算法。
　　内存利用率：标记/整理算法=标记/清除算法>复制算法。
　　
　　可以看到标记/清除算法是比较落后的算法了，但是后两种算法却是在此基础上建立的，俗话说“吃水不忘挖井人”，因此各位也莫要忘记了标记/清除这一算法前辈。而且，在某些时候，标记/清除也会有用武之地。