java自定义classloader引发的思考

2024-08-31 11:02:41

引用

java类的热替换

classloader机制

如下图所示，java的classloader是双亲委派机制。会首先从父classloader加载指定的class，如果加载不到才会从子classloader中加载。
主要这里的图片主要用于体现classloader的父子关系，实际上实现时并不一定存在继承关系。比如AppClassLoader的父classLoader是ExtClassLoader，但是实际实现时两者都是继承自URLClassLoader的。

自定义classloader

Animal类&包结构

包结构如图：

测试入口

输出结果如图所示：

思考1

我们定义的classloader真的被运行了吗？
实际上如果打一些日志或者是debug进去看下，会发现我们重写的方法并没有被执行，这是java classloader的委派机制搞的鬼，我们可以发现定制的TinglangClassLoader的父classloader为URLClassLoader，在URLClassLoader中就已经找到了Animal类了。
所以这里可以重写loadClass方法来保证我们的classLoader被执行。

思考2

我们将代码做一些变种，如下图所示：
执行结果直接抛异常了
这是由于Animal类来源于两个不同的类加载器。如果只是需要执行Animal中的say方法的话，直接反射调用即可，如下图所示：

思考3

我们再将代码做一下变化，如下图所示，Animal作为一个普通内部类来实现，如下图所示：
可以看到代码已经提示无法实例化内部类了，这个是由于要实例化非静态的内部类对象，必须要先实例化外部类的对象，可以采用下面的方法来解决：
ps：这里内部类有public修饰符~

思考4

tomcat也是定义了自己的classloader，那么为啥不用jvm提供的classloader呢？
结合相关的资料主要是三个方面的目的：
- webapp隔离：由于各个webapp中的class和lib文件需要相互隔离，不能出现一个应用中加载的类库会影响到另一个应用的情况。
- 安全性：与jvm相同，tomcat也期望使用单独的classloader去装载tomcat自身的类库，以免其他恶意或者无意的破坏。
- 热部署：tomcat修改文件可以不用重启自动装载类库，这个点后面我们会单独抽取示例。

思考5

既然ExtClassLoader是读取特定目录下的class文件，那么如果我将自定义的class文件移到$JAVA_HOME/jre/lib/ext/目录下是不是就能够达到指定classloader加载类的目标呢？
这个点是可以的，但是必须要求是jar。

思考6

类加载器常见的用途有类的隔离和热替换，类的隔离非常好理解，那么热替换呢？
仍然以我们之前的代码为例，如下图所示：
在程序运行过程中更新并编译Animal类中say方法
可以看到运行结果如图所示：
ps:注意第一张图中的红色框框部分，如果修改为Thread.currentThread().getContextClassLoader()会发现实际上不会起作用，这是由于要想实现同一个类的不同版本的共存，这些不同的版本必须由不同的类加载器进行加载，因此就不能把这些类的加载工作委托给类加载器来完成，因为它们只有一份。

最新文章

热门文章