The interview

双亲委派机制：

在加载请求时，请求会交给父加载器去完成，每次请求都是如此，将加载请求推送到主启动加载。如父加载器无法加载请求时，子加载器会去加载请求

tomcat对双亲委派机制的影像

* Tomcat作为一个web容器，要解决的问题有哪些？

1.web容器肯能部署多个应用程序，不同的应用程序依赖于同一个第三方依赖库的版本不同，因此保证每一个应用程序的类库都是独立、相互隔离

2. 部署在同一个web容器中的相同类库的相同版本可以共享，否则，会有重复的类库被加载进JVM；

3. web容器也有自己的类库，不能和应用程序的类库混淆，需要相互隔离；

4. web容器支持jsp文件修改后不用重启，jsp文件也是要编译成.class文件的，支持HotSwap功能。
基于上诉的问题看出

第一个问题：

        如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

第二个问题：

        默认的类加载器是能够实现的，因为他的职责就是保证唯一性。

第四个问题：

        想实现jsp文件的热修改，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

解决方案：

1. CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。

2. WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离

3. 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能

总结：

由此可见tomcat实现了隔离性，却破坏了双亲委派原则，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。而假如想要tomcat 的 Common ClassLoader 加载 WebApp ClassLoader 中的类的话，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。