文章目录
- [1. 类的使用](#1. 类的使用)
- [2. 类的卸载](#2. 类的卸载)
-
- [2.1 类、类的加载器、类的实例之间的引用关系](#2.1 类、类的加载器、类的实例之间的引用关系)
- [2.2 何种情况会被卸载](#2.2 何种情况会被卸载)
- [2.3 类卸载在实际生产中情况如何](#2.3 类卸载在实际生产中情况如何)
- [2.4 方法区的垃圾回收](#2.4 方法区的垃圾回收)
上一篇文章: JVM 类的加载过程详解 介绍了类的加载过程, 这篇文章来介绍类在完成加载后的使用及其卸载.
1. 类的使用
任何一个类型在使用之前都必须经历过完整的 加载、链接和初始化 3个加载步骤。
一旦一个类型成功经历过这3个步骤之后, 开发人员便可以对其上下其手了。
当类加载完成后，开发人员可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用 new 关键字为其创建对象实例。以下是一些举例：
-
实例化对象：使用 new 关键字实例化类的对象。例如：
MyClass obj = new MyClass(); -
调用静态方法：直接通过类名调用静态方法。例如：
MyClass.staticMethod(); -
访问静态变量：通过类名访问静态变量。例如：
MyClass.staticVariable; -
通过反射：通过反射机制可以在运行时动态获取类的信息并调用其方法。可以使用
Class.forName("ClassName")获取类对象，然后调用相应的方法。 -
加载资源文件：可以使用类加载器加载类路径下的资源文件，如配置文件等。例如：
MyClass.class.getResourceAsStream("config.properties"); -
使用类的实例方法：通过类的实例调用其方法。例如：
obj.instanceMethod(); -
继承和多态：如果类是子类，可以通过父类引用指向子类对象实现多态。例如：
ParentClass obj = new ChildClass(); -
内部类的使用：如果类中包含内部类，可以通过外部类实例化内部类对象。例如：
OuterClass.InnerClass innerObj = outerObj.new InnerClass();
2. 类的卸载
2.1 类、类的加载器、类的实例之间的引用关系
在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。
2.2 何种情况会被卸载
一个类何时结束生命周期，取决于代表它的 Class 对象何时结束生命周期。
举例：
当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期。
loader1变量和obj变量间接引用代表Sample类的Class对象，而objClass变量则直接引用它。
如果程序运行过程中，将上图左侧三个引用变量都置为null，此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。
当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载；如果不存在Sample类会被重新加载，在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。
2.3 类卸载在实际生产中情况如何
类的卸载
(1) 启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)
(2) 被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到 unreachable 的可能性极小。
(3) 被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中(比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)，被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。
综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。
2.4 方法区的垃圾回收
方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量 和 不再使用的类型。
HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
判定一个常量是否"废弃"还是相对简单，而要判定一个类型是否属于"不再被使用的类"的条件就比较苛刻了。需要同时满足下面 三个条件：
- 该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
- 加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是"被允许"，而并不是和对象一样，没有引用了就必然会回收。
