前言
Tomcat如何实现不同的应用程序，使用不同的第三方类库？带着疑问学下去
打破双亲委派
以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行? 我们思考一下:
Tomcat是个web容器， 那么它要解决什么问题:
- 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的 类库都是独立的，保证相互隔离。
- 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。
- web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
- web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不 用重启。
比如以下伪代码，我们又要确保各自隔离，又要确保底层库通用。必定主要实现自定义ClassLoader
Tomcat 平台
应用A
com.xm.Test1
应用B
com.xm.Test1
Tomcat 如果使用默认的双亲委派类加载机制行不行?
答案是不行的。为什么?
第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的， 默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
第二个问 题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。 第三个问题和第一个问题一样。 我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class 文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后 的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器，所以 你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载 这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
Tomcat自定义加载器详解
tomcat的几个主要类加载器:
- commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问;
- catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见;
- sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见;
- WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；主要负责管理用户自定义目录下的 lib,classes
从图中的委派关系中可以看出:
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使 用，从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的 目的就是为了被丢弃:当Web容器检测到JSP文件被修改时，会替换掉目前的 JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。
tomcat 这种类加载机制违背了java 推荐的双亲委派模型了吗?
答案是：违背了。 我们前面说过，双亲委派机制要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定， 每个 webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制。
public class JarFileTest {
public static void main(String[] args) {
JarFile jarFile = new JarFile("xxx.jar");
JarEntry entry = jarFile.getJarEntry("java/servlet/AsyncEvent1.class");
System.out.println(entry.getName());
}
}
加载规则
1. map -> 自己缓存中查找
2. jvm -> 查找是否已经加载
3. 尝试通过类加载器（ExtClassLoader）加载类，防止Webapp重写JDK中的类
4. Tomcat认定特殊的类，是否委派给父类去加载 CommonClassLoader（URLClassLoader）去加载
5. 去自己的webapps里面去加载
6. 如果还没有加载到，无条件交给父类去加载 CommonClassLoader（URLClassLoader）去加载
热加载与热部署
热加载—是针对应用Context来的
-
热加载的目的是让JVM中老的class对象替换为新的class对象，因为不能直接替换，我们需要卸载掉classLoader
-
如何开启热加载
reloadable 默认false<Context path="/hello" docBase="\ServletDemo" reloadable="true"/> -
删除修改，都会进行热加载
-
添加不会热加载
public class WebappLoader extends LifecycleMBeanBase implements Loader, PropertyChangeListener { @Override public void backgroundProcess() { if (reloadable && modified()) { // 触发了热加载 try { Thread.currentThread().setContextClassLoader (WebappLoader.class.getClassLoader()); if (context != null) { context.reload(); } } finally { if (context != null && context.getLoader() != null) { Thread.currentThread().setContextClassLoader (context.getLoader().getClassLoader()); } } } } }modified 最终调用这里
public abstract class WebappClassLoaderBase extends ... { public boolean modified() { for (Entry<String,ResourceEntry> entry : resourceEntries.entrySet()) { long cachedLastModified = entry.getValue().lastModified; long lastModified = resources.getClassLoaderResource( entry.getKey()).getLastModified(); // 某一个文件最后一次修改时间是什么 if (lastModified != cachedLastModified) { ... return true; } } // Check if JARs have been added or removed // 检测jar包删除与修改 WebResource[] jars = resources.listResources("/WEB-INF/lib"); // Filter out non-JAR resources ... // No classes have been modified return false; } }reload源码流程
public class StandardContext extends ContainerBase implements Context, NotificationEmitter { @Override public synchronized void reload() { // 暂停，停止接受请求等 setPaused(true); // 停止，老webappClassLoader=null stop(); // 开始，new webappClassLoader()类加载器，通过它重新加载新的类 start(); // 恢复 setPaused(false); } }
热部署—Host （如果我们某个虚拟主机应用发生变化，进行热部署）