初探JVM-ClassLoader源码

原创 2013年12月02日 01:21:05

        之前简单介绍了一下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

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

从jdk源码角度理解jvm类加载机制

关于jvm类加载机制,个人感觉还是挺有深度的,可能一般写代码关注业务居多,对jvm的一些机制关注太少,只知其表,而不然其因,实在肤浅。这样写代码估计也写不出优雅的代码来。 网络上关于jvn类加载机制的...

JVM类加载机制(ClassLoader)源码解析(1)

其实JVM类加载机制,简单地说就是类管理,也就是我们生成的class文件。 三个步骤:装载(load)、链接(link)、解析(Resolve)、还有初始化(Initialize) 关于网上有很多...

JVM类加载-从ClassLoader源码看双亲委托模型

其实JVM类加载机制,简单地说就是类管理,也就是我们生成的class文件。 三个步骤:装载(load)、链接(link)、解析(Resolve)、还有初始化(Initialize) 关于网上有很多...
  • Mark_LQ
  • Mark_LQ
  • 2015年04月10日 14:53
  • 1077

JVM高级特性与实践(九):类加载器 与 双亲委派模式(自定义类加载器源码探究ClassLoader)

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码块被称为“类加载器”...

JVM高级特性与实践(九):类加载器 与 双亲委派模式(自定义类加载器源码探究ClassLoader)

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码块被称为“类加载器”...

classloader源码

  • 2009年06月23日 15:31
  • 996KB
  • 下载

JVM classloader 总结

  • 2012年09月27日 09:18
  • 70KB
  • 下载

Java程序员从笨鸟到菜鸟之(九十八)深入java虚拟机(七)深入源码看java类加载器ClassLoader

欢迎阅读本专题的其他博客:                      深入java虚拟机(一)——java虚拟机底层结构详解                          深入j...

java虚拟机类加载过程内存情况底层源码分析及ClassLoader讲解

读书笔记加自我总结----------------------------------------------- 《疯狂JAVAj讲义》 《深入理解JAVA虚拟机》第七章虚拟机加载机制 ...

深入java虚拟机(七)深入源码看java类加载器ClassLoader

ClassLoader类加载器是负责加载类的对象。ClassLoader 类是一个抽象类。如果给定类的二进制名称(即为包名加类名的全称),那么类加载器会试图查找或生成构成类定义的数据。一般策略是将名称...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:初探JVM-ClassLoader源码
举报原因:
原因补充:

(最多只允许输入30个字)