类加载机制

1. 类加载机制

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

加载.class文件的方式：

• 从本地系统中直接加载
• 通过网络下载.class文件
• 从zip，jar等归档文件中加载.class文件
• 从专有数据库中提取.class文件
• 将Java源文件动态编译为.class文件

2. 类的生命周期

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

2.1. 加载

查找并加载类的二进制数据加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

• 通过一个类的全限定名来获取其定义的二进制字节流。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
• 在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

2.2. 验证

验证：确保被加载的类的正确性

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

2.3. 准备

为类的静态变量分配内存，并将其初始化为默认值

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

1. 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
2. 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

假设一个类变量的定义为：public static int value = 3；

那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的public static指令是在程序编译后，存放于类构造器（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。

这里还需要注意如下几点：

• 对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
• 对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
• 对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
• 如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。

1. 如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

假设上面的类变量value被定义为： public static final int value = 3；

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中

2.4. 解析

把类中的符号引用转换为直接引用。

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

2.5. 初始化

初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：

1. 声明类变量是指定初始值
2. 使用静态代码块为类变量指定初始值

JVM初始化步骤：

1. 假如这个类还没有被加载和连接，则程序先加载并连接该类
2. 假如该类的直接父类还没有被初始化，则先初始化其直接父类
3. 假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：

1. 创建类的实例，也就是new的方式
2. 访问某个类或接口的静态变量，或者对该静态变量赋值
3. 调用类的静态方法
4. 反射（如Class.forName(“com.shengsiyuan.Test”)）
5. 初始化某个类的子类，则其父类也会被初始化
6. Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类

2.6. 结束生命周期

在如下几种情况下，Java虚拟机将结束生命周期

• 执行了System.exit()方法
• 程序正常执行结束
• 程序在执行过程中遇到了异常或错误而异常终止
• 由于操作系统出现错误而导致Java虚拟机进程终止

3. Jvm类加载-双亲委派

JVM类加载机制的特点：

1. 全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
2. 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类
3. 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效

双亲委派机制

通常类加载器可以大致划分为以下三类，它们遵循双亲委派规则：

1. 启动类加载器：Bootstrap ClassLoader，负责加载存放在JDKjrelib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
2. 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDKjrelibext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.开头的类），开发者可以直接使用扩展类加载器。
3. 应用程序类加载器：System ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

1. 当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
2. 当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
3. 如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；
4. 若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

双亲委派优点

委托模式主要为了确保Java核心库的组件总是正确地被加载，避免重复加载。优先使用“引导类载入器”，然后是“扩展类载入器”，为了在出现和JAVA核心库同名资源的时候，加载的总是正确的系统组件。比如说就算我在自己的CLASSPATH下写了一个恶意的java.lang.Object类，也不会被载入。JVM载入的永远是系统核心库中的正确的java.lang.Object类。

双亲委派可见性

子类加载器可以看到父类加载器加载的类，而反之则不行。

正因为这个前提，当“启动类加载器”加载了Java核心库，“系统类加载器”后续加载的库才可以访问Java核心库。反过来，如果当“系统类加载器”加载了某些自开发的类，“启动类加载器”中是无法直接访问的。

4. 破坏双亲委派

双亲委派模型不是一个强制性的约束模型，双亲委派模型也有不太适用的时候，这时根据具体的情况我们就要破坏这种机制，下面介绍两种破坏双亲委派的情况：

4.1. 线程上下文类加载器

Thread.currentThread().getContextClassLoader();从方法名字来看,应该是获取当前上下文的类加载器。

Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。

这些 SPI 的接口由 Java 核心库来提供，而这些 SPI 的实现代码则是作为 Java 应用所依赖的 jar 包被包含进类路径（CLASSPATH）里。SPI接口中的代码经常需要加载具体的实现类。那么问题来了，SPI的接口是Java核心库的一部分，是由启动类加载器(Bootstrap Classloader)来加载的；SPI的实现类是由系统类加载器(System ClassLoader)来加载的。引导类加载器是无法找到 SPI 的实现类的，因为依照双亲委派模型，BootstrapClassloader无法委派SystemClassLoader来加载类。

ClassLoader A -> System class loader -> Extension class loader -> Bootstrap class loader

那么委派链左边的ClassLoader就可以很自然的使用右边的ClassLoader所加载的类。但如果情况要反过来，是右边的ClassLoader所加载的代码需要反过来去找委派链靠左边的ClassLoader去加载东西怎么办呢？没辙，双亲委派是单向的，没办法反过来从右边找左边。

于是，Thread就把当前的类加载器给保存下来了，其他加载器需要的时候，就通过当前线程的加载器获取到。每一个Thread都有一个相关联的Context ClassLoader（由native方法建立的除外），可以通过Thread.setContextClassLoader()方法设置。如果你没有主动设置，Thread默认集成Parent Thread的 Context ClassLoader（注意，是parent Thread 不是父类）。如果你整个应用中都没有对此作任何处理，那么 所有的Thread都会以System ClassLoader作为Context ClassLoader。知道这一点很重要，因为从web服务器，java企业服务器使用一些复杂而且精巧的ClassLoader结构去实现诸如JNDI、线程池和热部署等功能以来，这种简单的情况越发的少见了，一般都会使用特定的classloader来设置thread context classLoader。

4.2. 自定义类加载器

破坏委派双亲模型就是由于用户追求动态性导致的，“动态性”就是指代码热替换、模块热部署等，就是希望程序不需要重启就可以更新class文件，最典型的例子就是SpringBoot的热部署和OSGi。这里拿OSGi举例，OSGi实现模块化热部署的关键就是它自定义类加载机制的实现，每一个程序模块(OSGi中称为Bundle)都有自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉实现热部署。所以，在OSGi环境下，类加载器不再是层次模型，而是网状模型。

当OSGi收到一个类加载的时候会按照以下的顺序进行搜索：

1. 将以 java.* 开头的类委派给父类加载器加载
2. 否则，将委派列表名单内的类委派给父类加载器加载
3. 否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载
4. 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载
5. 检查Fragment Bundle中是否可以加载
6. 查找Dynamic Import列表的Bundle
7. 若以上都没有进行类加载，则加载失败

5. Tomcat的类加载模式

前文我们了解了Java中类加载器的运行方式；但主流的Web服务器都会有自己的一套类加载器，为什么呢？因为对于服务器来说他要自己解决一些问题：

1. 部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以实现相互隔离。两个不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求一个类库在一个服务器中只有一份，服务器应当保证两个应用程序的类库可以互相独立使用。
2. 部署在同一个Web容器上的两个Web应用程序所使用的相同的类库相同的版本可以互相共享。例如，用户可能有10个使用Spring组织的应用程序部署在同一台服务器上，如果把10份Spring分别存放在各个应用程序的隔离目录中，将会是很大的资源浪费——这主要倒不是浪费磁盘空间的问题，而是指类库在使用时都要被加载到Web容器的内存，如果类库不能共享，虚拟机的方法区就会很容易出现过度膨胀的风险。
3. Web容器需要尽可能地保证自身的安全不受部署的Web应用程序影响。Web容器也有用Java实现的，那么肯定不能把Web容器的类库和程序的类库弄混。
4. 支持jsp的web容器，要支持热部署。我们知道运行jsp时实际上会先将jsp翻译成servlet，再编译为.class再在虚拟机运行起来再返回给客户端。而我们在编写jsp时，当tomcat服务器正在运行的时候，我们直接在jsp中修改代码时并不需要重启服务器，这就是达到了动态加载类的效果。

显然，如果Tomcat使用默认的类加载机制是无法满足上述要求的:

1. 无法加载两个相同类库的不同版本的，因为默认类加载只在乎权限定类名，第一条不行。
2. 可以实现。
3. 默认类加载只在乎权限定类明，所以第三条不行。
4. 前文我们说过，JVM确定是否为同一个类对象会要求类和类加载器都相同，默认的肯定不行，但我们可以想到当改变jsp代码的时候就改一次类加载器。

Tomcat的类加载流程如上图：

• CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用
• 而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。
• WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
• 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

目录结构大致为：

• /common目录中：类库可被Tomcat和所有的Web应用程序共同使用。
• /server目录中：类库可被Tomcat使用，对所有的Web应用程序都不可见。
• /shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见。
• /WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

因此就解决了上面的四个问题：

1. 部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以实现相互隔离：各个WebAppClassLoader实例之间相互隔离
2. 部署在同一个Web容器上的两个Web应用程序所使用的相同的类库相同的版本可以互相共享：可以放在Common或Shared目录下让这些程序共享
3. Web容器需要尽可能地保证自身的安全不受部署的Web应用程序影响：CatalinaClassLoader加载web服务器需要的类库，WebAppClassLoader只能得到SharedClassLoader的类库
4. 支持jsp的web容器，要支持热部署：每当改变jsp时，更新JasperClassLoader