我所知道JVM虚拟机之类的生命周期四（unloading 卸载阶段）

前言

前边几篇文章讲解了类的生命周期之加载，链接，初始化阶段，接下来我们要说说的是卸载阶段

那么想要讲解卸载阶段，那么就要搞懂类、类加载器、类的实例之间的引用关系

比如说此时有一个示例Sample类

此时我们当Sample类被加载、链接和初始化后，它的生命周期就开始了。

当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期

注意：一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期

类、类的加载器、类的实例之间的引用关系

在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。

另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见代表某个类的Class实例与其类的加载器之间为双向关联关系

一个类的实例总是引用代表这个类的Class对象，在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。

此外所有的Java类都有一个静态属性class，它引用代表这个类的Class对象

以之前的示例Sample类来说，请看下列图示

loader1变量和obj变量间接应用代表Sample类的Class对象，而objClass变量则直接引用它。

若我们想代表Sample类的Class对象被回收掉（属于堆空间的对象）

这时栈空间里的ObjClass引用变量指针需要干掉，但是发现Obj引用变量指针还在引用

所以我们需要把obj引用变量的指针也干掉，切断联系

这时我们还发现loader1引用指针还在指向MyClassLoader对象，并且同时也指向代表Sample类的Class对象，所以我们还要接着干掉

如果程序运行过程中，将上图左侧三个引用变量都置为null

此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。

当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载

如果不存在Sample类会被重新加载，在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。

此时我们就可以发现回收Class对象，就比较的苛刻，此时我们回顾一下方法区的垃圾回收

回顾方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型

HotSpot虚拟机对常量池的回收策略是很明确的：只要常量池中的常量没有被任何地方引用，就可以被回收

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:

• 该类所有的实例都已经被回收，也就是]ava堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、3SP的重加载等，否则通常是很难达成的。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

接下来我们了解清楚类、类加载器、类的实例之间的引用关系，就可以来看看类的卸载怎么回事了

类的卸载

启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)

被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载

因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。

被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。

比如稍微复杂点的应用场景中(示例:很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)，被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。

综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。

同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能