深入理解Java虚拟机:类加载器
2017-02-19 20:13
253 查看
类加载器(ClassLoader)用来加载 class字节码到 Java 虚拟机中。一般来说,Java 虚拟机使用 Java 类的方式如下:Java 源文件在经过 Javac之后就被转换成 Java 字节码文件(.class 文件)。类加载器负责读取 Java 字节代码,并转换成 java.lang.Class 类的一个实例。每一个这样的实例用来表示一个 Java 类。实际的情况可能更加复杂,比如 Java 字节代码可能是通过工具动态生成的,也可能是通过网络下载。
这里所指的“相等”包括代表类的Class对象的equal方法、isAssignableFrom()、isInstance()方法及instance关键字返回的结果。
运行结果:
主要分为Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader和User Defined ClassLoader。
启动类加载器(Bootstrap ClassLoader):
这个类加载器使用C++语言实现,并非ClassLoader的子类。主要负责加载存放在JAVA_HOME / jre / lib / rt.jar里面所有的class文件,或者被-Xbootclasspath参数所指定路径中以rt.jar命名的文件。
扩展类加载器(Extension ClassLoader):
这个加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载AVA_HOME / lib / ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库。
应用程序类加载器(Application ClassLoader):
这个加载器由sun.misc.Launcher$AppClassLoader实现,它负责加载classpath对应的jar及目录。一般情况下这个就是程序中默认的类加载器。
自定义类加载器(User Defined ClassLoader):
开发人员继承ClassLoader抽象类自行实现的类加载器,基于自行开发的ClassLoader可用于并非加载classpath中(例如从网络上下载的jar或二进制字节码)、还可以在加载class文件之前做些小动作 如:加密等。
双亲委托的工作过程:如果一个类加载器收到了一个类加载请求,它首先不会自己去加载这个类,而是把这个请求委托给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成加载请求(它管理的范围之中没有这个类)时,子加载器才会尝试着自己去加载。
使用双亲委托模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,例如java.lang.Object存放在rt.jar之中,无论那个类加载器要加载这个类,最终都是委托给启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类,相反,如果没有双亲委托模型,由各个类加载器去完成的话,如果用户自己写一个名为java.lang.Object的类,并放在classpath中,应用程序中可能会出现多个不同的Object类,java类型体系中最基本安全行为也就无法保证。
双亲委派模型的实现:
类与类加载器
类加载器虽然只用于实现类的加载动作,但是它在 Java 程序中起到的作用却远远不限于类加载阶段。对于任意一个类,都需要由加载它的类加载器和这个类本身一同确定其在 Java 虚拟机中的唯一性,每个类加载器,都拥有一个独立的类名称空间。这句话可以表达得更通俗一些:比较两个类是否 “相等”,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于相同一个 Class 文件,被同一个虚拟机加载,只要加载他们的类加载器不同,那么这两个类就必定不等。这里所指的“相等”包括代表类的Class对象的equal方法、isAssignableFrom()、isInstance()方法及instance关键字返回的结果。
public class ClassLoaderTest { public static void main(String[] args) throws Exception { ClassLoader myLoader = new ClassLoader(){ @override public Class<?> loadClass(String name) throws ClassNotFundException { try{ String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class"; InputStream is = getClass().getResourceAsStream(fileName); if(is == null) return super.loadClass(name); byte[] b = new byte[is.available]; is.read(b); return defineClass(name,b,0,b.length); }catch(IOException e){ throw new ClassNotFundException(); } } }; Object obj = myLoader.loaderClass("com.test.ClassLoaderTest").newInstance(); System.out.println(obj.getClass()); System.out.println(obj instance com.test.ClassLoaderTest); } }
运行结果:
class com.test.ClassLoaderTest false
类加载器分类
主要分为Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader和User Defined ClassLoader。
启动类加载器(Bootstrap ClassLoader):
这个类加载器使用C++语言实现,并非ClassLoader的子类。主要负责加载存放在JAVA_HOME / jre / lib / rt.jar里面所有的class文件,或者被-Xbootclasspath参数所指定路径中以rt.jar命名的文件。
扩展类加载器(Extension ClassLoader):
这个加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载AVA_HOME / lib / ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库。
应用程序类加载器(Application ClassLoader):
这个加载器由sun.misc.Launcher$AppClassLoader实现,它负责加载classpath对应的jar及目录。一般情况下这个就是程序中默认的类加载器。
自定义类加载器(User Defined ClassLoader):
开发人员继承ClassLoader抽象类自行实现的类加载器,基于自行开发的ClassLoader可用于并非加载classpath中(例如从网络上下载的jar或二进制字节码)、还可以在加载class文件之前做些小动作 如:加密等。
双亲委派模型:
上图中所展示的类加载器之间的这种层次关系,就称为类加载器的双亲委托模型。双亲委托模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现,而是使用组合关系来复用父加载器的代码。双亲委托的工作过程:如果一个类加载器收到了一个类加载请求,它首先不会自己去加载这个类,而是把这个请求委托给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成加载请求(它管理的范围之中没有这个类)时,子加载器才会尝试着自己去加载。
使用双亲委托模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,例如java.lang.Object存放在rt.jar之中,无论那个类加载器要加载这个类,最终都是委托给启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类,相反,如果没有双亲委托模型,由各个类加载器去完成的话,如果用户自己写一个名为java.lang.Object的类,并放在classpath中,应用程序中可能会出现多个不同的Object类,java类型体系中最基本安全行为也就无法保证。
双亲委派模型的实现:
protect synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFUndException{ //首先,检查请求的类是否已经被加载过 Class c = findLoadedClass(name); if(c == null){ tyr{ if(parent != null){ c = parent.loadClass(name,false); }else{ c = findBootStrapClassOrNull(name); } }catch(ClassNotFundException e){ //如果父类加载抛出 ClassNotFundException //说明父类加载器无法完成加载请求 } if(c == null){ //在父类加载器无法加载的时候 //再调用本身的 findClass 方法进行类加载 c = findClass(name); } } if(resolve){ resolveClass(c); } return c; }
相关文章推荐
- 【深入理解Java虚拟机学习笔记】虚拟机类加载机制
- 深入理解Java虚拟机JVM高级特性与最佳实践阅读总结—— 第七章 虚拟机类加载机制
- 第7章 虚拟机类加载机制--《深入理解 Java 虚拟机》笔记
- 深入理解java虚拟机之类的加载
- 深入理解Java虚拟机之类加载机制
- 深入理解 Java 虚拟机(五)类加载的时机
- 深入理解Java虚拟机笔记--JVM内存模型及溢出问题总结
- 深入理解Java类加载器(1):Java类加载原理解析
- 深入理解Java虚拟机到底是什么
- 【转】【深入Java虚拟机】之四:类加载机制
- [java]深入理解Java虚拟机到底是什么
- 深入理解Java虚拟机到底是什么东西
- 深入理解Java:类加载机制及反射
- 深入Java虚拟机JVM类加载初始化学习
- 第6章 类文件结构--《深入理解 Java 虚拟机》笔记
- 阅读笔记——深入理解Java虚拟机
- 深入理解Java虚拟机到底是什么
- jvm 开始(深入理解java 虚拟机)
- 深入理解JVM—JVM内存模型(很经典) (部分摘自 深入JAVA虚拟机 周志明著)
- 【深入Java虚拟机】之类加载机制