第 15 章垃圾回收相关概念、System.gc()、内存溢出与内存泄漏、垃圾回收的并行与并发、强软弱虚引用

川长思鸟来 2022-12-29 09:11 43阅读 0赞

# 第 15 章 垃圾回收相关概念 #

## 1、System.gc() 的理解 ##

### 1.1、System.gc() 方法 (`重点`) ###

> **System.gc() 方法 或 Runtime.getRuntime().gc()**
> 
>  *  **`主动触发Full GC, 同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。`**

1.  **在默认情况下，通过`System.gc()`或者`Runtime.getRuntime().gc()`的调用，`会显式触发Full GC`，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。**
2.  然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用(不能确保立即生效)
3.  **JVM实现者可以通过System.gc() 调用来决定JVM的GC行为**。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。
4.  在一些特殊情况下，如我们正在编写一个性能基准，我们可以在运行之间调用System.gc()

> **代码示例：手动执行 GC 操作**

**代码示例 1**

*  代码

/** * @author shkstart shkstart@126.com * @create 2020 14:49 */
    public class SystemGCTest { 
        public static void main(String[] args) { 
            new SystemGCTest();
    
            /* 提醒jvm的垃圾回收器执行gc,但是不确定是否马上执行gc 与Runtime.getRuntime().gc();的作用一样。 */
            //System.gc();
    
            // 强制调用使用引用的对象的finalize()方法
            System.runFinalization();
        }
    
        @Override
        protected void finalize() throws Throwable { 
            super.finalize();
            System.out.println("SystemGCTest 重写了finalize()");
        }
    }

*  有时候会调用 finalize() 方法，有时候并不会调用

"C:\Program Files\Java\jdk1.8.0_144\bin\java" 
    SystemGCTest 重写了finalize()
    
    Process finished with exit code 0

### 1.2、不可达对象回收行为 ###

> **手动 GC 理解不可达对象的回收行为**

*  代码

/** * @author shkstart shkstart@126.com * @create 2020 14:57 */
    public class LocalVarGC { 
        public void localvarGC1() { 
            byte[] buffer = new byte[10 * 1024 * 1024];//10MB
            System.gc();
        }
    
        public void localvarGC2() { 
            byte[] buffer = new byte[10 * 1024 * 1024];
            buffer = null;
            System.gc();
        }
    
        public void localvarGC3() { 
            { 
                byte[] buffer = new byte[10 * 1024 * 1024];
            }
            System.gc();
        }
    
        public void localvarGC4() { 
            { 
                byte[] buffer = new byte[10 * 1024 * 1024];
            }
            int value = 10;
            System.gc();
        }
    
        public void localvarGC5() { 
            localvarGC1();
            System.gc();
        }
    
        public static void main(String[] args) { 
            LocalVarGC local = new LocalVarGC();
    
            // TODO
            local.localvarGC1();
        }
    }

*  JVM 参数

-XX:+PrintGCDetails // 打印详细的GC信息

--------------------

**调用 localvarGC1() 方法**

*  执行 System.gc() 仅仅是将年轻代的 buffer 数组对象放到了老年代（Why？buffer 数组年龄应该还没达到阈值吧）

[GC (System.gc()) [PSYoungGen: 15482K->10744K(76288K)] 15482K->10976K(251392K), 0.0060965 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    [Full GC (System.gc()) [PSYoungGen: 10744K->0K(76288K)] [ParOldGen: 232K->10908K(175104K)] 10976K->10908K(251392K), [Metaspace: 3466K->3466K(1056768K)], 0.0048454 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    Heap
     PSYoungGen      total 76288K, used 655K [0x000000076b380000, 0x0000000770880000, 0x00000007c0000000)
      eden space 65536K, 1% used [0x000000076b380000,0x000000076b423ee8,0x000000076f380000)
      from space 10752K, 0% used [0x000000076f380000,0x000000076f380000,0x000000076fe00000)
      to   space 10752K, 0% used [0x000000076fe00000,0x000000076fe00000,0x0000000770880000)
     ParOldGen       total 175104K, used 10908K [0x00000006c1a00000, 0x00000006cc500000, 0x000000076b380000)
      object space 175104K, 6% used [0x00000006c1a00000,0x00000006c24a7088,0x00000006cc500000)
     Metaspace       used 3473K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

--------------------

**调用 localvarGC2() 方法**

*  由于 buffer 数组对象没有引用指向它，执行 System.gc() 将被回收

[GC (System.gc()) [PSYoungGen: 15482K->872K(76288K)] 15482K->880K(251392K), 0.0008529 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 872K->0K(76288K)] [ParOldGen: 8K->668K(175104K)] 880K->668K(251392K), [Metaspace: 3466K->3466K(1056768K)], 0.0035955 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     PSYoungGen      total 76288K, used 655K [0x000000076b380000, 0x0000000770880000, 0x00000007c0000000)
      eden space 65536K, 1% used [0x000000076b380000,0x000000076b423ee8,0x000000076f380000)
      from space 10752K, 0% used [0x000000076f380000,0x000000076f380000,0x000000076fe00000)
      to   space 10752K, 0% used [0x000000076fe00000,0x000000076fe00000,0x0000000770880000)
     ParOldGen       total 175104K, used 668K [0x00000006c1a00000, 0x00000006cc500000, 0x000000076b380000)
      object space 175104K, 0% used [0x00000006c1a00000,0x00000006c1aa7078,0x00000006cc500000)
     Metaspace       used 3473K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

--------------------

**调用 localvarGC3() 方法**

*  虽然出了代码块的作用域，但是 buffer 数组对象并没有被回收

[GC (System.gc()) [PSYoungGen: 15482K->10736K(76288K)] 15482K->10992K(251392K), 0.0054629 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 10736K->0K(76288K)] [ParOldGen: 256K->10908K(175104K)] 10992K->10908K(251392K), [Metaspace: 3466K->3466K(1056768K)], 0.0057568 secs] [Times: user=0.05 sys=0.06, real=0.02 secs] 
    Heap
     PSYoungGen      total 76288K, used 655K [0x000000076b380000, 0x0000000770880000, 0x00000007c0000000)
      eden space 65536K, 1% used [0x000000076b380000,0x000000076b423ee8,0x000000076f380000)
      from space 10752K, 0% used [0x000000076f380000,0x000000076f380000,0x000000076fe00000)
      to   space 10752K, 0% used [0x000000076fe00000,0x000000076fe00000,0x0000000770880000)
     ParOldGen       total 175104K, used 10908K [0x00000006c1a00000, 0x00000006cc500000, 0x000000076b380000)
      object space 175104K, 6% used [0x00000006c1a00000,0x00000006c24a7088,0x00000006cc500000)
     Metaspace       used 3472K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

*  来看看字节码：实例方法局部变量表第一个变量肯定是 this

![image-20200731224709351][]

*  你有没有看到，局部变量表的大小是 2 ，也就是说执行 System.gc() 时，栈中还有 buffer 变量指向堆中的字节数组

![image-20200731224806161][]

--------------------

**调用 localvarGC4() 方法**

*  就多定义了一个局部变量 value ，怎么就能把字节数组回收了呢？

[GC (System.gc()) [PSYoungGen: 15482K->808K(76288K)] 15482K->816K(251392K), 0.0010067 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 808K->0K(76288K)] [ParOldGen: 8K->668K(175104K)] 816K->668K(251392K), [Metaspace: 3466K->3466K(1056768K)], 0.0039890 secs] [Times: user=0.00 sys=0.02, real=0.01 secs] 
    Heap
     PSYoungGen      total 76288K, used 655K [0x000000076b380000, 0x0000000770880000, 0x00000007c0000000)
      eden space 65536K, 1% used [0x000000076b380000,0x000000076b423ee8,0x000000076f380000)
      from space 10752K, 0% used [0x000000076f380000,0x000000076f380000,0x000000076fe00000)
      to   space 10752K, 0% used [0x000000076fe00000,0x000000076fe00000,0x0000000770880000)
     ParOldGen       total 175104K, used 668K [0x00000006c1a00000, 0x00000006cc500000, 0x000000076b380000)
      object space 175104K, 0% used [0x00000006c1a00000,0x00000006c1aa7078,0x00000006cc500000)
     Metaspace       used 3472K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

*  看，value 位于局部变量表中索引为 1 的位置

![image-20200731225006745][]

*  局部变量表长度为 2 ，这说明了出了代码块时，buffer 就出了其作用域范围，此时没有为 value 开启新的槽，所以 value 变量占据了 buffer 变量的槽（Slot），导致堆中的字节数组没有引用再指向它，执行 System.gc() 时被回收

![image-20200731225047000][]

--------------------

**调用 localvarGC5() 方法**

*  这局部变量除了方法范围就是失效了，堆中的字节数组被回收

[GC (System.gc()) [PSYoungGen: 15482K->10744K(76288K)] 15482K->10968K(251392K), 0.0054897 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 10744K->0K(76288K)] [ParOldGen: 224K->10908K(175104K)] 10968K->10908K(251392K), [Metaspace: 3465K->3465K(1056768K)], 0.0048527 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (System.gc()) [PSYoungGen: 0K->0K(76288K)] 10908K->10908K(251392K), 0.0002221 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 0K->0K(76288K)] [ParOldGen: 10908K->668K(175104K)] 10908K->668K(251392K), [Metaspace: 3465K->3465K(1056768K)], 0.0055602 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
    Heap
     PSYoungGen      total 76288K, used 655K [0x000000076b380000, 0x0000000770880000, 0x00000007c0000000)
      eden space 65536K, 1% used [0x000000076b380000,0x000000076b423ee8,0x000000076f380000)
      from space 10752K, 0% used [0x000000076fe00000,0x000000076fe00000,0x0000000770880000)
      to   space 10752K, 0% used [0x000000076f380000,0x000000076f380000,0x000000076fe00000)
     ParOldGen       total 175104K, used 668K [0x00000006c1a00000, 0x00000006cc500000, 0x000000076b380000)
      object space 175104K, 0% used [0x00000006c1a00000,0x00000006c1aa7078,0x00000006cc500000)
     Metaspace       used 3472K, capacity 4500K, committed 4864K, reserved 1056768K
      class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

--------------------

**图解分析**

![image-20200801093140763][]

## 2、内存溢出与内存泄漏 `(重点)` ##

### 2.1、内存溢出 ###

> **内存溢出（OOM）: OutofMemoryError 的解释是, 没有空闲内存, 并且垃圾收集器也无法提供更多内存。**
> 
>  *  没有`足够`的内存空间, 来创建新对象
>  *  造成内存溢出的原因有很多
>     
>      *  `堆空间内存分配不合理`, 可通过`-Xms、-Xmx`来调整
>      *  可能存`大量内存泄漏`, 对象不被使用了, 但是GCRoot还引用着这些对象, 此时GC不会回收它们
>      *  创建了很多`大对象`, 并且这些对象所在的区域, 很少发生GC, 停留在内存中的时间较长
>      *  JDK7的时候, `永久代`就容易出现OOM, 因为`永久代`大小受虚拟机内存的限制, 而且对永久代的垃圾回收也很少, 所以很容易导致OOM

1.  内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，`内存溢出也是引发程序崩溃的罪魁祸首之一。`
2.  **由于GC一直在发展，所以一般情况下，除非应用程序占用的内存增长速度非常快，`造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。`**
3.  大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次`独占式的Full GC操作`，这时候会**回收大量的内存，供应用程序继续使用**。
4.  Javadoc中对 **`OutofMemoryError`** 的解释是，**没有空闲内存，并且垃圾收集器也无法提供更多内存。**

> **内存溢出（OOM）原因分析**

首先说没有空闲内存的情况：说明Java虚拟机的堆内存不够。原因有二：

1.  **Java虚拟机的堆内存设置不够。**
    
     *  比如：可能`存在内存泄漏`问题；也很有可能就是`堆的大小不合理`，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。
     *  我们可以`通过参数-Xms 、-Xmx来调整`。
2.  **代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在GCRoot引用）**
    
     *  对于老版本的Oracle JDK，因为`永久代的大小是有限的`，**并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极**，所以当我们不断添加新类型的时候，**永久代出现OutOfMemoryError也非常多见**
     *  尤其是在运行时存在大量动态类型生成的场合；类似intern字符串缓存占用太多空间，也会导致OOM问题。
     *  对应的异常信息，会标记出来和`永久代`相关：`“java.lang.OutOfMemoryError:PermGen space"`。
     *  随着`元空间`的引入，方法区内存已经不再那么窘迫，所以相应的OOM有所改观，出现OOM，异常信息则变成了：`“java.lang.OutofMemoryError:Metaspace"`。**直接内存不足，也会导致OOM。**

--------------------

**说明**

1.  这里面隐含着一层意思是，**`在抛出OutofMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间。`**
    
     *  例如：在`引用机制`分析中，涉及到`JVM`会去`尝试回收软引用指向的对象`等。
     *  在java.nio.Bits.reserveMemory()方法中，我们能清楚的看到，System.gc()会被调用，以清理空间。
2.  **当然，也不是在任何情况下垃圾收集器都会被触发的**
    
     *  比如，我们去分配一个超大对象，类似一个超大数组超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以`直接抛出OutofMemoryError`。

### 2.2、内存泄漏 ###

> **内存泄漏（Memory Leak）**
> 
>  *  `对象已经不会再被程序使用到`了, 但是他们又`被GCRoot所关联`, 所以GC不能回收它们, 这种情况就叫做内存泄漏
>  *  有些时候`对象的生命周期`太长, 甚至会导致OOM, 在某种意义上也是`内存泄漏`
>  *  在`单例模式`中, 因为单例程序的生命周期一般和应用程序是一样的, 假如我们的`单例程序`中引用了外部对象的话, 该外部对象就一直不会被释放。
>  *  一些提供`close()`的资源, 未手动关闭, 它是不会自动释放; 比如`数据库连接connection, 网络连接socket, IO资源`, 这些资源一般在try catch finally的finally中释放, 如果手动释放, 那么它们就会一直存在内存中, 造成内存泄漏。

1.  也称作`“存储渗漏”`。严格来说，**只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。**
2.  但实际情况很多时候一些不太好的实践（或疏忽）会导致**对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”。**
3.  `尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OutofMemory异常，导致程序崩溃。`
4.  注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。

> **内存泄露的举例**

**官方例子**

*  左边的图：Java使用`可达性分析算法`，最上面的数据不可达，`就是需要被回收的对象`。
 *  右边的图：**后期有`一些对象不用了`，按道理应该断开引用，`但是存在一些链没有断开，从而导致没有办法被回收。`**

![image-20200712195158470][]

**我们的例子**

*  单例模式
    
     *  **单例的生命周期和应用程序是一样长的**，所以在单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
 *  **一些提供close()的资源未关闭导致内存泄漏**
    
     *  `数据库连接 dataSourse.getConnection()`，`网络连接socket和io连接必须手动close`，**否则是不能被回收的。**

## 3、Stop the World (停止用户线程) ##

> **关于 Stop the World 的理解**

1.  `Stop-the-World`，简称STW，指的是`GC事件发生过程`中，`会产生应用程序的停顿`。**停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。**
2.  可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿 (STW)，为什么需要停顿所有 Java 执行线程呢？
    
     *  **`分析工作`必须在一个能`确保一致性的快照`中进行; (不然分析出来的可达对象是不准确的.)**
     *  一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
     *  **`如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证`**
3.  被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以 **`我们需要减少STW的发生`**。

> **Stop the World 的注意事项**

1.  STW事件和采用哪款GC无关，**所有的GC都有这个事件。**
2.  哪怕是G1也不能完全避免Stop-the-world情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
3.  STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
4.  **开发中不要用System.gc() ，这会导致Stop-the-World的发生。**

## 4、垃圾回收的并行与并发 `(重要)` ##

### 4.1、并发的概念 ###

> **并发**

1.  在操作系统中，是指`一个时间段`中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在`同一个处理器`上运行
2.  `并发`不是真正意义上的`“同时进行”`，只是`CPU`把一个时间段划分成`几个时间片段`（时间区间），然后在这几个时间区间之间`来回切换`
3.  由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行

![image-20200712202522051][]

### 4.2、并行的概念 ###

> **并行**

1.  当系统有`一个以上CPU`时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，**两个进程互不抢占CPU资源**，`可以同时进行，我们称之为并行（Parallel）`
2.  其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行
3.  适合科学计算，后台处理等弱交互场景

![image-20200712202822129][]

> **并发与并行的对比**

1.  并发，指的是多个事情，在同一时间段内同时发生了。
2.  并行，指的是多个事情，在同一时间点上同时发生了。
3.  并发的多个任务之间是互相抢占资源的。并行的多个任务之间是不互相抢占资源的。
4.  `只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的。`

### 4.3、垃圾回收的并行与串行 ###

> **垃圾回收的并行与串行**

1.  `并行（Parallel）`：指`多条垃圾收集线程并行工作`，**但此时用户线程仍处于等待状态**。
    
     *  如`ParNew、Parallel Scavenge、Parallel Old`
2.  `串行（Serial）`
    
     *  相较于并行的概念，单线程执行。
     *  如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收（单线程）

![image-20200712203607845][]

### 4.4、垃圾回收的并发 ###

> **垃圾回收的并发 : 用户线程 和 垃圾收集线程 同时执行**

1.  `并发（Concurrent）`：指`用户线程`与`垃圾收集线程`同时执行（但不一定是并行的，可能会交替执行），**`垃圾回收线程在执行时不会停顿用户程序的运行`。**
2.  比如用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；
3.  **典型垃圾回收器：`CMS、G1`**

![image-20200712203815517][]

## 5、安全点与安全区域 (在安全区域才能GC) ##

> **安全点（Safepoint）**
> 
>  *  **`Safe Point的选择很重要，如果太少可能导致GC等待的时间太长(导致一直不会GC, 发生OOM)，如果太频繁可能导致运行时的性能问题。(STW, 用户体验不好)`**
>  *  选择一些执行时间较长的指令作为Safe Point，如 **`方法调用、循环跳转和异常跳转`**

1.  **程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，`这些位置称为“安全点（Safepoint）”。`**
2.  **Safe Point的选择很重要，如果太少可能导致GC等待的时间太长`(导致一直不会GC, 发生OOM)`，如果太频繁可能导致运行时的性能问题。`(STW, 用户体验不好)`**
3.  大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。
4.  比如：`选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转`等。

> **安全点的中断实现方式**

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

1.  `抢先式中断`：（目前没有虚拟机采用了）首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
2.  `主动式中断`：设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。（有轮询的机制）

> **安全区域（Safe Region）**

1.  Safepoint 机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？
2.  例如线程处于Sleep状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。
3.  对于这种情况，就需要安全区域（Safe Region）来解决。
4.  安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

> **安全区域的执行流程**

1.  当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程
2.  当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止；

## 6、再谈引用：强引用 `(重要)` ##

> **再谈引用**

1.  我们希望能描述这样一类对象：**`当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。`**
2.  **既偏门又非常高频的面试题：**`强引用、软引用、弱引用、虚引用有什么区别？具体使用场景是什么？`
3.  在JDK1.2版之后，Java对引用的概念进行了扩充，将引用分为：
    
     *  `强引用（Strong Reference）`
     *  `软引用（Soft Reference）`
     *  `弱引用（Weak Reference）`
     *  `虚引用（Phantom Reference）`
4.  这4种引用强度依次`逐渐减弱`。**除强引用外，其他3种引用均可以在java.lang.ref包中找到它们的身影。** 如下图，显示了这3种引用类型对应的类，开发人员可以在应用程序中直接使用它们。

![image-20200801111511851][]

> **四中引用类型的举例**

*  Reference子类中只有**终结器引用是包内可见**的，其他3种引用类型均为public，可以在应用程序中直接使用

1.  **`强引用（StrongReference）`**：最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即**类似“object obj=new Object()”这种引用关系**。`无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。`
2.  **`软引用（SoftReference）`**：**在系统将要发生`内存溢出(OOM)`之前，将会把这些对象`列入回收范围之中进行第二次回收`。如果这次回收后还没有足够的内存，才会抛出`内存溢出异常。`**
3.  **`弱引用（WeakReference）`**：**`被弱引用关联的对象只能生存到下一次垃圾收集之前`。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。**
4.  **`虚引用（PhantomReference）`**：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。**为一个对象设置虚引用关联的唯一目的`就是能在这个对象被收集器回收时收到一个系统通知。`**

> **强引用**

1.  在Java程序中，最常见的引用类型是强引用`（普通系统99%以上都是强引用）`，也就是我们最常见的普通对象引用，也是`默认的引用类型`。
2.  **当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。**
3.  `只要强引用的对象是可触及(被GCRoot所关联)的，垃圾收集器就永远不会回收掉被引用的对象。`
4.  对于一个普通的对象，如果没有其他的引用关系，**只要超过了引用的作用域或者显式地将相应（强）引用赋值为null**，就是可以**当做垃圾被收集**了，当然具体回收时机还是要看垃圾收集策略。
5.  相对的，**`软引用、弱引用和虚引用`的对象是软可触及、弱可触及和虚可触及的，在一定条件下，都是可以被回收的。**

*  **所以，`强引用`是造成`Java内存泄漏的`主要原因之一。**

> **强引用代码举例**

*  代码

/** * 强引用的测试 */
    public class StrongReferenceTest { 
        public static void main(String[] args) { 
            StringBuffer str = new StringBuffer ("Hello,guizy");
            StringBuffer str1 = str;
    
            str = null;
            System.gc();
    
            try { 
                Thread.sleep(3000);
            } catch (InterruptedException e) { 
                e.printStackTrace();
            }
    
            System.out.println(str1);
        }
    }

*  程序输出

Hello,guizy

*  局部变量str指向stringBuffer实例所在堆空间，通过str可以操作该实例，那么str就是stringBuffer实例的强引用对应内存结构：

StringBuffer str = new StringBuffer("hello mogublog");

![image-20200712211501377][]

*  如果此时，再运行一个赋值语句

StringBuffer str = new StringBuffer("hello mogublog");
    StringBuffer str1 = str;

![image-20200712211732976][]

*  在程序中我们将 str = null; 则 原来堆中的对象也不会被回收，因为还有其它对象指向该区域

**总结**

本例中的两个引用，都是强引用，强引用具备以下特点：

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

## 7、再谈引用：软引用 `(重要)` ##

> **软引用（Soft Reference）：内存不足即回收**
> 
>  *  被`软引用`的对象, 在GC第二次回收的时候, 发现内存不足, 此时才会将`软引用的对象`列入到`GC回收范围`; 第一次GC回收的是`不可达对象`
>  *  `当内存足够时，不会回收软引用可达的对象。内存不够时，会回收软引用的可达对象`

> **`软引用、弱引用都非常适合来保存那些可有可无的缓存数据。`** 如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

1.  **软引用是用来描述一些还有用，但非必需的对象。** 只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。注意，这里的第一次回收是不可达的对象
2.  **`软引用通常用来实现内存敏感的缓存。`** 比如：高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。
3.  垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列（Reference Queue）。
4.  类似弱引用，只不过Java虚拟机会尽量让软引用的存活时间长一些，迫不得已才清理。
5.  一句话概括：**`当内存足够时，不会回收软引用可达的对象。内存不够时，会回收软引用的可达对象`**

在JDK1.2版之后提供了`SoftReference类`来实现软引用

// 声明强引用
    Object obj = new Object();
    // 创建一个软引用
    SoftReference<Object> sf = new SoftReference<>(obj);
    obj = null; //销毁强引用，这是必须的，不然会存在强引用和软引用

> **软引用代码举例**

*  代码

/** * 软引用的测试：内存不足即回收 * -Xms10m -Xmx10m * * @author shkstart shkstart@126.com * @create 2020 16:06 */
    public class SoftReferenceTest { 
        public static class User { 
            public int id;
            public String name;
    
            public User(int id, String name) { 
                this.id = id;
                this.name = name;
            }
    
            @Override
            public String toString() { 
                return "[id=" + id + ", name=" + name + "] ";
            }
        }
    
        public static void main(String[] args) { 
            //创建对象，建立软引用
            SoftReference<User> userSoftRef = new SoftReference<User>(new User(1, "songhk"));
    
            /* 上面的一行代码，等价于如下的三行代码 User u1 = new User(1, "songhk"); SoftReference<User> userSoftRef = new SoftReference<User>(u1); u1 = null;//取消强引用 */
    
            //从软引用中重新获得强引用对象
            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 { 
                /* 再次从软引用中获取数据 在内存不够，报OOM之前，垃圾回收器会回收软引用的可达对象。 */
                System.out.println(userSoftRef.get());//
            }
        }
    }

*  在 JVM 内存不足时，会清理软引用对象

[id=1, name=songhk] 
    After GC:
    [id=1, name=songhk] 
    java.lang.OutOfMemoryError: Java heap space
    	at com.atguigu.java1.SoftReferenceTest.main(SoftReferenceTest.java:51)
    null

## 8、再谈引用：弱引用 `(重要)` ##

> **弱引用（Weak Reference）发现即回收**
> 
>  *  被`弱引用`关联的对象, 只能存活到`下一次GC`, 当`垃圾回收线程`发现`弱引用`, 无论内存是否充足, 都会被回收
>  *  当GC的时候, 软引用还需要通过`某种算法`来判断是否回收, 弱引用只要被发现,就被回收; 相对于软引用, 更容易回收

1.  **弱引用也是用来描述那些非必需对象**，`只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。`
2.  **但是，由于`垃圾回收器的线程`通常`优先级很低`，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。**
3.  弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的 **`引用队列`**，通过这个队列可以跟踪对象的回收情况。
4.  **软引用、弱引用都非常适合来保存那些可有可无的缓存数据。** 如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

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

在JDK1.2版之后提供了`WeakReference类`来实现弱引用

// 声明强引用
    Object obj = new Object();
    // 创建一个弱引用
    WeakReference<Object> sf = new WeakReference<>(obj);
    obj = null; //销毁强引用，这是必须的，不然会存在强引用和弱引用

> **面试题：你开发中使用过WeakHashMap吗？**
> 
>  *  **WeakHashMap用来存储图片信息，可以在内存不足的时候，及时回收，避免了OOM**

*  看源码，WeakHashMap 类中同样也维护了一个 Entry\[\] 数组

Entry<K,V>[] table;

*  Entry 类继承了 WeakReference 类

private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> { 
        V value;
        final int hash;
        Entry<K,V> next;

> **弱引用代码举例**

*  代码

/** * 弱引用的测试 * * @author shkstart shkstart@126.com * @create 2020 16:06 */
    public class WeakReferenceTest { 
        public static class User { 
            public User(int id, String name) { 
                this.id = id;
                this.name = name;
            }
    
            public int id;
            public String name;
    
            @Override
            public String toString() { 
                return "[id=" + id + ", name=" + name + "] ";
            }
        }
    
        public static void main(String[] args) { 
            //构造了弱引用
            WeakReference<User> userWeakRef = new WeakReference<User>(new User(1, "songhk"));
            //从弱引用中重新获取对象
            System.out.println(userWeakRef.get());
    
            System.gc();
            // 不管当前内存空间足够与否，都会回收它的内存
            System.out.println("After GC:");
            // 重新尝试从弱引用中获取对象
            System.out.println(userWeakRef.get());
        }
    }

*  执行垃圾回收后，弱引用对象必定被清除

[id=1, name=songhk] 
    After GC:
    null

## 9、再谈引用：虚引用 `(重要)` ##

> **虚引用（Phantom Reference）：对象回收跟踪**
> 
>  *  **一个对象`设置虚引用`关联的唯一目的`在于跟踪垃圾回收过程`**。比如：能在这个对象被收集器回收时收到一个系统通知。

1.  也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个
2.  一个对象是否有虚引用的存在，完全不会决定对象的生命周期。**如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。**
3.  **它不能单独使用**，也无法通过虚引用来获取被引用的对象。**当试图通过虚引用的get()方法取得对象时，总是null ，即通过虚引用无法获取到我们的数据**
4.  为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。比如：能在这个对象被收集器回收时收到一个系统通知。
5.  虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
6.  由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。

--------------------

在JDK1.2版之后提供了PhantomReference类来实现虚引用。

// 声明强引用
    Object obj = new Object();
    // 声明引用队列
    ReferenceQueue phantomQueue = new ReferenceQueue();
    // 声明虚引用（还需要传入引用队列）
    PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
    obj = null;

> **虚引用代码示例**

*  代码

/** * 虚引用的测试 * * @author shkstart shkstart@126.com * @create 2020 16:07 */
    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();
            }
        }
    }

*  `第一次尝试获取虚引用的值，发现无法获取的，这是因为虚引用是无法直接获取对象的值`; 然后进行第一次GC，因为会调用finalize方法 (只能调用一次)，将对象复活了，所以对象没有被回收
 *  但是调用第二次GC操作的时候，因为`finalize方法只能执行一次`，所以就触发了GC操作，`将对象回收了，同时将会触发第二个操作就是将待回收的对象存入到引用队列中。`

null
    调用当前类的finalize()方法
    obj 可用
    第 2 次 gc
    追踪垃圾回收过程：PhantomReferenceTest实例被GC了
    obj 是 null

## 10、再谈引用：终结器引用 ##

1.  **它用于`实现对象的finalize()`方法，也可以称为`终结器引用`**
2.  无需手动编码，其内部配合引用队列使用
3.  在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象调用它的finalize()方法，第二次GC时才回收被引用的对象

[image-20200731224709351]: /images/20221120/af7dae0dbb344abc9fd693c90e568ea2.png
[image-20200731224806161]: /images/20221120/61e58523c025453b92e4d6912f24997e.png
[image-20200731225006745]: /images/20221120/59058734d70a45b1b162523a83421cef.png
[image-20200731225047000]: /images/20221120/5c823d256f5a41a39db70156b47fb42f.png
[image-20200801093140763]: /images/20221120/fba6ec2e86b545e2b9a4ef1b3d7a44e5.png
[image-20200712195158470]: /images/20221120/a536d4dfb5bc48bbaca92f491205bc92.png
[image-20200712202522051]: /images/20221120/bf8aa1587a494ddba29946414be37f99.png
[image-20200712202822129]: /images/20221120/c7a3285a7abc49e9a9bdb07979078ad9.png
[image-20200712203607845]: /images/20221120/f9f70c06a6d6409b90a868630de57187.png
[image-20200712203815517]: /images/20221120/c0a17344ba1a4c76809da60c54c32214.png
[image-20200801111511851]: /images/20221120/26abeb899de34389b60975d7edc87ec2.png
[image-20200712211501377]: /images/20221120/920d573cb5f246d5b3de4791883898c7.png
[image-20200712211732976]: /images/20221120/07daf4568252482ba9bd90390b51a047.png