深刻理解Java类加载器(ClassLoader)

时间 2019-11-16

原文原文链接

【版权申明】未经博主赞成，谢绝转载！（请尊重原创，博主保留追究权）

本篇博文主要是探讨类加载器，同时在本篇中列举的源码都基于Java8版本，不一样的版本可能有些许差别。主要内容以下java

类加载的机制的层次结构

每一个编写的".java"拓展名类文件都存储着须要执行的程序逻辑，这些".java"文件通过Java编译器编译成拓展名为".class"的文件，".class"文件中保存着Java代码经转换后的虚拟机指令，当须要使用某个类时，虚拟机将会加载它的".class"文件，并建立对应的class对象，将class文件加载到虚拟机的内存，这个过程称为类加载，这里咱们须要了解一下类加载的过程，以下：mysql

加载：类加载过程的一个阶段：经过一个类的彻底限定查找此类字节码文件，并利用字节码文件建立一个Class对象sql
验证：目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，不会危害虚拟机自身安全。主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。数据库
准备：为类变量(即static修饰的字段变量)分配内存而且设置该类变量的初始值即0(如static int i=5;这里只将i初始化为0，至于5的值将在初始化时赋值)，这里不包含用final修饰的static，由于final在编译的时候就会分配了，注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一块儿分配到Java堆中。api
解析：主要将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标，能够是任何字面量，而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。有类或接口的解析，字段解析，类方法解析，接口方法解析(这里涉及到字节码变量的引用，如需更详细了解，可参考《深刻Java虚拟机》)。数组
初始化：类加载最后阶段，若该类具备超类，则对其进行初始化，执行静态初始化器和静态初始化成员变量(如前面只初始化了默认值的static变量将会在这个阶段赋值，成员变量也将被初始化)。缓存

这即是类加载的5个过程，而类加载器的任务是根据一个类的全限定名来读取此类的二进制字节流到JVM中，而后转换为一个与目标类对应的java.lang.Class对象实例，在虚拟机提供了3种类加载器，引导（Bootstrap）类加载器、扩展（Extension）类加载器、系统（System）类加载器（也称应用类加载器），下面分别介绍安全

##启动（Bootstrap）类加载器
启动类加载器主要加载的是JVM自身须要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中，注意必因为虚拟机是按照文件名识别加载jar包的，如rt.jar，若是文件名不被虚拟机识别，即便把jar包丢到lib目录下也是没有做用的(出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。网络

##扩展（Extension）类加载器
扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类，由Java语言实现的，是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者能够直接使用标准扩展类加载器。app

//ExtClassLoader类中获取路径的代码
private static File[] getExtDirs() {
     //加载<JAVA_HOME>/lib/ext目录中的类库
     String s = System.getProperty("java.ext.dirs");
     File[] dirs;
     if (s != null) {
         StringTokenizer st =
             new StringTokenizer(s, File.pathSeparator);
         int count = st.countTokens();
         dirs = new File[count];
         for (int i = 0; i < count; i++) {
             dirs[i] = new File(st.nextToken());
         }
     } else {
         dirs = new File[0];
     }
     return dirs;
 }复制代码

系统（System）类加载器

也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是咱们常常用到的classpath路径，开发者能够直接使用系统类加载器，通常状况下该类加载是程序中默认的类加载器，经过ClassLoader#getSystemClassLoader()方法能够获取到该类加载器。
　在Java的平常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，咱们还能够自定义类加载器，须要注意的是，Java虚拟机对class文件采用的是按需加载的方式，也就是说当须要使用该类时才会将它的class文件加载到内存生成class对象，并且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式即把请求交由父类处理，它一种任务委派模式，下面咱们进一步了解它。　

理解双亲委派模式

双亲委派模式工做原理

双亲委派模式要求除了顶层的启动类加载器外，其他的类加载器都应当有本身的父类加载器，请注意双亲委派模式中的父子关系并不是一般所说的类继承关系，而是采用组合关系来复用父类加载器的相关代码，类加载器间的关系以下：

双亲委派模式是在Java 1.2后引入的，其工做原理的是，若是一个类加载器收到了类加载请求，它并不会本身先去加载，而是把这个请求委托给父类的加载器去执行，若是父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，若是父类加载器能够完成类加载任务，就成功返回，假若父类加载器没法完成此加载任务，子加载器才会尝试本身去加载，这就是双亲委派模式，即每一个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子本身想办法去完成，这不就是传说中的实力坑爹啊？那么采用这种模式有啥用呢?

双亲委派模式优点

采用双亲委派模式的是好处是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对象天然也不会相同。

了解class文件的显示加载与隐式加载的概念

所谓class文件的显示加载与隐式加载的方式是指JVM加载class文件到内存的方式，显示加载指的是在代码中经过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。而隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是经过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另一个类的对象，此时额外引用的类将经过JVM自动加载到内存中。在平常开发以上两种方式通常会混合使用，这里咱们知道有这么回事便可。

编写本身的类加载器

经过前面的分析可知，实现自定义类加载器须要继承ClassLoader或者URLClassLoader，继承ClassLoader则须要本身重写findClass()方法并编写加载逻辑，继承URLClassLoader则能够省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢？

当class文件不在ClassPath路径下，默认系统类加载器没法找到该class文件，在这种状况下咱们须要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。
当一个class文件是经过网络传输而且可能会进行相应的加密操做时，须要先对class文件进行相应的解密后再加载到JVM内存中，这种状况下也须要编写自定义的ClassLoader并实现相应的逻辑。
当须要实现热部署功能时(一个class文件经过不一样的类加载器产生不一样class对象从而实现热部署功能)，须要实现自定义ClassLoader的逻辑。

自定义File类加载器

这里咱们继承ClassLoader实现自定义的特定路径下的文件类加载器并加载编译后DemoObj.class，源码代码以下

public class DemoObj {
    @Override
    public String toString() {
        return "I am DemoObj";
    }
}复制代码

package com.zejian.classloader;

import java.io.*;

/** * Created by zejian on 2017/6/21. */
public class FileClassLoader extends ClassLoader {
    private String rootDir;

    public FileClassLoader(String rootDir) {
        this.rootDir = rootDir;
    }

    /** * 编写findClass方法的逻辑 * @param name * @return * @throws ClassNotFoundException */
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 获取类的class文件字节数组
        byte[] classData = getClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            //直接生成class对象
            return defineClass(name, classData, 0, classData.length);
        }
    }

    /** * 编写获取class文件并转换为字节码流的逻辑 * @param className * @return */
    private byte[] getClassData(String className) {
        // 读取类文件的字节
        String path = classNameToPath(className);
        try {
            InputStream ins = new FileInputStream(path);
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int bufferSize = 4096;
            byte[] buffer = new byte[bufferSize];
            int bytesNumRead = 0;
            // 读取类文件的字节码
            while ((bytesNumRead = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesNumRead);
            }
            return baos.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

    /** * 类文件的彻底路径 * @param className * @return */
    private String classNameToPath(String className) {
        return rootDir + File.separatorChar
                + className.replace('.', File.separatorChar) + ".class";
    }

    public static void main(String[] args) throws ClassNotFoundException {
        String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
        //建立自定义文件类加载器
        FileClassLoader loader = new FileClassLoader(rootDir);

        try {
            //加载指定的class文件
            Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
            System.out.println(object1.newInstance().toString());

            //输出结果:I am DemoObj
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}复制代码

显然咱们经过getClassData()方法找到class文件并转换为字节流，并重写findClass()方法，利用defineClass()方法建立了类的class对象。在main方法中调用了loadClass()方法加载指定路径下的class文件，因为启动类加载器、拓展类加载器以及系统类加载器都没法在其路径下找到该类，所以最终将有自定义类加载器加载，即调用findClass()方法进行加载。若是继承URLClassLoader实现，那代码就更简洁了，以下：

/** * Created by zejian on 2017/6/21. */
public class FileUrlClassLoader extends URLClassLoader {

    public FileUrlClassLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }

    public FileUrlClassLoader(URL[] urls) {
        super(urls);
    }

    public FileUrlClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
        super(urls, parent, factory);
    }


    public static void main(String[] args) throws ClassNotFoundException, MalformedURLException {
        String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
        //建立自定义文件类加载器
        File file = new File(rootDir);
        //File to URI
        URI uri=file.toURI();
        URL[] urls={uri.toURL()};

        FileUrlClassLoader loader = new FileUrlClassLoader(urls);

        try {
            //加载指定的class文件
            Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
            System.out.println(object1.newInstance().toString());

            //输出结果:I am DemoObj
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}复制代码

很是简洁除了须要重写构造器外无需编写findClass()方法及其class文件的字节流转换逻辑。

自定义网络类加载器

自定义网络类加载器，主要用于读取经过网络传递的class文件（在这里咱们省略class文件的解密过程），并将其转换成字节流生成对应的class对象，以下

/** * Created by zejian on 2017/6/21. */
public class NetClassLoader extends ClassLoader {

    private String url;//class文件的URL

    public NetClassLoader(String url) {
        this.url = url;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = getClassDataFromNet(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            return defineClass(name, classData, 0, classData.length);
        }
    }

    /** * 从网络获取class文件 * @param className * @return */
    private byte[] getClassDataFromNet(String className) {
        String path = classNameToPath(className);
        try {
            URL url = new URL(path);
            InputStream ins = url.openStream();
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int bufferSize = 4096;
            byte[] buffer = new byte[bufferSize];
            int bytesNumRead = 0;
            // 读取类文件的字节
            while ((bytesNumRead = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesNumRead);
            }
            //这里省略解密的过程.......
            return baos.toByteArray();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    private String classNameToPath(String className) {
        // 获得类文件的URL
        return url + "/" + className.replace('.', '/') + ".class";
    }

}复制代码

比较简单，主要是在获取字节码流时的区别，从网络直接获取到字节流再转车字节数组而后利用defineClass方法建立class对象，若是继承URLClassLoader类则和前面文件路径的实现是相似的，无需担忧路径是filePath仍是Url，由于URLClassLoader内的URLClassPath对象会根据传递过来的URL数组中的路径判断是文件仍是jar包，而后根据不一样的路径建立FileLoader或者JarLoader或默认类Loader去读取对于的路径或者url下的class文件。

热部署类加载器

所谓的热部署就是利用同一个class文件不一样的类加载器在内存建立出两个不一样的class对象(关于这点的缘由前面已分析过，即利用不一样的类加载实例)，因为JVM在加载类以前会检测请求的类是否已加载过(即在loadClass()方法中调用findLoadedClass()方法)，若是被加载过，则直接从缓存获取，不会从新加载。注意同一个类加载器的实例和同一个class文件只能被加载器一次，屡次加载将报错，所以咱们实现的热部署必须让同一个class文件能够根据不一样的类加载器重复加载，以实现所谓的热部署。实际上前面的实现的FileClassLoader和FileUrlClassLoader已具有这个功能，但前提是直接调用findClass()方法，而不是调用loadClass()方法，由于ClassLoader中loadClass()方法体中调用findLoadedClass()方法进行了检测是否已被加载，所以咱们直接调用findClass()方法就能够绕过这个问题，固然也能够从新loadClass方法，但强烈不建议这么干。利用FileClassLoader类测试代码以下：

public static void main(String[] args) throws ClassNotFoundException {
        String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
        //建立自定义文件类加载器
        FileClassLoader loader = new FileClassLoader(rootDir);
        FileClassLoader loader2 = new FileClassLoader(rootDir);

        try {
            //加载指定的class文件,调用loadClass()
            Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
            Class<?> object2=loader2.loadClass("com.zejian.classloader.DemoObj");

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

            //加载指定的class文件,直接调用findClass(),绕过检测机制，建立不一样class对象。
            Class<?> object3=loader.findClass("com.zejian.classloader.DemoObj");
            Class<?> object4=loader2.findClass("com.zejian.classloader.DemoObj");

            System.out.println("loadClass->obj3:"+object3.hashCode());
            System.out.println("loadClass->obj4:"+object4.hashCode());

            /** * 输出结果: * loadClass->obj1:644117698 loadClass->obj2:644117698 findClass->obj3:723074861 findClass->obj4:895328852 */

        } catch (Exception e) {
            e.printStackTrace();
        }
    }复制代码

双亲委派模型的破坏者-线程上下文类加载器

在Java应用中存在着不少服务提供者接口（Service Provider Interface，SPI），这些接口容许第三方为它们提供实现，如常见的 SPI 有 JDBC、JNDI等，这些 SPI 的接口属于 Java 核心库，通常存在rt.jar包中，由Bootstrap类加载器加载，而 SPI 的第三方实现代码则是做为Java应用所依赖的 jar 包被存放在classpath路径下，因为SPI接口中的代码常常须要加载具体的第三方实现类并调用其相关方法，但SPI的核心接口类是由引导类加载器来加载的，而Bootstrap类加载器没法直接加载SPI的实现类，同时因为双亲委派模式的存在，Bootstrap类加载器也没法反向委托AppClassLoader加载器SPI的实现类。在这种状况下，咱们就须要一种特殊的类加载器来加载第三方的类库，而线程上下文类加载器就是很好的选择。
线程上下文类加载器（contextClassLoader）是从 JDK 1.2 开始引入的，咱们能够经过java.lang.Thread类中的getContextClassLoader()和 setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。若是没有手动设置上下文类加载器，线程将继承其父线程的上下文类加载器，初始线程的上下文类加载器是系统类加载器（AppClassLoader）,在线程中运行的代码能够经过此类加载器来加载类和资源，以下图所示，以jdbc.jar加载为例

从图可知rt.jar核心包是有Bootstrap类加载器加载的，其内包含SPI核心接口类，因为SPI中的类常常须要调用外部实现类的方法，而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)没法经过Bootstrap类加载器加载，所以只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”，它在执行过程当中抛弃双亲委派加载链模式，使程序能够逆向使用类加载器，固然这也使得Java类加载器变得更加灵活。为了进一步证明这种场景，不妨看看DriverManager类的源码，DriverManager是Java核心rt.jar包中的类，该类用来管理不一样数据库的实现驱动即Driver，它们都实现了Java核心包中的java.sql.Driver接口，如mysql驱动包中的com.mysql.jdbc.Driver，这里主要看看如何加载外部实现类，在DriverManager初始化时会执行以下代码

//DriverManager是Java核心包rt.jar的类
public class DriverManager {
    //省略没必要要的代码
    static {
        loadInitialDrivers();//执行该方法
        println("JDBC DriverManager initialized");
    }

//loadInitialDrivers方法
 private static void loadInitialDrivers() {
     sun.misc.Providers()
     AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                //加载外部的Driver的实现类
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
              //省略没必要要的代码......
            }
        });
    }复制代码

在DriverManager类初始化时执行了loadInitialDrivers()方法,在该方法中经过ServiceLoader.load(Driver.class);去加载外部实现的驱动类，ServiceLoader类会去读取mysql的jdbc.jar下META-INF文件的内容，以下所示

而com.mysql.jdbc.Driver继承类以下：

public class Driver extends com.mysql.cj.jdbc.Driver {
    public Driver() throws SQLException {
        super();
    }

    static {
        System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
                + "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
    }
}复制代码

从注释能够看出日常咱们使用com.mysql.jdbc.Driver已被丢弃了，取而代之的是com.mysql.cj.jdbc.Driver，也就是说官方再也不建议咱们使用以下代码注册mysql驱动

//不建议使用该方式注册驱动类
Class.forName("com.mysql.jdbc.Driver");
String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
// 经过java库获取数据库链接
Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");复制代码

而是直接去掉注册步骤，以下便可

String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
// 经过java库获取数据库链接
Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");复制代码

这样ServiceLoader会帮助咱们处理一切，并最终经过load()方法加载，看看load()方法实现

public static ServiceLoader load(Class service) {
     //经过线程上下文类加载器加载
      ClassLoader cl = Thread.currentThread().getContextClassLoader();
      return ServiceLoader.load(service, cl);
  }复制代码

很明显了确实经过线程上下文类加载器加载的，实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的，经过这种方式实现了Java核心代码内部去调用外部实现类。咱们知道线程上下文类加载器默认状况下就是AppClassLoader，那为何不直接经过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢？实际上是可行的，但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点，那就是代码部署到不一样服务时会出现问题，如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题，由于这些服务使用的线程上下文类加载器并不是AppClassLoader，而是Java Web应用服自家的类加载器，类加载器不一样。，因此咱们应用该少用getSystemClassLoader()。总之不一样的服务使用的可能默认ClassLoader是不一样的，但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader，从而避免没必要要的问题。ok~.关于线程上下文类加载器暂且聊到这，前面阐述的DriverManager类，你们能够自行看看源码，相信会有更多的体会，另外关于ServiceLoader本篇并无过多的阐述，毕竟咱们主题是类加载器，但ServiceLoader是个很不错的解耦机制，你们能够自行查阅其相关用法。

ok~，本篇到此告一段落，若有误处，欢迎留言，谢谢。

参考资料：
blog.csdn.net/yangcheng33…
ifeve.com/wp-content/…

《深刻理解JVM虚拟机》《深刻分析Java Web 技术内幕》