利用classloader同一个项目中加载另一个同名的类_ClassLoader原理分析及应用场景...

本文为小编原创文章，首发于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类

类加载器的关系如下：

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

源码解析

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

loaderClass：实现双亲委派

findClass：用来复写加载

defineClass：本地方法，最终加载类只能通过defineClass

自定义类加载器

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

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