java类加载

引用：https://www.jianshu.com/p/cc66138d72b1，https://blog.csdn.net/xinlingchengbao/article/details/88376479

第一，Java 类加载的过程简介

        一般来说，我们把 Java 的类加载过程分为三个主要步骤：加载，连接，初始化，具体行为在 Java 虚拟机规范里有非常详细的定义。

        首先是加载过程（Loading），它是 Java 将字节码数据从不同的数据源读取到 JVM 中，并映射为 JVM 认可的数据结构（Class 对象），这里的数据源可能是各种各样的形态，比如 jar 文件，class 文件，甚至是网络数据源等；如果输入数据不是 ClassFile 的结构，则会抛出 ClassFormatError。加载阶段是用户参与的阶段，我们可以自定义类加载器，去实现自己的类加载过程。

        第二阶段是链接（Linking），这是核心的步骤，简单说是把原始的类定义信息平滑地转入 JVM 运行的过程中。这里可进一步细分成三个步骤：1，验证（Verification），这是虚拟机安全的重要保障，JVM 需要核验字节信息是符合 Java 虚拟机规范的，否则就被认为是 VerifyError，这样就防止了恶意信息或者不合规信息危害 JVM 的运行，验证阶段有可能触发更多 class 的加载。2，准备（Pereparation），创建类或者接口中的静态变量，并初始化静态变量的初始值。但这里的“初始化”和下面的显示初始化阶段是有区别的，侧重点在于分配所需要的内存空间，不会去执行更进一步的 JVM 指令。3，解析（Resolution），在这一步会将常量池中的符号引用（symbolic reference）替换为直接引用。在 Java 虚拟机规范中，详细介绍了类，接口，方法和字段等各方面的解析。

        最后是初始化阶段（initialization），这一步真正去执行类初始化的代码逻辑，包括静态字段赋值的动作，以及执行类定义中的静态初始化块内的逻辑，编译器在编译阶段就会把这部分逻辑整理好，父类型的初始化逻辑优先于当前类型的逻辑。再来谈谈双亲委派模型，简单说就是当加载器（Class-Loader）试图加载某个类型的时候，除非父类加载器找不到相应类型，否则尽量将这个任务代理给当前加载器的父加载器去做。使用委派模型的目的是避免重复加载 Java 类型。

第二，自定义类加载器的常见场景

        实现类似进程内隔离，类加载器实际上用作不同的命名空间，以及提供类似容器，模块化的效果。例如：1，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是 Jave EE 和 OSGL，JPMS等框架。2，应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。3，或者是需要自己操纵字节码，动态修改生成类型。

        我们可以总体上简单理解自定义类加载过程：1，通过指定名称，找到其二进制实现，这里往往就是自定义类加载器会“定制”的部分，例如，在特定数据源根据名字获取字节码，或者修改或生成字节码。2，然后，创建 Class 对象，并完成类加载过程。二进制信息到 class 对象的转换，通常就依赖 defineClass，我们无需自己实现，它是 final 方法。有了 Class 对象，后续完成加载过程就顺利成章了。

第三，如何降低类加载的开销

        这么多类加载，有没有什么通用方法，不需要代码和其他工作量，就可以降低类加载的开销？这个可以有。

        1，比如 AOT，相当于直接编译成机器码，降低的其实主要是解释和编译开销。但是其目前还是个实验特性，支持的平台也有限，比如，JDK 9 仅支持 Linux x64，所以局限性太大，先暂且不谈。

        2，还有就是较少人知道的 AppCDS（Application Class-Data Sharing），CDS 在 Java 5 中被引进，但仅限于 Bootstrap Class-loader，在 8u40 中实现了 AppCDS，支持其他的类加载器，目前已经在 JDK 10 中开源。

        简单来说，AppCDS 基本原理和工作过程是：首先，JVM 将类信息加载，解析成元数据，并根据是否需要修改，将其分类为 Read-Only 部分和 Read-Write 部分。然后，将这些元数据直接存储在文件系统中，作为所谓的 Shared Archive。第二，在应用程序启动时，指定归档文件，并开启 AppCDS。AppCDS 改善启动速度非常明显，传统的 Java EE 应用，一般可以提高 20% ~ 30%以上。与此同时，降低内存 footprint，因为同一环境的 Java 进程间可以共享部分数据结构。当然，也不是没有局限性，如果恰好大量使用了运行时动态类加载，它的帮助就有限了。

Class.forName 和 ClassLoader 

Class.forName加载类时将类进了初始化，而ClassLoader的loadClass并没有对类进行初始化，只是把类加载到了虚拟机中。

总结：Class.forName()执行初始化过程 执行静态代码化。

             ClassLoader.loadClass不执行初始化过程。

根据java虚拟机规范，所有java虚拟机实现必须在每个类或接口被java程序首次主动使用时才初始化。

主动使用有以下6种：
1) 创建类的实例
2) 访问某个类或者接口的静态变量，或者对该静态变量赋值（如果访问静态编译时常量(即编译时可以确定值的常量)不会导致类的初始化）
3) 调用类的静态方法
4) 反射（Class.forName(xxx.xxx.xxx)）
5) 初始化一个类的子类（相当于对父类的主动使用），不过直接通过子类引用父类元素，不会引起子类的初始化（参见示例6）
6) Java虚拟机被标明为启动类的类（包含main方法的）

类与接口的初始化不同，如果一个类被初始化，则其父类或父接口也会被初始化，但如果一个接口初始化，则不会引起其父接口的初始化。

而类的实例化，则调用对应的构造函数【clone？】

Java中有5种创建对象的方式

使用new关键字	} → 调用了构造函数
使用Class类的newInstance方法	} → 调用了构造函数
使用Constructor类的newInstance方法	} → 调用了构造函数
使用clone方法	} → 没有调用构造函数
使用反序列化	} → 没有调用构造函数

 

双亲委派模型

双亲委派过程

当一个类加载器收到类加载任务时，立即将任务委派给它的父类加载器去执行，直至委派给最顶层的启动类加载器为止。如果父类加载器无法加载委派给它的类时，将类加载任务退回给它的下一级加载器去执行;
除了启动类加载器以外，每个类加载器拥有一个父类加载器，用户的自定义类加载器的父类加载器是AppClassLoader；
双亲委派模型可以保证全限名指定的类，只被加载一次；
双亲委派模型不具有强制性约束，是Java设计者推荐的类加载器实现方式；

双亲委派模式优势

• 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
• 其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
• 可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常

 

java.lang.SecurityException: Prohibited package name: java.lang

不确定的理解：双亲委派有点类似maven类加载的层级概念，maven貌似是就近原则