前言
近期在蚂蚁金服接触了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 无法卸载成功