在JVM有 两种类型的类加载器,一种是由c编写,一种是由java编写的,其中启动类加载器(Bootstrap Class Loader)是由c编写,其余的都是有java编写,由java编写的类加载器都继承自类java.lang.ClassLoader,为什么小编要这么区分呢,这是因为c++编写的,开发者无法直接获取到, 所以不允许直接通过引用进行操作。下面我们分别介绍几个类加载器:
1、启动类(Bootstrap)加载器:是由本地代码实现的类加载器,他负责将<Java_Runtime_Home>/lib下面的类库加载到内存中,例如rt.jar。由于引导类加载器涉及到虚拟机本地实现细节,开发者无法直接获取到启动类加载器的引用,所以不允许直接通过引用进行操作。其实,JVM将c++处理类加载的一套逻辑定义为启动类加载器,它是没有实体的。
2、标准扩展(Extension)类加载:是由Sun的ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的。 它负责将<Java_Runtime_Home>/lib/ext或者由系统变量java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
3、系统(System) 类加载器:是由Sun的AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的。它负责系统类路径(CLASSPATH)中指定地方类库加载到内存中。 开发者可以直接使用系统类加载器。
各种类加载器存在逻辑上的父子关系,但是并不是真正的父子关系,因为他们之间没有从属关系。
除了上面列举的 三种类加载器,还有一种比较特殊的类加载—— 线程上下文加载器
如果一个类加载器接收到加载某个类的请求,首先将加载任务委托给父类加载器,一次递归,如果父类加载器可以完成加载任务,就成功返回;只有再父类无法完成此加载任务时,才自己去加载。下面我们用一张图类描述整个过程:
在回到这个问题之前我们需要知道 类加载加载的类在jvm中如何存储?
从上面的图中我们可以看出,不同的类加载加载类在都在不同的区域,也就说如果我们同一个类使用不同的 类加载器加载,那么在jvm 中就会存在多份同样的字节码, 这种做法无疑是一种非常严重的资源浪费。这个时候如果我们使用 双亲委派机制,在加载某个的类的时候,就会递归向上查找,也就是首选使用Bootstra类加载器尝试加载,如果找不到再向下。这样能保证同一个类使用同一个类加载器加载。
因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制,父类加载器无法加载到需要的文件,以Driver接口为例,由于Driver接口定义在jdk当中的,而其实现由各个数据库的服务商来提供,比如mysql的就写了MySQL Connector
,那么问题就来了,DriverManager(也由jdk提供)要加载各个实现了Driver接口的实现类,然后进行管理,但是DriverManager由启动类加载器加载,只能记载JAVA_HOME的lib下文件,而其实现是由服务商提供的,由系统类加载器加载,这个时候就需要启动类加载器来委托子类来加载Driver实现,从而破坏了双亲委派。
既然我们要打破双亲委派,哪肯定是因为这种机制存在一定的弊端,从上面的分析我们都知道这种机制只能向上委派,所以我们要打破这种机制无非两种思路, 向下委派或者不委派。
SPI机制是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件,自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能,比如在Dubbo、JDBC中都使用到了SPI机制。这就是打破双亲委派的一种手段,直接通过约定的路径直接加载类。
同时我们还可以通过线程上下文加载器实现向下委派,可以通过线程上下文加载器直接制定类加载:
//获取
Thread.currentThread().getContextClassLoader()
// 设置
Thread.currentThread().setContextClassLoader(new Classloader_4());
比如我定义了一个类名为String所在包为java.lang,因为这个类本来是属于jdk的,如果没有沙箱安全机制的话,这个类将会污染到我所有的String,但是由于沙箱安全机制,所以就委托顶层的bootstrap加载器查找这个类,如果没有的话就委托extsion,extsion没有就到aapclassloader,但是由于String就是jdk的源代码,所以在bootstrap那里就加载到了,先找到先使用,所以就使用bootstrap里面的String,后面的一概不能使用,这就保证了不被恶意代码污染。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/u013045437/article/details/116098151
内容来源于网络,如有侵权,请联系作者删除!