前言
近期在蚂蚁金服接触了SOFAArk,其中涉及到类的动态装配与卸载,对垃圾回收有了进一步的理解。 首先垃圾回收我认为可以分为实例的垃圾回收(堆中的对象)以及类的垃圾回收(类卸载,发生在方法区)
类的生命周期
https://blog.csdn.net/xorxos/article/details/80490240 当类被加载、连接和初始化后,它的生命周期就开始了。(注意这一步是类加载的过程)
当代表类的Class对象不再被引用,即不可触及时,Class对象就会结束生命周期,类在方法区内的数据也会被卸载,从而结束类的生命周期。 由此可见,一个类何时结束生命周期,取决于代表它的Class对象何时结束生命周期。
类实例的生命周期
类实例经过new之后,在堆开辟空间,类实例的生命周期开始了。(注意这是对象的创建过程)
类实例生命周期的结束即实例的垃圾回收,发生在堆,根据引用计数法和可达性分析判断一个对象是否死亡,死亡后进行回收即结束。
①类加载检查: 虚拟机遇到?条 new 指令时,?先将去检查这个指令的参数是否能在常量池中定位到 这个类的符号引?,并且检查这个符号引?代表的类是否已被加载过、解析和初始化过。如果没有,那 必须先执?相应的类加载过程。 ②分配内存: 在类加载检查通过后,接下来虚拟机将为新?对象分配内存。对象所需的内存??在类 加载完成后便可确定,为对象分配空间的任务等同于把?块确定??的内存从 Java 堆中划分出来。分 配?式有 “指针碰撞” 和 “空闲列表” 两种,选择那种分配?式由 Java 堆是否规整决定,?Java堆是 否规整?由所采?的垃圾收集器是否带有压缩整理功能决定。 内存分配的两种?式:(补充内容,需要掌握) 选择以上两种?式中的哪?种,取决于 Java 堆内存是否规整。? Java 堆内存是否规整,取决于 GC 收集器的算法是"标记-清除",还是"标记-整理"(也称作"标记-压缩"),值得注意的是,复制算法内 存也是规整的 内存分配并发问题(补充内容,需要掌握) 在创建对象的时候有?个很重要的问题,就是线程安全,因为在实际开发过程中,创建对象是很频繁的 事情,作为虚拟机来说,必须要保证线程是安全的,通常来讲,虚拟机采?两种?式来保证线程安全: CAS+失败重试: CAS 是乐观锁的?种实现?式。所谓乐观锁就是,每次不加锁?是假设没有冲 突?去完成某项操作,如果因为冲突失败就重试,直到成功为?。虚拟机采? CAS 配上失败重 试的?式保证更新操作的原?性。 TLAB: 为每?个线程预先在Eden区分配?块?内存,JVM在给线程中的对象分配内存时,?先在 TLAB分配,当对象?于TLAB中的剩余内存或TLAB的内存已?尽时,再采?上述的CAS进?内存分 配 ③初始化零值: 内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象 头),这?步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使?,程序能访问到这 些字段的数据类型所对应的零值 ④设置对象头: 初始化零值完成之后,虚拟机要对对象进?必要的设置,例如这个对象是那个类的实 例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。 这些信息存放在对 象头中。 另外,根据虚拟机当前运?状态的不同,如是否启?偏向锁等,对象头会有不同的设置? 式。 ⑤执? init ?法: 在上??作都完成之后,从虚拟机的视?来看,?个新的对象已经产?了,但从 Java 程序的视?来看,对象创建才刚开始, ?法还没有执?,所有的字段都还为零。所以? 般来说,执? new 指令之后会接着执? ?法,把对象按照程序员的意愿进?初始化,这样 ?个真正可?的对象才算完全产?出来。
类实例的垃圾回收
发生在堆,根据可达性分析和引用计数法,判断对象实例死亡后,进行回收,回收也不是马上进行,会有个宣布死刑的“缓刑期”,然后执行finalized方法。
类的垃圾回收
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/
卸载 Biz 最大的挑战在于 ClassLoader 的卸载,如果 ClassLoader 没有卸载干净,极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻,包含:
- 该类所有实例都已经回收
- 加载该类的 ClassLoader 已经回收
- 该类对应的 java.lang.Class 对象已经没有在任何地方被引用,无法在任何地方通过反射访问该类的方法
每个 Biz 都由独立的 BizClassLoader 加载,只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用,则会导致 Biz 无法卸载成功
|