前提

结合我的上一章【你好,Class 字节码https://xie.infoq.cn/article/274ce981e1c2b4c95d01efe6d】介绍，大家对我们的这位“好朋友”的一个特征，Class 字节码有了一定的了解了吧，如果还保护了解，请给小编留言，我一定继续努力让大家对“好朋友”的印象更深一步。

接下来，我们换一个话题聊聊，说说我们这个“好朋友”的另外一个很重要的特点：类加载器，我擅自

把它比作的眼睛或者心灵的窗口哦。

概述

class 字节码(类)被加载到计算机系统内存中，从被加载到内存中开始，到卸载出内存为止，它的整个生命周期包括:加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7 个阶段。其中验证、准备、解析 3 个部分统称为链接(Linking)。

初始化阶段，规范则是严格规定了有且只有 5 种情况必须执行立即对类进行“初始化”，在此之前

必须要完成相关的“加载、验证、准备、[解析]”。

1) 当遇到执行 [getstatic、putstatic、invokestatic、new]，如果在类没有进行初始化的时候，需要先强制处罚初始化之后，在进行调用对应的方法。此外 final 类型的字段，基本上会在编译的时候进行赋值到常量池中去。

• getstatic 方法：读取非 final 类型的 static 的字段

• putstatic 方法：读取非 final 类型的 static 的字段

• invokestatic 方法：调用相关的类的静态 static 方法

• new 创建对象：new 关键字实例化对象

2) 当执行反射 Reflection 机制，进行控制相关的操作，如果类未进行相关的初始化，则必须需要进行初始化操作。

3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4) 当进程启动时，用户需要指定一个要执行的主类(包含 main 方法的那个类),必须先进行初始化加载这个主类。

5)当使用 JDK1.7 的动态语言支持时（invokedynamic），如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

加载

需要完成以下 3 件事情:

1. 通过一个类的全限定名来获取定义此类的二进制字节流。

2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3. 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

常量 HELLOWORLD，但其实在编译阶段通过常量传播优化，已经将此常量的值“helloworld”存储到了 NotInitialization 类的常量池中，以后 NotInitialization 对常量 ConstClass.HELLOWORLD 的引用实际都被转化为 NotInitialization 类对自身常量池的引用了。 也就是说，实际上 NotInitialization 的 Class 文件之中并没有 ConstClass 类的符号引用入口，这两个类在编译成 Class 之后就不存在任何联系了。

链接

验证

连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前必须要求，并且不会危害系统自身的安全。但从整体上看，验证阶段大致上会完成下面 4 个阶段的检验动作:文件格式验证、元数据验证、字节码验证、符号引用验证。

准备

正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的概念需要强调一下。

首先，这时候进行内存分配的仅包括类变量(被 static 修饰的变量)，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。

其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为:public static int value=123;那变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时候尚未开始执行任何 Java 方法，而把 value 赋值为 123 的 putstatic 指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把 value 赋值为 123 的动作将在初始化阶段才会执行。

假设上面类变量 value 的定义变为:public static final int value=123; 编译时 Javac 将会为 value 生成 ConstantValue 属性，在准备阶段就会根据 ConstantValue 的设置将 value 赋值为 123。

解析

"这位朋友"将常量池内的符号引用替换为直接引用的过程，主要通过结合常量池链接索引表+各部分的数据表+无符号数进行加息相关的数据整合。

初始化

类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由系统主导和控制。

初始化阶段，才真正开始执行类中定义的 Java 程序代码在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达: 初始化阶段是执行类构造器<clinit>()方法的过程。

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的。<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

“朋友”会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞。

类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在 Java 系统中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些:比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class 文件，被同一个加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

这里所指的“相等”，包括代表类的 Class 对象的 equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。

自定义 ClassLoader 的子类时候，我们常见的会有两种做法，一种是重写 loadClass 方法，另一种是重写 findClass 方法。其实这两种方法本质上差不多，毕竟 loadClass 也会调用 findClass，但是从逻辑上讲我们最好不要直接修改 loadClass 的内部逻辑。我建议的做法是只在 findClass 里重写自定义类的加载方法。

类加载器种类

两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使用 C++语言实现，是“它”自身的一部分;另一种就是所有其他的类加载器，这些类加载器都由 Java 语言实现，并且全都继承自抽象类 java.lang.ClassLoader。启动类加载器(Bootstrap ClassLoader):这个类将器负责将存放在<JAVA_HOME>\lib 目录中的，或者被-Xbootclasspath 参数所指定的路径中的，并且是可以识别的(仅按照文件名识别，如 rt.jar，名字不符合类库即使放在 lib 目录中也不会被加载)类库加载到方法区内存中。

启动类加载器无法被 Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用 null 代替即可。

扩展类加载器(Extension ClassLoader):这个加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载<JAVA_HOME>\lib\ext 目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器(Application ClassLoader):这个类加载器由 sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。我们的应用程序都是由这 3 种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。

双亲委托模型

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承(Inheritance)的关系来实现，而是都使用组合(Composition)关系来复用父加载器的代码。

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为 java.lang.Object 的类，并放在程序的 ClassPath 中，那系统中将会出现多个不同的 Object 类，Java 类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

Tomcat 类加载器

本身也是一个 java 项目，因此其也需要被 JDK 的类加载机制加载，也就必然存在引导类加载器、扩展类加载器和应用(系统)

Common ClassLoader 作为 Catalina ClassLoader 和 Shared ClassLoader 的 parent，而 Shared ClassLoader 又可能存在多个 children 类加载器 WebApp ClassLoader，一个 WebApp ClassLoader 实际上就对应一个 Web 应用，那 Web 应用就有可能存在 Jsp 页面，这些 Jsp 页面最终会转成 class 类被加载，因此也需要一个 Jsp 的类加载器。需要注意的是，在代码层面 Catalina ClassLoader、Shared ClassLoader、CommonClassLoader 对应的实体类实际上都是 URLClassLoader 或者 SecureClassLoader，一般我们只是根据加载内容的不同和加载父子顺序的关系，在逻辑上划分为这三个类加载器;而 WebApp ClassLoader 和 JasperLoader 都是存在对应的类加载器类的。

1. Bootstrap 引导类加载器加载 JVM 启动所需的类，以及标准扩展类(位于 jre/lib/ext)

2. Catalina 系统类加载器 加载 tomcat 启动的类，比如 bootstrap.jar，通常在 catalina.bat 或者 catalina.sh 中指定。位于 CATALINA_HOME/bin

3. Common 通用类加载器 加载 tomcat 使用以及应用通用的一些类，位于 CATALINA_HOME/lib 下

4. Shared 共享类加载器 加载所有 webapp 应用的共享的服务类库。

5. Webapp 应用类加载器每个应用在部署后，都会创建一个唯一的类加载器。该类加载器会加载位于 WEB-INF/lib 下的 jar 文件中的 class 和 WEB-INF/classes 下的 class 文件。

总结

总体进行类加载器机制的分析和了解本期就到这里，未完待续......