谈谈类装载器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"));

        结果是什么?一试便知。

你可能感兴趣的:(java技术)