目录

1 概述

1.1 什么是类的加载

1.2 在什么时候才会启动类加载器？

1.3 从哪个地方去加载.class文件

2 加载过程

1、加载

2、验证

3、准备

4、解析

5、初始化

3 类加载器

3.1 类加载器

3.2 类加载的三种方式

3.3 双亲委派原则

双亲委派模式优势

类加载器间的关系

3.4 自定义类加载器

1 概述

类的加载过程是指类加载器尝试加载class二进制文件，并在JVM中生成对应的数据结构，然后使其分布在JVM对应的内存区域。

1.1 什么是类的加载

在介绍类的加载机制之前，先来看看，类的加载机制在整个java程序运行期间处于一个什么环节，下面使用一张图来表示：



从上图可以看，java文件通过编译器变成了.class文件，接下来类加载器又将这些.class文件加载到JVM中。其中类装载器的作用其实就是类的加载。今天我们要讨论的就是这个环节。有了这个印象之后我们再来看类的加载的概念：

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

到现在为止，我们基本上对类加载机制处于整个程序运行的环节位置，还有类加载机制的概念有了基本的印象。在类加载.class文件之前，还有两个问题需要我们去弄清楚：

1.2 在什么时候才会启动类加载器？

其实，类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

1.3 从哪个地方去加载.class文件

在这里进行一个简单的分类。例举了5个来源

（1）本地磁盘

（2）网上加载.class文件（Applet）

（3）从数据库中

（4）压缩文件中（ZAR，jar等）

（5）从其他文件生成的（JSP应用）

有了这个认识之后，下面就开始讲讲，类加载机制了。首先看的就是类加载机制的过程。

2 加载过程

JVM类加载工作原理：就是把类的class文件加载到内存中，并对数据进行校验、转换解析和初始化，最终形成被虚拟机使用的java类型。

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。它们的顺序如下图所示：



其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

下面就一个一个去分析一下这几个过程。

1、加载

类加载过程的一个阶段，ClassLoader通过一个类的完全限定名查找此类字节码文件，并利用字节码文件创建一个class对象。

”加载“是”类加机制”的第一个过程，在加载阶段，虚拟机主要完成三件事：

（1）通过一个类的全限定名来获取其定义的二进制字节流

（2）将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构

（3）在堆中生成一个代表这个类的Class对象，作为方法区中这些数据的访问入口。

相对于类加载的其他阶段而言，加载阶段是可控性最强的阶段，因为程序员可以使用系统的类加载器加载，还可以使用自己的类加载器加载。我们在最后一部分会详细介绍这个类加载器。在这里我们只需要知道类加载器的作用就是上面虚拟机需要完成的三件事，仅此而已就好了。

2、验证

验证的主要作用就是确保被加载的类的正确性。也是连接阶段的第一步。说白了也就是我们加载好的.class文件不能对我们的虚拟机有危害，所以先检测验证一下。他主要是完成四个阶段的验证：

（1）文件格式的验证：验证.class文件字节流是否符合class文件的格式的规范，并且能够被当前版本的虚拟机处理。这里面主要对魔数、主版本号、常量池等等的校验（魔数、主版本号都是.class文件里面包含的数据信息、在这里可以不用理解）。

（2）元数据验证：主要是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求，比如说验证这个类是不是有父类，类中的字段方法是不是和父类冲突等等。

（3）字节码验证：这是整个验证过程最复杂的阶段，主要是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在元数据验证阶段对数据类型做出验证后，这个阶段主要对类的方法做出分析，保证类的方法在运行时不会做出威海虚拟机安全的事。

（4）符号引用验证：它是验证的最后一个阶段，发生在虚拟机将符号引用转化为直接引用的时候。主要是对类自身以外的信息进行校验。目的是确保解析动作能够完成。

对整个类加载机制而言，验证阶段是一个很重要但是非必需的阶段，如果我们的代码能够确保没有问题，那么我们就没有必要去验证，毕竟验证需要花费一定的的时间。当然我们可以使用-Xverfity:none来关闭大部分的验证。

3、准备

准备阶段主要为类变量分配内存并设置初始值。这些内存都在方法区分配。在这个阶段我们只需要注意两点就好了，也就是类变量和初始值两个关键词：

（1）类变量（static）会分配内存，但是实例变量不会，实例变量主要随着对象的实例化一块分配到java堆中，

（2）这里的初始值指的是数据类型默认值，而不是代码中被显示赋予的值。比如

public static int value = 1; //在这里准备阶段过后的value值为0，而不是1。赋值为1的动作在初始化阶段。

当然还有其他的默认值。



注意，在上面value是被static所修饰的准备阶段之后是0，但是如果同时被final和static修饰准备阶段之后就是1了。我们可以理解为static final在编译器就将结果放入调用它的类的常量池中了。

4、解析

解析阶段主要是虚拟机将常量池中的符号引用转化为直接引用的过程。什么是符号应用和直接引用呢？

符号引用：以一组符号来描述所引用的目标，可以是任何形式的字面量，只要是能无歧义的定位到目标就好，就好比在班级中，老师可以用张三来代表你，也可以用你的学号来代表你，但无论任何方式这些都只是一个代号（符号），这个代号指向你（符号引用）直接引用：直接引用是可以指向目标的指针、相对偏移量或者是一个能直接或间接定位到目标的句柄。和虚拟机实现的内存有关，不同的虚拟机直接引用一般不同。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

1.类或接口的解析

假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的引用，那虚拟机完成整个解析过程需要以下3个步骤：
（1）如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。
（2）如果C是一个数组类型，并且数组的元素类型为对象，那将会按照第1点的规则加载数组元素类型。
（3）如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为了一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具有对C的访问权限。如果发现不具备访问权限，则抛出java.lang.IllegalAccessError异常。

2.字段解析

首先解析字段表内class_index项中索引的CONSTANT_Class_info符号引用，也就是字段所属的类或接口的符号引用，如果解析完成，将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的搜索。
（1）如果C 本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（2）否则，如果C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（3）否则，如果C 不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（4）否则，查找失败，抛出java.lang.NoSuchFieldError异常。

如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

如果有一个同名字段同时出现在C的接口和父类中，或者同时在自己的父类或多个接口中出现，那编译器可能拒绝编译，并提示”The field xxx is ambiguous”。

3.类方法解析

首先解析类方法表内class_index项中索引的CONSTANT_Class_info符号引用，也就是方法所属的类或接口的符号引用，如果解析完成，将这个类方法所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续类方法的搜索。
（1）类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C 是个接口，那就直接抛出java.lang.IncompatibleClassChangeError异常。
（2）如果通过了第一步，在类C 中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（3）否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（4）否则，在类C实现的接口列表以及他们的父接口中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在相匹配的方法，说明类C是一个抽象类这时查找结束，抛出java.lang.AbstractMethodError异常。
（5）否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError。

最后，如果查找成功返回了直接引用，将会对这个方法进行权限验证，如果发现不具备此方法的访问权限，则抛出java.lang.IllegalAccessError异常。

4.接口方法解析

首先解析接口方法表内class_index项中索引的CONSTANT_Class_info符号引用，也就是方法所属的类或接口的符号引用，如果解析完成，将这个接口方法所属的接口用C表示，虚拟机规范要求按照如下步骤对C进行后续接口方法的搜索。
（1）与类解析方法不同，如果在接口方法表中发现class_index中的索引C是个类而不是个接口，那就直接抛出java.lang.IncompatibleClassChangeError异常。
（2）否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（3）否则，在接口C的父接口中递归查找，直到java.lang.Object类（查找范围包括Object类）为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（4）否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError。

5、初始化

这是类加载机制的最后一步，在这个阶段，java程序代码才开始真正执行。我们知道，在准备阶段已经为类变量赋过一次值。在初始化阶端，程序员可以根据自己的需求来赋值了。一句话描述这个阶段就是执行类构造器< clinit >()方法的过程。

在初始化阶段，主要为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：

①声明类变量是指定初始值

②使用静态代码块为类变量指定初始值

JVM初始化步骤

1、假如这个类还没有被加载和连接，则程序先加载并连接该类

2、假如该类的直接父类还没有被初始化，则先初始化其直接父类

3、假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：

创建类的实例，也就是new的方式
	
访问某个类或接口的静态变量，或者对该静态变量赋值
public class Demo {
    static{
        System.out.println("进行初始化");
    }
    //访问简单静态变量x，会导致Demo类的初始化。
    public static int x = 10;
}

调用类的静态方法
public class Demo{
    static{
        System.out.println("进行初始化");
    }
    //在其他类中调用静态方法test，会导致Demo类的初始化。
    public static void test(){
    }
}

反射（如 Class.forName(“com.shengsiyuan.Test”)）
public static void main(String[] args) throws ClassNotFoundException {
        //通过反射导致Demo类初始化
        Class.forName("co.youzi.test.Demo");
    }

初始化某个类的子类，则其父类也会被初始化
public class Parent {
    static{
        System.out.println("父类初始化");
    }
    public static int x = 10;
}
public class Child extend Parent{
    static{
        System.out.println("子类初始化");
    }
    public static int y = 100;
}
public class Test {
    public static void main(String[] args) throws ClassNotFoundException {
        System.out.println(Child.y);//输出 父类初始化 子类初始化 100
        //System.out.println(Child.x);//输出 父类初始化 10
    }
}

注意：通过子类使用父类的静态变量只会导致父类的初始化，子类不会初始化。

Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类
也就是main函数所在类会被初始化，如上面的Test类。

除此之外，所有引用类的方式都不会触发初始化，称为被动引用，例如：

通过子类引用父类的静态字段，不会导致子类初始化。
	
通过数组定义来引用类，不会触发此类的初始化。MyClass[] cs = new MyClass[10];
public class Test05 {
    public static void main(String[] args) throws ClassNotFoundException {
        //Parent类不会被初始化
        Parent[] parent = new Parent[10];
        System.out.println(parent.length);
    }
}

常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
public class Simple {
    static{
        System.out.println("进行初始化");
    }
    //访问静态常量MAX不会导致Simple类的初始化
    public final static int MAX = 10;
    //虽然RANDOM是静态常量，但是由于计算复杂，只有初始化后才能得到结果，因此其他类使用RANDOM会导致Simple类的初始化
    public final static int RANDOM = new java.util.Random(10).nextInt();
}

好了，到目前为止就是类加载机制的整个过程，但是还有一个重要的概念，那就是类加载器。在加载阶段其实我们提到过类加载器，说是在后面详细说，在这就好好地介绍一下类加载器。

注：由此步我们就可以得知，我们在分析向上转型的例子时的程序代码的运行顺序了：父类静态内容——子类静态内容——父类构造——子类构造——子类方法 。

3 类加载器

虚拟机设计团队把加载动作放到JVM外部实现，以便让应用程序决定如何获取所需的类。

JVM设计者把类加载阶段中的通过类全名来获取此类的二进制字节流这个动作放到java虚拟机外部去实现，以便让应用程序决定如何获取所需要的类。实现这个动作的代码模块成为“类加载器”。

3.1 类加载器

    对于任何一个类，都需要由加载它的类加载器和这个类来确定其在JVM中的唯一性。也就是说，两个类来源于同一个Class文件，并且被同一个类加载器加载，这两个类才相等。

forName和loaderClass区别

Class.forName()得到的class是已经初始化完成的。
	
Classloader.loaderClass得到的class是还没有链接（验证，准备，解析三个过程被称为链接）的。
1、Java语言系统自带有三个类加载器:

Bootstrap ClassLoader ：最顶层的加载类，主要加载核心类库，也就是我们环境变量下面%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。比如java -Xbootclasspath/a:path被指定的文件追加到默认的bootstrap路径中。我们可以打开我的电脑，在上面的目录下查看，看看这些jar包是不是存在于这个目录。Extention ClassLoader ：扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。Appclass Loader：也称为SystemAppClass。 加载当前应用的classpath的所有类。我们看到java为我们提供了三个类加载器，应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。这三种类加载器的加载顺序是什么呢？

Bootstrap ClassLoader > Extention ClassLoader > Appclass Loader

一张图来看一下他们的层次关系





从上面的结果可以看出，并没有获取到ExtClassLoader的父Loader，原因是Bootstrap Loader（引导类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null。

3.2 类加载的三种方式

认识了这三种类加载器，接下来我们看看类加载的三种方式。

（1）通过命令行启动应用时由JVM初始化加载含有main()方法的主类。

（2）通过Class.forName()方法动态加载，会默认执行初始化块（static{}），但是Class.forName(name,initialize,loader)中的initialze可指定是否要执行初始化块。

（3）通过ClassLoader.loadClass()方法动态加载，不会执行初始化块。

首先我们定义一个FDD类
public class FDD 
{
    static {
                 System.out.println("我是静态代码块。。。。"); 
            }
}

然后我们看一下如何去加载

package com.fdd.test;
public class FDDloaderTest {
    public static void main(String[] args) throws ClassNotFoundException 
    { 
        ClassLoader loader = HelloWorld.class.getClassLoader(); 
        System.out.println(loader); 
        //一、 使用ClassLoader.loadClass()来加载类，不会执行初始化块 
        loader.loadClass("Fdd"); 
        //二、 使用Class.forName()来加载类，默认会执行初始化块                 
        Class.forName("Fdd"); 
        //三、使用Class.forName()来加载类，指定ClassLoader，初始化时不执行静态块 
        Class.forName("Fdd", false, loader); 
     }
}

上面是同不同的方式去加载类，结果是不一样的。

3.3 双亲委派原则

他的工作流程是： 当一个类加载器收到类加载任务，会先交给其父类加载器去完成，因此最终加载任务都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，才会尝试执行加载任务。这个理解起来就简单了，比如说，另外一个人给小费，自己不会先去直接拿来塞自己钱包，我们先把钱给领导，领导再给领导，一直到公司老板，老板不想要了，再一级一级往下分。老板要是要这个钱，下面的领导和自己就一分钱没有了。（例子不好，理解就好）

采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。双亲委派原则归纳一下就是：

可以避免重复加载，父类已经加载了，子类就不需要再次加载更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。



双亲委派模式优势

采用双亲委派模式的是好处是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


所以无论如何都无法加载成功的。下面我们从代码层面了解几个Java中定义的类加载器及其双亲委派模式的实现，它们类图关系如下



从图可以看出顶层的类加载器是ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器），这里我们主要介绍ClassLoader中几个比较重要的方法。

loadClass(String)

该方法加载指定名称（包括包名）的二进制类型，该方法在JDK1.2之后不再建议用户重写但用户可以直接调用该方法，loadClass()方法是ClassLoader类自己实现的，该方法中的逻辑就是双亲委派模式的实现，其源码如下，loadClass(String name, boolean resolve)是一个重载方法，resolve参数代表是否生成class对象的同时进行解析相关操作。：

protected Class<?> loadClass(String name, boolean resolve)
      throws ClassNotFoundException
  {
      synchronized (getClassLoadingLock(name)) {
          // 先从缓存查找该class对象，找到就不用重新加载
          Class<?> c = findLoadedClass(name);
          if (c == null) {
              long t0 = System.nanoTime();
              try {
                  if (parent != null) {
                      //如果找不到，则委托给父类加载器去加载
                      c = parent.loadClass(name, false);
                  } else {
                  //如果没有父类，则委托给启动加载器去加载
                      c = findBootstrapClassOrNull(name);
                  }
              } catch (ClassNotFoundException e) {
                  // ClassNotFoundException thrown if class not found
                  // from the non-null parent class loader
              }

              if (c == null) {
                  // If still not found, then invoke findClass in order
                  // 如果都没有找到，则通过自定义实现的findClass去查找并加载
                  c = findClass(name);

                  // this is the defining class loader; record the stats
                  sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                  sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                  sun.misc.PerfCounter.getFindClasses().increment();
              }
          }
          if (resolve) {//是否需要在加载时进行解析
              resolveClass(c);
          }
          return c;
      }
  }


正如loadClass方法所展示的，当类加载请求到来时，先从缓存中查找该类对象，如果存在直接返回，如果不存在则交给该类加载去的父加载器去加载，倘若没有父加载则交给顶级启动类加载器去加载，最后倘若仍没有找到，则使用findClass()方法去加载（关于findClass()稍后会进一步介绍）。从loadClass实现也可以知道如果不想重新定义加载类的规则，也没有复杂的逻辑，只想在运行时加载自己指定的类，那么我们可以直接使用this.getClass().getClassLoder.loadClass("className")，这样就可以直接调用ClassLoader的loadClass方法获取到class对象。

findClass(String)
在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass()方法中被调用的，当loadClass()方法中父加载器加载失败后，则会调用自己的findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass方法通常是和defineClass方法一起使用的(稍后会分析)，ClassLoader类中findClass()方法源码如下：

//直接抛出异常
protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
}


defineClass(byte[] b, int off, int len)
defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑)，通过这个方法不仅能够通过class文件实例化class对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象，defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象，简单例子如下：

protected Class<?> findClass(String name) throws ClassNotFoundException {
	  // 获取类的字节数组
      byte[] classData = getClassData(name);  
      if (classData == null) {
          throw new ClassNotFoundException();
      } else {
	      //使用defineClass生成class对象
          return defineClass(name, classData, 0, classData.length);
      }
  }


需要注意的是，如果直接调用defineClass()方法生成类的Class对象，这个类的Class对象并没有解析(也可以理解为链接阶段，毕竟解析是链接的最后一步)，其解析操作需要等待初始化阶段进行。

resolveClass(Class≺?≻ c)

	使用该方法可以使用类的Class对象创建完成也同时被解析。前面我们说链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。
上述4个方法是ClassLoader类中的比较重要的方法，也是我们可能会经常用到的方法。接看SercureClassLoader扩展了 ClassLoader，新增了几个与使用相关的代码源(对代码源的位置及其证书的验证)和权限定义类验证(主要指对class源码的访问权限)的方法，一般我们不会直接跟这个类打交道，更多是与它的子类URLClassLoader有所关联，前面说过，ClassLoader是一个抽象类，很多方法是空的没有实现，比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现，并新增了URLClassPath类协助取得Class字节码流等功能，在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁，下面是URLClassLoader的类图(利用IDEA生成的类图)



从类图结构看出URLClassLoader中存在一个URLClassPath类，通过这个类就可以找到要加载的字节码流，也就是说URLClassPath类负责找到要加载的字节码，再读取成字节流，最后通过defineClass()方法创建类的Class对象。从URLClassLoader类的结构图可以看出其构造方法都有一个必须传递的参数URL[]，该参数的元素是代表字节码文件的路径,换句话说在创建URLClassLoader对象时必须要指定这个类加载器的到那个目录下找class文件。同时也应该注意URL[]也是URLClassPath类的必传参数，在创建URLClassPath对象时，会根据传递过来的URL数组中的路径判断是文件还是jar包，然后根据不同的路径创建FileLoader或者JarLoader或默认Loader类去加载相应路径下的class文件，而当JVM调用findClass()方法时，就由这3个加载器中的一个将class文件的字节码流加载到内存中，最后利用字节码流创建类的class对象。请记住，如果我们在定义类加载器时选择继承ClassLoader类而非URLClassLoader，必须手动编写findclass()方法的加载逻辑以及获取字节码流的逻辑。了解完URLClassLoader后接着看看剩余的两个类加载器，即拓展类加载器ExtClassLoader和系统类加载器AppClassLoader，这两个类都继承自URLClassLoader，是sun.misc.Launcher的静态内部类。sun.misc.Launcher主要被系统用于启动主应用程序，ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的，其类主要类结构如下：



它们间的关系正如前面所阐述的那样，同时我们发现ExtClassLoader并没有重写loadClass()方法，这足矣说明其遵循双亲委派模式，而AppClassLoader重载了loadCass()方法，但最终调用的还是父类loadClass()方法，因此依然遵守双亲委派模式，重载方法源码如下：

 /**
  * Override loadClass 方法，新增包权限检测功能
  */
 public Class loadClass(String name, boolean resolve)
     throws ClassNotFoundException
 {
     int i = name.lastIndexOf('.');
     if (i != -1) {
         SecurityManager sm = System.getSecurityManager();
         if (sm != null) {
             sm.checkPackageAccess(name.substring(0, i));
         }
     }
     //依然调用父类的方法
     return (super.loadClass(name, resolve));
 }


其实无论是ExtClassLoader还是AppClassLoader都继承URLClassLoader类，因此它们都遵守双亲委托模型，这点是毋庸置疑的。ok，到此我们对ClassLoader、URLClassLoader、ExtClassLoader、AppClassLoader以及Launcher类间的关系有了比较清晰的了解，同时对一些主要的方法也有一定的认识，这里并没有对这些类的源码进行详细的分析，毕竟没有那个必要，因为我们主要弄得类与类间的关系和常用的方法同时搞清楚双亲委托模式的实现过程，为编写自定义类加载器做铺垫就足够了。ok，前面出现了很多父类加载器的说法，但每个类加载器的父类到底是谁，一直没有阐明，下面我们就通过代码验证的方式来阐明这答案。

类加载器间的关系

我们进一步了解类加载器间的关系(并非指继承关系)，主要可以分为以下4点


	
启动类加载器，由C++实现，没有父类。
	
	

	
拓展类加载器(ExtClassLoader)，由Java语言实现，父类加载器为null
	
	

	
系统类加载器(AppClassLoader)，由Java语言实现，父类加载器为ExtClassLoader
	
	

	
自定义类加载器，父类加载器肯定为AppClassLoader。
	
下面我们通过程序来验证上述阐述的观点

/**
 * Created by zejian on 2017/6/18.
 * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
 */
//自定义ClassLoader，完整代码稍后分析
class FileClassLoader extends  ClassLoader{
    private String rootDir;

    public FileClassLoader(String rootDir) {
        this.rootDir = rootDir;
    }
    // 编写获取类的字节码并创建class对象的逻辑
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
       //...省略逻辑代码
    }
	//编写读取字节流的方法
    private byte[] getClassData(String className) {
        // 读取类文件的字节
        //省略代码....
    }
}

public class ClassLoaderTest {

    public static void main(String[] args) throws ClassNotFoundException {
       
			 FileClassLoader loader1 = new FileClassLoader(rootDir);
			
			  System.out.println("自定义类加载器的父加载器: "+loader1.getParent());
			  System.out.println("系统默认的AppClassLoader: "+ClassLoader.getSystemClassLoader());
			  System.out.println("AppClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent());
			  System.out.println("ExtClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent().getParent());
			
			/**
			输出结果:
			    自定义类加载器的父加载器: sun.misc.Launcher$AppClassLoader@29453f44
			    系统默认的AppClassLoader: sun.misc.Launcher$AppClassLoader@29453f44
			    AppClassLoader的父类加载器: sun.misc.Launcher$ExtClassLoader@6f94fa3e
			    ExtClassLoader的父类加载器: null
			*/

    }
}


代码中，我们自定义了一个FileClassLoader，这里我们继承了ClassLoader而非URLClassLoader,因此需要自己编写findClass()方法逻辑以及加载字节码的逻辑，关于自定义类加载器我们稍后会分析，这里仅需要知道FileClassLoader是自定义加载器即可，接着在main方法中，通过ClassLoader.getSystemClassLoader()获取到系统默认类加载器，通过获取其父类加载器及其父父类加载器，同时还获取了自定义类加载器的父类加载器,最终输出结果正如我们所预料的，AppClassLoader的父类加载器为ExtClassLoader，而ExtClassLoader没有父类加载器。如果我们实现自己的类加载器，它的父加载器都只会是AppClassLoader。这里我们不妨看看Lancher的构造器源码

public Launcher() {
        // 首先创建拓展类加载器
        ClassLoader extcl;
        try {
            extcl = ExtClassLoader.getExtClassLoader();
        } catch (IOException e) {
            throw new InternalError(
                "Could not create extension class loader");
        }

        // Now create the class loader to use to launch the application
        try {
	        //再创建AppClassLoader并把extcl作为父加载器传递给AppClassLoader
            loader = AppClassLoader.getAppClassLoader(extcl);
        } catch (IOException e) {
            throw new InternalError(
                "Could not create application class loader");
        }

        //设置线程上下文类加载器，稍后分析
        Thread.currentThread().setContextClassLoader(loader);
//省略其他没必要的代码......
        }
    }


显然Lancher初始化时首先会创建ExtClassLoader类加载器，然后再创建AppClassLoader并把ExtClassLoader传递给它作为父类加载器，这里还把AppClassLoader默认设置为线程上下文类加载器，关于线程上下文类加载器稍后会分析。那ExtClassLoader类加载器为什么是null呢？看下面的源码创建过程就明白，在创建ExtClassLoader强制设置了其父加载器为null。

//Lancher中创建ExtClassLoader
extcl = ExtClassLoader.getExtClassLoader();

//getExtClassLoader()方法
public static ExtClassLoader getExtClassLoader() throws IOException{

  //........省略其他代码 
  return new ExtClassLoader(dirs);                     
  // .........
}

//构造方法
public ExtClassLoader(File[] dirs) throws IOException {
   //调用父类构造URLClassLoader传递null作为parent
   super(getExtURLs(dirs), null, factory);
}

//URLClassLoader构造
public URLClassLoader(URL[] urls, ClassLoader parent,
                          URLStreamHandlerFactory factory) {


显然ExtClassLoader的父类为null，而AppClassLoader的父加载器为ExtClassLoader，所有自定义的类加载器其父加载器只会是AppClassLoader，注意这里所指的父类并不是Java继承关系中的那种父子关系。

在JVM中表示两个class对象是否为同一个类对象存在两个必要条件

类的完整类名必须一致，包括包名。
	
加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。
也就是说，在JVM中，即使这个两个类对象(class对象)来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的，这是因为不同的ClassLoader实例对象都拥有不同的独立的类名称空间，所以加载的class对象也会存在不同的类名空间中，但前提是覆写loadclass方法，从前面双亲委派模式对loadClass()方法的源码分析中可以知，在方法第一步会通过Class<?> c = findLoadedClass(name);从缓存查找，类名完整名称相同则不会再次被加载，因此我们必须绕过缓存查询才能重新加载class对象。当然也可直接调用findClass()方法，这样也避免从缓存查找，如下

String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
//创建两个不同的自定义类加载器实例
FileClassLoader loader1 = new FileClassLoader(rootDir);
FileClassLoader loader2 = new FileClassLoader(rootDir);
//通过findClass创建类的Class对象
Class<?> object1=loader1.findClass("com.zejian.classloader.DemoObj");
Class<?> object2=loader2.findClass("com.zejian.classloader.DemoObj");

System.out.println("findClass->obj1:"+object1.hashCode());
System.out.println("findClass->obj2:"+object2.hashCode());

/**
  * 直接调用findClass方法输出结果:
  * findClass->obj1:723074861
    findClass->obj2:895328852
    生成不同的实例
  */


如果调用父类的loadClass方法，结果如下，除非重写loadClass()方法去掉缓存查找步骤，不过现在一般都不建议重写loadClass()方法。

//直接调用父类的loadClass()方法
Class<?> obj1 =loader1.loadClass("com.zejian.classloader.DemoObj");
Class<?> obj2 =loader2.loadClass("com.zejian.classloader.DemoObj");

//不同实例对象的自定义类加载器
System.out.println("loadClass->obj1:"+obj1.hashCode());
System.out.println("loadClass->obj2:"+obj2.hashCode());
//系统类加载器
System.out.println("Class->obj3:"+DemoObj.class.hashCode());

/**
* 直接调用loadClass方法的输出结果,注意并没有重写loadClass方法
* loadClass->obj1:1872034366
  loadClass->obj2:1872034366
  Class->    obj3:1872034366
  都是同一个实例
*/


所以如果不从缓存查询相同完全类名的class对象，那么只有ClassLoader的实例对象不同，同一字节码文件创建的class对象自然也不会相同。

3.4 自定义类加载器

在这一部分第一小节中，我们提到了java系统为我们提供的三种类加载器，还给出了他们的层次关系图，最下面就是自定义类加载器，那么我们如何自己定义类加载器呢？这主要有两种方式

（1）遵守双亲委派模型：继承ClassLoader，重写findClass()方法。

（2）破坏双亲委派模型：继承ClassLoader,重写loadClass()方法。 通常我们推荐采用第一种方法自定义类加载器，最大程度上的遵守双亲委派模型。

我们看一下实现步骤

（1）创建一个类继承ClassLoader抽象类

（2）重写findClass()方法

（3）在findClass()方法中调用defineClass()

public class MyClassLoader extends ClassLoader {
    private String libPath; 
    public DiskClassLoader(String path) { 
        libPath = path; 
    } 
    @Override protected Class<?> findClass(String name) throws ClassNotFoundException {             
        String fileName = getFileName(name); 
        File file = new File(libPath,fileName); 
        try { 
                FileInputStream is = new FileInputStream(file); 
                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                int len = 0; 
                try { 
                        while ((len = is.read()) != -1)
                        { 
                            bos.write(len); 
                         }
                    }
                 catch (IOException e)
                 {
                    e.printStackTrace();
                 }
                 byte[] data = bos.toByteArray();
                 is.close();
                 bos.close();
                 return defineClass(name,data,0,data.length);
         }
      catch (IOException e) {
             e.printStackTrace(); 
      }
      return super.findClass(name); 
}
 //获取要加载 的class文件名 
    private String getFileName(String name) {
         int index = name.lastIndexOf('.'); 
         if(index == -1){ 
            return name+".class"; 
         }
        else
        {
             return name.substring(index+1)+".class"; 
         } 

    }

}

接下来我们就可以自己去加载类了，使用方法大体就是两行

MyClassLoader diskLoader = new MyClassLoader("D:\\lib");
        //加载class文件，注意是com.fdd.Test
Class c = diskLoader.loadClass("com.fdd.Test");

参考：

http://blog.csdn.net/javazejian

https://baijiahao.baidu.com/s?id=1636309817155065432&wfr=spider&for=pc

 

 

 

 

 

 

 

 

 

第一次写MFC程序，在生成的Dlg.cpp中要加入自己写的工具类，但是引入.h文件之后报错 
error LNK2019: 无法解析的外部符号

很是郁闷，经过一番查找，都在说是缺少库文件，项目–》属性–》配置属性–》链接器-》输入–》附加依赖项 

在其中加入所需库文件，同时在“链接器–》常规–》附加库目录”中填入相应库名，这样应该就可以了。

但是我都不知道缺哪个库文件怎么办啊，又是一番查找，发现一个新方法，在Dlg.cpp中直接引入自己的.cpp文件，然后就编译通过了，具体原理还不太清楚，还请知道的大神以供小弟留言学习。

java 类的加载机制
概述
Java语言的类型可以分为两大类：基本类型和引用类型。
JVM架构图
一、什么是类加载
1.1类的加载机制在整个java程序运行期间处于一个什么环节
1.2 在什么时候才会启动类加载器？
1.3从哪个地方去加载.class文件
二、类加载的过程
2.1加载
2.2 连接-验证
2.3 连接-准备
2.4 连接-解析
2.5 初始化
三、类加载器
3.1、Java语言系统自带有三个类加载器:
3.2 类加载的三种方式
四、双亲委派原则
五、自定义类加载器
总结类的加载机制：

概述
Java语言的类型可以分为两大类：基本类型和引用类型。

基本类型  包括byte，short，int，long，float，double，boolean，char。
引用类型  包括类，接口，数组类和泛型参数。由于泛型参数会在编译过程中被擦除，因此Java虚拟机实际上只有前三种。在类，接口和数组类中，数组类是由Java虚拟机直接生成的，其它两种则有对应的字节流。

JVM架构图


JVM被分为三个主要的子系统

（1）类加载器子系统（2）运行时数据区（3）执行引擎
  我们写的java文件是不能直接运行的，我们可以在IDEA中右键文件名点击运行，这中间其实掺杂了一系列的复杂处理过程。这篇文章，我们只讨论我们的代码在运行之前的一个环节，叫做类的加载。

  首先，认识类加载机制，然后，详细介绍类加载的过程。最后，介绍了类加载器，还有双亲委派原则。
一、什么是类加载
1.1类的加载机制在整个java程序运行期间处于一个什么环节
下面使用一张图来表示：



  从上图可以看，java文件通过编译器变成了.class文件，接下来类加载器又将这些.class文件加载到JVM中。其中类装载器的作用其实就是类的加载。有了这个印象之后我们再来看类的加载的概念：

  类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结构。
  到现在为止，我们基本上对类加载机制处于整个程序运行的环节位置，还有类加载机制的概念有了基本的印象。在类加载.class文件之前，还有两个问题需要我们去弄清楚：
1.2 在什么时候才会启动类加载器？
  其实，类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。
1.3从哪个地方去加载.class文件
在这里进行一个简单的分类。例举了5个来源
（1）本地磁盘
（2）网上加载.class文件（Applet）
（3）从数据库中
（4）压缩文件中（ZAR，jar等）
（5）从其他文件生成的（JSP应用）
  有了这个认识之后，下面就开始讲讲，类加载机制了。首先看的就是类加载机制的过程。
二、类加载的过程
  类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。它们的顺序如下图所示：



  其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始。

另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

下面就一个一个去分析一下这几个过程。
2.1加载
”加载“是”类加机制”的第一个过程，在加载阶段，虚拟机主要完成三件事：
（1）通过一个类的全限定名来获取其定义的二进制字节流
（2）将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
（3）在堆中生成一个代表这个类的Class对象，作为方法区中这些数据的访问入口。
  相对于类加载的其他阶段而言，加载阶段是可控性最强的阶段，因为程序员可以使用系统的类加载器加载，还可以使用自己的类加载器加载。我们在最后一部分会详细介绍这个类加载器。在这里我们只需要知道类加载器的作用就是上面虚拟机需要完成的三件事，仅此而已就好了。
2.2 连接-验证
  验证的主要作用就是确保被加载的类的正确性。也是连接阶段的第一步。说白了也就是我们加载好的.class文件不能对我们的虚拟机有危害，所以先检测验证一下。他主要是完成四个阶段的验证：
（1）文件格式的验证：验证.class文件字节流是否符合class文件的格式的规范，并且能够被当前版本的虚拟机处理。这里面主要对魔数、主版本号、常量池等等的校验（魔数、主版本号都是.class文件里面包含的数据信息、在这里可以不用理解）。
（2）元数据验证：主要是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求，比如说验证这个类是不是有父类，类中的字段方法是不是和父类冲突等等。
（3）字节码验证：这是整个验证过程最复杂的阶段，主要是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在元数据验证阶段对数据类型做出验证后，这个阶段主要对类的方法做出分析，保证类的方法在运行时不会做出威海虚拟机安全的事。
（4）符号引用验证：它是验证的最后一个阶段，发生在虚拟机将符号引用转化为直接引用的时候。主要是对类自身以外的信息进行校验。目的是确保解析动作能够完成。
  对整个类加载机制而言，验证阶段是一个很重要但是非必需的阶段，如果我们的代码能够确保没有问题，那么我们就没有必要去验证，毕竟验证需要花费一定的的时间。当然我们可以使用-Xverfity:none来关闭大部分的验证。
2.3 连接-准备
  准备阶段主要为类变量分配内存并设置初始值。这些内存都在方法区分配。在这个阶段我们只需要注意两点就好了，也就是类变量和初始值两个关键词：
（1）类变量（static）会分配内存，但是实例变量不会，实例变量主要随着对象的实例化一块分配到java堆中，
（2）这里的初始值指的是数据类型默认值，而不是代码中被显示赋予的值。比如
  public static int value = 1; //在这里准备阶段过后的value值为0，而不是1。赋值为1的动作在初始化阶段。
当然还有其他的默认值。




数据类型
默认值




int
0


long
0L


short
0(short)


boolean
false


float
0.0f


double
0.0d


  注意，在上面value是被static所修饰的准备阶段之后是0，但是如果同时被final和static修饰准备阶段之后就是1了。我们可以理解为static final在编译器就将结果放入调用它的类的常量池中了。
2.4 连接-解析
  解析阶段主要是虚拟机将常量池中的符号引用转化为直接引用的过程。什么是符号应用和直接引用呢？

符号引用：以一组符号来描述所引用的目标，可以是任何形式的字面量，只要是能无歧义的定位到目标就好，就好比在班级中，老师可以用张三来代表你，也可以用你的学号来代表你，但无论任何方式这些都只是一个代号（符号），这个代号指向你（符号引用）
直接引用：直接引用是可以指向目标的指针、相对偏移量或者是一个能直接或间接定位到目标的句柄。和虚拟机实现的内存有关，不同的虚拟机直接引用一般不同。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

2.5 初始化
  这是类加载机制的最后一步，在这个阶段，java程序代码才开始真正执行。我们知道，在准备阶段已经为类变量赋过一次值。在初始化阶端，程序员可以根据自己的需求来赋值了。一句话描述这个阶段就是执行类构造器< clinit >()方法的过程。
  在初始化阶段，主要为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：
①声明类变量是指定初始值
②使用静态代码块为类变量指定初始值
JVM初始化步骤
1、假如这个类还没有被加载和连接，则程序先加载并连接该类
2、假如该类的直接父类还没有被初始化，则先初始化其直接父类
3、假如类中有初始化语句，则系统依次执行这些初始化语句
  类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：





初始化时机




1.
创建类的实例，也就是new的方式


2.
访问某个类或接口的静态变量，或者对该静态变量赋值


3.
调用类的静态方法


4.
反射（如 Class.forName(“com.shengsiyuan.Test”)）


5.
初始化某个类的子类，则其父类也会被初始化


6.
Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类


   到目前为止就是类加载机制的整个过程，但是还有一个重要的概念，那就是类加载器。在加载阶段其实我们提到过类加载器，说是在后面详细说，在这就好好地介绍一下类加载器。
三、类加载器
虚拟机设计团队把加载动作放到JVM外部实现，以便让应用程序决定如何获取所需的类。
3.1、Java语言系统自带有三个类加载器:

   类加载器有两种，一种是启动类加载器，其它的类加载器都是java.lang.ClassLoader的子类。启动类加载器是由C++实现的，没有对应的Java对象，因此在Java中只能用null代替。除了启动类加载器之外，另外两个重要的类加载器是扩展类加载器和应用类加载器，均由Java核心类库提供。

   启动类加载器加载最为基础，最为重要的类，如JRE的lib目录下jar包中的类；扩展类加载器的父类是启动类加载器，它负责加载相对次要，但又通用的类，如JRE的lib/ext目录下jar包中的类；应用类加载器的父类加载器则是扩展类加载器，它负责加载应用程序路径下的类。

Bootstrap ClassLoader ：最顶层的加载类(启动类加载器)，主要加载核心类库，也就是我们环境变量下面%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。比如java -Xbootclasspath/a:path被指定的文件追加到默认的bootstrap路径中。我们可以打开我的电脑，在上面的目录下查看，看看这些jar包是不是存在于这个目录。
Extention ClassLoader ：扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。
Appclass Loader：也称为SystemAppClass。 加载当前应用的classpath的所有类。

我们看到java为我们提供了三个类加载器，应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。这三种类加载器的加载顺序是什么呢？

Bootstrap ClassLoader > Extention ClassLoader > Appclass Loader
代码验证下：


   从上面的结果可以看出，并没有获取到ExtClassLoader的父Loader，原因是Bootstrap Loader（引导类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null。
3.2 类加载的三种方式
认识了这三种类加载器，接下来我们看看类加载的三种方式。
（1）通过命令行启动应用时由JVM初始化加载含有main()方法的主类。
（2）通过Class.forName()方法动态加载，会默认执行初始化块（static{}），但是Class.forName(name,initialize,loader)中的initialze可指定是否要执行初始化块。
（3）通过ClassLoader.loadClass()方法动态加载，不会执行初始化块。
示例代码如下：
FDD.java
package com.tengfei.fairy.test.classloader;

public class FDD {
    static{
        System.out.println("我是静态代码块。。。");
    }
}

FDDloaderTest.java
package com.tengfei.fairy.test.classloader;

/**
 * @ Description :类不同加载方式，结果不同
 *  //1、 使用ClassLoader.loadClass()来加载类，不会执行初始化块 loader.loadClass("Fdd");
 *  // 2、 使用Class.forName()来加载类，默认会执行初始化块 Class.forName("Fdd");、
 *  // 3、使用Class.forName()来加载类，指定ClassLoader，初始化时不执行静态块 Class.forName("Fdd", false, loader);
 */
public class FDDloaderTest {
    public static void main(String[] args) throws ClassNotFoundException {
        ClassLoader loader = FDD.class.getClassLoader();
//        System.out.println("  loader.loadClass(\"FDD\" )-----------");
//        loader.loadClass("com.tengfei.fairy.test.classloader.FDD");
        System.out.println(" Class.forName()----------");
        Class.forName("com.tengfei.fairy.test.classloader.FDD");
//        System.out.println(" Class.forName(\"Fdd\", false, loader) ----------");
//        Class.forName("com.tengfei.fairy.test.classloader.FDD", false, loader);
        System.out.println(loader);
    }
}

四、双亲委派原则
   当一个类加载器收到一个类加载的请求，它首先会将该请求委派给父类加载器去加载，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该被传入到顶层的启动类加载器(Bootstrap ClassLoader)中，只有当父类加载器反馈无法完成这个列的加载请求时（它的搜索范围内不存在这个类），子类加载器才尝试加载。其层次结构示意图如下：



   采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。双亲委派原则归纳一下就是：

可以避免重复加载，父类已经加载了，子类就不需要再次加载
更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。

五、自定义类加载器
  在这一部分第一小节中，我们提到了java系统为我们提供的三种类加载器，还给出了他们的层次关系图，最下面就是自定义类加载器，那么我们如何自己定义类加载器呢？这主要有两种方式


（1）遵守双亲委派模型：继承ClassLoader，重写findClass()方法。


（2）破坏双亲委派模型：继承ClassLoader,重写loadClass()方法。 通常我们推荐采用第一种方法自定义类加载器，最大程度上的遵守双亲委派模型。


我们看一下实现步骤


（1）创建一个类继承ClassLoader抽象类


（2）重写findClass()方法


（3）在findClass()方法中调用defineClass()


代码实现如下：
package com.tengfei.fairy.test.classloader;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;

/**
 * @ Description :自定义类加载器,重写findClass（）方法
 */
public class MyClassLoader extends ClassLoader {
    private String libPath;
    public MyClassLoader(String path) {
        libPath = path;
    }
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        String fileName = getFileName(name);
        File file = new File(libPath, fileName);
        try {
            FileInputStream is = new FileInputStream(file);
            ByteArrayOutputStream bos = new ByteArrayOutputStream();
            int len = 0;
            try {
                while ((len = is.read()) != -1) {
                    bos.write(len);
                }
            } catch (IOException e) {
                e.printStackTrace();
            }
            byte[] data = bos.toByteArray();
            is.close();
            bos.close();
            return defineClass(name, data, 0, data.length);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return super.findClass(name);
    }

    //获取要加载 的class文件名
    private String getFileName(String name) {
        int index = name.lastIndexOf('.');
        if (index == -1) {
            return name + ".class";
        } else {
            return name.substring(index + 1) + ".class";
        }
    }
}

接下来我们就可以自己去加载类了，使用方法大体就是两行
MyClassLoader diskLoader = new MyClassLoader("D:\\lib");
//加载class文件，注意是
com.fdd.TestClass c = diskLoader.loadClass("com.fdd.Test");


总结类的加载机制：


参考：

classloader加载class文件的原理和机制

Java类加载机制

多重继承中同名方法就出现了竞争关系，需要明确到底是继承的哪个方法。
方法调用阶段确定被调用方法的版本。所有方法调用中的目标方法在Class文件中都是一个常量池中的符号引用。要调用方法首先要知道其直接引用（方法入口地址）。
一、先谈解析
将符号引用转化为直接引用（方法在实际运行时内存布局中的入口地址），有一部分是在类加载的解析阶段，这种解析成立的前提是：该方法“编译期可知，运行期不可变”，主要包括静态方法（与类型直接关联）、私有方法（外部不可访问），其他还有实例构造器方法、父类方法和被final修饰的方法。此类方法各自的特点决定了他们都不可能是通过继承或者别的方式（实现）重写其它版本。

静态方法通过invokestatic字节码指令调用

私有方法、实例构造器方法、父类方法使用invokespecial指令调用

被final修饰的方法使用invokevirtual指令调用
二、再谈分派
1、分派会做什么
分派分为静态和动态，又分为单分派和多分派
静态分派

例如重载

Human man = new Man();

上面代码中的Human是静态类型，Man是实际类型。

虚拟机（准确的说是编译器）在重载时通过参数的静态类型而不是实际类型作为选择方法版本的判定依据。而静态类型是编译器可知的，因此在编译阶段，javac编译器会根据参数的静态类型决定使用哪个重载版本，并把这个版本的方法的符号引用写到invokevirtual指令的参数中。

所有利用静态类型来定位方法执行版本的分派动作成为静态分派，静态分派的典型应用是方法重载。
动态分派

例如重写

方法调用指令使用的是invokevirtual指令，其运行时解析过程大致分为以下几个步骤：

1）找到操作数栈顶的第一个元素所指向的对象（是将要执行的方法的所有者，称为接受者）的实际类型，记作C。

2）如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果未通过，则返回java.lang.IllegalAccessError异常。

3）如果未在类型C中找到与常量中的描述符和简单名称都相符的方法，则按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。

4）如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。
综合重载和重写，区别就是重写在定位方法的接受者（所有者），重载是在这个所有者里面所有同名的方法中通过参数列表进行区分，判断依据中以参数的静态类型做区别。
2、分派是怎么实现的
虚拟方法表

重写了的方法指向自己的实际入口地址

未重写的方法指向父类的实际入口地址
可以看到上述Java没有多重继承时候的设计。因为多重继承在判断具体该使用哪一个方法的时候非常复杂，因此Java在设计上没有采用多重继承。像python是支持多重继承的，其方法解析顺序（MRO）算法也是变更了多次。
补充:多重实现(Java支持实现多个接口)

两个接口有同名的方法，然而都没有实现，实现类必须完成同名方法的实现。

两个接口有同名的方法，只要其中有一个自己的默认实现，实现类必须完成同名方法的重写。

两个接口没有同名的方法，实现类需完成没有默认实现的方法。

两个接口有同名返回值却不一样的方法，需要改变其中一个接口的方法名，因为此时不管是实现两个方法还是不实现都不正确，一个方法的区别是靠方法签名进行区别的，方法签名包括方法名和参数列表，返回值不能作为区别。
本文主要参考

《深入理解Java虚拟机》——周志明