这两篇文章分别介绍了类的生命周期、ClassLoader类。今天,我们继续介绍类的热加载。
一、类的卸载
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)实现方式:
- 如果要被热加载的类不会被bootstrap、Ext、App类加载器加载到(不在其路径下),可以创建不同的自定义类加载器实例,然后调用loadClass()、findClass()方法,从而热加载该类;(反正上面那些类加载器也加载不到,所以即使有双亲委派也没事)
- 如果要被热加载的类会被bootstrap、Ext、App类加载器加载到,创建不同的自定义类加载器实例,然后调用findClass()方法,从而热加载该类;(绕过双亲委派,以及findLoadedClass()缓存的检查)
- 重写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容器, 那么它要解决什么问题:
- 一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。
- 部署在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机。
- web容器也有自己依赖的类库,不能于应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。
- 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 中的类,该怎么办?