初探JVM-ClassLoader源码

        之前简单介绍了一下JVM中的ClassLoader （见《JVM类加载机制-ClassLoader》），现在我们再来看看ClassLoader的源码。

ClassLoader 

        首先，我们看看ClassLoader的构造方法，如果不传入参的话，默认父加载为SystemClassLoader默认加载器。

protected ClassLoader() {
        this(checkCreateClassLoader(),getSystemClassLoader());
}

 

        我们再细看一层，发现SystemClassLoader原来要到sun.misc.Launcher里面去。其实JVM用到的3个类加载器，有两个是sun.misc.Launcher里面的AppClassLoader和ExtClassLoader，还有一个BootstrapLoader是C++写的，这里我们就不细究了。

private static synchronized void initSystemClassLoader() {
        if (!sclSet) {
            if (scl !=null)
                throw new IllegalStateException("recursive invocation");
            sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
            if (l !=null) {
                Throwable oops = null;
                scl = l.getClassLoader();
                try {
                    scl = AccessController.doPrivileged(new SystemClassLoaderAction(scl));
                } catch (PrivilegedActionException pae) {
                    oops = pae.getCause();
                }
            }
            sclSet = true;
        }
}

        我们再来看看loadClass()，这个无疑是整个ClassLoader的重点，其处理逻辑为：

1. 调用 findLoadedClass()检查是否已经加载类。

2. 在父类加载器上调用loadClass()，让父类先尝试加载（委派模型）。如果父类加载器为null，就是说到达顶层加载器了，则用内置类加载方法findBootstrapClass0()来加载。

3. 顶层加载器的findBootstrapClass0()也找不到class的话，就会抛出异常，此时再调用当前加载器的findClass()查找。

        通过这个流程，能保证每个class只load一次，避免发生类冲突。而且按照委派模型，每次都从顶层ClassLoader开始加载，确保类加载的安全。

protected synchronized Class<?>loadClass(String name, boolean resolve)throws ClassNotFoundException {     
        Class c = findLoadedClass(name);  // Check if it has already beenloaded
        if (c ==null) {
            try {
                if (parent !=null)
                    c = parent.loadClass(name,false);
                else
                    c = findBootstrapClass0(name);
            }
            catch (ClassNotFoundException e) {             
                c = findClass(name);  // If still not found, then invokefindClass
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
}
private native final Class findLoadedClass0(String name);
private native Class findBootstrapClass(String name);
private native void resolveClass0(Class c);
protected Class<?>findClass(String name)throws ClassNotFoundException
        throw new ClassNotFoundException(name);
}

        以上代码能看出，底层load和find的实现都不是Java写的，交给本地方法实现，由JVM管理。

        另外你也许会疑惑，ClassLoader.findClass()里面竟然直接抛出异常。这是因为JVM一般的类都是由findBootstrapClass0()来查找的，如果找不到，就说明classpath中没有此class了，所以这里只能继续抛出ClassNotFoundException。

（所以我们看到ClassNotFoundException出现的时候，第一反应应该检查一下classpath的设置，检查该类的.class是否存在，检查jar包有没有部署好等等。）

        其实findClass()是留给用户自定义的类加载器实现的。因为findBootstrapClass0()只会在classPath中查找.class文件，如果你通过别的方式（如网络），或者在别的路径（classpath以外的路径）加载，就要自定义ClassLoader，并通过重写findClass()来重新指向你的类。 如URLClassLoader

        这里最好不要重写loadClass()，因为会损坏ClassLoader的委派模型，造成安全隐患。

 

        另外，我们可以用代码来查看JVM加载器的层次结构。

        JVM的ClassLoader是三层结构，分别是：BootstrapLoader加载系统类，ExtClassLoader加载扩展类，AppClassLoader加载应用类。

        我们建一个测试类Inner4Test，然后循环打印出它的类加载器。

        Class<?> c = Class.forName("com.jscai.classloader.Inner4Test");
        ClassLoader loader = c.getClassLoader();
        while (loader !=null) {
            System.out.println(loader.toString());
            loader = loader.getParent();
       }

console：

sun.misc.Launcher$AppClassLoader@79b0edb2

sun.misc.Launcher$ExtClassLoader@4ec57f88

        这里清晰地打印出JVM类加载的层次，但只有AppClassLoader和ExtClassLoader，其实BootstrapLoader的缺席，是因为BootstrapLoader是C++写的，Java这边没法显示，所以认为null。

 

 

        接着，我们看看UrlClassLoader是怎么实现自定义加载的。

URLClassLoader

        URLClassLoader加载器用于从 指向JAR文件和目录的URL的搜索路径 来加载类和资源。相对于JVM的加载器只能加载classpath来说，他可以指向任意可达的URL来加载类资源。

 

        从类的继承结构来看，URLClassLoader->SecureClassLoader->ClassLoader，URLClassLoader间接继承了ClassLoader。

public class URLClassLoader extends SecureClassLoaderimplements Closeable

 

        在URLClassLoader自定义的类加载策略中，没有修改loadClass()，而只是重写了findClass()。他会把我们传入的类名"com.jscai.classloader.Ext4Test"，根据构造函数中的path，拼装成.class文件名"com/jscai/classloader/Ext4Test.class"，然后在defineClass()中把.class文件加载成类对象。

        在执行URLClassLoader.loadClass()的时候，因为是URL指向的类资源在classpath以外，所以在委派模型上面是找不到的。这时候抛出ClassNotFound异常，跳到URLClassLoader.findClass()来执行自定义的加载。

    protected Class<?> findClass(final String name)throws ClassNotFoundException{
        try {
            return (Class) AccessController.doPrivileged(newPrivilegedExceptionAction() {
                public Object run()throws ClassNotFoundException {
                    String path = name.replace('.','/').concat(".class");
                    Resource res = ucp.getResource(path,false);
                    if (res !=null) {
                        try {
                            return defineClass(name,res,true);
                        }
                        catch (IOException e) {
                            thrownewClassNotFoundException(name, e);
                        }
                    }
                    else {
                        thrownewClassNotFoundException(name);
                    }
                }
            }, acc);
        }
        catch (java.security.PrivilegedActionExceptionpae) {
            throw (ClassNotFoundException) pae.getException();
        }
    }

 

        这里写个简单的URLClassLoader-demo，先创建一个简单的测试类Ext4Test，然后写一个测试方法来证明JVM能正常加载：

        System.out.println(Class.forName("com.jscai.classloader.Ext4Test"));

 

        然后到bin目录把Ext4Test.class连同package文件夹（因为URLClassLoader会根据包名解析成目录结构）放到根目录下的newClass目录，然后把Ext4Test类删掉。再运行刚刚的测试方法，会抛出ClassNotFoundException。说明此时Ext4Test类不在classpath，JVM的类加载器已经找不到它了。

        这时候再指定URLClassLoader来加载，这时候能正常运行，说明URLClassLoader能找到classpath以外的Ext4Test.class。

        String url = "file:/" + System.getProperty("user.dir") +"/newClass/";
        URLClassLoader ucl = new URLClassLoader(new URL[]{new URL(url)});
        Class<?> c = ucl.loadClass("com.jscai.classloader.Ext4Test");
        ClassLoader loader = c.getClassLoader();
        while (loader !=null) {
            System.out.println(loader.toString());
            loader = loader.getParent();
        }

console：

java.net.URLClassLoader@248523a0

sun.misc.Launcher$AppClassLoader@79b0edb2

sun.misc.Launcher$ExtClassLoader@4ec57f88

 

        而且这里能看出，类加载遵循委派模型，URLClassLoader位于JVM的类加载器之后。

        所以，这里如果只是加载classpath以内的class，那JVM类加载器加载完就结束了，即使用URLClassLoader来加载，也不会经过URLClassLoader的。

        String InnerName = "com.jscai.classloader.Inner4Test";
        URLClassLoader ucl = new URLClassLoader(new URL[]{new URL(url)});
        Class<?> c = ucl.loadClass(InnerName);
        ClassLoader loader = c.getClassLoader();
        while (loader != null) {
            System.out.println(loader.toString());
            loader = loader.getParent();
        }

console：

sun.misc.Launcher$AppClassLoader@79b0edb2

sun.misc.Launcher$ExtClassLoader@4ec57f88

 

动态加载--Class的识别

        了解了JVM的ClassLoader和自定义类加载器后，我们谈谈ClassLoader比较火的应用--类的动态加载/装载。

        类的动态加载就是在不重启JVM的前提下，把新的class加载到内存中（新的class对象覆盖旧的class对象）。那为什么ClassLoader能动态加载，JVM中是怎么管理class对象的， JVM中是怎么辨别class对象的新旧的，……等等很多问题都是值得我们去思考和探究，在这里我们先讨论，JVM中是怎么识别一个class对象的。

 

        在JVM中，唯一标识一个class对象需要看两个条件：A类全名(包名+类名)，B加载器实例。

        就是说，只要是同一个类加载器实例加载的同一个名字的class对象，JVM都认为是同一个类。

        Class<?> c1 = Class.forName("com.jscai.classloader.Inner4Test");
        Class<?> c2 = Class.forName("com.jscai.classloader.Inner4Test");
        System.out.println("They aresame class : " + (c1 == c2));

console ：

They are same class : true

        两个Object用==比较，返回true，就是两者的地址相等，就说明是同一个Object。因此我们能看出，同名的class在JVM只会加载一次，所以两者相等。

        但是如果用URLClassLoader加载外面的类Ext4Test，效果却不一样：

        String url = "file:/" + System.getProperty("user.dir") +"/newClass/";
        URLClassLoader ucl1 = new URLClassLoader(new URL[]{new URL(url)});
        URLClassLoader ucl2 = new URLClassLoader(new URL[]{new URL(url)});
        Class<?> c1 = ucl1.loadClass("com.jscai.classloader.Ext4Test");
        Class<?> c2 = ucl2.loadClass("com.jscai.classloader.Ext4Test");
        System.out.println("They aresame class : " + (c1 == c2));

console：

They are same class : false

        虽然类名是一样的，但是使用的类加载器实例不同，所以JVM不认为这俩是同一个class，两者就不想等了。而上个例子中，两个Inner4Test的class相等，是因为JVM的类加载实例都是单例，同名和同加载器实例的两个条件都符合了。

        同样我们可以把类加载器实例换成一样的，两个class就相等了：

        URLClassLoader ucl1 = new URLClassLoader(new URL[]{new URL(url)});
        Class<?> c1 = ucl1.loadClass("com.jscai.classloader.Ext4Test");
        Class<?> c2 = ucl1.loadClass("com.jscai.classloader.Ext4Test");
        System.out.println("They aresame class : " + (c1 == c2));

console：

They are same class : true

 

        因此，根据这个特点，我们可以自定义类加载器，来实现动态加载类（装载）：一方面管理好现有的实例对象，另一方面监听是否有jar更新，如果有更新就重新生成加载器实例去加载这些class，这样新的class就能代替旧的class，就能实现动态加载而避免整体重启了。例如Tomcat的热部署。   （当然，具体实现还是很复杂的，没有我说的那么简单！）

 

---- 源码参考JDK-7