面试官问:如何打破双亲委派机制?

一. 引言

在上篇JVM类加载机制中,讲到了类加载的双亲委派机制,那为什么又要打破双亲委派机制呢?难道是它不好用吗?

我们想一个场景,比如在一个tomcat中,部署了多个应用包,其中一个包使用的是spring5.0,另一个包使用的是spring4.0,此时在双亲委派机制下,如果先加载spring4.0的包,那么另一个使用spring5.0的包再来加载的时候发现spring的相关类已经被类加载器加载过了,就不会再次加载。可想而知,这就会导致巨大的兼容性问题。因此,在特殊场景下,是需要打破双亲委派机制的。

二. 如何打破双亲委派机制

打破双亲委派机制实际上就是不让父加载器加载来加载我们需要的类,下面我们来尝试一下用自定义类加载器打破双亲委派机制来加载一个自定义的String类

看过上篇文章的小伙伴一定知道,其实双亲委派的核心代码就是这里面试官问:如何打破双亲委派机制?_第1张图片

 那我们就直接来改写这个方法

面试官问:如何打破双亲委派机制?_第2张图片

很简单,直接把双亲委派机制的代码删除即可

运行一下

面试官问:如何打破双亲委派机制?_第3张图片 报错了,系统提示java\lang\Object.class (系统找不到指定的路径。) 找不到这个类

怎么解决呢?

感觉能想到最简单的方法,就是把Object.class复制到我们自己的类路径下

说试就试

我在自己的目录下新建java.lang包,然后把Object.class丢到这个目录下,再运行看看

 面试官问:如何打破双亲委派机制?_第4张图片

面试官问:如何打破双亲委派机制?_第5张图片 又报错了,这是为什么呢?

沙箱安全机制! 这是为了防止java的核心类库被随意篡改,如果随便一个人都可以来修改java的核心类库的话,那程序还有什么安全性可言?

那么接下来再针对这个问题对代码做个修改,既然核心类库不让我修改,那么核心类库我就继续沿用双亲委派机制好了呗,只对自己的类来打破双亲委派机制

面试官问:如何打破双亲委派机制?_第6张图片

 如果是自己的文件则使用自定义类加载器,如果是其他类则使用默认类加载器

面试官问:如何打破双亲委派机制?_第7张图片

验证成功,到这里我们已经顺利打破双亲委派机制啦~ 

你可能感兴趣的:(JVM,java,jvm,面试)