java_guide_类加载器

类加载器总结

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包和类。

双亲委派模型介绍

每个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工做的时候会默认使用 双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，不然才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，所以全部的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器没法处理时，才由本身来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 做为父类加载器。

 

 每一个类加载都有一个父类加载器，咱们经过下面的程序来验证。

public class ClassLoaderDemo {
    public static void main(String[] args) {
        System.out.println("ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader());
        System.out.println("The Parent of ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader().getParent());
        System.out.println("The GrandParent of ClassLodarDemo's ClassLoader is " + ClassLoaderDemo.class.getClassLoader().getParent().getParent());
    }
}

 

ClassLodarDemo's ClassLoader is sun.misc.Launcher$AppClassLoader@18b4aac2
The Parent of ClassLodarDemo's ClassLoader is sun.misc.Launcher$ExtClassLoader@1b6d3586
The GrandParent of ClassLodarDemo's ClassLoader is null

 

AppClassLoader的父类加载器为ExtClassLoader ExtClassLoader的父类加载器为null，null并不表明ExtClassLoader没有父类加载器，而是 BootstrapClassLoader 。

双亲委派模型的好处

双亲委派模型保证了Java程序的稳定运行，能够避免类的重复加载（JVM 区分不一样类的方式不只仅根据类名，相同的类文件被不一样的类加载器加载产生的是两个不一样的类），也保证了 Java 的核心 API 不被篡改。若是没有使用双亲委派模型，而是每一个类加载器加载本身的话就会出现一些问题，好比咱们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不一样的 Object 类。

---

 

转：深刻分析Java ClassLoader原理

1、什么是ClassLoader?
         你们都知道，当咱们写好一个Java程序以后，不是管是CS仍是BS应用，都是由若干个.class文件组织而成的一个完整的Java应用程序，当程序在运行时，即会调用该程序的一个入口函数来调用系统的相关功能，而这些功能都被封装在不一样的class文件当中，因此常常要从这个class文件中要调用另一个class文件中的方法，若是另一个文件不存在的，则会引起系统异常。而程序在启动的时候，并不会一次性加载程序所要用的全部class文件，而是根据程序的须要，经过Java的类加载机制（ClassLoader）来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存以后，才能被其它class所引用。因此ClassLoader就是用来动态加载class文件到内存当中用的。

 一、原理介绍
       ClassLoader使用的是双亲委托模型来搜索类的，每一个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）自己没有父类加载器，但能够用做其它ClassLoader实例的的父类加载器。当一个ClassLoader实例须要加载某个类时，它会试图亲自搜索某个类以前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，若是没加载到，则把任务转交给Extension ClassLoader试图加载，若是也没加载到，则转交给App ClassLoader 进行加载，若是它也没有加载获得的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。若是它们都没有加载到这个类时，则抛出ClassNotFoundException异常。不然将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。

二、为何要使用双亲委托这种模型呢？
       由于这样能够避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。考虑到安全因素，咱们试想一下，若是不使用这种委托模式，那咱们就能够随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在很是大的安全隐患，而双亲委托的方式，就能够避免这种状况，由于String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，因此用户自定义的ClassLoader永远也没法加载一个本身写的String，除非你改变JDK中ClassLoader搜索类的默认算法。

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

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

4、定义自已的ClassLoader
既然JVM已经提供了默认的类加载器，为何还要定义自已的类加载器呢？

由于Java中提供的默认ClassLoader，只加载指定目录下的jar和class，若是咱们想加载其它位置的类或jar时，好比：我要加载网络上的一个class文件，经过动态加载到内存以后，要调用这个类中的方法实现个人业务逻辑。在这样的状况下，默认的ClassLoader就不能知足咱们的需求了，因此须要定义本身的ClassLoader。

定义自已的类加载器分为两步：

一、继承java.lang.ClassLoader

二、重写父类的findClass方法

读者可能在这里有疑问，父类有那么多方法，为何恰恰只重写findClass方法？

      由于JDK已经在loadClass方法中帮咱们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，因此咱们只需重写该方法便可。如没有特殊的要求，通常不建议重写loadClass搜索类的算法。