[Tomcat源码系列] Tomcat 类加载器结构

一、从类加载器(ClassLoader)结构说起
1.基本介绍（此部分可参见<<Core Java 2 Volume II>> Chapter9. Security)
      顾名思义，类加载器是用于加载Java的类定义信息(.class)。需要注意的是类加载器仅在需要的才加载类定义信息，参见<<Core Java 2 Volume II>> Chapter9. Security关于ClassLoader的说明如下

      Note that the virtual machine loads only those class files that are needed for the execution of a program. For example, suppose program execution starts with MyProgram.class. Here are the steps that the virtual machine carries out.

• The virtual machine has a mechanism for loading class files, for example, by reading the files from disk or by requesting them from the Web; it uses this mechanism to load the contents of the MyProgram class file.
• If the MyProgram class has instance variables or superclasses of another class type, these class files are loaded as well. (The process of loading all the classes that a given class depends on is called resolving the class.)
• The virtual machine then executes the main method in MyProgram (which is static, so no instance of a class needs to be created).
• If the main method or a method that main calls requires additional classes, these are loaded next.

 

JVM的类加载机制使用多个ClassLoader来完成类加载的功能，譬如JVM至少会包含如下三个类加载器：

• The bootstrap class loader：启动类加载器，是JVM的组成部分，使用C语言实现。加载JVM基础Class（譬如rt.jar）。实际没有Bootstrap类加载器的实例，譬如String.class.getClassLoader()返回null
• The extension class loader：扩展类加载器，JVM标准扩展类加载器，加载位于{jre path}/lib/ext目录下类
• The system class loader：系统加载器，加载在classpath路径下定义的class

我们可以通过 obj.getClass().getClassLoader()来获得对象相应的类定义是由哪个ClassLoader加载的
2.对象创建和ClassLoader
     JVM提供了如下三种创建对象的方式

• new：通过new操作创建对象，那么相应对象的类定义由创建操作所在的类的类加载器加载
• Class.forName("...").newInstance：类定义的加载器与new相同
• xxxClassLoader.loadClass("...").newInstance：类定义的加载器为xxxClassLoader

      需要注意的是，JVM识别类定义之间是否一样，除了检查类全名(譬如xxx.MyClass)是否一样，还检查其相应的ClassLoader是否一样。譬如如下操作会抛出ClassCastException

Object obj = xxxClassLoader.loadClass("xxx.MyClass").newInstance(); //此处xxxClassLoader的parent不是当前类的加载器
xxx.MyClass xxx = (xxx.MyClass) obj;//ClassLoader不一样，因此JVM认为是类型是不一样的

3.ClassLoader代码分析(java.lang.ClassLoader)
我们从入口loadClass开始

protected synchronized Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
    {
    //检查是是否已经加载过
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
        if (parent != null) {
            //代理给parent去加载类
            c = parent.loadClass(name, false);
        } else {
            //由Bootstrap去加载类
            c = findBootstrapClass0(name);
        }
        } catch (ClassNotFoundException e) {
            //parent和Bootstrap都无法加载，则由自定义的方式去加载类
            //通过扩展该方法来实现自定义的类加载器
            c = findClass(name);
        }
    }

//这是标准的也是JVM推荐的类加载方式，先由parent，然后由Bootstrap，最后是自定义的类，然而Servlet规范定义的是与此相悖的，后面我们再看

    if (resolve) {
        resolveClass(c);
    }
    return c;
}

自定义的类加载器主要会有两个过程：获得类定义的byte串、解析byte串到class的结构，第一个步骤是我们应该处理的，而第二个步骤是JVM直接提供的，也就是ClassLoader的defineClass方法，有兴趣可以看看java.lang.ClassLoader.defineClass方法
二、Tomat类加载器结构
1.如下是Tomcat6的类加载器结果图

写道

      [BootStrapClassLoader](实际没有这个类)
                      |
     ExtensionClassLoader(对于Sun JVM，是sun.misc.Launcher$ExtClassLoader)
                      |
     SystemClassLoader(对于Sun JVM，是sun.misc.Launcher$AppClassLoader)
                      |
     CommonClassLoader(对于Tomcat 6，是org.apache.catalina.loader.StandardClassLoader)
               /               \
CatalinaClassLoader           SharedClassLoader
                                             |
                          org.apache.catalina.loader.WebappClassLoader
                                             |
                              org.apache.jasper.servlet.JasperLoader

• CommonClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中的common.loader指定，以SystemClassLoader为parent(目前默认定义是common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar)
• CatalinaClassLoader   ：加载的类目录通过{tomcat}/conf/catalina.properties中server.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则ServerClassLoader 与CommonClassLoader是同一个(默认server.loader配置为空)
• SharedClassLoader：加载的类目录通过{tomcat}/conf/catalina.properties中share.loader指定，以CommonClassLoader为parent，如果server.loader配置为空，则CatalinaClassLoader 与CommonClassLoader是同一个(默认share.loader配置为空)
• WebappClassLoader：每个Context一个WebappClassLoader实例，负责加载context的/WEB-INF/lib和/WEB-INF/classes目录，context间的隔离就是通过不同的WebappClassLoader来做到的。由于类定义一旦加载就不可改变，因此要实现tomcat的context的reload功能，实际上是通过新建一个新的WebappClassLoader来做的，因此reload的做法实际上代价是很高昂的，需要注意的是，JVM内存的Perm区是只吃不拉的，因此抛弃掉的WebappClassLoader加载的类并不会被JVM释放，因此tomcat的reload功能如果应用定义的类比较多的话，reload几次就OutOfPermSpace异常了。（关于JVM的内存管理，可以参见之前的文章 ，后续对这一块重新做总结）
• JasperLoader：每个JSP一个JasperLoader实例，与WebappClassLoader做法类似，JSP支持修改生效是通过丢弃旧的JasperLoader，建一个新的JasperLoader来做到的，同样的，存在轻微的PermSpace的内存泄露的情况

2.WebappClassLoader详解
       我们来看看WebappClassLoader具体是如何实现的，如上，loadClass方法是我们的重点(有时候我们的类会使用Class.getResourceAsStream或者ClassLoader.getResourceAsStream，这种搜索资源的方式会与loadClass的机制类似，因此这里不重复说明)。

public Class loadClass(String name, boolean resolve)
        throws ClassNotFoundException {

        if (log.isDebugEnabled())
            log.debug("loadClass(" + name + ", " + resolve + ")");
        Class clazz = null;

        // Log access to stopped classloader
        if (!started) {
            try {
                throw new IllegalStateException();
            } catch (IllegalStateException e) {
                log.info(sm.getString("webappClassLoader.stopped", name), e);
            }
        }

        // (0) 检查WebappClassLoader之前是否已经load过这个资源
clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return (clazz);
        }

        // (0.1) 检查ClassLoader之前是否已经load过
        clazz = findLoadedClass(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return (clazz);
        }

        // (0.2) 先检查系统ClassLoader，因此WEB-INF/lib和WEB-INF/classes或{tomcat}/libs下的类定义不能覆盖JVM 底层能够查找到的定义(譬如不能通过定义java.lang.Integer替代底层的实现
        try {
            clazz = system.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return (clazz);
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // (0.5) Permission to access this class when using a SecurityManager
        if (securityManager != null) {
            int i = name.lastIndexOf('.');
            if (i >= 0) {
                try {
                    securityManager.checkPackageAccess(name.substring(0,i));
                } catch (SecurityException se) {
                    String error = "Security Violation, attempt to use " +
                        "Restricted Class: " + name;
                    log.info(error, se);
                    throw new ClassNotFoundException(error, se);
                }
            }
        }

        //这是一个很奇怪的定义，JVM的ClassLoader建议先由parent去load，load不到自己再去load(见如上 ClassLoader部分)，而Servelet规范的建议则恰好相反，Tomcat的实现则做个折中，由用户去决定(context的 delegate定义)，默认使用Servlet规范的建议，即delegate=false
        boolean delegateLoad = delegate || filter(name);

        // (1) 先由parent去尝试加载，此处的parent是SharedClassLoader，见如上说明，如上说明，除非设置了delegate，否则这里不执行
        if (delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader1 " + parent);
            ClassLoader loader = parent;
             //此处parent是否为空取决于context 的privileged属性配置，默认privileged=true，即parent为SharedClassLoader
            if (loader == null)
                loader = system;
            try {
                clazz = loader.loadClass(name);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return (clazz);
                }
            } catch (ClassNotFoundException e) {
                ;
            }
        }

        // (2) 到WEB-INF/lib和WEB-INF/classes目录去搜索，细节部分可以再看一下findClass，会发现默认是先搜索WEB-INF/classes后搜索WEB-INF/lib
        if (log.isDebugEnabled())
            log.debug("  Searching local repositories");
        try {
            clazz = findClass(name);
            if (clazz != null) {
                if (log.isDebugEnabled())
                    log.debug("  Loading class from local repository");
                if (resolve)
                    resolveClass(clazz);
                return (clazz);
            }
        } catch (ClassNotFoundException e) {
            ;
        }

        // (3) 由parent再去尝试加载一下
        if (!delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader at end: " + parent);
            ClassLoader loader = parent;
            if (loader == null)
                loader = system;
            try {
                clazz = loader.loadClass(name);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return (clazz);
                }
            } catch (ClassNotFoundException e) {
                ;
            }
        }

        throw new ClassNotFoundException(name);
    }

 

评论

4 楼 ayufox 2012-07-18  

haitaoandroid 写道

想问博主一个问题：在39行用系统类加载器加载后，即clazz = system.loadClass(name); 
如果失败，为什么在后面第74行或者第111行还要再用系统类加载器试一下？不是多此一举吗？因为还是会失败啊

呵呵，在parent为null的情况下，这里代码确实是多此一举

3 楼 haitaoandroid 2012-07-10  

想问博主一个问题：在39行用系统类加载器加载后，即clazz = system.loadClass(name); 
如果失败，为什么在后面第74行或者第111行还要再用系统类加载器试一下？不是多此一举吗？因为还是会失败啊

2 楼 ayufox 2010-04-06  

axbyzc 写道

leader出品， 必属精品。 

惭愧惭愧啊，还是需要兄弟们捧场啊

1 楼 axbyzc 2010-04-06  

leader出品， 必属精品。