JVM全面分析之类加载系统

类加载系统总体架构

​​​​​​​​​​
类加载系统经过三个阶段非别为：加载(此处的加载为狭义上的加载)、链接、初始化三步。其中链接又分为：验证、解析、准备阶段。

加载

1. 通过一个类的全限定名获取定义此类的二进制字节流。
2. 将这个字节流中静态的存储结构转换为方法区运行时数据结构。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

加载.class文件的方式

1. 从本地系统中直接加载
2. 通过网络获取，典型场景：Web Applet
3. 从zip压缩包中读取，称为日后jar、war格式的基础
4. 运行时计算生成，使用最多的是：动态代理技术
5. 由其他文件生成，典型场景：JSP应用
6. 从转悠数据库中提取.class文件，比较少见
7. 从加密文件中获取，典型的防class文件被反编译的保护措施

链接

验证（Verify）

 目的在于确保class文件的字节流中包含信息符合当前虚拟机的要求，保证被加载类的正确性。不会危害虚拟机自身安全。
 主要包括四种验证：文件格式验证，元数据验证，字节码验证，符号引用验证。

准备

  为类变量分配内存并且设置该类变量的默认初始值，即零值。
  这里不包含用final修饰的static。因为final在编译的时候就会分配了，准备阶段会显示初始化；
  这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到java堆中。

解析（Resolve）

  将常量池内的符号引用转换为直接引用的过程。
  事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行。
  符号引用就是一组符号来描述引用的目标，符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或者一个间接定位到目标的句柄
  解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等、对应常量池中的CONSTANT_Class_info、CONSTANT_fieldref_info、CONSTANT_Methodref_info

初始化

  初始化阶段是执行类构造器方法<clinit>()的过程
  此方法不需要定义，是javac编译器自动收集类中的所有类变量的复制动作和静态代码块中的语句合并而来
  构造器方法中指令按语句在源文件中出现的顺序执行
  <clinit>() 不同于类的构造器
  若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。
  虚拟机必须保证一个类的<clinit>()方法在多线程下呗同步加锁。

类加载器分类

  JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

  从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

   无论类加载器的类型如何划分，在程序中我们最常见的类加载器只有三个，如下所示：

这里的四者之间的关系是包含关系，不是上层下层，也不是子父类的继承关系！！！
从上图来看，出了Bootstrap Class Loader属于引导类加载器外，其他所有类加载器都属于自定义类加载器，因为他们都继承自抽象类ClassLoader。

上图是部分类加载器的类继承图。同时，sun.misc.Launcher是一个java虚拟机的入口应用。因为应用类加载器和扩展类加载器都是其内部类。

public class ClassLoaderTest {
   public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
       // 获取系统类加载器
       ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
       System.out.println(systemClassLoader);

       // 获取系统类加载器的上层：扩展类加载器
       ClassLoader extClassLoader = systemClassLoader.getParent();
       System.out.println(extClassLoader);

       // 获取扩展类加载器的上层：引导类加载器
       ClassLoader bootStrapClassLoader = extClassLoader.getParent();
       System.out.println(bootStrapClassLoader);

       // 获取用户自定义类的加载器
       ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
       System.out.println(classLoader);

       // java核心类库String的类加载器
       ClassLoader classLoader1 = String.class.getClassLoader();
       System.out.println(classLoader1);
   }
}

输出结果如下

sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@73a8dfcc
null
sun.misc.Launcher$AppClassLoader@18b4aac2
null

可以看到自定义类加载器就是用的系统类加载器进行加载；而java的核心类库使用的是引导类加载器进行加载；引导类加载器无法获取到，因为其是使用cc++语言编写的

启动类加载器（引导类加载器，Bootstrap ClassLoader）

• 这个类加载使用c/c++语言实现的，嵌套在JVM内部。或者说就是JVM的一部分
• 他用来加载Java的核心类库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
• 并不继承自java.lang.ClassLoader，没有父加载器
• 加载扩展类和应用程序类加载器，并制定为他们的父类加载器
• 出于安全考虑，Bootstrap启动类加载器只加载报名为java、javax、sun开头的类。

虚拟机自带的类加载器 之 扩展类加载器（Extension Classloader）

• Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
• 派生于ClassLoader类
• 父类加载器为启动类加载器
• 从java.ext.dirs系统属性所制定的目录中加载类库，或JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建JAR放在此目录下，也会自动由扩展类加载器加载。

虚拟机自带的类加载器 之 应用程序类加载器（系统类加载器，AppClassLoader）

• java语言编写，由sun.misc.Launcher$AppClassLoader实现
• 派生于ClassLoader类
• 父类加载器为扩展类加载器
• 他负责家在环境变量classpath或系统属性java.class.path制定路径下的类库
• 该类加载器是程序中默认的类加载器，一般来说，java引用的类都由他来完成加载
• 通过ClassLoader#getSystemClassLoader（）方法可以获取到该类加载器。

public class ClassLoaderTest2 {
    public static void main(String[] args) {
        // 获取BootstrapClassLoader能够加载的api的路径
        URL[] urLs = Launcher.getBootstrapClassPath().getURLs();
        for (URL urL : urLs) {
            System.out.println(urL.toExternalForm());
        }

        System.out.println("===================");

        // 获取扩展类加载器加载的路径
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")) {
            System.out.println(path);
        }

    }
}

自定义类加载器

为什么要自定义类加载器？

• 隔离类加载
• 修改类加载的方式
• 扩展加载源
• 防止源码泄漏

用户自定义类加载器实现步骤

1. 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类的加载器，以满足一些特殊需求
2. 在JDK1.2之前，自定义类加载器时，总会继承ClassLoader类并重写loadClass()方法，从而实现自定义的类的加载类。但是JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中。
3. 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方法，使自定义类加载器编写更加简洁

两个class对象是否为同一个类

1. 类的全限定名必须一致
2. 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同

   换句话说，在jvm中，即使这里两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不一样的。
   JVM必须知道一个类型是由启动类加载器加载的还是由用户类加载器加载的。如果一个类是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

类的主动使用与被动使用

主动使用

• 创建类的实例
• 访问某个类或接口的静态变量，或者对该静态变量赋值
• 调用类的静态方法
• 反射（比如：Class.forName("com.baidu.Test")）
• 初始化一个类的子类
• Java虚拟机启动时被表明为启动类的类
• JDK 7 开始提供的动态语言支持：
    java.lang.invoke.MethodHandle实例的解析结果
    REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

被动使用

  除了以上七种情况，其他使用java类的方式都被看作是对类的被动使用，都不会导致类的初始化