1、内存结构
- 类加载器子系统负责从文件系统或者网络中加载class文件,class文件在文件开头有特定的文件标识
- ClassLoader只负责Class文件的加载,至于它是否可运行,则是由Execution Engine(执行引擎)决定的
- 加载的类信息存放于方法区中,除了类的信息外,方法区中还存放运行时常量池、静态变量、即时编译器编译后的代码等信息
2、类的加载过程
加载:
- 通过一个雷额全限定名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
连接:
初始化:
区分对象的创建过程:
3、类加载器
类加载器分类:引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader);将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
虚拟机自带的加载器:
(1)启动类加载器(引导类加载器,Bootstrap ClassLoader)
- 这个类加载器使用c/c++语言实现的,嵌套在jvm内部,就是jvm的一部分;
- 它用来加载java的核心库(JAVA_HOME/jre/lib/rt.jar\resources.jar或sun.boot.class.path路径下的内容),用于提供jvm自身需要的类;
- 并不继承java.lang.ClassLoader,没有父加载器;
- 用来加载扩展类和应用程序类加载器,并指定为他们的父类加载器;
- 出于安全考虑,Bootstrap ClassLoader只加载报名未java、javax、sun等开头的类。
(2)扩展类加载器(Extension ClassLoader)
- java语言编写,由sun.misc.Launcher$ExtClassLoader实现
- 派生于ClassLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载库,或从jdk的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的jar放在此目录下,也会自动由扩展类加载器加载。
(3)应用程序类加载器(系统类加载器,AppClassLoader)
- java语言编写,由sun.misc.Launcher$AppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器,一般来说,java应用的类都是由它来完成加载
- 通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器
用户自定义类加载器(为什么需要自定义类加载器):
- 隔离加载类--在同一个架构中引入多个框架,会出现路径相同的jar包,防止包冲突
- 修改类加载的方式
- 扩展加载源
- 防止源码泄露
获取ClassLoader
4、委派双亲机制
java虚拟机对class文件采用的是按需加载的方式(需要使用该类时才会将它的class文件加载到内存中并生成class对象),加载某个类的class文件时,java虚拟机采用的是双亲委派模式,即把请求交由父类处理器,它是一种任务委派模式。
工作原理:
(1)如果一个类加载器收到了类加载请求,他并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
(2)如果父类加载器还存在其父类加载器,则进一步向上委托,层层向上,请求最终将到达顶层的启动类加载器;
(3)如果父类加载器可以完成类加载任务,就成功返回,若父类加载器无法完成此加载任务,再交由子类加载器加载,层层向下,直到类加载完成。
优势:
(1)避免类的重复加载
(2)保护程序安全,防止核心api被随意篡改-->自定义类,java.lang.String和java.lang.ShkStart等,及时用户自定义,类加载器也只会加载java核心包中的lang包中的类,不会加载用户自定义的
5、沙箱安全机制
7、其他
在jvm中判断两个class对象是否为同一个类存在的两个必要条件:
- 类的完整类名必须一致,包括包名;
- 加载这个类的加载器(指ClassLoader实例对象)必须相同。
jvm必须知道一个类型是由启动类加载器的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么jvm会将这个类加载器的一个引用作为类信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,jvm需要保证这两个类型的类加载器是相同的。