java类加载过程（双亲委派模型）和 破坏双亲委派 及 tomcat类加载器

一、java类加载过程（双亲委派模型）

我们先来看一张图片，有助于理解类加载器与类加载过程。

概念

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接时候用的Java类型。

类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、（验证、准备、解析）连接、初始化、使用、卸载。其中验证、准备、解析统称为连接

上图中，加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须严格按照这种顺序开始。

解析阶段则不一定，它在某些情况下，可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（动态绑定|晚期绑定）

类加载-时机

主动引用

Java虚拟机规范中并没有进行强制约束什么时候开始类加载过程的第一个阶段-加载，可以交给虚拟机具体实现来自由把握。但对于初始化阶段，虚拟机规范严格规定有且只有5种情况必须立即对类进行初始化（加载、验证、准备自然要在此之前开始）

• 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发初始化操作。

4条指令最常见Java代码场景：用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候、调用一个类的静态方法的时候。

• 用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要触发初始化操作。

• 初始化一个类的时候，发现其父类还有进行过初始化，则需要触发先其父类的初始化操作。

注意这里和接口的初始化有点区别，，一个接口在初始化时，并不要求其父接口全部都完成了初始化，只要在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

• 虚拟机启动时，需要指定一个执行的主类（包含main方法的类），虚拟机会先初始化这类。

• 用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化操作。

被动引用

以上5种场景均有一个必须的限定：“有且只有”，这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。
示例1：

/**
 * 通过子类引用父类的静态字段，不会导致子类初始化
 */
public class SuperClass {
    static {
        System.out.println("SuperClass init....");
    }

    public static int value = 123;
}

package com.xdwang.demo;

public class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init....");
    }
}

package com.xdwang.demo;

public class Test {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

运行结果：

SuperClass init....
123

结论：
对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。（是否触发子类的加载和验证，取决于虚拟机具体的实现，对于HotSpot来说，可以通过-XX:+TraceClassLoading参数观察到此操作会导致子类的加载）

示例2：

package com.xdwang.demo;
 
public class Test2 {
    public static void main(String[] args) {
        //
        SuperClass[] superClasses = new SubClass[10];
    }
}

无任何输出

结论：
通过数组定义来引用类，不会触发此类的初始化

这里其实会触发另一个类的初始化

示例3

    public class ConstClass {
        static {
            System.out.println("ConstClass init....");
        }
 
        public static final String MM = "hello Franco";
    }
 
    package com.xdwang.demo;
 
    public class Test3 {
        public static void main(String[] args) {
            System.out.println(ConstClass.MM);
        }
    }

运行结果：

hello Franco

并没有ConstClass init….，这是因为虽然Test3里引用了ConstClass类中的常量，但其实在编译阶段通过常量传播优化，已经将此常量存储到Test3类的常量池中。两个类在编译成class之后就不存在任何联系了。

类加载-过程

加载

加载阶段（可参考java.lang.ClassLoader的loadClass()方法），虚拟机要完成以下3件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；

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

3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；

加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

验证阶段是非常重要的，这个阶段是否严谨，直接决定了Java虚拟机是否能承受恶意代码的工具，从执行性能的角度上讲，验证阶段的工作量在虚拟机的类加载子系统中又占了相当大一部分。

验证阶段大致会完成4个阶段的检验动作：

1. 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能够被当前版本的虚拟机处理

   是否以魔术0xCAFEBABE开头
   主次版本号是否在当前虚拟机的处理范围之内
   常量池中的常量是否有不被支持的类型。
   ….
   

2. 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；

   这个类是否有父类。（除了java.lang.Object之外）
   这个类的父类是否集继承了不允许被继承的类（被final修饰的类）
   如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法
   ….
   

3. 字节码验证：整个验证过程最复杂的一个阶段。主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件

   保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似在操作栈放int型数据，使用却按long行加载如本地变量表中。
   保证跳转指令不会跳转到方法体意外的字节码指令上
   ….
   

4. 符号引用验证：目的是确保解析动作能正常执行，发生在虚拟机将符号引用转换为直接引用的时候，这个转化动作将在连接的第三阶段-解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验。

   符号引用中通过字符串描述的全限定名是否能够找到对应的类。
   在指定类中是否存在符号方法的字段描述符以及简单名称所描述的方法和字段
   符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。
   ….
   

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

public static int value=123;

那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

至于“特殊情况”是指：

public static final int value=123

即当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0.

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化

类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序猿通过程序制定的主观计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器()方法的过程。

• ()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。如下：

   public class Test
   {
       static
       {
           i=0;//给变量赋值可以正常编译通过
           System.out.println(i);//这句编译器会报错：Cannot reference a field before it is defined（非法向前应用）
       }
       static int i=1;
   }
  

• ()方法与实例构造器()方法不同，它不需要显示地调用父类构造器，虚拟机会保证在子类()方法执行之前，父类的()方法已经执行完毕，一次虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。
  由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。（下面的例子，B=2）

static class Parent{
    public static int A=1;
    static{
        A=2;
    }
}
static class Sub extends Parent{
    public static int B=A;
}
public class Test{
    public static void main(String[] args){
        System.out.println(Sub.B);
    }
}

• ()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生产()方法。

• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成()方法。但接口与类不同的是，执行接口的()方法不需要先执行父接口的()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的()方法。

• 虚拟机会保证一个类的()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的()方法中有好事很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。

public class DealLoopTest {
    static class DeadLoopClass {
        static {
            if (true)// 如果不加上这个if语句，编译器将提示“Initializer does not complete normally”错误
            {
                System.out.println(Thread.currentThread() + "init DeadLoopClass");
                while (true) {
                }
            }
        }
    }
 

public static void main(String[] args) {
    Runnable script = new Runnable() {
        public void run() {
            System.out.println(Thread.currentThread() + " start");
            DeadLoopClass dlc = new DeadLoopClass();
            System.out.println(Thread.currentThread() + " run over");
        }
    };
 

Thread thread1 = new Thread(script);
Thread thread2 = new Thread(script);
thread1.start();
thread2.start();

}

}

运行结果：（即一条线程在死循环以模拟长时间操作，另一条线程在阻塞等待）

Thread[Thread-1,5,main] start
Thread[Thread-0,5,main] start
Thread[Thread-1,5,main]init DeadLoopClass

需要注意的是，其他线程虽然会被阻塞，但如果执行()方法的那条线程退出()方法后，其他线程唤醒之后不会再次进入()方法。同一个类加载器下，一个类型只会初始化一次。
将上面代码中的静态块替换如下：

static {
    System.out.println(Thread.currentThread() + "init DeadLoopClass");
    try {
        TimeUnit.SECONDS.sleep(10);
    }
    catch (InterruptedException e) {
        e.printStackTrace();
    }
}

运行结果：

Thread[Thread-0,5,main] start
Thread[Thread-1,5,main] start
Thread[Thread-0,5,main]init DeadLoopClass
Thread[Thread-0,5,main] run over
Thread[Thread-1,5,main] run over

原因在类加载-时机的主动引用中已经解释了。

类加载器（class loader）

概念

类加载器（class loader）用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。

类加载器应用在很多方面，比如类层次划分、OSGi、热部署、代码加密等领域。

基本上所有的类加载器都是 java.lang.ClassLoader类的一个实例

java.lang.ClassLoader类

java.lang.ClassLoader类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class类的一个实例。除此之外，ClassLoader还负责加载 Java 应用所需的资源，如图像文件和配置文件等。

为了完成加载类的这个职责，ClassLoader提供了一系列的方法

方法	说明
getParent()	返回该类加载器的父类加载器。
loadClass(String name)	加载名称为name的类，返回的结果是java.lang.Class类的实例。
findClass(String name)	查找名称为name的类，返回的结果是java.lang.Class类的实例。
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回的结果是java.lang.Class类的实例。
defineClass(String name, byte[] b, int off, int len)	把字节数组 b中的内容转换成 Java 类，返回的结果是 java.lang.Class类的实例。这个方法被声明为final的。
resolveClass(Class c)	链接指定的 Java 类。

类与类加载器的关系

类加载器虽然只用于实现类的加载动作，但它在java程序中起到作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一起确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。（比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类肯定不会相等）

这里说的相等，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。

JVM在搜索类的时候，又是如何判定两个class是相同的呢？

JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。

对象的创建和ClassLoader

 JVM提供了如下三种创建对象的方式：

• new：通过new操作创建对象，那么相应对象的类定义由创建操作所在的类的类加载器加载

• Class.forName("…").newInstance：类定义的加载器与new相同

• xxxClassLoader.loadClass("…").newInstance：类定义的加载器为xxxClassLoader

  需要注意的是，JVM识别类定义之间是否一样，除了检查类全名(譬如xxx.MyClass)是否一样，还检查其相应的ClassLoader是否一样。譬如如下操作会抛出ClassCastException

Object obj = xxxClassLoader.loadClass("xxx.MyClass").newInstance(); //此处xxxClassLoader的parent不是当前类的加载器
xxx.MyClass xxx = (xxx.MyClass) obj;//ClassLoader不一样，因此JVM认为是类型是不一样的

类加载器分类

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader：

1. BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由C++实现，负责加载
   %JAVA_HOME%/lib目录下的jar包和类或者或被 -Xbootclasspath参数指定的路径中的所有类。
2. ExtensionClassLoader(扩展类加载器) ：主要负责加载目录 %JRE_HOME%/lib/ext
   目录下的jar包和类，或被 java.ext.dirs 系统变量所指定的路径下的jar包。
3. AppClassLoader(应用程序类加载器) :面向我们用户的加载器，负责加载当前应用classpath下的所有jar包和类。

使用过程：
在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。只有当父加载器在自己的搜索范围内找不到指定的类时（即ClassNotFoundException），才由自己来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

双亲委派模型

概念

如上图所示：AppClassLoader 在加载一个未知的类名时，它并不是立即去搜寻 Classpath，它会首先将这个类名称交给 ExtensionClassLoader 来加载，如果 ExtensionClassLoader 可以加载，那么 AppClassLoader 就不用麻烦了。否则它就会搜索 Classpath 。
而 ExtensionClassLoader 在加载一个未知的类名时，它也并不是立即搜寻 ext 路径，它会首先将类名称交给 BootstrapClassLoader 来加载，如果 BootstrapClassLoader 可以加载，那么 ExtensionClassLoader 也就不用麻烦了。否则它就会搜索 ext 路径下的 jar 包。
这三个 ClassLoader 之间形成了级联的父子关系，每个 ClassLoader 都很懒，尽量把工作交给父亲做，父亲干不了了自己才会干。每个 ClassLoader 对象内部都会有一个 parent 属性指向它的父加载器。

为什么使用双亲委派模型（有什么优点）？

简单的来说：一个是安全性，另一个就是性能；（避免重复加载 和 避免核心类被篡改）

如果用户自定义一个java.lang.String类，该String类具有系统的String类一样的功能，只是在某个函数稍作修改。比如equals函数，这个函数经常使用，如果在这这个函数中，黑客加入一些“病毒代码”。并且通过自定义类加载器加入到JVM中。此时，如果没有双亲委派模型，那么JVM就可能误以为黑客自定义的java.lang.String类是系统的String类，导致“病毒代码”被执行。

而有了双亲委派模型，黑客自定义的java.lang.String类永远都不会被加载进内存。因为首先是最顶端的类加载器加载系统的java.lang.String类，最终自定义的类加载器无法加载java.lang.String类。

双亲委派模型实现

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现代码都集中在ClassLoader类默认的loadClass方法中。

loadClass默认实现如下：

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
}

再看看loadClass(String name, boolean resolve)函数：

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 1、检查请求的类是否已经被加载过了
        Class c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 如果父类加载器抛出ClassNotFoundException，说明父类加载器无法完成加载请求
            }
            if (c == null) {
                // 在父类加载器无法加载的时候，再调用本身的findClass方法来进行类加载
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

1. 检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name,
   false);）.或者是调用bootstrap类加载器来加载。
3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的findClass方法来完成类加载。

换句话说，如果自定义类加载器，就必须重写findClass方法！

findClass的默认实现如下：

protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
}

可以看出，抽象类ClassLoader的findClass函数默认是抛出异常的。而前面我们知道，loadClass在父加载器无法加载类的时候，就会调用我们自定义的类加载器中的findeClass函数，因此我们必须要在loadClass这个函数里面实现将一个指定类名称转换为Class对象.

如果是读取一个指定的名称的类为字节数组的话，这很好办。但是如何将字节数组转为Class对象呢？很简单，Java提供了defineClass方法，通过这个方法，就可以把一个字节数组转为Class对象啦~

defineClass主要的功能是：

将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。如，假设class文件是加密过的，则需要解密后作为形参传入defineClass函数。

defineClass默认实现如下：

protected final Class<?> defineClass(String name, byte[] b, int off, int len)
        throws ClassFormatError  {
        return defineClass(name, b, off, len, null);
}

函数调用过程：

示例

首先，我们定义一个待加载的普通Java类:Test.java。放在com.xdwang.demo包下:

package com.xdwang.demo;
 
public class Test {
    public void hello() {
        System.out.println("恩，是的，我是由 " + getClass().getClassLoader().getClass() + " 加载进来的");
    }
}

如果你是直接在当前项目里面创建，待Test.java编译后，请把Test.class文件拷贝走，再将Test.java删除。因为如果Test.class存放在当前项目中，根据双亲委派模型可知，会通过sun.misc.Launcher$AppClassLoader 类加载器加载。为了让我们自定义的类加载器加载，我们把Test.class文件放入到其他目录。

接下来就是自定义我们的类加载器：

import java.io.FileInputStream;
import java.lang.reflect.Method;
 
public class Main {
    static class MyClassLoader extends ClassLoader {
        private String classPath;
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }
        private byte[] loadByte(String name) throws Exception {
            name = name.replaceAll("\\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name
                    + ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
 
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                return defineClass(name, data, 0, data.length);
            } catch (Exception e) {
                e.printStackTrace();
                throw new ClassNotFoundException();
            }
        }
 
    };
 
    public static void main(String args[]) throws Exception {
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //Test.class目录在D:/test/com/xdwang/demo下
        Class clazz = classLoader.loadClass("com.xdwang.demo.Test");
        Object obj = clazz.newInstance();
        Method helloMethod = clazz.getDeclaredMethod("hello", null);
        helloMethod.invoke(obj, null);
    }
}

运行结果：

恩，是的，我是由 class Main$MyClassLoader 加载进来的

二、破坏双亲委派

为什么需要破坏双亲委派？

因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件，以Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如mysql的就写了MySQL Connector，那么问题就来了，DriverManager（也由jdk提供）要加载各个实现了Driver接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能记载JAVA_HOME的lib下文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派，这里仅仅是举了破坏双亲委派的其中一个情况。

第一次破坏：

由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法唯一逻辑就是去调用自己的loadClass()。

第二次破坏：

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的同一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美。

如果基础类又要调用回用户的代码，那该么办？

一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，
它的代码由启动类加载器去加载（在JDK1.3时放进去的rt.jar），但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码，但启动类加载器不可能“认识”这些代码。

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。

第三次破坏：

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求导致的，这里所说的“动态性”指的是当前一些非常“热门”的名词：代码热替换、模块热部署等，简答的说就是机器不用重启，只要部署上就能用。
OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi幻境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1）将java.＊开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载。
3）否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7）否则，类加载器失败。

Class.forName()和ClassLoader.loadClass()的区别

Class.forName(className)方法，内部实际调用的方法是Class.forName(className,true,classloader);
第2个boolean参数表示类是否需要初始化， Class.forName(className)默认是需要初始化。
一旦初始化，就会触发目标对象的 static块代码执行，static参数也也会被再次初始化。
ClassLoader.loadClass(className)方法，内部实际调用的方法是ClassLoader.loadClass(className,false);
第2个 boolean参数，表示目标对象是否进行链接，false表示不进行链接，由上面介绍可以，
不进行链接意味着不进行包括初始化等一些列步骤，那么静态块和静态对象就不会得到执行

我们这里介绍了类加载机制和它的加载过程，以及对双亲委派机制对于java的基础平台的重大意义。接下来我们再来看看tomcat中的类加载过程。

三、Tomcat 类加载器结构

抛出问题

1、既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？(阿里的面试官问)

答： 显然不会有风险，如果有，Tomcat都运行这么多年了，那群Tomcat大神能不改进吗？ tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，还是要去顶层请求classloader.

2、我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

1）. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
2）. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。
3）. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
4）. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

再看看我们的问题：Tomcat 如果使用默认的类加载机制行不行？
答案是不行的。为什么？我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加载器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

1.Tomcat 如何实现自己独特的类加载机制？

所以，Tomcat 是怎么实现的呢？牛逼的Tomcat团队已经设计好了。如下是Tomcat6的类加载器结果图

  [BootStrapClassLoader](实际没有这个类)
                  |
 ExtensionClassLoader(对于Sun JVM，是sun.misc.Launcher$ExtClassLoader)
                  |
 SystemClassLoader(对于Sun JVM，是sun.misc.Launcher$AppClassLoader)
                  |
 CommonClassLoader(对于Tomcat 6，是org.apache.catalina.loader.StandardClassLoader)
           /               \

CatalinaClassLoader           SharedClassLoader
                                             |
                          org.apache.catalina.loader.WebappClassLoader
                                             |
                              org.apache.jasper.servlet.JasperLoader

我们看到，前面3个类加载和jvm默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载/common/、/server/、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。

• CommonClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中的common.loader指定，以SystemClassLoader为parent(目前默认定义是common.loader=$catalina.base/lib,${catalina.base}/lib/.jar,$catalina.home/lib,${catalina.home}/lib/.jar)
• CatalinaClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中server.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则ServerClassLoader
  与CommonClassLoader是同一个(默认server.loader配置为空)
• SharedClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中share.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则CatalinaClassLoader
  与CommonClassLoader是同一个(默认share.loader配置为空)
• WebappClassLoader：每个Context一个WebappClassLoader实例，负责加载context的/WEB-INF/lib和/WEB-INF/classes目录，context间的隔离就是通过不同的WebappClassLoader来做到的。由于类定义一旦加载就不可改变，因此要实现tomcat的context的reload功能，实际上是通过新建一个新的WebappClassLoader来做的，因此reload的做法实际上代价是很高昂的，需要注意的是，JVM内存的Perm区是只吃不拉的，因此抛弃掉的WebappClassLoader加载的类并不会被JVM释放，因此tomcat的reload功能如果应用定义的类比较多的话，reload几次就OutOfPermSpace异常了。（关于JVM的内存管理，可以参见之前的文章
  ，后续对这一块重新做总结）
• JasperLoader：每个JSP一个JasperLoader实例，与WebappClassLoader做法类似，JSP支持修改生效是通过丢弃旧的JasperLoader，建一个新的JasperLoader来做到的，同样的，存在轻微的PermSpace的内存泄露的情况

从图中的委派关系中可以看出：

• CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
• WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
• 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

好了，至此，我们已经知道了tomcat为什么要这么设计，以及是如何设计的，那么，tomcat 违背了java 推荐的双亲委派模型了吗？答案是：违背了。 我们前面说过：

双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器在加载类信息时都应当由自己的父类加载器加载。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

我们扩展出一个问题：如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？

看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。

2.WebappClassLoader详解

我们来看看WebappClassLoader具体是如何实现的，如上，loadClass方法是我们的重点(有时候我们的类会使用Class.getResourceAsStream或者ClassLoader.getResourceAsStream，这种搜索资源的方式会与loadClass的机制类似，因此这里不重复说明)。

public Class loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
 
        if (log.isDebugEnabled())
            log.debug("loadClass(" + name + ", " + resolve + ")");
        Class clazz = null;
 
        // Log access to stopped classloader
        if (!started) {
            try {
                throw new IllegalStateException();
            } catch (IllegalStateException e) {
                log.info(sm.getString("webappClassLoader.stopped", name), e);
            }
        }
 
        // (0) 检查WebappClassLoader之前是否已经load过这个资源
clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return (clazz);
        }
 
        // (0.1) 检查ClassLoader之前是否已经load过
        clazz = findLoadedClass(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return (clazz);
        }
 
        // (0.2) 先检查系统ClassLoader，因此WEB-INF/lib和WEB-INF/classes或{tomcat}/libs下的类定义不能覆盖JVM 底层能够查找到的定义(譬如不能通过定义java.lang.Integer替代底层的实现
        try {
            clazz = system.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return (clazz);
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }
 
        // (0.5) Permission to access this class when using a SecurityManager
        if (securityManager != null) {
            int i = name.lastIndexOf('.');
            if (i >= 0) {
                try {
                    securityManager.checkPackageAccess(name.substring(0,i));
                } catch (SecurityException se) {
                    String error = "Security Violation, attempt to use " +
                        "Restricted Class: " + name;
                    log.info(error, se);
                    throw new ClassNotFoundException(error, se);
                }
            }
        }
 
        //这是一个很奇怪的定义，JVM的ClassLoader建议先由parent去load，load不到自己再去load(见如上 ClassLoader部分)，而Servelet规范的建议则恰好相反，Tomcat的实现则做个折中，由用户去决定(context的 delegate定义)，默认使用Servlet规范的建议，即delegate=false
        boolean delegateLoad = delegate || filter(name);
 
        // (1) 先由parent去尝试加载，此处的parent是SharedClassLoader，见如上说明，如上说明，除非设置了delegate，否则这里不执行
        if (delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader1 " + parent);
            ClassLoader loader = parent;
             //此处parent是否为空取决于context 的privileged属性配置，默认privileged=true，即parent为SharedClassLoader
            if (loader == null)
                loader = system;
            try {
                clazz = loader.loadClass(name);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return (clazz);
                }
            } catch (ClassNotFoundException e) {
                ;
            }
        }
 
        // (2) 到WEB-INF/lib和WEB-INF/classes目录去搜索，细节部分可以再看一下findClass，会发现默认是先搜索WEB-INF/classes后搜索WEB-INF/lib
        if (log.isDebugEnabled())
            log.debug("  Searching local repositories");
        try {
            clazz = findClass(name);
            if (clazz != null) {
                if (log.isDebugEnabled())
                    log.debug("  Loading class from local repository");
                if (resolve)
                    resolveClass(clazz);
                return (clazz);
            }
        } catch (ClassNotFoundException e) {
            ;
        }
 
        // (3) 由parent再去尝试加载一下
        if (!delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader at end: " + parent);
            ClassLoader loader = parent;
            if (loader == null)
                loader = system;
            try {
                clazz = loader.loadClass(name);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return (clazz);
                }
            } catch (ClassNotFoundException e) {
                ;
            }
        }
 
        throw new ClassNotFoundException(name);
    }

Tomcat类加载过程总结：

tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。具体的加载逻辑位于WebAppClassLoaderBase.loadClass()方法中，代码篇幅长，这里以文字描述加载一个类过程：

1. 先在本地缓存中查找是否已经加载过该类(对于一些已经加载了的类，会被缓存在resourceEntries这个数据结构中)，如果已经加载即返回，否则
   继续下一步。
2. 让系统类加载器(AppClassLoader)尝试加载该类，主要是为了防止一些基础类会被web中的类覆盖，如果加载到即返回，返回继续。
3. 前两步均没加载到目标类，那么web应用的类加载器将自行加载，如果加载到则返回，否则继续下一步。
4. 最后还是加载不到的话，则委托父类加载器(Common ClassLoader)去加载。

第3第4两个步骤的顺序已经违反了双亲委托机制，除了tomcat之外，JDBC,JNDI,Thread.currentThread().setContextClassLoader();等很多地方都一样是违反了双亲委托。