双亲委托类加载机制_类加载机制，双亲委派模型（1）

一般来说，我们把java的类加载过程分为三个主要步骤：加载，链接，初始化。

首先是加载阶段，它是java将字节码数据从不同的数据源读取到JVM中，并映射为JVM认可的数据结构，并映射为JVM认可的数据结构(Class对象)，这里的数据源可能是各种各样的形态，如jar文件，class文件，甚至是网络数据源；如果输入的数据不是ClassFile的结构，则会抛出ClassFormatError。

第二阶段是链接(Linking)，这是核心的步骤，简单说是吧原始的类定义信息平滑地转化如JVM运行的过程中。这里可进一步新氛围三个步骤：

验证(Verification)，这是虚拟机安全的重要保障，JVM需要核验字节信息是符合Java虚拟机规范的，否则就认为是VerifyError，这样就放置了恶意信息或者不合规的信息危害JVM的运行，验证阶段可能触发更多的class的加载。

准备(Preparation)，创建类或者接口中的静态变量，并初始化静态变量的初始值。

单这里的“初始化”和下面的显式初始化阶段是有区别的，侧重点在于分配所需要的内存空间，不回去执行更进一步的JVM指令。

解析(Resolution)，在这异步会将常量池中的符号引用(symbolic reference)替换为直接引用。在Java虚拟机规范中，详细介绍了类、接口、方法和字段等各个方面的解析。

最后是初始化阶段(initialization)，这一步真正去执行类初始化的代码逻辑，包括惊呆字段赋值的动作，一级执行类定义总的静态初始化块内的逻辑，编译器在编译阶段就会把这部分逻辑整理好，父类型的初始化逻辑优先于当前类型的逻辑。

在来谈谈双亲委派模型，简单说就是当类加载器(Class_Loader)试图加载某个类型的时候，除非父加载器找不到相应的类型，否则尽量将整个任务代理给当前加载器的父加载器去做。使用委派模型的目的是避免重复加载Java类型。

package com.wzl.day11;

/**

* @author wuzhilang

* @Title: Day11

* @ProjectName questions

* @Description: TODO

* @date 8/27/20196:27 PM

*/

/**

* 编译并反编译一下：

* 命令：Javac Day11.java

* Javap –v Day11.class

*/

public class Day11 {

public static int a = 100;

public static final int INT_CONSTANT = 1000;

public static final Integer INTEGER_CONSTANT = Integer.valueOf(10000);

}

运行

javac -encoding UTF-8 Day11.java

Javap –v Day11.class

输出的结果为

Classfile /D:/questions/question/src/com/wzl/day11/Day11.class

Last modified Aug 27, 2019; size 471 bytes

MD5 checksum c71fc3ab252eb1585d635d591ac61712

Compiled from "Day11.java"

public class com.wzl.day11.Day11

minor version: 0

major version: 52

flags: ACC_PUBLIC, ACC_SUPER

Constant pool:

#1 = Methodref #6.#21 // java/lang/Object."":()V

#2 = Fieldref #5.#22 // com/wzl/day11/Day11.a:I

#3 = Methodref #23.#24 // java/lang/Integer.valueOf:(I)Ljava/lang/Integer;

#4 = Fieldref #5.#25 // com/wzl/day11/Day11.INTEGER_CONSTANT:Ljava/lang/Integer;

#5 = Class #26 // com/wzl/day11/Day11

#6 = Class #27 // java/lang/Object

#7 = Utf8 a

#8 = Utf8 I

#9 = Utf8 INT_CONSTANT

#10 = Utf8 ConstantValue

#11 = Integer 1000

#12 = Utf8 INTEGER_CONSTANT

#13 = Utf8 Ljava/lang/Integer;

#14 = Utf8

#15 = Utf8 ()V

#16 = Utf8 Code

#17 = Utf8 LineNumberTable

#18 = Utf8

#19 = Utf8 SourceFile

#20 = Utf8 Day11.java

#21 = NameAndType #14:#15 // "":()V

#22 = NameAndType #7:#8 // a:I

#23 = Class #28 // java/lang/Integer

#24 = NameAndType #29:#30 // valueOf:(I)Ljava/lang/Integer;

#25 = NameAndType #12:#13 // INTEGER_CONSTANT:Ljava/lang/Integer;

#26 = Utf8 com/wzl/day11/Day11

#27 = Utf8 java/lang/Object

#28 = Utf8 java/lang/Integer

#29 = Utf8 valueOf

#30 = Utf8 (I)Ljava/lang/Integer;

{

public static int a;

descriptor: I

flags: ACC_PUBLIC, ACC_STATIC

public static final int INT_CONSTANT;

descriptor: I

flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL

ConstantValue: int 1000

public static final java.lang.Integer INTEGER_CONSTANT;

descriptor: Ljava/lang/Integer;

flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL

public com.wzl.day11.Day11();

descriptor: ()V

flags: ACC_PUBLIC

Code:

stack=1, locals=1, args_size=1

0: aload_0

1: invokespecial #1 // Method java/lang/Object."":()V

4: return

LineNumberTable:

line 16: 0

static {};

descriptor: ()V

flags: ACC_STATIC

Code:

stack=1, locals=0, args_size=0

0: bipush 100

2: putstatic #2 // Field a:I

5: sipush 10000

8: invokestatic #3 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;

11: putstatic #4 // Field INTEGER_CONSTANT:Ljava/lang/Integer;

14: return

LineNumberTable:

line 17: 0

line 19: 5

}

SourceFile: "Day11.java"

可以看出，普通原始类型静态变量和引用类型(即使是变量)，是需要额外调用putstatic等jvm指令的，这些是在显式初始化阶段执行，而不是准备阶段调用；而原始类型的变量，则不需要这样的步骤。

如果要真正理解双亲委派模型，需要理解java中类加载器的架构和职责，至少要懂具体有哪些内建的类加载器，。

从应用角度，解决某些类加载问题，例如我的java程序启动较慢，有没有办法尽量减小Java类加载的开销？

# 指定新的bootclasspath，替换java.*包的内部实现

java -Xbootclasspath: your_App

# a意味着append，将指定目录添加到bootclasspath后面

java -Xbootclasspath/a: your_App

# p意味着prepend，将指定目录添加到bootclasspath前面

java -Xbootclasspath/p: your_App

用法其实很易懂，例如，使用最常见的 “/p” ，既然是前置，就有机会替换个别基础类的实现。

我们一般可以使用下面方法获取类加载器，但是通常的JDK/JRE实现中，扩展类加载器getParent()都只能返回null。

public final ClassLoader getParent()

拓展类加载器(Extension or Ext Class-Loader)，负责加载我们最熟悉的classpath的内容。这里有一个容易混淆的概念，系统(system)类加载器，通常来说，其默认就是JDK内建的应用类加载器，但是它同样是可能修改的，比如：

java -Djava.system.class.loader=com.yourcorn.YourClassLodader HelloWorld

如果我们指定了这个桉树，JDK内建的应用类加载器就会后才能为定制加载器的父类，这种方式通常用在类似需要改变双亲委派模式的场景。

具体的操作如下：

通常类加载机制有三个基本特征：

双亲委派模型。但不是所有的类加载都遵守这个模型，有的时候启动类加载器所加载 的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以再标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现，例如JAVA中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。

可见性，子类加载器可以访问父加载器的类型，但是反过来是不允许的，不然因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。

单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会再子加载器中重复加载。但是注意，类加载器“邻居”间 ，同一类型仍然可以被加载多次，因为互相不可见。

-- 未完待续