一. tomcat是如何打破双亲委派机制的?

首先, 来举个例子, 通常,一个tomcat要加载几个应用程序呢? 当然是n多个应用程序, 加入我们使用的都是spring的框架, 那我们能保证所有的应用程序都是用spring4 或者spring5 么? 不可能, 他可能既有spring4的项目, 又有spring5的项目. 那么tomcat在加载spring4项目的war包是, 会不会和spring5项目的war包冲突呢? 因为spring4, 和 spring5中有很多类的类名是一样的, 但是实现不一样. 如果都是交给父类加载器加载, 那么肯定只能加载一份. 也就是spring4和spring5的项目不能共存. 而实际上的情况呢? 我们的tomcat可以加在各种各样类型的war包, 相互之间没有影响. 他是怎么做到的呢?

因为tomcat打破了双亲委派机制, 下面我们就来看看tomcat是如何打破双亲委派机制的?

如上图, 上面的橙色部门还是和原来一样, 采用双亲委派机制. 而黄色部分是tomcat第一部分自定义的类加载器, 这部分主要是加载tomcat包中的类, 这一部分依然采用的是双亲委派机制, 而绿色部分是tomcat第二部分自定义类加载器, 正事这一部分, 打破了类的双亲委派机制. 先面我们就来详细看看tomcat自定的类加载器

1. tomcat第一部分自定义类加载器(黄色部分)

这部分类加载器, 在tomcat7及以前是tomcat自定义的三个类加载器, 分别在家不同文件加载的jar包. 而到了tomcat8及以后, tomcat将这三个文件夹合并了, 合并成了一个lib包. 也就是我们现在看到的lib包

我们来看看这三个类加载器的主要功能.

• commonClassLoader: tomcat最基本的类加载器, 加载路径中的class可以被tomcat容器本身和各个webapp访问;
• catalinaClassLoader: tomcat容器中私有的类加载器, 加载路径中的class对于webapp不可见
• sharedClassLoader: 各个webapps共享的类加载器, 加载路径中的class对于所有的webapp都可见, 但是对于tomcat容器不可见.

这一部分类加载器, 依然采用的是双亲委派机制, 原因是, 他只有一份. 如果有重复, 那么也是以这一份为准.

2. tomcat第二部分自定义类加载器(绿色部分)

绿色部分是java项目在打war包的时候, tomcat自动生成的类加载器, 也就是说 , 每一个项目打成一个war包, tomcat都会自动生成一个类加载器, 专门用来加载这个war包. 而这个类加载器打破了双亲委派机制. 我们可以想象一下, 加入这个webapp类加载器没有打破双亲委派机制会怎么样?

如果没有打破, 他就会委托父类加载器去加载, 一旦加载到了,  子类加载器就没有机会在加载了. 那么, spring4和spring5的项目想共存, 那是不可能的了.

所以, 这一部分他打破了双亲委派机制

这样一来, webapp类加载器不需要在让上级去加载, 他自己就可以加载对应war里的class文件. 当然了, 其他的项目文件, 还是要委托上级加载的.

下面我们来实现一个自定义的类加载器

二. 自定义tomcat的war包类加载器

如何打破双亲委派机制, 我们已经写过一个demo了. 详见: https://www.cnblogs.com/ITPower/p/13211490.html

那么, 现在我有两个war包, 分处于不同的文件夹, tomcat如何使用各自的类加载器加载自己包下的class类呢?

我们来举个例子, 比如: 在我的home目录下有两个文件夹, tomcat-test和tomcat-test1. 用这两个文件夹来模拟两个项目.

虽然类名和类路径都是一样的,但是他们的内容是不同的

这个时候,如果tomcat要同时加载这两个目录下的User1.class文件, 我们如何操作呢?

其实,非常简单, 按照上面的思路, tomcat只需要为每一个文件夹生成一个新的类加载器就可以了.

public static void main(String[] args) throws Exception {　　　　 // 第一个类加载器
        DefinedClassLoaderTest classLoader = new DefinedClassLoaderTest("/Users/luoxiaoli/tomcat-test");
        Class<?> clazz = classLoader.loadClass("com.lxl.jvm.User1");
        Object obj = clazz.newInstance();
        Method sout = clazz.getDeclaredMethod("sout", null);
        sout.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
　　　　 // 第二个类加载器
        DefinedClassLoaderTest classLoader1 = new DefinedClassLoaderTest("/Users/luoxiaoli/tomcat-test1");
        Class<?> clazz1 = classLoader1.loadClass("com.lxl.jvm.User1");
        Object obj1 = clazz1.newInstance();
        Method sout1 = clazz1.getDeclaredMethod("sout", null);
        sout1.invoke(obj1, null);
        System.out.println(clazz1.getClassLoader().getClass().getName());
    }

他们都是只加载自己目录下的文件.  我们来看看执行结果:

调用了user1的sout方法

com.lxl.jvm.DefinedClassLoaderTest

调用了另外一个项目user1的sout方法, 他们是不同的

com.lxl.jvm.DefinedClassLoaderTest

三. 延伸思考: 我们看到上面tomcat自定义的类加载器中, 还有一个jsp类加载器. jsp是可以实现热部署的, 那么他是如何实现的呢?

我们都知道jsp其实是一个servlet容器, 有tomcat加载. tomcat会为每一个jsp生成一个类加载器. 这样每个类加载器都加载自己的jsp, 不会加载别人的. 当jsp文件内容修改时, tomcat会有一个监听程序来监听jsp的改动. 比如文件夹的修改时间, 一旦时间变了, 就重新加载文件夹中的内容.

具体tomcat是怎么实现的呢? tomcat自定义了一个thread, 用来监听不同文件夹中文件的内容是否修改, 如何监听呢? 就看文件夹的update time有没有变化, 如果有变化了, 那么就会重新加载.