JVM垃圾回收

在Java中，我们程序员是不需要手动释放一些无用的内存的，而是由虚拟机自行执行。这在一定程度上确保了内存泄露的发生，给我们提供了一个更加安全的环境，接下来我们就来认识一下JVM的垃圾回收机制。

#GC

GC 名为垃圾收集器（Gabage Collection),当我们创建一个对象时JVM所提供的GC就会开始对这个对象的监测，通常，GC采用有向图的方式记录和管理堆(heap)中的所有对象。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的"。当GC确定一些对象为"不可达"时，GC就有责任回收这些内存空间。

#判断一个对象是否能被回收

既然要回收对象，那么我们就需要来判断一个对象是否可以被JVM回收，通常用来判断的方法有两个。

1.引用计数法

引用计数描述的算法为: 给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任 何时刻计数器为0的对象就是不能再被使用的，即对象已"死"。 引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个不错的算法。比如Python语言就采 用引用计数法进行内存管理。 但是，在主流的JVM中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题。

循环引用问题

public class Test {
 public Object instance = null;
 private static int _1MB = 1024 * 1024;
 private byte[] bigSize = new byte[2 * _1MB];
 public static void testGC() {
 Test test1 = new Test();
 Test test2 = new Test();
 test1.instance = test2;
 test2.instance = test1;
 test1 = null;
 test2 = null;
 // 强制jvm进行垃圾回收
 System.gc();
 }
 public static void main(String[] args) {
 testGC();
 }
}

在上述代码中，我们分别在test1和test2对象中的instance变量中分别引用对方，之后我们将test1与test2置空，意味着此时我们应该回收它们，但是这两个对象依旧被互相引用，它们互相的引用计数都为1，也就是说如果要回收test1就要先回收test2，要回收test2就要先回收test1，这样就进入了一个死循环，就好比我们线程的死锁。一下是代码的执行结果：

[GC (System.gc())  6092K->856K(125952K), 0.0007504 secs] 

从结果可以看出，GC日志包含" 6092K->856K(125952K)"，意味着虚拟机并没有完成回收。

可达性分析

在上面我们讲了，Java并不采用引用计数法来判断对象是否已"死"，而采用"可达性分析"来判断对象是 否存活(同样采用此法的还有C#、Lisp-最早的一门采用动态内存分配的语言)。 此算法的核心思想为 : 通过一系列称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索 走过的路径称之为"引用链"，当一个对象到GC Roots没有任何的引用链相连时(从GC Roots到这个对象 不可达)时，证明此对象是不可用的。

#JVM垃圾回收算法

既然我们已经了解了JVM如何判断一个对象是否存活，那么我们就可以开始对了解JVM如何将那不在被引用的对象 进行销毁。

1.标记清除法

"标记-清除"算法是最基础的收集算法。算法分为"标记"和"清除"两个阶段 : 首先标记出所有需要回收的对象（即那些不在被引用的对象），在标记完成后统一回收所有被标记的对象。后续的收集算法都是基于这种 思路并对其不足加以改进而已。 "标记-清除"算法的不足主要有两个 :

1. 效率问题 : 标记和清除这两个过程的效率都不高 2. 空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中 需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集。

如上图，我们可知在用该方法回收无用对象后产生了大量的内存碎片，这对于我们的空间利用是极其不利的，如下图

2.复制算法

"复制"算法是为了解决"标记-清理"的效率问题。它将可用内存按容量划分为大小相等的两块，每次只使 用其中的一块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另一块上面，然后 再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配 时也就不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运行高效。算法的执行流程如下图 : 

但该算法的缺点也是显而易见的，就是空间的利用率只有一半，每次都只能使用一半的内存空间。

3.标记整理算法

复制算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用 复制算法。 针对老年代的特点，提出了一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的 内存。流程图如下:

4.分代算法

分代算法和上面讲的 3 种算法不同，分代算法是通过区域划分，实现不同区域和不同的垃圾回收策略， 从而实现更好的垃圾回收。对于不同的情况和地域设置更符合当地 的规则，从而实现更好的管理，这就时分代算法的设计思想。 当前 JVM 垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只 是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。在新生代中，每 次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没 有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整理"算法。

在我们开辟的内存中，我们将其分为新生代和老年代，其中新生代占内存的1/3,老年代占2/3。在新生代中又可以分为Eden，Survivor From， Survivor To 三个区，分别占比为8：1：1.

当GC开始时，对象被创建在Eden区中当Eden区达到某个内存阈值时会将存活的对象转入from区，之后每进行一次GC在依然存活对象就会在from与to区中来回切换，每次切换存活的对象的年龄就会加一，当年龄达到某个值时（默认为15）就会将该对象移入老年代。同时，我们如果创建了一个大对象，那么这个对象会直接被放入老年代，这是因为在from与to区中来回复制一个大对象是十分消耗资源的。最后说明一下，在新生代中进行的GC成为”Minor GC“.

当我们将对象放入老年代后，如果老年代区域所用的内存达到阈值就会开始对老年代的GC，称为”Full GC“或者”Major GC “。

5.”Minor GC“与”Major GC“

1. Minor GC又称为新生代GC : 指的是发生在新生代的垃圾收集。因为Java对象大多都具备朝 生夕灭的特性，因此Minor GC(采用复制算法)非常频繁，一般回收速度也比较快。

2. Full GC 又称为 老年代GC或者Major GC : 指发生在老年代的垃圾收集。出现了Major GC， 经常会伴随至少一次的Minor GC(并非绝对，在Parallel Scavenge收集器中就有直接进行 Full GC的策略选择过程)。Major GC的速度一般会比Minor GC慢10倍以上。

最后

本文中图片来源于网络。