[Java] 垃圾回收机制与引用类型 - 《后端开发问题》

一、垃圾回收
- 1、垃圾回收机制
  - 1.1. 如何判断对象是否需要被回收
- 2、垃圾收集算法
二、引用类型

Java 语言的一个重要特性是引入了自动的内存管理机制，开发人员并不需要关心内存的分配和回收的底层细节。Java 平台通过垃圾回收器来进行自动的内存管理。

一、垃圾回收

注意：垃圾回收主要是对（堆区）的处理

1、垃圾回收机制

Java 的垃圾回收器要负责完成 3 件任务：

分配内存
确保被引用的对象的内存不被错误回收
回收不再被引用的对象的内存空间

一般情况下，当垃圾回收器在进行回收操作的时候，整个应用的执行是被暂时中止（stop-the-world）的。这是因为垃圾回收器需要更新应用中所有对象引用的实际内存地址。所以在多 CPU 的平台上，就可以通过并行的方式来回收垃圾。单 CPU 平台则只能串行进行。
不同的硬件平台所能支持的垃圾回收方式也不同。垃圾回收是一个复杂而且耗时的操作。如果 JVM 花费过多的时间在垃圾回收上，则势必会影响应用的运行性能。

1.1. 如何判断对象是否需要被回收

引用计数法
给对象添加一引用计数器，被引用一次计数器值就加 1；当引用失效时，计数器值就减 1；计数器为 0 时，对象就是不可能再被使用的，简单高效，缺点是无法解决对象之间相互循环引用的问题。
可达性分析算法
通过一系列的称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。此算法解决了上述循环引用的问题。

2、垃圾收集算法

不同的应用所期望的垃圾回收方式也会有所不同:

服务器端应用可能希望在应用的整个运行时间中，花在垃圾回收上的时间总数越小越好。
对于与用户交互的应用来说，则可能希望所垃圾回收所带来的应用停顿的时间间隔越小越好。

JVM 中提供了多种垃圾回收方法以及对应的性能调优参数，应用可以根据需要来进行定制：

2.1. 标记-清除算法

最基础的收集算法是“标记-清除”（Mark-Sweep）算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
它的主要不足有两个：

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

2.2. 复制算法

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。

现在的商业虚拟机都采用这种算法来回收新生代，IBM 研究指出新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden（伊甸园）空间和两块较小的 Survivor（存活区）空间，每次使用 Eden 和其中一块 Survivor 。
当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。HotSpot 虚拟机默认 Eden:Survivor = 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（其中一块Survivor不可用），只有 10% 的内存会被“浪费”。
当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。
内存的分配担保就好比我们去银行借款，如果我们信誉很好，在 98% 的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。
内存的分配担保也一样，如果另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

2.3. 标记整理算法

复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

2.4. 分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期的不同将内存划分为几块并采用不用的垃圾收集算法。
一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

二、引用类型

java.lang.ref 包中提供了对一个对象的不同的引用方式。JVM 的垃圾回收器对于不同类型的引用有不同的处理方式

1、强引用

强引用就是指在程序代码之中普遍存在的，类似”Object obj=new Object()”这类的引用，垃圾收集器永远不会回收存活的强引用对象。
如 Date date = new Date()，date 就是一个对象的强引用。对象的强引用可以在程序中到处传递。很多情况下，会同时有多个引用指向同一个对象。强引用的存在限制了对象在内存中的存活时间。假如对象 A 中包含了一个对象 B 的强引用，那么一般情况下，对象 B 的存活时间就不会短于对象 A。如果对象 A 没有显式的把对象 B 的引用设为 null 的话，就只有当对象 A 被垃圾回收之后，对象 B 才不再有引用指向它，才可能获得被垃圾回收的机会。

2、软引用

还有用但并非必需的对象。在系统 将要发生内存溢出异常之前 ，将会把这些对象列进回收范围之中进行第二次回收。
当 JVM 中的内存不足的时候，垃圾回收器会释放那些只被软引用所指向的对象。如果全部释放完这些对象之后，内存还不足，才会抛出 OutOfMemory 错误。软引用非常适合于创建缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。比如考虑一个图像编辑器的程序。该程序会把图像文件的全部内容都读取到内存中，以方便进行处理。而用户也可以同时打开多个文件。当同时打开的文件过多的时候，就可能造成内存不足。如果使用软引用来指向图像文件内容的话，垃圾回收器就可以在必要的时候回收掉这些内存。

/*
    在运行下面程序的时候，可以使用 -Xmx 参数来限制 JVM 可用的内存。
    由于软引用所指向的对象可能被回收掉，在通过 get 方法来获取软引用所实际指向
      的对象的时候，总是要检查该对象是否还存活。
*/
public class ImageData {
    private String path;
    private SoftReference<byte[]> dataRef;
    public ImageData(String path) {
        this.path = path;
        dataRef = new SoftReference<byte[]>(new byte[0]);
    }
    private byte[] readImage() {
        return new byte[1024 * 1024]; // 省略了读取文件的操作
    }
    public byte[] getData() {
        byte[] dataArray = dataRef.get();
        if (dataArray == null || dataArray.length == 0) {
            dataArray = readImage();
            dataRef = new SoftReference<byte[]>(dataArray);
        }
       return dataArray;
    }
}

3、弱引用

用来描述非必需对象的，被弱引用关联的对象 只能生存到下一次垃圾收集发生之前 。当垃圾收集器工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象。
在垃圾回收器运行的时候，如果一个对象的所有引用都是弱引用的话，该对象会被回收。弱引用的作用在于解决强引用所带来的对象之间在存活时间上的耦合关系。弱引用最常见的用处是在集合类中，尤其在哈希表中。哈希表的接口允许使用任何 Java 对象作为键来使用。当一个键值对被放入到哈希表中之后，哈希表对象本身就有了对这些键和值对象的引用。如果这种引用是强引用的话，那么只要哈希表对象本身还存活，其中所包含的键和值对象是不会被回收的。如果某个存活时间很长的哈希表中包含的键值对很多，最终就有可能消耗掉 JVM 中全部的内存。

4、虚引用

也叫“幽灵引用”，是最弱的一种引用关系。 无法通过虚引用来取得一个对象实例 。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
Java 提供了对象终止化机制（finalization）。在Object 类里面有个finalize方法，其设计的初衷是在一个对象被真正回收之前，可以用来执行一些清理的工作。因为 Java 并没有提供类似 C++ 的析构函数一样的机制，就通过 finalize 方法来实现。但是问题在于垃圾回收器的运行时间是不固定的，所以这些清理工作的实际运行时间也是不能预知的。幽灵引用（phantom reference）可以解决这个问题。在创建幽灵引用PhantomReference的时候必须要指定一个引用队列。当一个对象的 finalize 方法已经被调用了之后，这个对象的幽灵引用会被加入到队列中。通过检查该队列里面的内容就知道一个对象是不是已经准备要被回收了。
幽灵引用及其队列的使用情况并不多见，主要用来实现比较精细的内存使用控制，这对于移动设备来说是很有意义的。程序可以在确定一个对象要被回收之后，再申请内存创建新的对象。通过这种方式可以使得程序所消耗的内存维持在一个相对较低的数量。

/*
    在下面的代码中，每次申请新的缓冲区的时候，都首先确保之前的缓冲区的字节数组已经被成功回收。
    引用队列的 remove 方法会阻塞直到新的幽灵引用被加入到队列中。不过需要注意的是，这种做法
        会导致垃圾回收器被运行的次数过多，可能会造成程序的吞吐量过低。
*/
public class PhantomBuffer {
    private byte[] data = new byte[0];
      private ReferenceQueue<byte[]> queue = new ReferenceQueue<byte[]>();
       private PhantomReference<byte[]> ref = new PhantomReference<byte[]>(data, queue);
       public byte[] get(int size) {
           if (size <= 0) {
               throw new IllegalArgumentException("Wrong buffer size");
           }
           if (data.length < size) {
               data = null;
               System.gc(); // 强制运行垃圾回收器
            try {
                   queue.remove(); // 该方法会阻塞直到队列非空
                   ref.clear(); // 幽灵引用不会自动清空，要手动运行
                   ref = null;
                   data = new byte[size];
                   ref = new PhantomReference<byte[]>(data, queue);
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
          }
          return data;
       }
}

参考资料： Java垃圾回收 Java 深度历险（四）——Java 垃圾回收机制与引用类型