类实例与类的垃圾回收

拼搏现实的明天。 2022-09-05 00:07 99阅读 0赞

## 前言 ##

近期在蚂蚁金服接触了SOFAArk，其中涉及到类的动态装配与卸载，对垃圾回收有了进一步的理解。  
首先垃圾回收我认为可以分为实例的垃圾回收（堆中的对象）以及类的垃圾回收（类卸载，发生在方法区）

## 类的生命周期 ##

[https://blog.csdn.net/xorxos/article/details/80490240][https_blog.csdn.net_xorxos_article_details_80490240]  
　当类被加载、连接和初始化后，它的生命周期就开始了。**（注意这一步是类加载的过程）**

当代表类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，**类在方法区内的数据也会被卸载**，从而结束类的生命周期。  
　由此可见，一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

## 类实例的生命周期 ##

类实例经过new之后，在堆开辟空间，类实例的生命周期开始了。**（注意这是对象的创建过程）**  
![在这里插入图片描述][ae644d70c4554c4eaaf0e5632ca338bd.png]

类实例生命周期的结束即实例的垃圾回收，发生在堆，根据引用计数法和可达性分析判断一个对象是否死亡，死亡后进行回收即结束。

> ①类加载检查： 虚拟机遇到⼀条 new 指令时，⾸先将去检查这个指令的参数是否能在常量池中定位到  
> 这个类的符号引⽤，并且检查这个符号引⽤代表的类是否已被加载过、解析和初始化过。如果没有，那 必须先执⾏相应的类加载过程。  
> ②分配内存：  
> 在类加载检查通过后，接下来虚拟机将为新⽣对象分配内存。对象所需的内存⼤⼩在类  
> 加载完成后便可确定，为对象分配空间的任务等同于把⼀块确定⼤⼩的内存从 Java 堆中划分出来。分 配⽅式有 “指针碰撞” 和 “空闲列表”  
> 两种，选择那种分配⽅式由 Java 堆是否规整决定，⽽Java堆是 否规整⼜由所采⽤的垃圾收集器是否带有压缩整理功能决定。  
> 内存分配的两种⽅式：（补充内容，需要掌握） 选择以上两种⽅式中的哪⼀种，取决于 Java 堆内存是否规整。⽽ Java  
> 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内  
> 存也是规整的 内存分配并发问题（补充内容，需要掌握）  
> 在创建对象的时候有⼀个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的  
> 事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采⽤两种⽅式来保证线程安全： CAS+失败重试： CAS  
> 是乐观锁的⼀种实现⽅式。所谓乐观锁就是，每次不加锁⽽是假设没有冲 突⽽去完成某项操作，如果因为冲突失败就重试，直到成功为⽌。虚拟机采⽤  
> CAS 配上失败重 试的⽅式保证更新操作的原⼦性。 TLAB：  
> 为每⼀个线程预先在Eden区分配⼀块⼉内存，JVM在给线程中的对象分配内存时，⾸先在  
> TLAB分配，当对象⼤于TLAB中的剩余内存或TLAB的内存已⽤尽时，再采⽤上述的CAS进⾏内存分 配  
> ③初始化零值：  
> 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象 头），这⼀步操作保证了对象的实例字段在 Java  
> 代码中可以不赋初始值就直接使⽤，程序能访问到这 些字段的数据类型所对应的零值  
> ④设置对象头：  
> 初始化零值完成之后，虚拟机要对对象进⾏必要的设置，例如这个对象是那个类的实 例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC  
> 分代年龄等信息。 这些信息存放在对 象头中。 另外，根据虚拟机当前运⾏状态的不同，如是否启⽤偏向锁等，对象头会有不同的设置⽅ 式。  
> ⑤执⾏  
> init ⽅法： 在上⾯⼯作都完成之后，从虚拟机的视⻆来看，⼀个新的对象已经产⽣了，但从 Java 程序的视⻆来看，对象创建才刚开始，  
> ⽅法还没有执⾏，所有的字段都还为零。所以⼀ 般来说，执⾏ new 指令之后会接着执⾏  
> ⽅法，把对象按照程序员的意愿进⾏初始化，这样 ⼀个真正可⽤的对象才算完全产⽣出来。

## 类实例的垃圾回收 ##

发生在堆，根据可达性分析和引用计数法，判断对象实例死亡后，进行回收，回收也不是马上进行，会有个宣布死刑的“缓刑期”，然后执行finalized方法。

## 类的垃圾回收 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDI3MzMwMg_size_16_color_FFFFFF_t_70]  
[https://www.cnblogs.com/yuexiaoyun/articles/14001377.html][https_www.cnblogs.com_yuexiaoyun_articles_14001377.html]  
发生在方法区，即类的卸载。条件严苛：  
1、该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。  
2、加载该类的 ClassLoader 已经被回收。  
3、该类对应的 java.lang.Class 对象没有在任何地⽅被引⽤，⽆法在任何地⽅通过反射访问该类的⽅法。  
注意：  
使用启动类加载器装载的类型永远是可触及的，所以永远不会被卸载。只有使用用户定义的类装载器装载的类型才会变成不可触及的，从而被虚拟机回收。  
**总结：**  
要进行类卸载（方法区回收类的二进制数据结构），要将堆中的类加载器对象、类的Class对象、类的实例对象全部回收，然后再进行类卸载。  
Java虛拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了一Xnoclassgc 参数进行控制，还可以使用-verbose：class以及-XX： +TraceClass一Loading、-XX：+TraceClassUnLoading查看类加载和卸载信息。

## SOFAArk中类卸载的思考 ##

SOFAArk卸载类并不能完全卸载干净，因此要保证每个模块尽量小。根据类卸载的过程，我理解为方法区中类并不能完全将所有类相关的数据结构卸载干净。

## SOFAArk中Biz卸载面临的挑战 ##

这要从biz的生命周期说起。  
[https://www.sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/][https_www.sofastack.tech_projects_sofa-boot_sofa-ark-biz-lifecycle]

卸载 Biz 最大的挑战在于 ClassLoader 的卸载，如果 ClassLoader 没有卸载干净，极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻，包含：

*  该类所有实例都已经回收
 *  加载该类的 ClassLoader 已经回收
 *  该类对应的 java.lang.Class 对象已经没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

每个 Biz 都由独立的 BizClassLoader 加载，只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用，则会导致 Biz 无法卸载成功

[https_blog.csdn.net_xorxos_article_details_80490240]: https://blog.csdn.net/xorxos/article/details/80490240
[ae644d70c4554c4eaaf0e5632ca338bd.png]: /images/20220829/f06c4e576b92434ca933013373db7902.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDI3MzMwMg_size_16_color_FFFFFF_t_70]: /images/20220829/025f6e46bd934cb89beecb6289f530a9.png
[https_www.cnblogs.com_yuexiaoyun_articles_14001377.html]: https://www.cnblogs.com/yuexiaoyun/articles/14001377.html
[https_www.sofastack.tech_projects_sofa-boot_sofa-ark-biz-lifecycle]: https://www.sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/