Java虚拟机之垃圾收集算法
写在前面
本文作为阅读了周志明作者的 <<深入理解Java虚拟机>> 的读书笔记。由于个人理解有限，本文摘抄的内容可能比较片面，强烈建议入手本书！还有比较遗憾的一件事是这部分的官方文档我不知道去哪里能够找到，毕竟作者使用的是
JDK6，而我使用的是JDK8 ；如果能够结合文档来看的话，应该能消除更多疑惑吧。但我从这篇文档中获取到了一点信息。文中的图片均参考书中的图绘制而成。
对象已死？
在收集对象之前，需要知道对象哪些对象已经不可能在被使用，这需要一点小技巧。
引用计数算法
描述：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为 0 的对象就是不可能再被使用的。
引用计数算法的实现简单，判定效率也很高，但它很难解决对象之间的相互循环引用的问题。
考虑图中这种情况，A，B 两个对象互相引用，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知 GC 收集器回收它们。
我在文章开头所提到的那篇文档中找到这样的一句话：
对象最终将成为未引用对象，并且它们所占用的存储可以被其他对象回收使用。收集器的基本操作是遍历对象图，查找所有可到达的对象并将其保存，同时识别所有不可达的对象并恢复其存储。遍历每个集合的整个对象图将是非常昂贵的，因此已采用了多种技术来使集合更有效。
我们至少能从这段话中得到的信息是，GC 是以图遍历的形式去查找所有可达对象的。
根搜索算法
描述：通过一系列的名为 “GC Roots" 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连（图论的描述就是从 GC Roots 到这个对象不可达）时，则证明此对象是不可用的。
JAVA 语言里，GC Roots 的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中的引用的对象
- 方法区中的类静态属性引用的对象
- 方法区中的常量引用的对象
- 本地方法栈中
JNI( Native 方法) 的引用的对象
方法区回收
书中详细的介绍了这一块，但值得一提的是 方法区（或者 HotSpot 虚拟机中的永久代）在 JDK 8 中已经被移除。但重新引入了一个新的本地内存区块-类元数据。
Java类在
Java Hotspot VM中具有内部表示形式，被称为类元数据。在Java Hotspot VM的早期版本中，类元数据是在所谓的永久生成中分配的。在JDK 8中，永久代已删除，并且类元数据已分配在本机内存中。默认情况下，可用于类元数据的本地内存数量是无限的。使用该选项MaxMetaspaceSize对用于类元数据的本机内存量设置上限。Java Hotspot VM显式管理用于元数据的空间。从操作系统请求空间，然后将其分成多个块。类加载器从其块分配元数据空间（块绑定到特定的类加载器）。当为类加载器卸载类时，其块将被回收以重新使用或返回给OS。元数据使用分配的空间mmap，而不是malloc。
书中有提到如何判定一个类是否是 “无用的类”，类需要同时满足下面 3 个条件才能算是 “无用的类”：
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
- 加载该类的
ClassLoader已经被回收。 - 该类对应的
java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
垃圾收集算法
垃圾收集算法的实现涉及大量的程序细节，这里仅仅介绍算法的思想。
标记-清除算法
描述：算法分为 ”标记“ 和 ”清除“（Mark-Sweep） 两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。
缺点：
-
效率问题；标记和清除过程的效率都不高；
-
空间问题：空间碎片太多，当程序需要分配较大对象时而无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
复制算法
目的：为了解决效率问题
描述：将可用内存分为大小相等的两块，每次使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
缺点：可用内存缩小为原来的一半
标记-整理算法
复制收集算法在对象存活率较高时，就要执行较多的复制操作，效率将会变低。
描述：标记过程仍然与 “标记-清除” 算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
描述：根据对象的存活周期的不同将内存划分为几块。一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。