JVM组成1 之类加载器(ClassLoader)
2018-02-07 00:00
357 查看
摘要: JVM一般由类加载器、运行时数据区(堆、方法区、虚拟机栈等)、执行引擎等组成
负责加载JDK中的核心类库,如:rt.jar、resources.jar、charsets.jar、sunrsasign.jar、jsse.jar、jce.jar等(加载jdk/jre/lib/下的部分jar包以及jdk/jre/classes下的class文件)
ExtensionClassLoader:称为扩展类加载器,负责加载Java的扩展类库,默认加载jdk/jre/lib/ext/目下的所有jar
AppClassLoader:称为系统类加载器,负责加载应用程序classpath目录下的所有jar和class文件
用户还可以根据需要定义自已的ClassLoader,自定义的ClassLoader都必须继承自java.lang.ClassLoader类(包括Java提供Extension ClassLoader和App ClassLoader)
Bootstrap ClassLoader不继承ClassLoader,因为它不是一个普通的Java类,底层由C++编写,已嵌入到了JVM内核当中。当JVM启动后,Bootstrap ClassLoader也随着启动,负责加载完核心类库后,并构造Extension ClassLoader和App ClassLoader类加载器
每个ClassLoader实例都有一个父类加载器的引用(不是继承的关系,是一个包含的关系)。
Bootstrap ClassLoader本身没有父类加载器,但可以用作其它ClassLoader实例的父类加载器。
当一个ClassLoader实例需要加载某个类时,它会先把这个任务委托给它的父类加载器,这个过程是由上至下依次检查的,
首先由最顶层的类加载器Bootstrap ClassLoader试图加载,
如果没加载到,则把任务转交给Extension ClassLoader加载,
如果也没加载到,则转交给App ClassLoader 进行加载,
如果它也没有加载得到的话,则返回给委托的发起者,由它到指定的文件系统或网络等URL中加载该类。
如果它们都没有加载到这个类时,则抛出ClassNotFoundException异常。
否则将这个找到的类生成一个类的定义,并将它加载到内存当中,最后返回这个类在内存中的Class实例对象。
为什么要使用双亲委托这种模型?因为这样可以避免重复加载,
当父亲已经加载了该类的时候,就没有必要子ClassLoader再加载一次。
考虑到安全因素,我们试想一下,如果不使用这种委托模式,那我们就可以随时使用自定义的String来动态替代java核心api中定义的String类型,这样会存在非常大的安全隐患,
而双亲委托的方式,就可以避免这种情况,因为String已经在启动时就被类加载器(Bootstrcp ClassLoader)加载,所以用户自定义的ClassLoader永远也无法加载一个自己写的String,
除非你改变JDK中ClassLoader搜索类的默认算法。
JVM在搜索类的时候,如何判定两个class是相同?
JVM在判定两个class是否相同时,不仅要判断两个类名是否相同,而且要判断是否由同一个类加载器加载的。
只有两者同时满足的情况下,JVM才认为这两个class是相同的。
就算两个class是同一份class字节码,如果被两个不同的ClassLoader实例所加载,JVM也会认为它们是两个不同class。
2.重写父类的findClass方法
因为JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法,
当在loadClass方法中搜索不到类时,loadClass方法就会调用findClass方法来搜索类,所以我们只需重写该方法即可。
如没有特殊的要求,一般不建议重写loadClass搜索类的算法。
作用
用来动态加载class文件到内存当中分类
BootStrapClassLoader:称为启动类加载器,是Java类加载层次中最顶层的类加载器,负责加载JDK中的核心类库,如:rt.jar、resources.jar、charsets.jar、sunrsasign.jar、jsse.jar、jce.jar等(加载jdk/jre/lib/下的部分jar包以及jdk/jre/classes下的class文件)
ExtensionClassLoader:称为扩展类加载器,负责加载Java的扩展类库,默认加载jdk/jre/lib/ext/目下的所有jar
AppClassLoader:称为系统类加载器,负责加载应用程序classpath目录下的所有jar和class文件
用户还可以根据需要定义自已的ClassLoader,自定义的ClassLoader都必须继承自java.lang.ClassLoader类(包括Java提供Extension ClassLoader和App ClassLoader)
Bootstrap ClassLoader不继承ClassLoader,因为它不是一个普通的Java类,底层由C++编写,已嵌入到了JVM内核当中。当JVM启动后,Bootstrap ClassLoader也随着启动,负责加载完核心类库后,并构造Extension ClassLoader和App ClassLoader类加载器
类加载器原理
ClassLoader使用的是双亲委托模型来搜索类的每个ClassLoader实例都有一个父类加载器的引用(不是继承的关系,是一个包含的关系)。
Bootstrap ClassLoader本身没有父类加载器,但可以用作其它ClassLoader实例的父类加载器。
当一个ClassLoader实例需要加载某个类时,它会先把这个任务委托给它的父类加载器,这个过程是由上至下依次检查的,
首先由最顶层的类加载器Bootstrap ClassLoader试图加载,
如果没加载到,则把任务转交给Extension ClassLoader加载,
如果也没加载到,则转交给App ClassLoader 进行加载,
如果它也没有加载得到的话,则返回给委托的发起者,由它到指定的文件系统或网络等URL中加载该类。
如果它们都没有加载到这个类时,则抛出ClassNotFoundException异常。
否则将这个找到的类生成一个类的定义,并将它加载到内存当中,最后返回这个类在内存中的Class实例对象。
为什么要使用双亲委托这种模型?因为这样可以避免重复加载,
当父亲已经加载了该类的时候,就没有必要子ClassLoader再加载一次。
考虑到安全因素,我们试想一下,如果不使用这种委托模式,那我们就可以随时使用自定义的String来动态替代java核心api中定义的String类型,这样会存在非常大的安全隐患,
而双亲委托的方式,就可以避免这种情况,因为String已经在启动时就被类加载器(Bootstrcp ClassLoader)加载,所以用户自定义的ClassLoader永远也无法加载一个自己写的String,
除非你改变JDK中ClassLoader搜索类的默认算法。
JVM在搜索类的时候,如何判定两个class是相同?
JVM在判定两个class是否相同时,不仅要判断两个类名是否相同,而且要判断是否由同一个类加载器加载的。
只有两者同时满足的情况下,JVM才认为这两个class是相同的。
就算两个class是同一份class字节码,如果被两个不同的ClassLoader实例所加载,JVM也会认为它们是两个不同class。
自定义类加载器
1.继承java.lang.ClassLoader2.重写父类的findClass方法
因为JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法,
当在loadClass方法中搜索不到类时,loadClass方法就会调用findClass方法来搜索类,所以我们只需重写该方法即可。
如没有特殊的要求,一般不建议重写loadClass搜索类的算法。
相关文章推荐
- JVM(Java虚拟机)启动时,会形成由三个类加载器组成的初始类加载器层次结构:
- JVM之类加载器
- JVM高级特性与实践(九):类加载器 与 双亲委派模式(自定义类加载器源码探究ClassLoader)
- 深入了解JVM之类加载器
- 当JVM(Java虚拟机)启动时,会形成由三个类加载器组成的初始类加载器层次结构
- Java虚拟机深入详解JVM之类加载器深度剖析、类的主动使用、被动使用
- JVM学习四:JVM之类加载器之初始化分析
- JVM之类加载器(ClassLoader)基本介绍
- [jvm解析系列][十]类加载器和双亲委派模型,你真的了解ClassLoader吗?
- JVM解读(二):JVM类加载器ClassLoader
- JVM学习三:JVM之类加载器之连接分析
- JVM基础之类加载器
- JVM原理之类加载器
- JVM学习二:JVM之类加载器之加载分析
- JVM学习五:JVM之类加载器之编译常量和主动使用
- 【JVM】JVM之类加载器
- JVM学习一:JVM之类加载器概况
- JVM高级特性与实践(九):类加载器 与 双亲委派模式(自定义类加载器源码探究ClassLoader)
- JVM高级特性与实践(九):类加载器 与 双亲委派模式(自定义类加载器源码探究ClassLoader)
- JVM学习六:JVM之类加载器之双亲委派机制