想实现不重启系统，而在系统运行过程中升级Web应用，有两种方案：

• 热加载
• 热部署

实现原理

跟类加载机制有关。

热加载

实现方式是Web容器启动一个后台线程，定期检测类文件变化。
若有变化，就重新加载类，在这个过程中不会清空Session ，一般用在开发环境。

热部署

类似地，也由后台线程定时检测Web应用变化，但它会重新加载整个Web应用。这会清空Session，比热加载更干净、彻底，一般用在生产环境。

Tomcat实现热加载、热部署

Tomcat通过开启后台线程，使得各个层次的容器组件都有机会完成一些周期性任务。

实际开发往往也需要执行一些周期性任务，比如监控程序周期性拉取系统健康状态。

Tomcat后台线程

开启后台线程做周期性任务，最常见的就是线程池的ScheduledThreadPoolExecutor，没错，Tomcat就是通过它来开启后台线程：

backgroundProcessorFuture = Container.getService(this).getServer().getUtilityExecutor()
			               .scheduleWithFixedDelay(
			                // 要周期性执行的Runnable
			                new ContainerBackgroundProcessor(),
			                //第一次执行延迟多久
			                backgroundProcessorDelay,
			                // 之后每次执行间隔多久
			                backgroundProcessorDelay,
			                // 时间单位
			                TimeUnit.SECONDS);

任务类ContainerBackgroundProcessor是ContainerBase的内部类，ContainerBase是所有容器组件的基类。

ContainerBackgroundProcessor

protected class ContainerBackgroundProcessor implements Runnable {

    @Override
    public void run() {
        // 入参"宿主类"实例
        processChildren(ContainerBase.this);
    }

    protected void processChildren(Container container) {
        try {
            // 1. 调用当前容器的backgroundProcess
            container.backgroundProcess();
            
            // 2. 遍历所有子容器，递归调用processChildren
            // 这样当前容器的子孙都会被处理            
            Container[] children = container.findChildren();
            for (int i = 0; i < children.length; i++) {
	            // 容器基类有个变量叫做backgroundProcessorDelay
	            // 如果大于0，表明子容器有自己的后台线程
	            // 无需父容器来调用它的processChildren方法
                if (children[i].getBackgroundProcessorDelay() <= 0) {
                    processChildren(children[i]);
                }
            }
        } catch (Throwable t) { ... }

processChildren把“宿主类”，即ContainerBase的类实例当成参数传给了run方法。

而在processChildren方法里，就做了两步：调用当前容器的backgroundProcess方法，以及递归调用子孙的backgroundProcess方法。请你注意backgroundProcess是Container接口中的方法，也就是说所有类型的容器都可以实现这个方法，在这个方法里完成需要周期性执行的任务。

这样只需在顶层容器Engine中启动一个后台线程，则该线程不但会执行Engine容器的周期性任务，还会执行所有子容器的周期性任务。

backgroundProcess方法

上述代码都是在基类ContainerBase实现，具体容器类需要做什么呢？

• 若有周期性任务，就实现backgroundProcess
• 若没有，则复用基类ContainerBase的方法

ContainerBase#backgroundProcess

public void backgroundProcess() {

    // 1.执行容器中Cluster组件的周期性任务
    Cluster cluster = getClusterInternal();
    if (cluster != null) {
        cluster.backgroundProcess();
    }
    
    // 2.执行容器中Realm组件的周期性任务
    Realm realm = getRealmInternal();
    if (realm != null) {
        realm.backgroundProcess();
   }
   
   // 3.执行容器中Valve组件的周期性任务
    Valve current = pipeline.getFirst();
    while (current != null) {
       current.backgroundProcess();
       current = current.getNext();
    }
    
    // 4. 触发容器的"周期事件"，Host容器的监听器HostConfig就靠它来调用
    fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null);
}

不仅每个容器可以有周期性任务，每个容器中的其他通用组件，比如跟集群管理有关的Cluster组件、跟安全管理有关的Realm组件都可以有自己的周期性任务。

容器之间的链式调用是通过Pipeline-Valve机制实现的，容器中的Valve也可以有周期性任务，并且被ContainerBase统一处理。

在backgroundProcess方法的最后，还触发了容器的“周期事件”。“周期事件”是什么呢？
它跟生命周期事件一样，是一种扩展机制，可以这样理解：
又一段时间过去了，容器还活着，你想做点什么吗？
如果你想做点什么，就创建一个监听器来监听这个“周期事件”，事件到了我负责调用你的方法。

总之，有了ContainerBase中的后台线程和backgroundProcess方法，各种子容器和通用组件不需要各自弄一个后台线程来处理周期性任务。

Tomcat热加载

有了ContainerBase的周期性任务处理“框架”，具体容器子类只需实现自己的周期性任务。
Tomcat的热加载，就实现在Context容器。

Context#backgroundProcess

StandardContext实现类中：

@Override
public void backgroundProcess() {

    if (!getState().isAvailable())
        return;

    // WebappLoader周期性检查
    // WEB-INF/classes、WEB-INF/lib 目录下的类文件是否有更新
    Loader loader = getLoader();
    if (loader != null) {
        loader.backgroundProcess();        
    }
    
    // Session管理器周期性检查是否有Session过期
    Manager manager = getManager();
    if (manager != null) {
        manager.backgroundProcess();
    }
    
    // 周期性检查静态资源是否有更新
    WebResourceRoot resources = getResources();
    if (resources != null) {
        resources.backgroundProcess();
    }
    super.backgroundProcess();
}

WebappLoader是如何实现热加载的呢？
关键是调用Context#reload方法：

• 停止和销毁Context容器及其所有子容器（Wrapper），即Wrapper里的Servlet实例也被销毁
• 停止和销毁Context容器关联的Listener和Filter
• 停止和销毁Context下的Pipeline和各种Valve
• 停止和销毁Context的类加载器，以及类加载器加载的类文件资源

启动Context容器，在这个过程中会重新创建前面四步被销毁的资源。
在这个过程中，类加载器发挥着关键作用。一个Context容器对应一个类加载器，类加载器在销毁的过程中会把它加载的所有类也全部销毁。Context容器在启动过程中，会创建一个新的类加载器来加载新的类文件。

在Context的reload方法里，并没有调用Session管理器的destroy方法，也就是说这个Context关联的Session是没有销毁的。

Tomcat热加载默认是关闭的，需在conf目录下的context.xml文件中设置reloadable参数开启：

<Context reloadable="true"/>

Tomcat热部署

跟热加载的本质区别是：
热部署会重新部署Web应用，原Context对象会被整个被销毁，因此该Context所关联一切资源都会被销毁，包括Session。

Tomcat热部署由哪个容器实现呢？
不是由Context，因为热部署过程中Context容器被销毁了，所以就是Host，Context的父容器。

Host容器并未在backgroundProcess中实现周期性检测，而是通过监听器HostConfig实现。
HostConfig就是前面提到的“周期事件”的监听器，“周期事件”达到时，HostConfig会做什么呢？

public void lifecycleEvent(LifecycleEvent event) {
    // 执行check
    if (event.getType().equals(Lifecycle.PERIODIC_EVENT)) {
        check();
    } 
}

protected void check() {

    if (host.getAutoDeploy()) {
        // 检查这个Host下所有已经部署的Web应用
        DeployedApplication[] apps =
            deployed.values().toArray(new DeployedApplication[0]);
            
        for (int i = 0; i < apps.length; i++) {
            //检查Web应用目录是否有变化
            checkResources(apps[i], false);
        }

        // 执行部署
        deployApps();
    }
}

HostConfig会检查webapps目录下的所有Web应用：

• 如果原来Web应用目录被删掉了，就把相应Context容器整个销毁掉
• 是否有新的Web应用目录放进来了，或者有新的WAR包放进来了，就部署相应的Web应用

因此HostConfig做的事情都是比较“宏观”的，它不会去检查具体类文件或者资源文件是否有变化，而是检查Web应用目录级别变化。

这两篇文章分别介绍了类的生命周期、ClassLoader类。今天，我们继续介绍类的热加载。

https://blog.csdn.net/liuxiao723846/article/details/109901300

https://blog.csdn.net/liuxiao723846/article/details/110009055

一、类的卸载

1、引用关系：

当某个类被类加载器加载到内存后，就会生成一个相应的Class对象。他们的关系如下：

1）类加载器和Class对象：

• 在类加载器的内部实现中，用一个Java集合来存放所加载类的Class实例的引用。
• 另一方面，一个Class对象总是会引用它的类加载器。调用Class对象的getClassLoader()方法，就能获得它的类加载器。

由此可见，Class实例和加载它的加载器之间为双向关联关系。

2）类、类的实例对象、类的Class对象：

• 一个类的实例总是引用代表这个类的Class对象，在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。
• 此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。

 

2、卸载类：

由Java虚拟机自带的类加载器（bootstrap、ext、app）所加载的类，在虚拟机的生命周期中，始终不会被卸载。因为，Java虚拟机本身会始终引用这些类加载器，而这些类加载器则会始终引用它们所加载的类的Class对象，因此这些Class对象始终是可触及的。

由用户自定义的类加载器加载的类是可以被卸载的。先看一下如何使用自定义加载器加载一个类，并创建类的实例。

 

代码也许不准确，但是过程很清晰，整个过程涉及三个变量，而且他们之间的引用关系很明确，即实例对象引用着类对应的Class对象，Class对象引用着类加载器，调用类的getClassLoader()方法可以获得该类的加载器。

1）类何时被卸载？

卸载类，其实就是卸载类对应的Class实例，以及方法区中关于该类对应的数据结构。所以要想卸载类必须：

• 先卸载该类的加载器，这很好理解，因为类引用着类加载器；
• 然后将类所创建的实例都卸载掉；

只有当这个类的加载器和类的实例都结束了生命周期，这个类的生命周期才结束。即

 

有一种情况，就是类加载器被卸载掉了，但是类还没有被卸载掉，这个时候如果有需要用这个类，就可以重新使用不需要加载，方法区的二进制数据结构也是原来的。如果类已经被卸载了，就需要重新加载这个类，当然方法区中的数据结构以及类信息都是重新加载的。

总结：

• 被bootstrap、Ext、App加载的类运行期间不会被卸载；
• 被自定义类加载器加载的类运行期间可以被卸载，但是几率也很小，因为涉及到垃圾回收等；

2）NoClassDefFoundError suddenly：

 

该错误在线上环境遇到过一次。

二、热加载

1、自定义类加载器：

通过前面的分析可知，实现自定义类加载器需要继承ClassLoader或者URLClassLoader，继承ClassLoader则需要自己重写findClass()方法并编写加载逻辑，继承URLClassLoader则可以省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢？

• 当class文件不在ClassPath路径下，默认系统类加载器无法找到该class文件，在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。
• 当一个class文件是通过网络传输并且可能会进行相应的加密操作时，需要先对class文件进行相应的解密后再加载到JVM内存中，这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。
• 当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能)，需要实现自定义ClassLoader的逻辑。

接下来我们看几个例子。

 

1.1）继承ClassLoader实现自定义File类加载器：

 

package cn.nuc.edu.LogTest.load;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;

public class FileClassLoader extends ClassLoader{
	private String rootPath;
	public FileClassLoader(String rootPath) {
		super();
		this.rootPath = rootPath;
	}
	@Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
		byte[] classData = null;
		InputStream ins = null;
		ByteArrayOutputStream baos = null;
		//1、读取类文件的字节码
		try {
			ins = new FileInputStream(classNameToPath(name));
			baos = new ByteArrayOutputStream();
            int bufferSize = 4096;
            byte[] buffer = new byte[bufferSize];
            int bytesNumRead = 0;
            while ((bytesNumRead = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesNumRead);
            }
            classData = baos.toByteArray();
        } catch (IOException e) {
            throw new ClassNotFoundException();
        } finally {
        	try {
        		if (baos != null) baos.close();
            	if (ins != null) ins.close();
        	} catch (Exception e) {
        		
        	}
        }
		//2、生成class对象
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            return defineClass(name, classData, 0, classData.length);
        }
    }
	private String classNameToPath(String className) {
	        return rootPath + File.separatorChar
	                + className.replace('.', File.separatorChar) + ".class";
	}
	 
	 public static void main(String[] args) throws Exception {
        //创建自定义文件类加载器
        FileClassLoader loader = new FileClassLoader("E:");
        Class<?> class1 = loader.loadClass("cn.nuc.edu.LogTest.load.Demo");
        System.out.println(class1.getClassLoader());
        System.out.println(class1.newInstance().toString());
     }
}

输出：

cn.nuc.edu.LogTest.load.FileClassLoader@4614ac54

demo2...

说明：FileClassLoader继承ClassLoader重写findClass方法，保证了双亲委派模型。在main方法中调用了loadClass()方法加载指定路径下的class文件，由于bootstrap、Ext以及App类加载器都无法在其路径下找到该类，因此最终将有自定义类加载器加载，即调用findClass()方法进行加载。

注：Demo.java不能放到IDE中。因为JVM加载类不关心rootPath，它只关心包名组成的路径和文件名（类名），rootPath是由具体的类加载器定义死的（App查找classpath路径），又因为FileClassLoader继承自ClassLoader，调用loadClass方法会根据双亲委派会直接交给上级类加载器加载，最终会被AppClassloader在IED的classpath上加载（执行AppClassLoader中的findClass方法），从而不会执行FileClassLoader的findClass方法了。所以，即使上面的rootPath是E:，也不能将Demo.java放到IDE中。

注：如果将上面改成loader.findClass("cn.nuc.edu.LogTest.load.Demo")，无论Demo.java是否在IED中，最终都会是自定义类加载器加载Demo。（绕过了双亲委派）

 

1.2）继承URLClassLoader实现自定义File类加载器：

package cn.nuc.edu.LogTest.load;

import java.io.File;
import java.net.URI;
import java.net.URL;
import java.net.URLClassLoader;

public class FileClassLoader2 extends URLClassLoader {
	public FileClassLoader2(URL[] urls) {
		super(urls);
	}

	public static void main(String[] args) throws Exception {
		String rootDir = "E:\\";
		// File to URI
		URI uri = new File(rootDir).toURI();
		URL[] urls = { uri.toURL() };

		// 创建自定义文件类加载器
		FileClassLoader2 loader = new FileClassLoader2(urls);
		Class<?> class1 = loader.loadClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class1.getClassLoader());
		System.out.println(class1.newInstance().toString());
		
		loader.close();
	}
}

输出：

cn.nuc.edu.LogTest.load.FileClassLoader@4614ac54

demo2...

说明：继承URLClassLoader，不需要自己再去实现findClass方法了，更加简单。同样，Demo.java不能放到IDE中。

注意：findClass()方法在URLClassLoader类中是protected的，而被protected修饰的成员对于本包和其子类可见，所以FileClassLoader2可以调用findClass()方法。

 

1.3）自定义网络类加载器：

可以自己实现findClass也可以继承URLClassLoader。

 

URL url = new URL(path);
InputStream ins = url.openStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
// 读取类文件的字节
while ((bytesNumRead = ins.read(buffer)) != -1) {
    baos.write(buffer, 0, bytesNumRead);
}

1.4）加载jar包：

http://icejoywoo.github.io/2017/02/22/jvm-classloader-issue.html

 

 2、热加载类：

想要知道热部署的原理，必须要了解java类的加载过程：首先将java文件编译成class文件，然后由类加载器将字节码文件加载到内存生成类对应的Class对象，接下来链接、初始化。。。

一般在系统中，类的加载都是由系统自带的类加载器完成，而且对于同一个全限定名的java类，只能被加载一次，而且无法被卸载，而且上面也分析过类的卸载不可靠。那该如何做呢？

所谓的热部署就是利用同一个class文件不同的类加载器在内存创建出两个不同的class对象，由于JVM在加载类之前会检测请求的类是否已加载过(即在loadClass()方法中调用findLoadedClass()方法)，如果被加载过，则直接从缓存获取，不会重新加载。注意同一个类加载器的实例和同一个class文件只能被加载器一次，多次加载将报错，因此我们实现的热部署必须让同一个class文件可以根据不同的类加载器重复加载，以实现所谓的热部署。

2.1）实现方式：

1. 如果要被热加载的类不会被bootstrap、Ext、App类加载器加载到（不在其路径下），可以创建不同的自定义类加载器实例，然后调用loadClass()、findClass()方法，从而热加载该类；（反正上面那些类加载器也加载不到，所以即使有双亲委派也没事）
2. 如果要被热加载的类会被bootstrap、Ext、App类加载器加载到，创建不同的自定义类加载器实例，然后调用findClass()方法，从而热加载该类；（绕过双亲委派，以及findLoadedClass()缓存的检查）
3. 重写loadClass方法，破坏双亲委派；（强烈不建议）

说明：真正的类加载是调用了findClass()方法完成的（Ext、App也都是）。loadClass方法只是双亲委派算法。

2.2）示例1：要热替换的Demo类可以被AppClassLoader加载到

1）使用FileClassLoader自定义类测试：

实际上前面的FileClassLoader已具备这个功能，但前提是直接调用findClass()方法，而不是调用loadClass()方法，因为ClassLoader中loadClass()方法体中调用findLoadedClass()方法进行了检测是否已被加载，因此我们直接调用findClass()方法就可以绕过这个问题。

A）使用loadClass方法，无法多次加载同一个类：

public static void main(String[] args) throws Exception {
    //创建自定义文件类加载器
    FileClassLoader loader = new FileClassLoader("E:\\workspace_suike\\LogTest\\target\\classes");//"E:"
    Class<?> class1 = loader.loadClass("cn.nuc.edu.LogTest.load.Demo");
    System.out.println(class1.getClassLoader());
    System.out.println(class1.hashCode());
    
    FileClassLoader loader2 = new FileClassLoader("E:\\workspace_suike\\LogTest\\target\\classes");
    Class<?> class2 = loader2.loadClass("cn.nuc.edu.LogTest.load.Demo");
    System.out.println(class2.getClassLoader());
    System.out.println(class2.hashCode());
}
//输出
sun.misc.Launcher$AppClassLoader@7d05e560
607547411
sun.misc.Launcher$AppClassLoader@7d05e560
607547411

说明：由于Demo类可以被AppClassLoader加载到，所以虽然创建了两个自定义类加载器实例，由于双亲委派，也无法使用自定义类加载器来加载该类。

B）使用findClass方法，多次加载同一个类：

public static void main(String[] args) throws Exception {
    //创建自定义文件类加载器
    FileClassLoader loader = new FileClassLoader("E:\\workspace_suike\\LogTest\\target\\classes");//"E:"
    Class<?> class1 = loader.findClass("cn.nuc.edu.LogTest.load.Demo");
    System.out.println(class1.getClassLoader());
    System.out.println(class1.hashCode());
    
    FileClassLoader loader2 = new FileClassLoader("E:\\workspace_suike\\LogTest\\target\\classes");
    Class<?> class2 = loader2.findClass("cn.nuc.edu.LogTest.load.Demo");
    System.out.println(class2.getClassLoader());
    System.out.println(class2.hashCode());
}
//输出
cn.nuc.edu.LogTest.load.FileClassLoader@1a3a2a52
1649907150
cn.nuc.edu.LogTest.load.FileClassLoader@642c39d2
1433743869

说明：这里调用了findClass方法，绕过了双亲委派检测，所以虽然AppClassLoader可以加载到Demo，但仍然使用的是自定义类加载器来加载的Demo类。此外如果用同一个类加载，调用两次findClass方法加载同一个类，会报LinkError错误。

2）使用FileClassLoader2类做测试：

A）调用loadClass方法，无法多次加载同一个类：

public class FileClassLoader2 extends URLClassLoader {
	public FileClassLoader2(URL[] urls) {
		super(urls);
	}

	public static void main(String[] args) throws Exception {
		String rootDir = "E:\\";
		URI uri = new File(rootDir).toURI();// File to URI
		URL[] urls = { uri.toURL() };

		FileClassLoader2 loader1 = new FileClassLoader2(urls);
		Class<?> class1 = loader1.loadClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class1.getClassLoader());
		System.out.println(class1.hashCode());
		
		FileClassLoader2 loader2 = new FileClassLoader2(urls);
		Class<?> class2 = loader2.loadClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class2.getClassLoader());
		System.out.println(class2.hashCode());
	}
}
//输出
sun.misc.Launcher$AppClassLoader@5736ab79
2053014315
sun.misc.Launcher$AppClassLoader@5736ab79
2053014315

B）使用findClass方法，多次加载同一个类：

public class FileClassLoader2 extends URLClassLoader {
	public FileClassLoader2(URL[] urls) {
		super(urls);
	}

	public static void main(String[] args) throws Exception {
		String rootDir = "E:\\";
		URI uri = new File(rootDir).toURI();// File to URI
		URL[] urls = { uri.toURL() };

		FileClassLoader2 loader1 = new FileClassLoader2(urls);
		Class<?> class1 = loader1.findClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class1.getClassLoader());
		System.out.println(class1.hashCode());
		
		FileClassLoader2 loader2 = new FileClassLoader2(urls);
		Class<?> class2 = loader2.findClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class2.getClassLoader());
		System.out.println(class2.hashCode());
	}
}
//输出：
cn.nuc.edu.LogTest.load.FileClassLoader2@1e0196f8
1391835856
cn.nuc.edu.LogTest.load.FileClassLoader2@2bbd83d
892236228

注：虽然URLClassLoader有close方法，但例子中没有调用该方法也可以加载新资源。

2.3）示例2：要热替换的Demo类无法被AppClassLoader加载到

这里我们就用FileClassLoader2做个测试：

1）使用loadClass方法：

public class FileClassLoader2 extends URLClassLoader {
	public FileClassLoader2(URL[] urls) {
		super(urls);
	}

	public static void main(String[] args) throws Exception {
		String rootDir = "E:\\";
		URI uri = new File(rootDir).toURI();// File to URI
		URL[] urls = { uri.toURL() };

		FileClassLoader2 loader1 = new FileClassLoader2(urls);
		Class<?> class1 = loader1.loadClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class1.getClassLoader());
		System.out.println(class1.hashCode());
		
		FileClassLoader2 loader2 = new FileClassLoader2(urls);
		Class<?> class2 = loader2.loadClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class2.getClassLoader());
		System.out.println(class2.hashCode());
	}
}
//输出
cn.nuc.edu.LogTest.load.FileClassLoader2@5fcbc39b
1931573327
cn.nuc.edu.LogTest.load.FileClassLoader2@1a61c596
195780229

2）使用findClass方法：

public class FileClassLoader2 extends URLClassLoader {
	public FileClassLoader2(URL[] urls) {
		super(urls);
	}

	public static void main(String[] args) throws Exception {
		String rootDir = "E:\\";
		URI uri = new File(rootDir).toURI();// File to URI
		URL[] urls = { uri.toURL() };

		FileClassLoader2 loader1 = new FileClassLoader2(urls);
		Class<?> class1 = loader1.findClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class1.getClassLoader());
		System.out.println(class1.hashCode());
		
		FileClassLoader2 loader2 = new FileClassLoader2(urls);
		Class<?> class2 = loader2.findClass("cn.nuc.edu.LogTest.load.Demo");
		System.out.println(class2.getClassLoader());
		System.out.println(class2.hashCode());
	}
}
//输出
cn.nuc.edu.LogTest.load.FileClassLoader2@5b202f4d
2053014315
cn.nuc.edu.LogTest.load.FileClassLoader2@52f5bad0
2054262321

说明：无论使用findClass和loadClass都可以通过多个classLoader示例加载多次同一个类。

3、Tomcat类加载器：

3.1）思考一个问题

我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。
3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

Tomcat 如果使用默认的类加载机制行不行？

答案是不行的。为什么？我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

3.2）Tomcat如何实现自己独特的类加载机制？

 

我们看到，前面3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器。它们分别加载/common/*、/server/*、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。

• CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。
• WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
• JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

3.3）扩展：

如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？

根据前面的知识点可以得出，使用线程上下文类加载器实现，可以让父类加载器请求子类加载器去完成类加载的动作。

 

参考：

https://www.cnblogs.com/guoyansi19900907/p/12566101.html 自定义类加载器、热加载

https://juejin.cn/post/6844903485226352653 自定义类加载器、热加载

https://www.cnblogs.com/codeobj/p/12082587.html

https://juejin.cn/post/6844903550300979214