谈谈类装载器ClassLoader以及“全盘负责委托机制”

        JVM在运行时产生三个ClassLoader:根装载器、ExtClassLoader(扩展类装载器)和AppClassLoader(系统类装载器)。其中根装载器不是ClassLoader的子类，它使用C++编写，所以我们在Java中是看不到它的。

        那么这三个ClassLoader是做什么的呢？

        根装载器主要负责装载JRE的核心类库，入JRE目标下的rt.jar、charsets.jar等；

        ExtClassLoader和AppClassLoader都是ClassLoader的子类，ExtClassLoader负责装载JRE扩展目录ext中的JAR包；AppClassLoader负责装载Classpath路径下的类包。

        这三个类装载器之间的父子关系是：根装载器是ExtClassLoader的父装载器，ExtClassLoader是AppClassLoader的父装载器。默认情况下，使用AppClassLoader装载应用程序的类，如下面这个例子所示：

public class ClassLoaderTest {
    public static void main(String[] args) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        System.out.println("current loader:"+loader);
        System.out.println("parent loader:"+loader.getParent());
        System.out.println("grandparent loader:"+loader.getParent().getParent());
    }
}

       运行结果:

current loader:sun.misc.Launcher$AppClassLoader@1c78e57
parent loader:sun.misc.Launcher$ExtClassLoader@5224ee
grandparent loader:null

        可以知道当前的ClassLoader是AppClassLoader，父ClassLoader是ExtClassLoader，祖父ClassLoader是根装载器，因为在java中无法获得它的句柄，所以返回null。

 

        于是我们可以联想到JVM装载类时使用的“全盘负责委托机制”。因为ClassLoader装载一个类时，永远是由根装载器来装载的，只有在找不到类时才从自己的类路径中查找并装载目标类，于是避免了有人编写了一个恶意的基础类(如java.lang.String)并装载到JVM中所带来的可怕后果。

        比如说：我们单独写一个java.lang.String：

package java.lang;

public class String {
    public String(String msg) {
        System.out.println("String");
        System.out.println(msg);
    }
}

        那么我们在其他类调用java.lang.String会出现什么结果呢，比如

System.out.println(new String("myString"));

        结果是什么？一试便知。