JVM- 类加载机制

1.2.3 解析

解析阶段是指将虚拟机中的符号引用替换为直接引用的过程。符号引用就是 class 文件中的：CONSTANT_Class_info、CONSTANT_Field_info、Constant_Method_info 等类型的常量。

• 符号引用
  符号引用与虚拟机实际的布局无关，引用的目标不一定要加载到内存中。各种虚拟机实现的内存布局可以各不相同。但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。
• 直接引用
  直接引豕可以是指向目标的指针，相对偏移量或是一个能间接定义到目标的句柄。如果有了直接引用，那引用的目标必须已经在内存中存在。

1.3 初始化

初始化阶段是执行类构造器折方法的过程。方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。 虚拟机会保证子执行之前，父类的方法已经执行完毕，如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成方法。

注意，类的初始化只有在以下 7 种情况下对类的主动使用才会发生：

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

尤其注意，以下 6 种情况不会发生类的初始化：

1. 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
2. 定义对象数组，不会触发该类的初始化。
3. 常量在编译器间会存入调用类的常量池中，本质上没有直接引用定义常量的类，不会触发定义常量所在的类。
4. 通过类名获取 Class 对象，不会触发类的初始化。
5. 通过 Class.forName 加载指定类时，如果指定参数 initalize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对灰进行初始化。
6. 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作。

1.4 使用

类实例化时，就进行类的使用阶段。此时，JVM 会为新对象分配内存，为实例变量赋默认值，为实例变量赋正确的初始值。
java 编译器为它编译的每一个类都至少生成一个实例化方法。在 java 的 class 文件中，这个实例初始化方法被称为""。针对源代码中每一个类的构造方法，java 编译器都产生一个方法。
对于这个方法，需要注意的是：对于 HotSpot 虚拟机，构造块{}中的代码会一并编译进方法中，如果有多个方法，构造块中的指令会复制成多份拷贝进每个方法中。
总结一下就是：在编译后，构造块会合并进实例化方法，对象的实例化只需要执行实例化方法即可。

举例如下，我们会看到两个实例化方法编译后的 4-13 行实际上对应的就是构造块的指令：

2. 类加载器
虚拟机设计团队把加载动作放到了 JVM 外部实现，以便让应用程序决定如何获取所需要的类，JVM 提供了三种类加载器：

Bootstrap ClassLoader

即启动类加载器，负责加载 JAVA_HOME/lib 目录中，或通过-Xbootclasspath 参数指定路径中的，且被虚拟机认可（按文件名识别，如 rt.jar)的类。
Extension ClassLoader

即扩展类加载器，负责加载 JAVA_HOME/lib/ext 目录中的，或通过 java.ext.dirs 变量指定路径中的类库。
Application ClassLoader

即应用类加载器，负责加载用户路径(classpath)上的类库。

除了以上三种 JVM 自带的类加载器之后，程序中也可通过继承 java.lang.ClassLoader 来实现自己定义的类加载器。
2.1 双亲委派
JVM 通过双亲委派模型来进行类的加载：


当一个类加载器收到类加载请求，他首先不会尝试自己去加载这个类，而把这个请求委派给父类去完成，每个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载器加载。只有当父类加载器反馈自己无法完成这个请求时（在它的加载路径下没有找到所需加载的 Class)，子类加载器才会尝试自己去加载。
父类委托机制的优点是能够提供软件系统的安全性。因为在此机制下，用户自定义的类加载器不可能加载应由其父加载器加载的可靠类，从而防止不可靠甚至恶意的代码代替由父加载器加载的可靠代码。例如，java.lang.Object 类总是由根类加载器加载，其它自定义的类加载器都不可能加载含有恶意代码的 java.lang.Object 类。
2.2 命名空间
每个类加载器都有自己的命令空间，命令空间由该加载器及所有父加载器所加载的类组成。
在同一个命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类。在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类。
同一个命名空间内的类是相互可见的。子加载器的命名空间包含所有父加载器的命名空间，因此由子加载器加载的类能够看见父加载器加载的类。例如应用类加载器加载的类能看见启动类加载器加载的类。
由父加载器加载的类不能看见子加载器加载的类。

如果两个加载器之间没有直接或间接的父子关系，那么它们相互不可见。
2.3 线程上下文加载器
在双亲委托模型下，类加载是由下至上的，即下层的类加载器会委托上进行加载。但是对于 SPI 来说，有些接口是由 Java 核心库所提供的， 而 Java 核心库是由启动类加载器，而这些接口的实现却来自于不同的 jar 包（厂商提供），Java 的启动类加载器是不会加载其他来源的 jar 包， 这样传统的双亲委托模型就无法满足 SPI 的要求，而通过给当前线程设置上下文类加载器，就可以由设置的线程上下文类加载器来实现对于接口实现类的加载。
线程上下文类加载器是从 JDK1.2 开始引入的，类 Thread 中的 getContextClassLoader()与 setContextClassLoader(ClassLoader cl) 分别用来获取和设置上下文类加载器。
如果没有通过 setContextClassLoader（ClassLoader cl)进行设置的话，线程将继承其父线程的上下文类加载器，Java 应用运行时的初始线程的上下文类加载器是应用类加载器。在线程中运行的代码可以通过该类加载器来加载类与资源。
父 Classloader 可以使用当前线程 Thread.currentThread().getContextClassLoader()所指定的 classloader 加载的类。这就改变了父 ClassLoader 不使用子 ClassLoader 或是其他没有直接父子关系的 ClassLoader 加载的类的情况，即改变了双亲委托模型。
线程上下文类加载器的一般使用模式如下所示，即：获取-> 使用-> 还原：
// 获取 - 使用 - 还原
ClassLoader classLoader = Thread.currentThread().getContxtClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetTccl);
    myMethod();
} finally {
    Thread.currentThread().setContextClassLoader(classLoader);
} 

myThread 里面则调用了 Thread.currentThread().getContextClassLoader(), 获取当前线程的上下文类加载器做某些事情。

如果一个类由类加载器 A 加载，那么这个类的依赖类也是由相同的类加载器加载的（如果该依赖类之前没有被加载过的话）

ContextClassLoader 的作用就是为了破坏 Java 的类加载委托机制。

当高层提供了统一的接口让低层实现，同时又要在高层加载(或实例化）低层的类时，就必须通过线程上下文类加载器来帮助高层的 ClassLoader 提取并加载该类。