类加载机制

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指令是在程序编译后，存放于类构造器<clinit>（）方法之中的，因此把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