JVM类加载
指的是java进程运行时,需要把.class文件从硬盘加载到内存,并进行一系列校验解析的过程.
核心: .class文件=>类对象; 硬盘=>内存.
类加载过程
在整个JVM的执行流程中,和程序员关系最密切的就是类加载的过程了,所以我们来看一下类加载的执行流程.
对于一个类,它的生命周期是这样的:
其中前五步是固定的顺序也是类的加载过程,其中中间的三步我们都属于连接,所以类加载有以下几个步骤:
1.加载
2.连接
a.验证
b.准备
c.解析
3.初始化
下面我们来看每个步骤的具体内容.
加载
定义:把硬盘上的.class文件,找到,打开文件,读取到文件指定内容.
"加载"截断是整个"类加载"的过程中的一个阶段,它和类加载ClassLoading是不同的,一个是加载Loading另一个是类加载ClassLoading,所以不要把两者搞混了.
在加载Loading阶段,Java虚拟机需要完成以下事情:
(1)通过一个类的全限定名来获取此类的二进制字节流.
(2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构.
(3)在内存中生成一个代表这个类的java.lang.class对象,作为方法区这类的各种数据访问入口.
验证
验证是进行连接阶段的第一步,这一阶段的目的是确保Class文件的字节流中包含的信息符合 Java虚拟机 规范的全部约束要求,保证这些信息被当作代码运行后不会危害虚拟机自身的安全.
验证选项:
文件格式验证
字节码验证
符号引用验证
准备
定义:给类对象申请内存空间.里面默认值全0(这个阶段中,类对象静态成员变量也是相当于0了).
比如此时有这么一行代码:
pubilc static int value = 123;
它是初始化value的int值为0,而非123.
解析
定义:针对类中的字符串进行处理,解析阶段是Java虚拟机常量池内的符号替换为直接引用的过程,也就是初始化常量的过程.
例如如下程序:
class Test {
private String s = "hello";
}
.class文件内会包含这个hello.
上述代码中,很明确的知道,s变量里相当于保存了"hello",也就是字符串常量的地址.但是在文件中,不存在"地址"这样的概念. 地址是"内存"的地址.咱们是文件,是硬盘.
虽然没有地址,但是可以先存储一个类似于地址"偏移量"这样的概念.
接下来,要把.class文件加载到内存中.就会先把"hello"这个字符串加载到内存中.此时"hello"就有地址了. 接下来,s里面的值就可以替换成当前"hello"真实的地址了.
直接引用=>此处文件中填充给s的"hello"的偏移量就可以认为是"符号引用".
初始化
定义:针对类对象后续的初始化,还要执行代码块的逻辑,还会触发父类加载,初始化静态成员,执行静态代码块.
初始化阶段,Java虚拟机真正开始执行类中编写的Java程序代码,将主导权交给应用程序.初始化阶段就是执行类构造器方法的过程.
双亲委派模型
提到类加载机制,不得不提的概念就是"双亲委派模型".(描述了如何找到.class文件的策略).
站在Java虚拟机角度来看,只存在两种不同的类加载器(进行类加载的专门模块):一种是启动类加载器(BootstrapClassLoader),这个类加载器使用C++语言实现,是虚拟机的一部分;另外一种就是其它所有的类加载器,这些类加载器都由Java实现,独立存在于虚拟机外部,全部继承于抽象类java.lang.ClassLoader. 作用:给一个"全限定类名"(带有包名的类名),给定之后,找到对应的.class文件.
这里面,加载器存在"父子关系"(不是面向对象中的),而是类似于"二叉树",有parent指针指向.
Bootstrap ClassLoader负责查找标准库中的目录.
ExtensionClassLoader负责查找扩展库中的目录.
Application ClassLoader负责查找当前项目的代码目录.
启动类加载器:加载JDK中lib目录中的Java核心类库,即JAVA_HOME/lib目录.扩展类加载器.加载lib/ext目录下的类.
应用程序类加载器:加载我们写的应用程序.
自定义类加载器:根据自己的需求定制类加载器
什么是双亲委派模型
如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类的加载器去完成,每一个层次的类都是如此,因此所有的加载请求最终都应该传送到最顶层的启动器的加载器当中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会自己尝试去完成加载.
具体流程:
1.从ApplicationClassLoader作为入口,先开始工作.
2.ApplicationClassLoader不会立即搜索自己负责的目录,要把搜索任务交给它的父亲
3.ExtensionClassLoader也不想立即搜索自己负责的目录,也把搜索目录交给自己的父亲.
4.BootstrapClassLoader也不想立即搜索,把搜索目录交给父亲.
5.BootstrapClassLoader发现自己没有父亲,才会真正搜索负责的目录(标准库目录).通过全限定类名,尝试在标准库目录中找符合要求的.class文件.
(1)如果找到了,接下来就直接进入到打开文件/读文件流程
(2)如果没找到,回到孩子这一辈的加载器中,尝试继续加载.
6.ExtensionClassLoader收到父亲交给他的任务后,自己自行搜索负责的目录.(当前项目目录/第三方目录)
(1)如果找到了,接下来进入后续的流程.
(2)如果没找到,也是回到孩子这一辈类加载器中继续加载.
7.ApplicationClassLoader收到父亲交给它的任务后,自己负责搜索的目录(当前项目目录/第三方目录)
(1)如果找到了,接下来就进入了后续流程
(2)如果未找到,也会回到这一辈的类加载器继续尝试加载.由于默认情况下ApplicationClassLoader没有孩子了,说明类加载的过程失败了,就出现ClassNotFoundException异常.
这样的过程,也与自己工作中问题处理逻辑一样:
当基层员工遇到一个问题时(自己拿不定主意),然后交给中层领导.,中层领导也拿不定,就会交给老板决定.老板如果能解决,就会直接解决,如果觉得没必要,就会交给中层领导,让它们自行解决,中层领导觉得自己能解决就会直接解决如果觉得没必要,就会交给员工解决.
这样的问题汇报是很重要的.
按照上述的顺序,假定在代码中定义了一个java.lang.String这样的类,最终执行结果,自定义的类,不会被jvm加载.
上述的设定,也可以有效避免自己写的类,不小心和标准库中的类名重复,导致标准库的类名失效.
上述一系列过程,也可以通过自己写一个类加载器打破原有过程,不过实现非常麻烦.
双亲委派模型的优点
1.避免重复加载类:比如A类和B类都有一个父类C类,那么A启动时就会将C类加载起来,那么在B类进行加载时就不需要重复加载C类了.
2.安全性:使用双亲委派模型也可以保证了Java核心的API不被篡改,如果没有使用双亲委派模型,而是每个类加载器加载自己的话就会出现一些问题,比如我们编写一个java.lang.Object类的话,那么程序运行的时候,系统就会出现多个不同的Object类,而有些Object类又是用户自己提供的因此安全性就不能得到保证了.
