java类的热加载

淡淡的烟草味﹌ 2021-09-03 09:16 322阅读 0赞

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

[https://blog.csdn.net/liuxiao723846/article/details/109901300][https_blog.csdn.net_liuxiao723846_article_details_109901300]

[https://blog.csdn.net/liuxiao723846/article/details/110009055][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对象。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXhpYW83MjM4NDY_size_16_color_FFFFFF_t_70][]

### 2、卸载类： ###

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

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

![20201128164702171.png][]

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

**1）类何时被卸载？**

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

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

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

![20201128164722106.png][]

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

**总结：**

*  被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][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][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][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_www.cnblogs.com_guoyansi19900907_p_12566101.html] 自定义类加载器、热加载

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

[https://www.cnblogs.com/codeobj/p/12082587.html][https_www.cnblogs.com_codeobj_p_12082587.html]

[https://juejin.cn/post/6844903550300979214][https_juejin.cn_post_6844903550300979214]

[https_blog.csdn.net_liuxiao723846_article_details_109901300]: https://blog.csdn.net/liuxiao723846/article/details/109901300
[https_blog.csdn.net_liuxiao723846_article_details_110009055]: https://blog.csdn.net/liuxiao723846/article/details/110009055
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXhpYW83MjM4NDY_size_16_color_FFFFFF_t_70]: /images/20210511/952ec84c79c741258ddb3c77d4e47017.png
[20201128164702171.png]: /images/20210511/9d8ee9a5b25b4b33b05c819090940c9e.png
[20201128164722106.png]: /images/20210511/7a6ece4315494e198ebc14d2dd45cbd8.png
[cn.nuc.edu.LogTest.load.FileClassLoader_4614ac54]: mailto:cn.nuc.edu.LogTest.load.FileClassLoader@4614ac54
[http_icejoywoo.github.io_2017_02_22_jvm-classloader-issue.html]: http://icejoywoo.github.io/2017/02/22/jvm-classloader-issue.html
[https_www.cnblogs.com_guoyansi19900907_p_12566101.html]: https://www.cnblogs.com/guoyansi19900907/p/12566101.html
[https_juejin.cn_post_6844903485226352653]: https://juejin.cn/post/6844903485226352653
[https_www.cnblogs.com_codeobj_p_12082587.html]: https://www.cnblogs.com/codeobj/p/12082587.html
[https_juejin.cn_post_6844903550300979214]: https://juejin.cn/post/6844903550300979214