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”));
结果是什么？一试便知。