6. 类装载器

class装载验证流程

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

类的生命周期

一. 加载

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

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

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

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

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

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

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

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

2. 元数据验证

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

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

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

4. 符号引用验证

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

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

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

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

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

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

1. 符号引用（Symbolic Reference）

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

2. 直接引用（Direct Reference）

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

五. 初始化

1. 执行类构造器

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

2. 子类的调用前保证父类的被调用

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

3. 是线程安全的

---

类加载器

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

一. 类加载器ClassLoader

1. 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)
  • 寻找已经加载的类

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

二. 双亲委派模式

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

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

双亲委派模式

2. 协同工作

• 双亲委派模式工作过程：类加载器收到了类加载的请求，它首先把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载
• 代码逻辑：先检查是否已经被加载过，若没有加载则调用父加载器的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;
}

三. 破坏双亲委派模式

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

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

2. 解决：线程上下文类加载器（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());
           }
   …..
  

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

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

---