龙空技术网

ClassLoader原理分析及应用场景

Java识堂 3810

前言:

而今各位老铁们对“javaclassloader”大约比较注重,我们都想要剖析一些“javaclassloader”的相关内容。那么小编也在网摘上汇集了一些对于“javaclassloader””的相关资讯,希望兄弟们能喜欢,姐妹们快快来学习一下吧!

本文为小编原创文章,首发于Java识堂,一个高原创,高收藏,有干货的微信公众号,一起成长,一起进步,欢迎关注

前言

先来看Java程序是怎么工作的

我们都知道Java是跨平台的,是因为不同平台下的JVM能将字节码文件解释为本地机器指令,JVM是怎么加载字节码文件的?答案就是ClassLoader,先来打印看一下ClassLoader对象

要理解这个输出,我们就得说一下双亲委派模式,如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器,如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式,即每个儿子都很懒,每次有活就丢给父亲去干,直到父亲说这件事我也干不了时,儿子自己想办法去完成。双亲委派模式中的父子关系并非通常所说的类继承关系,而是采用组合关系来复用父类加载器的相关代码。

采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层级关可以避免类的重复加载,当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次。其次是考虑到安全因素,java核心api中定义类型不会被随意替换,假设通过网络传递一个名为java.lang.Integer的类,通过双亲委托模式传递到启动类加载器,而启动类加载器在核心Java API发现这个名字的类,发现该类已被加载,并不会重新加载网络传递的过来的java.lang.Integer,而直接返回已加载过的Integer.class,这样便可以防止核心API库被随意篡改。检查和加载过程以及系统提供的ClassLoader的作用如下图。

LZ原来面试的时候就被问到,如果在你项目中建一个java.lang.String的类,那系统中用的String类是你定义的String类,还是原生api中的String类,用双亲加载来解释就很容易理解用的是原生api中的String类

类加载器的关系如下:

启动类加载器,由C++实现,没有父类拓展类加载器(ExtClassLoader),由Java语言实现,父类加载器为null系统类加载器(AppClassLoader),由Java语言实现,父类加载器为ExtClassLoader系统类加载器(AppClassLoader)自定义类加载器,父类加载器肯定为AppClassLoader。自定义类加载器,父类加载器肯定为AppClassLoader

源码解析

一般只需要理解ClassLoader 这3个方法即可

loaderClass:实现双亲委派

findClass:用来复写加载

defineClass:本地方法,最终加载类只能通过defineClass

自定义类加载器

为什么要编写自己的类加载器?

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

当继承ClassLoader时,只要重写findClass方法即可,还可以继承URLClassLoader,代码更简洁,这里不再赘述,下面写一个从指定文件中加载class文件的FileClassLoader

javac生成相应的class文件,放到指定目录,然后由FileClassLoader去加载

// 图中没有显示出来的部分String path = rootDir + File.separatorChar + className.replace('.', File.separatorChar) + ".class";
应用

可以对class文件进行加密和解密,实现应用的热部署,防止类重名等。这里只对Tomcat中的ClassLoader进行分析

在解释防止类重名作用前先抛出一个问题,Class对象的唯一标识能否只由全限定名确定?答案是不能,因为你无法保证多个项目间不出现相同的全限定名的类。比如和JDK原生类重名或者你的Web项目和Tomcat类重名(全限定名重名无法沟通,无法约束)。JVM判断2个类是否相同的条件是:(1)全限定名相同(2)由同一个类加载器加载

写个例子验证一下,先自定义一个FileClassLoader1,直接defineClass,不委托父类加载器进行加载

// 图中没有显示出来的部分String path = rootDir + File.separatorChar + className.replace('.', File.separatorChar) + ".class";

验证即使同一个class文件被不同classloader加载,也会被认为是不同的类

Tomcat中就定义了很多ClassLoader来防止重名。在Tomcat中提供了一个Common ClassLoader,它主要负责加载Tomcat使用的类和Jar包以及应用通用的一些类和Jar包,例如CATALINA_HOME/lib目录下的所有类和Jar包。Tomcat会为每个部署的应用创建一个唯一的类加载器,也就是WebApp ClassLoader,它负责加载该应用的WEB-INF/lib目录下的Jar文件以及WEB-INF/classes目录下的Class文件。由于没有应用都有自己的WebApp ClassLoader,这样就可以使不同的Web应用之间相互隔离,彼此之间看不到对方使用的类文件。即使不同项目下的类全限定名有可能相等,也能正常工作。

而对应用进行热部署时,会抛弃原有的WebApp ClassLoader,并为应用创建新的WebApp ClassLoader。

标签: #javaclassloader