Tomcat类加载器结构

上图是Tomcat文档中所展示的Tomcat类加载结构。在这个结构中Bootstartap和System的类加载器由java虚拟机实现。common类加载器由Tomcat容器实现，它对 Tomcat 内部类和所有 Web 应用程序都是可见的。此类加载器搜索的位置$CATALINA_BASE/conf/catalina.properties 中的common.loader属性定义。在catalina.properties文件也定义了server.loader和shared.loader属性，这两个属性分别由Server和Shared两个类加载器加载。

接下来让我们看一下Tomcat如何实现common类加载器。首先我们需要找到Bootstrap类的main方法。在main方中有一段代码如下，这段代码的大意是先判断Bootstrap是否为null，不为null，直接将Catalina ClassLoader设置到当前线程，用于加载服务器相关类，为null则进入bootstrap的init方法。

......
synchronized (daemonLock) {
            if (daemon == null) {
                // Don't set daemon until init() has completed
                Bootstrap bootstrap = new Bootstrap();
                try {
                    bootstrap.init();
                } catch (Throwable t) {
                    handleThrowable(t);
                    t.printStackTrace();
                    return;
                }
                daemon = bootstrap;
            } else {
                // When running as a service the call to stop will be on a new
                // thread so make sure the correct class loader is used to
                // prevent a range of class not found exceptions.
                Thread.currentThread().setContextClassLoader(daemon.catalinaLoader);
            }
        }
......

init方法会调用initClassLoaders()方法，在该方法中会调用createClassLoader方法创建commonLoader、catalinaLoader、sharedLoader三种类加载器。与上文中所介绍的三种类加载器一一对应。

 private void initClassLoaders() {
        try {
            commonLoader = createClassLoader("common", null);
            if (commonLoader == null) {
                // no config file, default to this loader - we might be in a 'single' env.
                commonLoader = this.getClass().getClassLoader();
            }
            catalinaLoader = createClassLoader("server", commonLoader);
            sharedLoader = createClassLoader("shared", commonLoader);
        } catch (Throwable t) {
            handleThrowable(t);
            log.error("Class loader creation threw exception", t);
            System.exit(1);
        }
    }

createClassLoader方法终会调用如下代码,通过这段代码可以知到commonLoader是一个URLClassLoader。

public static ClassLoader createClassLoader(List<Repository> repositories,
                                                final ClassLoader parent)
        throws Exception {
......
return AccessController.doPrivileged(
                new PrivilegedAction<URLClassLoader>() {
                    @Override
                    public URLClassLoader run() {
                        if (parent == null)
                            return new URLClassLoader(array);
                        else
                            return new URLClassLoader(array, parent);
                    }
                });
}

Common|Catalina|Shared的使用

在Bootstartap中的init方法中调用完initClassLoaders方法后，就开始了对类加载器的使用。Tomcat用catalinaLoader来加载Catalina类，这个类就是我们经常说的容器。加载完Catalina后会将sharedLoader作为参数传递给Catalina类，以便于后续给Webappx设置父加载器。

public void init() throws Exception {

        initClassLoaders();

        ......
         // 加载Catalina类
        Class<?> startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
        Object startupInstance = startupClass.getConstructor().newInstance();

        // 设置sharedLoad加载器   
        String methodName = "setParentClassLoader";
        Class<?> paramTypes[] = new Class[1];
        paramTypes[0] = Class.forName("java.lang.ClassLoader");
        Object paramValues[] = new Object[1];
        paramValues[0] = sharedLoader;
        Method method =
            startupInstance.getClass().getMethod(methodName, paramTypes);
        method.invoke(startupInstance, paramValues);

        catalinaDaemon = startupInstance;
    }

WebappX 加载器

上文介绍了common类加载器的创建和使用，那么Webappx类加载器又是如何被创建和使用的呢？

创建WebappX 加载器

在看Tomcat源码是如何创建webappx类加载器之前，让我们来做一个实验。假设我们已经编译好了一个全限定名为com.example.WebAppClassLoader.class文件，那么应该如何来加载这个类文件呢？一种方法是自定义一个类加载器。

public class MyClassLoader extends URLClassLoader {
    public MyClassLoader() {
        super(new URL[0]);
    }

    @Override
    protected Class<?> findClass(String name) {
        String myPath = "file:///D:/www/tomact-test-war/tomcat-test-case008/src/main/webapp/WEB-INF/" + name.replace(".","/") + ".class";
        byte[] cLassBytes = null;
        Path path = null;
        try {
            path = Paths.get(new URI(myPath));
            cLassBytes = Files.readAllBytes(path);
        } catch (IOException | URISyntaxException e) {
            e.printStackTrace();
        }
        Class clazz = defineClass(name, cLassBytes, 0, cLassBytes.length);
        return clazz;
    }
}

创建一个名为MyClassLoader的类并继承URLClassLoader类，重写findClass方法，一个简单的类加载器就创建完成了。

public static void main(String[] args) throws Exception {
        MyClassLoader cl = new MyClassLoader();
        Class<?> wacl = cl.findClass("com.example.WebAppClassLoader");
        try {
            Object obj = wacl.newInstance();
            Method method = wacl.getMethod("test_1");
            method.invoke(obj);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

package com.example;
public class WebAppClassLoader {
    public WebAppClassLoader() {
    }
    public void test_1() {
        System.out.println("自定类加载器");
    }
}

在main方法中创建MyClassLoader对象，并调用findClass方法，至此就将一个class文件加载到了虚拟机中。

好了，实验做完后，让我们回过头来看看Tomcat是如何创建WebappX类加载器的。

在StandardContext的startInternal方法中有这样一段代码

if (getLoader() == null) {
            WebappLoader webappLoader = new WebappLoader();
            webappLoader.setDelegate(getDelegate());
            setLoader(webappLoader);
        }

它会创建WebappLoader对象，并通过setLoader(webappLoader)赋值到一个实例变量中，然后会调用WebappLoader的start方法:

......
classLoader = createClassLoader();
            classLoader.setResources(context.getResources());
            classLoader.setDelegate(this.delegate);
......

进入createClassLoader方法：

private WebappClassLoaderBase createClassLoader()
        throws Exception {

        Class<?> clazz = Class.forName(loaderClass);
        WebappClassLoaderBase classLoader = null;

        if (parentClassLoader == null) {
            parentClassLoader = context.getParentClassLoader();
        } else {
            context.setParentClassLoader(parentClassLoader);
        }
        Class<?>[] argTypes = { ClassLoader.class };
        Object[] args = { parentClassLoader };
        Constructor<?> constr = clazz.getConstructor(argTypes);
        classLoader = (WebappClassLoaderBase) constr.newInstance(args);

        return classLoader;
    }

该方法会实例化一个ParallelWebappClassLoader实例，并且传递了sharedLoader作为其父亲加载器。

ParallelWebappClassLoader继承了WebappClassLoaderBase抽象类，WebappClassLoaderBase继承了URLClassLoader。在WebappClassLoaderBase类中重写了findClass方法。至此WebappX类加载器 就创建完成了。

那Webappx类加载器又是被如何使用的呢？

还记得在Tomcat动态部署一章介绍的那个webConfig方法吗？这个方法非常复杂。在这个方法的第四步中会调用populateJavaClassCache方法

private void populateJavaClassCache(String className,
            Map<String,JavaClassCacheEntry> javaClassCache) {
    ......
         try (InputStream is = context.getLoader().getClassLoader().getResourceAsStream(name)) {
                if (is == null) {
                    return;
                }
                ClassParser parser = new ClassParser(is);
                JavaClass clazz = parser.parse();
                populateJavaClassCache(clazz.getClassName(), clazz, javaClassCache);
            } catch (ClassFormatException | IOException e) {
                log.debug(sm.getString("contextConfig.invalidSciHandlesTypes",
                        className), e);
            }
    ......
 }

现在总结如下： 在Tomcat存在common、cataina、shared三个公共的classloader,默认情况下，这三个classloader其实是同一个，都是common classloader，而针对每个webapp，也就是context（对应代码中的StandardContext类），都有自己的WebappClassLoader实例来加载每个应用自己的类，该类加载的父类加载器就是是Shared ClassLoader。这样前面关于tomcat的类加载层次应该就清楚起来了。

delegate属性与双亲委派

在context.xml文件中可以配置delegate属性，以用来控制Webappx类加载器的类加载机制。delegate属性默认是false。

当delegate为true时webappx的类加载顺序如下：

• JVM 的引导类
• 系统类加载器类
• 通用类加载器类
• /WEB-INF/ Web 应用程序的类
• /WEB-INF/lib/*.jar您的 Web 应用程序

当delegate为false时webappx的类加载顺序如下：

• JVM 的引导类
• /WEB-INF/ Web 应用程序的类
• /WEB-INF/lib/*.jar您的 Web 应用程序
• 系统类加载器类（如上所述）
• 通用类加载器类（如上所述）

让我再来简单回忆一下JVM的双亲委派模型，在JVM中一个类的加载首先使用其父类加载器去加载，如果加载不到在使用自身的加载器去加载。

我们以Tomcat的类加载器结构为例，当delegate属性是true时，加载一个自定义servlet是从根加载器，然后是系统类加载器一步步找下来的，这一过程与JVM的双亲委派模型是一致的。但是当delegate为false时却不然，当delegate为fasle时首先依旧从根加载器加载类文件，但是第二步是从webappx类加载器中加载类文件，然后是系统类加载器，最后才是通用类加载器，这与标准的JVM模型并不一致，我们也可以说此时Tomcat打破了双亲委派模型。

Tomcat默认打破了双亲委派，这样的好处之一是当我们在Tomcat中部署多个应用时，即使这些应用程序依赖同一个第三方类库，虽然其版本不同但并不会相互影响。