垃圾回收——概述

本专栏学习内容来自尚硅谷宋红康老师的视频以及《深入理解JVM虚拟机》第三版

有兴趣的小伙伴可以点击视频地址观看，也可以点击下载电子书

垃圾回收概述

垃圾回收不是Java语言的伴生产物，早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生就已经存在了。

垃圾收集机制是Java的招牌能力，极大地提高了开发效率。

为什么需要GC

• 对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早会被消耗完，因为不断地分配内存空间而不进行回收，就好像在不停地生产生活垃圾而从来不打扫一样。
• 除了释放没用的对象，垃圾回收也可以清楚内存里的记录碎片，碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象
• 随着应用程序所应付的业务越来越庞大、复杂、用户越来愈多，没有GC就不能保证程序的正常运行。而经常造成STW的GC又跟不上实际的需求，所以才会不断的尝试对GC进行优化

Java自动内存管理介绍

优点

• 自动内粗管理，无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险。
• 自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发

缺点

• 对于Java开发人员而言，自动内存管理就像是一个黑匣子，如果过度依赖于自动，那将会是一场灾难，最严重的就会弱化开发人员在程序出现内存溢出时定位问题和解决问题的能力。
• 当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些自动化的技术实施必要的监控和调节

垃圾回收相关算法

标记阶段

概述

垃圾标记阶段的作用是判断对象是否存活

• 在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是死亡对象，只有被标记为已经死亡的对象，GC才会在执行垃圾回收是，释放掉其所占用的内存空间，因此这个过程我们可以称之为垃圾标记阶段
• 那么在JVM中究竟是如何标记一个死亡对象呢？简单来说，当一个对象以及不再被任何的存活对象继续引用时，就可以宣判已经死亡
• 判断对象存活一般有两种方式：引用计数算法和可达性分析算法

引用计数算法

• 引用计数算法比较简单，对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况
• 对于一个对象A，只要有任何一个对象应用了A，则A的引用计数器就加1；当引用失效时，计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收
• 优点：实现简单，垃圾对象便于辨识；判断效率高，回收没有延迟性
• 缺点：
  • 它需要单独的字段存储计数器，这样的作法增加了存储空间的开销
  • 每次赋值需要更新计数器，伴随着加法和减法的操作，这增加了时间开销
  • 引用计数器有一个严重问题，无法处理循环引用的情况。这是一条致命的缺陷，导致在Java的垃圾回收器中没有使用这类算法。

验证Java没有使用引用计数算法

利用反证法，让obj1与obj2互相引用

public class RefCountGC {
    //5MB，主要作用是让这个对下个占用一些内存
    private byte[] bytes = new byte[5 * 1024 * 1024];

    Object reference = null;

    public static void main(String[] args) {
        RefCountGC obj1 = new RefCountGC();
        RefCountGC obj2 = new RefCountGC();

        obj1.reference = obj2;
        obj2.reference = obj1;

        obj1 = null;
        obj2 = null;
        //显示的执行垃圾回收
        System.gc();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

如果是使用引用计数算法，obj1和obj2互相引用，不会被标记进行回收。

手动执行GC后，我们发现Eden区的内存确实被清理掉了，这就说明了Java的垃圾回收机制会对obj1和obj2进行回收，所以Java使用的就不是引用技术算法

可达性分析算法

概述

• 相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效的特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄露的发生
• 相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫做追踪性垃圾收集

基本思路

所有“GC Roots”根集合就是一组必须活跃的引用。

• 可达性分析算法是以根对象集合（GC Roots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达
• 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链
• 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象已经死亡，可以标记为垃圾对象
• 在可达性分析算法中，只有能够被根对象集合直接或间接连接的对象才是存活对象

GC Roots

在Java语言中，GC Roots包括以下几类元素

• 虚拟机栈中引用的对象
  • 比如：各个线程被调用的方法中使用到的参数、局部变量等
• 本地方法站内JNI（本地方法）引用的对象
• 方法区中累静态属性引用的对象
  • 比如：Java类的引用类型静态变量
• 方法区中常量引用的对象
  • 比如：字符串常量池里的引用
• 所有被同步锁synchronized持有的对象
• Java虚拟机内部的引用
  • 基本数据类型对应的Class对象，一些常驻的异常对象（NullPointerException，OutOfMemoryError），系统类加载器
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

除了这些笃定地GC Roots集合之外，根据用户所选择的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象临时性的加入，共同构成完整GC Roots集合。比如分代收集和局部回收

小技巧

由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在对内存里面，那它就是一个Root。

注意点

• 如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行，这点不满足的话分析结果的准确性就无法保证
• 这点也导致GC进行时必须STW（Stop The World）的一个重要原因

对象的finalization机制

概述

• Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑

• 当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法

• finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库链接等

• 永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用

  • 在finalize()时可能会导致对象复活
  • finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会
  • 一个糟糕的finalize()会严重影响GC的性能

对象的三种状态

由于finalize()方法的存在，对象在被GC时可能会出现三种不同的状态。

• 可触及的：从根节点开始，可以到达这个对象
• 可复活的：对象的所有引用都被释放，但对象有可能在finalize()中复活
• 不可触及的：对象的finalize()被调用，并且没有复活。不可触及的对象不可能被复活，因为finalize()只会被调用一次。

以上3种状态中，是由于finalize()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

具体过程

判断一个对象obj是否可以回收，至少要经历两次标记过程

1. 如果对象obj到GC Roots没有引用链，则进行第一次标记
2. 进行筛选，判断此对象是否有必要执行finalize()方法
   1. 如果对象obj没有重写finalize()方法，或者finalize()方法以及被虚拟机调用过，则虚拟机视为“没有必要执行”，obj被判定为不可触及的。
   2. 如果对象obj重写了finalize()放啊，且还未执行过，那么obj会被插入到F-Queue队列中，又一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法
   3. finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果obj在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，obj会被移除“即将回收”的集合。之后对象会再次出现没有引用存在的情况。在这个情况下finalize()方法不会再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize()方法只会被调用一次。

代码演示可复活的对象

通过输出来查看结果，第一次执行GC时会被进入finalize()方法，复活obj对象，当第二次进行GC时，因为finalize()以及被虚拟机调用过，所以obj直接被判定从不可触及的状态，会被垃圾回收。

public class CanReliveObj {
    public static CanReliveObj obj;//类变量，属于 GC Root


    //此方法只能被调用一次
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("调用当前类重写的finalize()方法");
        obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系
    }


    public static void main(String[] args) {
        try {
            obj = new CanReliveObj();
            // 对象第一次成功拯救自己
            obj = null;
            System.gc();//调用垃圾回收器
            System.out.println("第1次 gc");
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
            System.out.println("第2次 gc");
            // 下面这段代码与上面的完全相同，但是这次自救却失败了
            obj = null;
            System.gc();
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

//结果
第1次 gc
调用当前类重写的finalize()方法
obj is still alive
第2次 gc
obj is dead
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

清除阶段

概述

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存

目前在JVM中比较常见的三种垃圾收集算法是

• 标记-清除算法（Mark-Sweep）
• 复制算法（copying）
• 标记-压缩算法（Mark-Compact）

标记-清除算法（Mark-Sweep）

执行过程

如下图所示，当堆中的有效内存空间被耗尽时，就会停止整个程序（STW），然后进行两项工作

• 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的对象头中记录为可达对象
• 清除：Collector对堆内存从头到尾进行线性遍历，如果发现某个对象再对象头中没有标记为可达对象，则将其回收

优点

• 标记-清除算法是一种非常基础和常见的垃圾收集算法
• 较为容易实现

缺点

• 效率不算高
• 在进行GC的时候，需要停止整个应用程序，导致用户体验差
• 清理出来的空闲内存是不连续的，产生内存碎片，需要维护一个空闲列表

这里插上一嘴，在创建对象的时，如果空闲空间是连续的，就可以使用指针碰撞的方法来存放对象，效率较高，如果空闲空间不连续，则需要维护一个空闲列表，额外的占据了内存。并且在空间不连续的情况下，可容纳的最大连续空间比较小，当创建大对象时，可容纳的最大连续空间不足，则会尝试插入到老年代中。

注意点

这里所谓的清除，并不是真的置空，而是将需要清楚的对象地址保存在空闲的地址列表中。下次由新的对象需要加载时，判断垃圾的位置空间是否够，如果够就存放。

这跟格式化硬盘优点类似，假如我们直接把D盘格式化了，对D盘不进行任何操作，可以使用网上很多恢复工具将其恢复，但如果对D盘格式化后，又将数据写入到D盘，相当于原来的记录被覆盖了，就无法恢复。

复制算法（copying）

核心思想

复制算法将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中所有对象，交换两个内存的角色，最后完成垃圾回收。此方法在之前学到的新生代中的两个幸存者区中有用到过。

优点

• 没有标记和清除的过程，实现简单，运行高效
• 复制过去以后保证空间的连续性，不会出现”碎片“问题

缺点

• 需要两倍的内存空间
• 对于G1这种分拆成大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。

注意点

如果系统中的垃圾对象过多，就不适合使用复制算法，复制算法需要复制的存活对象数量并不会太大，或者说非常低才行。否则会严重影响效率。

标记-压缩算法（Mark-Compact）

背景

复制算法的高效性建立在存活对象少，垃圾对象多的前提下。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都存活，如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代的垃圾回收特性，需要使用其他的算法。

执行过程

如下图所示，第一阶段和标记-清除算法一样，从根节点开始标记所有被引用的对象，第二阶段将所有存活的对象压缩到内存的一段，按顺序排放，最后清理边界外所有的空间。

优点

• 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可（指针碰撞）。
• 消除了复制算法当中，内存减半的高额代价。

缺点

• 从效率上来说，标记-压缩算法要低于复制算法
• 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
• 移动过程中吗，需要全程暂停用户应用程序。即：STW

小结

对比以上三种算法，复制算法是当之无愧的老大，但却浪费了太多内存。

为了尽量兼顾上面的三个指标，标记-压缩算法相对来说更平滑一些，但是效率是不尽人意，它比复制算法多了一个标记的阶段，比标记-清除算法多了一个整理内存的阶段。

分代收集算法

分代收集算法和以上三个算法是作用于不同的地方的，前面所有的算法中，没有一种算法可以完全替代其他算法，都具备自己独特的优势和特点。

而分代收集算法是基于这样一个事实：不同的对象的生命周期是不一样的，因此不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分成新生代和老年代，这样可以根据不同的年代的特点使用不同的算法，以提高垃圾回收的效率

年轻代

年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存货对象大小有关，因此很适用于老年代的回收，而复制算法内存利用率不高的问题，通过HotSpot中的两个survivor设计得到缓解。

老年代

老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

这种情况下存在大量存活率高的对象，复制算法明显不合适，一般由标记-清除算法或者标记-压缩算法来实现

• 标记阶段的开销于存活对象的数量成正比
• 清除阶段的开销与所管理区域的大小成正相关
• 压缩阶段的开销与村会兑现的数据成正比

增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种STW的状态，在STW的状态下，应用程序所有的线程都会被挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间长，应用成熟会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集算法的诞生。

基本思想

如果一次性将所有的垃圾进行处理，需要造成系统长时间停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。以此反复，直到垃圾收集完成。

总的来说增量收集算法的基础仍是传统的标记-清除算法和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾手机现场以分阶段的方式完成标记、清理或复制工作。

缺点

使用这种方式，由于在垃圾回收过程中，间断的执行应用程序代码，所以能减少系统的停顿时间，但是因为线程切换和上下文转换的小号，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

• 一般来说，在相同条件下，堆空间越大，一次GC所需要的时间就越长，有关GC产生的停顿也越长，为了更好的控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理的回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿
• 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间
• 每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间

写在最后

以上这些算法讲解的都是基本的算法思路，实际GC实现过程要复杂的多，目前还在发展中的前沿GC都是符合算法，并且并行和并发兼备。

垃圾回收相关概念

垃圾回收的相关概念可以帮助我们理解垃圾回收算法以及垃圾回收器

System.gc()

概述

• 在默认情况下，通过调用System.gc()或Runtime.getRuntime().gc()可以触发Full GC，同时对新生代和老年代进行回收。
• 然后在调用System.gc()时有一个免责声明，无法保证对垃圾回收器的调用。也就是说调用System.gc()后什么时候调用垃圾回收器是不确定的。
• 一般情况下System.gc()无需手动触发，当我们进行一些性能基准测试时，可以在测试前手动触发一次System.gc()

在对象第一次需要被回收时，会触发对象的finalize()方法，多次执行以下代码，可以看到不是每一次都会触发的，这就证明了调用System.gc()无法保证对垃圾回收器的调用

public class SystemGCTest {
    public static void main(String[] args) {
        new SystemGCTest();
        //单单执行System.gc()无法保证会马上执行垃圾回收
        System.gc();

        //强制执行垃圾回收可以再执行System.runFinalization()
        //System.runFinalization();
    }

    @Override
    protected void finalize() throws Throwable {
        System.out.println("SystemGCTest重写finalize()");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

理解不可达对象的回收行为

执行以下代码，并将GC日志输出，逐条分析。

public class LocalGC {
    public void localGC1(){
        byte[] buffer = new byte[10 * 1024 * 1024]; //10M
        System.gc();
    }

    public void localGC2(){
        byte[] buffer = new byte[10 * 1024 * 1024]; //10M
        buffer = null;
        System.gc();
    }
    
    public void localGC3(){
        {
            byte[] buffer = new byte[10 * 1024 * 1024]; //10M
        }
        System.gc();
    }

    public void localGC4(){
        {
            byte[] buffer = new byte[10 * 1024 * 1024]; //10M
        }
        int value = 10;
        System.gc();
    }
    
    public void localGC5(){
        localGC1();
        System.gc();
    }
    
    public static void main(String[] args) {
        LocalGC localGC = new LocalGC();
        localGC.localGC1();
//        localGC.localGC2();
//        localGC.localGC3();
//        localGC.localGC4();
//        localGC.localGC5();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

localGC1()

对于localGC1()方法来说，堆中的byte数组还被引用，所以无法被回收

localGC2()

对于localGC2()来说，堆中的byte数组没有被任何GC Root引用，所以会被回收

localGC3()

localGC3()比较难以理解，实际上执行的结果是不会被回收

我们可以使用jclasslib工具查看，发现局部变量表的最大槽数是2，但是局部变量表中只有一个this对象，就像标记-清除算法中并不是真正意义上的清除，也就是说实际上我们的buffer是占用了第二个局部变量表，所以引用还是存在的

localGC4()

localGC4()中的byte数组是会被回收的，这是因为原本局部变量表中第二个槽的位置被value替代

localGC5()

localGC5()中执行的第一次GC是localGC1()中调用的System.gc()，这是不会对byte数组回收的，而第二次调用GC时，因为localGC1()方法已经执行完毕，栈帧已经被弹出，所以对于堆中的byte数组来说，已经没有GC Root在引用他，所以会被回收。

内存溢出

Java对内存溢出的解释是：没有空闲内存，并且垃圾收集器也无法提供更多内存

• 首先说没有空间内存的情况，说明Java虚拟机的堆内存不够
  1. Java虚拟机的堆内存设置不够
  2. 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集
• 在抛出OOM异常之前，通常垃圾收集器会被触发，尽其所能去清理出空间
  • 例如：在引用机制分析中，涉及到JVM会尝试回收软引用指向的对象等
  • 在java.nio.BIts.reserveMemory()方法中，我们能清楚的看到，System.gc()会被调用，以清理空间
• 不是在任何情况下垃圾收集器都会被触发的
  • 比如：我们去分配一个超大对象，这个对象的所需要占据的内存超过了堆内存的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OOM异常

内存泄漏

• 严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏
• 但实际情况很多时候一些不太好的实践会导致对象的生命周期变得很长甚至导致OOM，可以叫做宽泛意义上的内存泄漏
• 尽管内存泄漏并不会立刻引起程序甭哭，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，知道耗尽所有内存，最终出现OOM异常，导致程序崩溃

Java中内存泄漏的例子

在单例模式中，我们都知道单例模式所用的对象的生命周期从程序启动时创建，在程序结束时才销毁，如果使用单例对象引用外部的对象，则会导致外部对象的生命周期与单例对象的声明周期一样长，这也可以看做宽泛意义上的内存泄漏。

除了单例模式，在调用外部连接时，不及时关闭连接，也会出现内存泄漏，比如数据库连接，网络链接，io链接，都必须要手动close，否则是不能被回收的。

Stop The World

• Stop The World简称STW，指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时，整个应用程序线程都会被暂停，没有任何相应，有点像卡死的感觉，这个停顿称为STW
  • 例如：可达性分析算法中枚举根节点会导致Java执行线程停顿。
• 被STW中断的应用程序线程会在完成GC后恢复，频繁中断会让用户感觉卡顿，所以我们要减少STW的发生
• STW事件和采用的GC无关，所有的GC都会有这个事件，只能说垃圾回收器越优秀，回收效率越高，尽可能缩短了暂停时间。
• STW时JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作现场全部停掉。
• 开发中不要使用System.gc()，会导致STW的发生

垃圾回收的并发与并行

• 并行：指的是多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态
• 串行：相较于并行的概念，单线程执行
• 并发：用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时，会停顿用户程序允许

安全点

程序在执行时，并非在所与欧的地方都能停顿下来开始GC，只有在特定位置才能停顿，这些位置称为安全点

安全点的选择和重要，如果太少可能导致GC等待时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据”是否具有让程序长时间执行的特征为标准“，比如方法调用、循环跳转和异常跳转

如何在GC发生时，检查所有线程都跑到最近的安全点

主动式中断：设置一个中断标志，各个线程运行到安全点时主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。

安全区域

安全区域时指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。

例如：程序线程有时候会出现sleep的情况，这时候JVM执行GC不可能等到sleep结束，所以在程序线程进入sleep时会告知JVM我已经进入安全区域，可以执行GC。

引用

一道较为偏门又非常高频的面试题：强引用、软引用、弱引用、虚引用有什么区别？具体使用场景是什么？

其实在我们平时写代码中，99%的地方我们使用的都是强引用，在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用4种，这4种的引用强度依次逐渐减弱。

除了强引用之外，其他3种引用均可以在java.lang.ref包中找到他们的身影。

强引用（Strong Reference）

概念

在Java程序中，最常见的引用类型就是强引用，也就是我们最常见的普通对象引用，也是默认的引用类型。

强引用的对象是可触及的，垃圾收集器永远不会回收掉被引用的对象。

对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者现实的将引用赋值为null，就可以当作垃圾被收集了，具体回收时机还是要看垃圾收集策略。

相对的，软引用、弱引用、虚引用的对象都是软可触及、弱可触及、虚可触及的，在一定条件下，都是可以被回收的，所以，强引用是造成Java内存泄漏的主要原因之一。

特点

• 强引用可以直接访问目标对象
• 强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿抛出OOM异常，也不会回收强引用所指向的对象
• 强引用可能导致内存泄漏

软引用（Soft Reference）

概念

通俗理解：内存不足的时候就会回收软引用对象

软引用是用来描述一些还有用，但非必要的对象。只要被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围中进行第二次回收。

垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选的把引用存放在一个引用队列。

代码

public class SoftReferenceTest {
    public static void main(String[] args) {
        //这样堆中new User的引用就是软引用
        SoftReference<User> userSoftRef = new SoftReference<>(new User(1, "yellowstar"));


        //从软引用中重新获得强引用对象
        System.out.println(userSoftRef.get());

        System.gc();
        System.out.println("After GC:");
//        //垃圾回收之后获得软引用中的对象
        System.out.println(userSoftRef.get());//由于堆空间内存足够，所有不会回收软引用的可达对象。
//
        try {
            //让系统认为内存资源紧张、不够
            byte[] b = new byte[1024 * 1024 * 7];
        } catch (Throwable e) {
            e.printStackTrace();
        } finally {
            //再次从软引用中获取数据
            System.out.println(userSoftRef.get());//在报OOM之前，垃圾回收器会回收软引用的可达对象。
        }
    }
}

class User{
    int id;
    String name;

    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    @Override
    public String toString() {
        return "User{" +
                "id=" + id +
                ", name='" + name + '\'' +
                '}';
    }
}

//结果
User{id=1, name='yellowstar'}
After GC:
User{id=1, name='yellowstar'}
java.lang.OutOfMemoryError: Java heap space
	at com.example.practice6.ref.SoftReferenceTest.main(SoftReferenceTest.java:26)
null
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

弱引用（Weak Reference）

概念

通俗来讲弱引用就是发现就会被回收

弱引用也是用来描述那些非必要对象的，只被弱引用关联的对象只能生存道下一次垃圾收集发生为止，在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉制备弱引用关联的对象。

软引用、弱引用都非常适合来把保存那些可有可无的缓存数据。

弱引用对象与软引用对象最大的不同在于，当GC在进行回收时，需要通过算法检查是否回收软引用对象，而对于弱引用对象，GC总是进行回收。弱引用对象更容易、更快被GC回收。

代码

public class WeakReferenceTest {
    public static void main(String[] args) {
        //构造了弱引用
        WeakReference<User> userWeakRef = new WeakReference<User>(new User(1, "yellowstar"));
        //从弱引用中重新获取对象
        System.out.println(userWeakRef.get());

        System.gc();
        // 不管当前内存空间足够与否，都会回收它的内存
        System.out.println("After GC:");
        //重新尝试从弱引用中获取对象
        System.out.println(userWeakRef.get());
    }
}

//结果
User{id=1, name='yellowstar'}
After GC:
null
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

虚引用（Phantom Reference）

概念

虚引用时所有引用类型中最弱的一个。

一个对象是否有虚引用存在，完全不会决定对象的生命周期，如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。

它不能单独使用，也无法通过虚引用来获取被引用的对象，尝试获取对象时，总为null

为一个对象设置虚引用的唯一目的在于跟踪垃圾回收过程，比如：能在这个对象被垃圾收集器回收时收到一个系统通知。

代码

创建虚引用时，除了引用对象还需要传入一个引用队列，当对象被回收时，会将信息发送到引用队列中。

public class PhantomReferenceTest {
    public static PhantomReferenceTest obj;//当前类对象的声明
    static ReferenceQueue<PhantomReferenceTest> phantomQueue = null;//引用队列

    public static class CheckRefQueue extends Thread {
        @Override
        public void run() {
            while (true) {
                if (phantomQueue != null) {
                    PhantomReference<PhantomReferenceTest> objt = null;
                    try {
                        objt = (PhantomReference<PhantomReferenceTest>) phantomQueue.remove();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    if (objt != null) {
                        System.out.println("追踪垃圾回收过程：PhantomReferenceTest实例被GC了");
                    }
                }
            }
        }
    }

    @Override
    protected void finalize() throws Throwable { //finalize()方法只能被调用一次！
        super.finalize();
        System.out.println("调用当前类的finalize()方法");
        obj = this;
    }

    public static void main(String[] args) {
        Thread t = new CheckRefQueue();
        t.setDaemon(true);//设置为守护线程：当程序中没有非守护线程时，守护线程也就执行结束。
        t.start();

        phantomQueue = new ReferenceQueue<PhantomReferenceTest>();
        obj = new PhantomReferenceTest();
        //构造了 PhantomReferenceTest 对象的虚引用，并指定了引用队列
        PhantomReference<PhantomReferenceTest> phantomRef = new PhantomReference<PhantomReferenceTest>(obj, phantomQueue);

        try {
            //不可获取虚引用中的对象
            System.out.println(phantomRef.get());

            //将强引用去除
            obj = null;
            //第一次进行GC,由于对象可复活，GC无法回收该对象
            System.gc();
            Thread.sleep(1000);
            if (obj == null) {
                System.out.println("obj 是 null");
            } else {
                System.out.println("obj 可用");
            }
            System.out.println("第 2 次 gc");
            obj = null;
            System.gc(); //一旦将obj对象回收，就会将此虚引用存放到引用队列中。
            Thread.sleep(1000);
            if (obj == null) {
                System.out.println("obj 是 null");
            } else {
                System.out.println("obj 可用");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

//结果
null
调用当前类的finalize()方法
obj 可用
第 2 次 gc
追踪垃圾回收过程：PhantomReferenceTest实例被GC了
obj 是 null
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76