6. 类装载器

class装载验证流程

类从加载到卸载，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中验证、准备、解析3个部分统称为链接（Linking）

类的生命周期

一. 加载

“类加载”（Class Loading）过程的第一个阶段：

通过全限定名取的类的二进制流：获取方式多样

从ZIP包中读取：JAR、EAR、WAR
从网络中获取：Applet
运行时计算生成：动态代理技术
由其他文件生成：JSP
从数据库读取：SAP Netweaver中间件

将字节流所代表的静态存储结构化转为方法区数据结构
在Java堆中（HotSpot虚拟机）生成对应的java.lang.Class对象：作为方法区这个类的数据访问入口

二. 验证（链接阶段第一步）

这一阶段的目的是：保证Class流的格式是正确的，是一个非常重要、但不是一定必要的阶段；可使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类的加载时间

文件格式验证：通过文件格式验证才可以进入内存中的方法区，基于二进制流验证

是否以魔数0xCAFEBABE开头
版本号是否合理

元数据验证

是否有父类（除了java.lang.Object，所有的类都应当有父类）
继承了final类？（不允许继承）
非抽象类实现了所有的抽象方法
类中的字段、方法是否与父类产生矛盾（覆盖了父类的final字段、不符合规则的方法重载、方法参数都一致返回值类型却不同）

字节码验证（很复杂）：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的

运行检查
栈数据类型和操作码数据参数吻合
跳转指令指定到合理的位置，不会跳转到方法体以外的字节码指令上
方法体中的类型转换是有效的

符号引用验证

常量池中描述类是否存在（能否找到）
访问的方法或字段是否存在且有足够的权限（private、protected、public、default）

三. 准备（链接阶段第二步）

为类变量分配内存，并为类设置初始值（方法区中）

public static int v=1;
在准备阶段中，v会被设置为0
在初始化的<clinit>中才会被设置为1
对于static final类型，在准备阶段就会被赋上正确的值
public static final  int v=1;

四. 解析（链接阶段第三步）

虚拟机将常量池内的符号引用替换为直接引用的过程。

符号引用（Symbolic Reference）

字符串
引用对象不一定被加载到内存中

直接引用（Direct Reference）

指针或者地址偏移量
引用对象一定在内存

五. 初始化

执行类构造器<clinit>

所有类变量的赋值语句
静态语句块（static{}）中的语句

子类的<clinit>调用前保证父类的<clinit>被调用

由于父类的<clinit>()方法先执行，父类中定义的静态语句块要优先于子类的变量赋值操作

<clinit>是线程安全的

类加载器

任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。

一. 类加载器ClassLoader

ClassLoader是一个抽象类

public Class<?> loadClass(String name) throws ClassNotFoundException
- 载入并返回一个Class
protected final Class<?> defineClass(String name, byte[] b, int off, int len)
- 定义一个类，不公开调用
protected Class<?> findClass(String name) throws ClassNotFoundException
- loadClass回调该方法，自定义ClassLoader的推荐做法
protected final Class<?> findLoadedClass(String name)
- 寻找已经加载的类

ClassLoader的实例将读入Java字节码将类装载到JVM中
ClassLoader可以定制，满足不同的字节码流获取方式
ClassLoader负责类装载过程中的加载阶段

二. 双亲委派模式

类加载器分类（除了启ClassLoader，每个ClassLoader都有一个Parent作为父类加载器）

BootStrap ClassLoader （启动ClassLoader）
Extension ClassLoader （扩展ClassLoader）
App ClassLoader （应用ClassLoader/系统ClassLoader）
Custom ClassLoader(自定义ClassLoader)

双亲委派模式

协同工作

双亲委派模式工作过程：类加载器收到了类加载的请求，它首先把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载
代码逻辑：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    //首先，检查请求的类是否已经被加载过了
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
           if (parent != null) {
               c = parent.loadClass(name, false);
            } else {
               c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            //如果父类加载器抛出ClassNotFoundException
            //说明父类加载器无法完成加载请求
        }
           
        if (c == null) {
            //在父类加载器无法加载的时候
            //再调用本身的findClass方法来进行类加载
            c = findClass(name);
        }
    }
             
    if (resolve) {
        resolveClass(c);
    }
    return c;
}

三. 破坏双亲委派模式

双亲模式的问题：顶层ClassLoader，无法加载底层ClassLoader的类

JNDI：对资源进行集中管理和查找
- 代码由启动ClassLoader加载（rt.jar中），所以SPI（Service Provider Interface）在rt.jar中
- 而SPI的实现类，在AppLoader

解决：线程上下文类加载器（Thread Context ClassLoader）

通过java.lang.Thread.setContextClassLoader()进行设置
理解方式：好比在一群人中选出一个来担任行动（加载行为）的执行者
基本思想是，在顶层ClassLoader中，传入底层ClassLoader的实例
Java中所有涉及SPI的加载动作基本上都采用这种方式
- JNDI
- JDBC
- JCE
- JAXB
- JBI

代码来自于javax.xml.parsers.FactoryFinder,展示如何在启动类加载器加载AppLoader的类

static private Class getProviderClass(String className, ClassLoader cl,
     boolean doFallback, boolean useBSClsLoader) throws ClassNotFoundException{
     try {
         if (cl == null) {
             if (useBSClsLoader) {
                 return Class.forName(className, true, FactoryFinder.class.getClassLoader());
             } else {
                 cl = ss.getContextClassLoader();
                 if (cl == null) {
                     throw new ClassNotFoundException();
                 }
                 else {
                     return cl.loadClass(className); //使用上下文ClassLoader
                 }
             }
         }
         else {
             return cl.loadClass(className);
         }
     }
     catch (ClassNotFoundException e1) {
         if (doFallback) {
             // Use current class loader - should always be bootstrap CL
             return Class.forName(className, true, FactoryFinder.class.getClassLoader());
         }
 …..

对程序动态性的追求：代码热替换（HotSwap）、模块热部署（Hot Deployment）

目前OSGi已经成为了业界“事实上”的Java模块化标准
- OSGi的ClassLoader形成网状结构，根据需要自由加载Class
- 共识：OSGi中对类加载器的使用是很值得学习的，弄懂了OSGi的实现，就可以算是掌握了类加载器的精髓