类加载机制,双亲委派模型(2)

原创
2019/08/28 17:35
阅读数 94

接着昨天的记录,今天继续开始了。 在JDK9中,由于Jigsaw项目引入了Java平台模块化系统(JPMS),Java SE的源代码被划分为一系列模块。 类加载器,类文件容器等都发生了非常大的变化,API已经被划分到具体的模块中,所以上文中,利用“——Xbootclasspath/p” 替换某个Java核心类型代码,实际上变成了对对应的模块进行的修补,可以采用下面的解决方案: 首先,确认要修改的类文件已经编译好,并按照对应模块结构存放,然后,给模块打补丁:

java --patch-module java.base=your_pathch yourApp
  • 拓展类加载器将被重命名为平台类加载器(Platform Class-Loader),而且extension机制规则被移除。也就意味着,如果我们指定Java.ext.dirs环境变量,或者lib/ext目录存在,JVM将直接返回错误!建议解决方法就是将其放入classpath里。
  • 部分不需要AllPermission的Java基础模块,被降级到平台类加载器中,相应的权限粒度也被更精细粒度地限制起来。
  • rt.jar和tools.jar同样是被移除了!JDK的核心类库以及相关资源,被存储在jimage文件中,并通过新的JRT文件系统访问,二不是原有的JAR文件系统。虽然看起来很惊人,但幸好对于大部分软件的兼容性影响,其实是有限的,更直接的影响的是IDE等软件,通常只要升级到最新版本就可以了。
  • 增加了Layer的抽象,JVM启动默认创建BootLayer,开发者也可以自己去定义和实例化Layer,可以更加方便的实现类似容器一般的逻辑抽象。结合了Layer,目前的JVM内部结构就变成了下面的层次,内建类加载器都在BootLayer中,其他Layer内部有自定义的类加载器,不同版本模块可以同时工作在不同的Layer。 谈到类加载器,绕不够的一个话题是自定义类加载器,常见的场景有:
  • 实现类似进程内隔离,类加载器实际上用做不同的命名空间,以提供类似容器、模块化的效果。例如,两个模块依赖于某个类库的不同版本,如果分别被不同的容器加载,就可以互不干扰。这个方面的集大成这是JavaEE和OSGI、JPMS等框架。
  • 应用需要从不同的数据源获取类定义信息,例如网络数据源,而不是本地文件系统。
  • 或者是需要自己操纵字节码,动态修改或者生成类型。 我们可以总体上简单理解自定义类加载过程:
  • 通过指定名称,找到其二进制实现,这里往往就是自定义类加载器会定制的部分,例如在特定数据源根据名字获取字节码,或者修改或者生成字节码。
  • 然后,创建Class对象,并完成类加载过程。二进制信息到Class对象的转换,通常就依赖defineClass,我们无需自己实现,它是final方法。有了Class对象,后续完成加载过程就顺理成章了。
展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部