Java虚拟机类加载器

类加载器

类加载概念：在Java代码中，类型的加载、链接、初始化过程都是在程序运行期间完成的。

类的生命周期：加载(Loading)->验证(Verification)->准备(Preparation)->解析(Resolution)->初始化(Initialization)->使用(Using)->卸载(Unloading)

类加载的过程：类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在内存中创建一个java.lang.Class对象用来封装类在方法区内的数据结构。

1. 加载：查找并加载class文件到JVM内存当中：类加载器并不需要等到某个类被”主动使用“的时候再加载它
2. 链接

• 验证：确保被加载的类的正确性(文件结构检查，语义检查，字节码验证，二进制兼容性)
• 准备：为类的静态变量分配内存，并将其初始化为默认值 public static int a = 1; 这里赋值 a = 0；
• 解析：把类中的符号引用转为直接引用（直接引用：通过类的变量来引用到对应的对象，符号引用：与内存模型相关，通过引用的地址直接找到内存的地址）

3. 初始化：为类的静态变量赋于正确的初始化值，将 a 的值赋值为 1，虚拟机规范规定了有且只有几种情况必须对类进行初始化（主动使用）；
4. 静态变量的初始化是在一个叫 <clinit>方法中完成的

类的主动使用场景

1. 调用new关键字初始化类时，设置（putstatic）和取值（getstatic）类或者接口的static变量时（final修饰除外），调用（invokestatic）一个类或者接口的静态方法
2. 使用 java.lang.reflect包的方法对类进行反射调用时，如果类没有初始化，先触发初始化
3. 当初始化一个类时，其父类没有初始化，先触发父类初始化
4. 当虚拟机启动时，用户需要指定一个要执行的主类（main方法），虚拟机会先初始化这个主类
5. 当使用JDK1.7 的动态语言支持时，如果一个MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄对应的类没有进行初始化，那么需要先触发初始化
6. 其他情况都视为 被动使用，不会导致初始化
7. 调用ClassLoader类的loadClass方法加载一个类，并不是对类的主动使用，不会导致初始化。

接口初始化

1. 当一个接口初始化，并不要求其父接口都完成了初始化
2. 一个static类型的变量是由运行时生成的（如：UUID，Random），那么需要进行初始化
3. 接口中的常量本身就是final类型的，如果子类需要使用，无需初始化父接口
4. 类中的变量不是final类型的，该变量不会进入到常量池中，初始化类的时候会导致父类的初始化
5. 在初始化一个类时，并不会先初始化所实现的接口
6. 在初始化一个接口时，并不会初始化所实现的接口，只有真正使用父接口的时候，才会初始化父接口

Java虚拟机的生命周期，在遇到以下情况会结束生命周期

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

加载器的类型

1. Java自带的加载器（根加载器、扩展类加载器、系统/应用类加载器）
2. 用户自定义加载器（CustomerClassloader）

加载.class文件的方式

1. 从本地系统中加载
2. 通过网络下载 .class文件
3. 从zip、jar等归档文件中加载
4. 从专有的数据库中提取 .class文件
5. 将Java源文件动态编译为 .class文件

类的实例化过程

1. 为新的对象分配内存
2. 为实例变量赋予默认值
3. 为实例变量赋予正确的初始值
4. java编译器为它编译的每一个都至少生成一个实例初始化方法，在java的class文件中，这个实例初始化方法被称之为"<init>"，针对源代码中每一个类的构造方法，java编译器都产生一个<init>方法
5. 数组类型：对于数组实例来说，其类型是由JVM在运行期动态生成的。表示为 [Lcom.github.mgljava.ArrayTest这种形式。动态生成的类型其父类型就是 Object，对于数组来说，JavaDoc经常将构成数组的元素成为 Componet，实际上就是将数组降低一个维度后的类型。

实现自定义类加载器

1. 继承ClassLoader类，自己手写从 class文件到二进制文件的方法（loadClassData）
2. 重写findClass方法来调用 loadClassData
3. 调用defineClass
4. 调用链路： classloader.loadClass -> findClass -> defineClass

定义类加载器：真正加载类的那个加载器，其他的加载器成为初始类加载器

类加载器的命名空间

1. 每个类加载器都有自己的命名空间，命名空间由该加载器及所有父加载器加载的类组成
2. 在同一个命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类
3. 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类
4. 子加载器加载的类能够访问父加载器加载的类，而父加载器加载的类，无法访问子加载器加载的类
5. 不同的命名空间的类相互转换为报错（ClassCastException），因为两个命名空间的类是不可见的
6. 在运行期，一个Java类是由该类的完全限定类名（binary name，二进制名）和用于加载该类的定义类加载器（defining loader）所共同决定的
   如果同样的名字（相同的完全限定名）的类是由两个不同的加载器所加载，那么这些类就是不同的，即便 .class 文件的字节码完全一样，并且从相同的位置加载亦如此

类的卸载

1. 当一个类被加载、链接、初始化后，它的生命周期就开始了
2. 当类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，类在方法区的数据也会被卸载，从而结束生命周期
3. 一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期
4. Java虚拟机自带的类加载器所加载的类不会被卸载
5. 由用户自定义的类加载器加载的类可以被卸载

双亲委派模型

意思是如果一个类加载器需要加载类，那么首先它会把这个类请求委派给父类加载器去完成，每一层都是如此。一直递归到顶层，当父加载器无法完成这个请求时，子类才会尝试去加载。这里的双亲其实就指的是父类，没有mother。父类也不是我们平日所说的那种继承关系，只是调用逻辑是这样

类加载器的双亲委托模型的好处

1. 可以确保Java核心库的类型安全：所有的Java应用都至少会引用java.lang.Object类，也就是说在运行期，java.lang.Object这个类会被加载到Java虚拟机中；如果这个类加载过程是由自己的类加载器来加载的，那么在JVM中就会存在多个版本的Object类，而且这些类在不同的命名空间之间还是不兼容的。所以Java核心类库的加载都交给启动类加载器来加载，从而确保了Java应用所使用的都是同一个版本的Java核心类库，保证了兼容性。
2. 可以确保Java核心类库所提供的类不会被自定义的类所替代。
3. 不同的类加载器可以为相同名称(binary name)的类创建额外的命名空间，相同名称的类可以并存在Java虚拟机中，只需要利用不同的加载器来加载他们即可，不同类加载器所加载的类之间是不兼容的。就相当于在Java虚拟机内部创建了一个又一个相互隔离的Java类空间，这类技术在很多框架中都得到了实际应用。

扩展类加载器和AppClassLoader由谁加载？

1. 内建于JVM中的启动类加载器会加载java.lang.ClassLoader以及其他的Java平台类，当JVM启动时，一块特殊的机器码会运行，它会加载扩展类加载器和应用类加载器，这块特殊的机器码就是启动类加载器
2. 启动类加载器并不是Java类，而其他的加载器则都是Java类
3. 启动类加载器是特定平台的机器指令，它负责开启整个加载过程
4. 所有类加载器（除了启动类加载器）都被实现为Java类。不过总归要有一个组件来加载第一个Java类加载器，从而让整个加载过程能够顺利进行下去，加载第一个纯Java类的加载器就是启动类加载器的职责
5. 启动类加载器还会负责加载供JRE正常运行所需要的基本组件，包括 java.lang、java.util等包下的类

线程上下文类加载器（Context ClassLoader）

1. 当前类加载器（Current ClassLoader）：用于加载当前类的类加载器
2. 每个类都会尝试使用加载自己的类加载器去加载其他的类（所依赖的类）：如果ClassX依赖了ClassY，那么加载ClassX的类加载器就会尝试去加载ClassY（前提是ClassY尚未被加载），那么这个类加载器就叫做当前类加载器
3. 线程上下文类加载器是JDK1.2引入的，类Thread中的getContextClassLoader()与setContextClassLoader(Classloader classLoader)分别用来获取和设置线程下上文类加载器
4. 如果没有设置线程上下文类加载器，那么默认就是系统类加载器
5. 线程上下文类加载器出现的原因以及重要性：

• 父ClassLoader可以使用当前线程 Thread.currentThread.getContextClassLoader()所指定的classloader加载的类，这就改变了父ClassLoader 不能使用子ClassLoader或是其他没有直接父子关系的ClassLoader加载的类的情况，即改变了双亲委托模型。
• 线程上下文类加载器就是当前线程的 Current ClassLoader
• 在双亲委托模型下，类加载器是由下至上的，即下层的类加载器会委托上层进行加载。对于SPI来说，
• SPI(Service Provider Interface)：服务提供者接口，如 JNDI、JDBC有些接口时Java核心库所提供的，而Java核心库是由启动类加载器来加载的，而这些接口的实现却来自于不同的Jar包(厂商提供)，Java的启动类加载器是不会加载其他来源的jar包，这样传统的双亲委托模型就无法满足SPI的要求，而通过给当前线程设置上下文类加载，就可以由设置的上下文类加载器来实现对于接口实现类的加载。
• 当高层提供了同意的接口让低层去实现，同时又要在高层加载(或实例化)低层的类时，就必须要通过线程上下文类加载器来帮助高层的ClassLoader找到并加载该类。

线程上下文类加载器的一般使用模式(在框架中使用)

1. 获取 ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
2. 使用 Thread.currentThread().setContextClassLoader(targetTccl)； myMethod() -> 在myMethod()方法中先获取上下文类加载器来做某些事情。
3. 还原 Thread.currentThread().setContextClassLoader(classLoader)；