谈谈双亲委派模型的第四次破坏-模块化
简介
-
启动类加载器(Bootstrap Class Loader):由C++编写,负责加载<JAVA_HOME>\jre\lib目录下的类,例如最基本的Object,Integer,这些存在于rt.jar文件中的类,一般这些类都是Java程序的基石。 -
扩展类加载器(Extension Class Loader):负责加载<JAVA_HOME>\jre\lib\ext目录下的类,在JDK9之前我们可以将通用性的类库放在ext目录来扩展JAVA的功能,但实际的工程都是通过maven引入jar包依赖。并且在JDK9取消了这一类加载器,取而代之的是平台类加载器(Platform Class Loader),下面会对其介绍。 -
应用类加载器(Application Class Loader):负责加载ClassPath路径下的类,通常工程师编写的大部分类都是由这个类加载器加载。
工作顺序
解释
源代码
-
如果父类加载器不为空则用父类加载器加载 -
父类加载器加载不成功则本身再加载
Class<?> c = findLoadedClass(name);
//如果该类没加载过
if (c == null) {
try {
//如果有父类加载器
if (parent != null) {
//使用父类加载器加载
c = parent.loadClass(name, false);
...
}
}
if (c == null) {
...
//父类加载器没有加载成功则调用自身的findClass进行加载
c = findClass(name);
...
}
}
缺点
通过上 面的漫画不言而喻,当真正的敌人来了,靠这种低效的传达机制,怎么可能打一场胜仗呢?
启动类加载器负责加载<JAVA_HOME>\jre\lib目录
扩展类加载器负责加载<JAVA_HOME>\jre\lib\ext目录
应用类加载器负责加载ClassPath目录。
既然一切都是各司其职,为什么不能加载类的时候一步到位呢?
通过分析JDK9的类加载器源码,我发现最新的类加载器结构在一定程度上是缓解了这种情况的
02 JDK的模块化
在JDK9之前,JVM的基础类以前都是在rt.jar这个包里,这个包也是JRE运行的基石。这不仅是违反了单一职责原则,同样程序在编译的时候会将很多无用的类也一并打包,造成臃肿。
在JDK9中,整个JDK都基于模块化进行构建,以前的rt.jar, tool.jar被拆分成数十个模块,编译的时候只编译实际用到的模块,同时各个类加载器各司其职,只加载自己负责的模块。
03 模块化加载源码
Class > c = findLoadedClass(cn);
if (c == null) {
// 找到当前类属于哪个模块
LoadedModule loadedModule = findLoadedModule(cn);
if (loadedModule != null) {
//获取当前模块的类加载器
BuiltinClassLoader loader = loadedModule.loader();
//进行类加载
c = findClassInModuleOrNull(loadedModule, cn);
} else {
// 找不到模块信息才会进行双亲委派
if (parent != null) {
c = parent.loadClassOrNull(cn);
}
}
上面代码就是破坏双亲委派模型的“铁证”,而当我们继续跟进findLoadedModule,会发现是根据路径名找到对应的模块,而维护这一数据结构的就是下面这个Map。
Map<String, LoadedModule> packageToModule
= new ConcurrentHashMap<>(1024);
可以看到LoadedModule里面不仅有该模块的loader信息,还有用于描述依赖模块,对外暴露模块的信息的mref,LoadedModule也是模块化实现封装隔离机制的一块重要实现。
每一个module信息都有一个BuiltinClassloader,这个类有三个子类,我们通过源码分析他们的父子关系
在ClassLoaders类中可以发现,PlatformClassLoader的parent是BootClassLoader,而AppClassLoader的parent则是PlatformClassLoader。
在JDK9之前,JVM的基础类以前都是在rt.jar这个包里,这个包也是JRE运行的基石。这不仅是违反了单一职责原则,同样程序在编译的时候会将很多无用的类也一并打包,造成臃肿。
在JDK9中,整个JDK都基于模块化进行构建,以前的rt.jar, tool.jar被拆分成数十个模块,编译的时候只编译实际用到的模块,同时各个类加载器各司其职,只加载自己负责的模块。
Class > c = findLoadedClass(cn);
if (c == null) {
// 找到当前类属于哪个模块
LoadedModule loadedModule = findLoadedModule(cn);
if (loadedModule != null) {
//获取当前模块的类加载器
BuiltinClassLoader loader = loadedModule.loader();
//进行类加载
c = findClassInModuleOrNull(loadedModule, cn);
} else {
// 找不到模块信息才会进行双亲委派
if (parent != null) {
c = parent.loadClassOrNull(cn);
}
}
上面代码就是破坏双亲委派模型的“铁证”,而当我们继续跟进findLoadedModule,会发现是根据路径名找到对应的模块,而维护这一数据结构的就是下面这个Map。
Map<String, LoadedModule> packageToModule
= new ConcurrentHashMap<>(1024);
可以看到LoadedModule里面不仅有该模块的loader信息,还有用于描述依赖模块,对外暴露模块的信息的mref,LoadedModule也是模块化实现封装隔离机制的一块重要实现。
在ClassLoaders类中可以发现,PlatformClassLoader的parent是BootClassLoader,而AppClassLoader的parent则是PlatformClassLoader。
public class ClassLoaders {
// the built-in class loaders
private static final BootClassLoader BOOT_LOADER;
private static final PlatformClassLoader PLATFORM_LOADER;
private static final AppClassLoader APP_LOADER;
static {
//BootClassLoader
BOOT_LOADER =
new BootClassLoader((append != null && !append.isEmpty())
? new URLClassPath(append, true)
: null);
//PlatformClassLoader
PLATFORM_LOADER = new PlatformClassLoader(BOOT_LOADER);
...
//AppClassLoader
APP_LOADER = new AppClassLoader(PLATFORM_LOADER, ucp);
}
}
-
经过破坏后的双亲委派模型更加高效,减少了很多类加载器之间不必要的委派操作 -
JDK9的模块化可以减少Java程序打包的体积,同时拥有更好的隔离线与封装性 每个module拥有专属的类加载器,程序在并发性上也会更加出色
有道无术,术可成;有术无道,止于术
好文章,我在看❤️