JVM（四）：GC垃圾回收算法

一时失言乱红尘 2022-12-06 04:29 231阅读 0赞

### 目录 ###

*  垃圾回收器与内存分配策略
 *   *  1.1 起源
     *  1.2 对象已死？
     *   *  1.2.1 引用计数算法
         *  1.2.2 可达性算法
         *  1.2.3 四大引用
         *  1.2.4 finalize()方法
         *  1.2.5 回收方法区
     *  1.3 垃圾回收算法
     *   *  1.3.1 分代收集理论
         *  1.3.2 标记-清除算法
         *  1.3.3 标记-复制算法
         *  1.3.4 标记-整理算法

# 垃圾回收器与内存分配策略 #

## 1.1 起源 ##

Lisp是第一门开始使用内存动态分配和垃圾收集技术的语言

作者John McCarthy思考过垃圾收集需要完成的哪三件事？

*  哪些内存需要回收？
 *  什么时候回收？
 *  如何回收？

程序计数器、虚拟机栈、本地方法区随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出，有条不紊的执行着出栈和进栈的操作，这几个内存分配具有确定性，不需要考虑内存回收的问题

堆和方法区这两个区域则由很多的不确定性：一个接口的多个实现类内存需要可能不一样…

只有处于运行期间，我们才能知道程序创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器关注的正是这部分内存该如何存储

## 1.2 对象已死？ ##

在堆中存放Java的所有对象实例，垃圾收集器在对堆进行回收前，第一件事就是要确定哪些对象是死的，哪些对象是存活的。

### 1.2.1 引用计数算法 ###

判断对象是否存活的条件：在对象中添加一个引用计数器，每当有一个地方引用时，引用计数器+1，当引用失效时，引用计数器-1，任何时刻引用计数为零的对象就是不可能再被使用的

在其他语言中，有的使用了引用计数算法，但在Java中，我们就没有使用该算法，原因是：这个看似简单的算法，必须要配合大量的处理才能合理的运行，比如：对象之间的循环引用，基本无法解决

public class YinYong {
        
    	public Object instance = null;
    	public static void main(String[] args) {
        
    		YinYong test1 = new YinYong();
    		YinYong test2 = new YinYong();
    		test1.instance = test2;
    		test2.instance = test1;
    		test1 = null;
    		test2 = null;
    		System.gc();
    	}
    }

关于上面这个循环引用的算法，《深入理解Java虚拟机》并没有介绍特别清楚，这里详细介绍一下

线程私有区

*  程序计数器：记录正在执行的虚拟机字节码的地址
 *  虚拟机栈：方法执行的内存区，每个方法执行时都会在虚拟机栈中创建栈帧
 *  本地方法栈：虚拟机的Native方法执行的内存区

线程共享区

*  Java堆：对象分配的区域，这是垃圾回收的主要区域
 *  方法区：存放着类信息、常量、静态变量等数据、常量池

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center]

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T5YaM7nX-1599899310955)(C:\\Users\\黄良帅\\AppData\\Roaming\\Typora\\typora-user-images\\1599651456948.png)\]][img-T5YaM7nX-1599899310955_C_Users_AppData_Roaming_Typora_typora-user-images_1599651456948.png]

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1WOvLUaC-1599899310961)(C:\\Users\\黄良帅\\AppData\\Roaming\\Typora\\typora-user-images\\1599651471659.png)\]][img-1WOvLUaC-1599899310961_C_Users_AppData_Roaming_Typora_typora-user-images_1599651471659.png]

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v8UhF77J-1599899310965)(C:\\Users\\黄良帅\\AppData\\Roaming\\Typora\\typora-user-images\\1599651482026.png)\]][img-v8UhF77J-1599899310965_C_Users_AppData_Roaming_Typora_typora-user-images_1599651482026.png]

### 1.2.2 可达性算法 ###

算法思路：通过一系列成为"GC Roots"的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程中的路径被称为"引用链"，如果某个对象到GC Roots之间没有引用链连接的话或者图论也就是不可达，那么这个对象就可以被回收了

GC Root的对象：

*  虚拟机栈中引用的对象
 *  方法区中类静态属性引用的对象
 *  常量池中引用的对象
 *  本地方法栈JNI，也就是Native引用的对象

![img][]

### 1.2.3 四大引用 ###

无论是引用计数法还是可达性分析，都离不开引用这个词，在Java中引用主要有强引用、软引用、弱引用、虚引用。

*  强引用—不回收、 StrongReference
    
    对于强引用来说，是我们经常使用的大部分都是强引用，**如果一个对象具有强引用**，那就类似于必不可少的生活用品，**垃圾回收器不会回收它**。当我们的**空间不足时**，JVM宁愿抛出**OutOfMemoryError**也就是内存溢出，让程序终止，也不会靠随意的回收具有强引用的对象来解决内存不足的问题
    
        StringBuffer buffer = new StringBuffer();
        StringBuffer buffer1 = buffer;
    
    对于一个普通的对象，如果没有其他引用的关系，只要**超过了引用的作用域或者将强引用赋值为null**，就是可以当做垃圾被收集了
 *  软引用—有用但非需、内存不足既回收、 SoftReference
    
    1.  内存足够时，不会回收软引用的可达对象
    2.  当内存不够时，就会进行回收可达对象，如果回收完之后，内存还不够，就会报OOM
    
        user u1 = new user( 1,"songhk");
         softReference<User> userSoftRef = new SoftReference<User>(u1);
         ul = null;
    
    软引用通常实现缓存。比如：图片缓存和网页缓存用到软引用
    
    如果还有空间，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同 时，不会耗尽内存
 *  弱引用----发现既回收、WeakReference
    
    弱引用也是用来描述那些非必需对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。
    
    例子：存储可有可无的数据：
    
    WeakHashMap：内存不足时就会被回收，内部的Entry继承类WeakReference
 *  虚引用——对象回收跟踪、Phantom Reference
    
    一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收
    
    它不能单独使用，必须和引用队列（ ReferenceQueue ），当垃圾回收器准备回收对象时，如果发现他还有虚引用，就会在回收对象的回收之前，把这个虚引用加入到引用队列中，从而可以查看当前JVM垃圾回收的情况

### 1.2.4 finalize()方法 ###

如果一个对象经过我们可达性算法的计算，判定为不可达的对象，并不是直接将其进行杀死 ，而是进入到一个缓刑的阶段

真正宣告一个对象是否死亡要经历两次标记过程：

*  如果对象在进行可达性分析后，发现对象不可达，则将会进行第一次标记，随后进行一次筛选，条件为：是否有必要执行finalize方法，如果对象没有重写finalize方法或者finalize已经被调用一次，JVM判定没有必要执行，直接进行回收
 *  如果JVM判定有必要执行finalize的话，会将其放在一个F-Quene的队列中，并执行对象的finalize方法，同样JVM对队列中的对象进行标记。如果这时候对象的finalize方法中，将自己与引用链上的任何一个对象建立了联系，那样，JVM就会在第二次标记的时候将它移出“即将回收”的集合

建议：因为finalize方法的出现具有一定的戏剧色彩，为了使C、C++的程序猿更容易接受而做出的妥协

### 1.2.5 回收方法区 ###

方法区主要回收两部分内容：废弃的常量和不再使用的类型

而对于一个类型是否被回收就比较困难，需要满足三个条件：

*  所有的实例都被回收，也就是堆中不存在该类和派生子类
 *  加载该类的加载器也被回收（基本不可能达成）
 *  该类在java.lang.Class对象没有在任何地方引用

## 1.3 垃圾回收算法 ##

垃圾收集算法可以划分为”引用计数式垃圾收集“和”追踪式垃圾收集“

### 1.3.1 分代收集理论 ###

两个假说：

*  弱分代假说：绝大多数的对象都是朝生夕灭的
 *  强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡

设计原则：收集器应该将Java堆划分不同的区域，然后将回收对象依据其年龄分配到不同的区域进行存储

设计者将堆分为新生代和老年代两个区域，本来这种想法挺好的，但是出现了一个问题，也就是对象之间会存在跨代引用

我们要对新生代的对象进行垃圾的收集，但某个对象引用了老年代中的数据，不得不再去遍历老年代中的对象来确保可达性分析结果的准确性

所以，为这个理论增添了第三条经验法则：

*  跨代引用假说：跨代引用相对于同代引用来说，仅占少数

基于这条假说，我们对于那些隔代引用的对象，不再去单独的扫描他们，而是将他们放在一个新生代记忆集的数据结构中

部分收集—Partial GC

*  新生代收集：目标是新生代的
 *  老年代收集：目标是老年代的 CMS收集器
 *  混合收集：目标整个新生代和部分老年代 G1收集器

整堆收集----Full GC：收集整个Java堆和方法区的垃圾收集

### 1.3.2 标记-清除算法 ###

这是最早出现的垃圾清除算法

算法分为两个阶段：先对要回收的对象进行标记，然后再进行回收

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 1]

缺点：

*  执行效率不稳定：堆中有大量对象，会进行大量的标记和清除
 *  内部的碎片化问题：标记和清除之后会产生大量的不连续的内存碎片

### 1.3.3 标记-复制算法 ###

半区复制的垃圾收集算法

将可用内存按容量划分为大小相等的两块，每次使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把使用过的内存空间一次性清理掉。

在1989年，提出了一种更加优化的半区复制算法，将新生代分成了一块较大的伊甸园区和两块较小的幸存区

每次分配内存只使用伊甸园和一块幸存区，发生垃圾收集时，将伊甸园和幸存区存活的对象一次性复制到另外一个幸存区，然后直接清理掉伊甸园和已用过的幸存区。

在新生代中的对象存活比较少，所以可以一次性复制到幸存区，但是如果万一超过了内存，怎么办？

需要依赖其他内存区域，也就是老年代进行内存分配担保

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 2]

优点：不会产生内存碎片

缺点：内存间赋值开销 只有一半空间可用 空间浪费太多

### 1.3.4 标记-整理算法 ###

标记过程仍然使用标记-清除，后序步骤将所有存活的对象都向内存空间一端移动，然后清理掉边界以外的内存

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 3]

缺点：在每次移动的过程中，尤其是对老年代这种存活对象多的区域，会导致效率的降低

优点：没有了内存碎片的产生

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/3fa664a699884006829ec62cabbaf6c4.png
[img-T5YaM7nX-1599899310955_C_Users_AppData_Roaming_Typora_typora-user-images_1599651456948.png]: /images/20221123/d2a3e710e8ae4ccf83d1c41096d3c9fd.png
[img-1WOvLUaC-1599899310961_C_Users_AppData_Roaming_Typora_typora-user-images_1599651471659.png]: /images/20221123/e0d9a7be3e6c451e9379717f4bb01ac0.png
[img-v8UhF77J-1599899310965_C_Users_AppData_Roaming_Typora_typora-user-images_1599651482026.png]: /images/20221123/4e1ff2ee58964974b468ae5422144a04.png
[img]: /images/20221123/b5ac923e186e40f99d8877c92d74d225.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/02150fd5e7144ad6adf49d101ddbac78.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/8968ccc4bd924ecbbcfa19410292f7f2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTE1NDM5_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/24e19d5d9ea14f5aa67fa66bd5627bd6.png