每日一问：讲讲 Java 虚拟机的垃圾回收

昨天我们用比较精简的文字讲了 Java 虚拟机结构，没看过的可以直接从这里查看：
每日一问：你了解 Java 虚拟机结构么？

今天我们必须来看看 Java 虚拟机的垃圾回收算法是怎样的。不过在开始之前，我们一定得确定哪些是活着的对象，又有哪些是可以进行回收的。

判断对象是否存活方式

引用计数算法

对应判断一个对象是否可以回收，我想引用计数一定是最容易被想到的算法了吧。给每个对象加一个引用计数器，每当有一个地方引用它时，计数器就加 1，引用失效后减 1，当对象的计数器为 0，则说明这个对象可以被回收了。这个算法非常简单，但存在一个非常大的弊端：一旦两个对象相互引用，这个算法就没辙了。

根搜索算法

Java 就是采用的根搜索算法进行判断对象是否存活。这个算法的思路是：通过一系列名为 "GC Roots" 的对象作为起始点，从这些结点开始向下搜索，当一个对象到 "GC Roots" 没有任何引用链相连的话，则证明这个对象是可以被回收的。在 Java 中，可以作为 "GC Roots" 的对象包括：

虚拟机栈中引用的对象；
方法区中的类静态属性和常量引用的对象；
本地方法栈中 JNI 引用的对象；

四种引用

在 JDK 1.2 之后，引用被分为了强引用、软引用、弱引用和虚引用四种，这四种引用强度依次逐渐减弱。

强引用

强引用在 Android 代码中普遍存在，只要强引用还在，垃圾回收器就不会回收掉被引用的对象，这就是为什么我们用内部类持有 Activity 实例会造成内存泄漏的根本原因。

软引用

软引用用来描述一些还有用，但非必需的对象，用 SoftReference 实现，被软引用关联的对象，在系统将要发生 OOM 之前，会把这些对象列进回收范围之中并进行第二次回收。软引用在 Android 中主要是用于做缓存，比如软引用缓存网络请求的图片。

弱引用

弱引用也是用来描述非必需对象的，但它的强度比软引用更弱，用 WeakReference 实现。被弱引用管理的对象只能生存到下一次垃圾收集发生之前。弱引用在 Android 中主要用于处理内存泄漏。

虚引用

虚引用其实没啥好说的，一个对象是否有虚引用的存在，完全不会对生存时间构成影响，也无法通过虚引用来取得一个对象实例。就目前为止，我还没有在 Android 开发中使用过它。

都有些什么垃圾回收算法

学习 Java 虚拟机的垃圾回收算法之前，我们必须来看看我们常见的几种垃圾回收算法的思想，并把它们的优劣进行一定的对比，这样一定才能让你理解更加深刻。

标记 - 清除算法

标记 - 清除算法应该是最简单基础的收集算法了，只需要标记需要回收的对象，标记完成后统一回收即可。但其有两个非常明显的弊端。

标记清除效率都不高；
标记清除后会产生大量不连续的内存碎片，导致程序以后需要较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制收集算法

复制算法主要是将可用内存划分为大小相等的两块，每次只使用其中的一块，当这一块内存用完，就将存活着的对象复制到另一块内存上去，然后把已使用过的内存空间一次性清理掉。复制回收算法能有效地避免内存碎片，但是算法需要把内存一分为二，导致内存使用率大大降低。

标记 - 整理算法

复制收集算法在对象存活率较高时就需要进行较多的复制操作，效率非很低。效率会很低。标记-整理算法就解决了这样的问题，同样采用的是根搜索算法进行存活对象标记，但后续是将所有存活的对象都移动到内存的一端，然后清理掉端外界的对象。

分代收集算法

当前包括 Java 虚拟机在内的商业虚拟机都采用的是分代收集算法。这种算法其实就是根据对象的存活周期不同将内存划分为几块。一般把 Java 堆分为新生代和老年代，然后根据各个年代的特点采用最适合的收集算法。

Java 虚拟机的垃圾回收策略

前面说了 Java 虚拟机采用的是分代回收算法，该算法会根据各个年代的特点采用最适合的收集算法，我们就必须了解 Java 堆分的各个年代区域的特点。

JVM 中共分为三个代：新生代、老年代和持久代。其中持久代主要存放的是 Java 类的类信息，与垃圾收集要收集的 Java 对象关系不大。

新生代：所有新生成的对象首先都是放在新生代的，新生代采用复制回收算法。新生代的目标就是尽可能快速地收集掉那些生命周期短的对象。新生代按照 8:1 的比例分为一个 Eden 区和两个 Survivor 区。大部分对象在 Eden 区生成，当 Eden 区满时，还存活的对象将被复制到其中的一个 Survivor 区，当这个 Survivor 区满时，此区的存活对象将被复制到另外一个 Survivor 区，当另一个 Survivor 区也满了的时候，从第一个 Survivor 区复制过来的并且此时还存活的对象，将被复制到了「年老区」。需要注意，Survivor 的两个区是对称的，没有任何的先后关系，所以同一个区中可能同时存在 Eden 复制过来的对象，和从前一个 Survivor 区复制过来的对象，而复制到年老区的只有从第一个 Survivor 区过来的对象，而且，Survivor 区总有一个是空的。
老年代：在新生代中经历了 N 次垃圾回收后仍然存活的对象，就会被放到老年代中，老年代采用标记整理回收算法。因此，可以认为老年代中存放的都是一些生命周期较长的对象。
持久代：用于存放静态文件，如 final 常量、static 常量、常量池等。持久代对垃圾回收没有显著影响，但有些应用可能动态生成或者调用一些 class。在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。

谈谈 Java 垃圾回收的触发条件

Java 垃圾回收包含两种类型：Scavenge GC 和 Full GC。

Scavenge GC：一般情况下，当新对象生成，并且在 Eden 申请空间失败的时候，就会触发 Scavenge GC，对 Eden 区进行 GC，清除非存活的对象，并且把尚且存活的对象移动到 Survivor 区，然后整理 Survivor 的两个区。这种方式的 GC 是对新生代的 Eden 区进行，不会影响到老年代。因为大部分对象都是从 Eden 区开始的，同时 Eden 区不会分配的很大，所以 Eden 区的 GC 会频繁进行。
Full GC：Full GC 将会对整个堆进行整理，包括新生代、老年代和持久代。Full GC 因为需要对整个堆进行回收，所以比 Scavenge GC 要慢，因此应该尽量减少 Full GC 的次数。在对 JVM 调优的过程中，很大一部分工作就是对 Full GC 的调节，有如下原因可能导致 Full GC:
1. 老年代被写满；
2. 持久代被写满；
3. System.gc() 被显式调用；

好了，这一篇文字比起前面的文字稍微多了一些，主要是知识关联性稍微大了一些，又不适合分开讲解，所以就只能这样了。