java 委托机制_谈谈类装载器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"));

结果是什么？一试便知。