Java在new一个对象时,会先查看对象所属的类有没有被加载到内存中。如果没有,则会通过类的全限定名将类加载到内存中,再进行对象的创建工作。
1. 什么是类的加载
类的加载是指JVM将编译后的class二进制文件读取到内存中(存放在方法区内),然后在堆区创建一个java.lang.Class对象,用来封装该类在方法区内的数据结构。因此,我们能够通过Class对象访问该类在方法区内的各种数据结构。
2. 类加载的过程
JVM类的加载主要分为三步:装载,链接和初始化。如下图所示:
其中,链接过程又分为了验证,解析和准备三个步骤。
2.1 装载
装载是指JVM查找并读取class二进制文件的过程。它拥有三个步骤:
- 通过一个类的全限定名获得其定义的二进制字节流。
- 将这个二进制字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在堆中创建一个封装了该类定义的Class对象,作为其在方法区上访问数据结构的接口。
相对于类加载的其他阶段,装载阶段是可控性最强的阶段。因为开发人员既可以使用系统提供的类加载器来装载,也可以使用自定义的类加载器来完成装载。
2.2 链接
链接分为三个步骤:验证,准备和解析。
2.2.1 验证
验证是链接阶段的第一步,主要是为了确保当前class文件中的字节流信息符合JVM虚拟机的规范。它主要包括4种检验工作:文件格式验证,元数据验证,字节码验证和符号引用验证。
2.2.2 准备
准备阶段是为类的静态变量分配内存,并将其初始化为默认值。
这里所设置的默认值通常情况下是数据类型默认的零值(如0、0L、null、false等),而不是被在Java代码中被显式地赋予的值。
2.2.3 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
更多关于符号引用和直接引用,请参考:https://www.zhihu.com/question/30300585/answer/51335493
更多关于常量池的解释,请参考:
https://www.jb51.net/article/222551.htm
2.3 初始化
初始化阶段是为静态变量赋予正确的初始值,并执行类中的静态代码块。
3. 双亲委托模型
双亲委托模型的工作过程是:如果一个类加载器(ClassLoader)收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委托给父类加载器去完成。因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需要加载的类)时,子加载器才会尝试自己去加载。
使用双亲委托机制的好处是能够有效确保一个类的全局唯一性。当程序中出现多个限定名相同的类时,类加载器在执行加载时,始终只会加载其中的某一个类。
JVM中的类加载器如下:
- Bootstrap ClassLoader 负责加载$JAVA_HOME中 jre/lib/rt.jar 里所有的class或Xbootclassoath选项指定的jar包。由C++实现,不是ClassLoader子类。
- Extension ClassLoader 负责加载java平台中扩展功能的一些jar包,包括$JAVA_HOME中jre/lib/*.jar 或 -Djava.ext.dirs指定目录下的jar包。
- App ClassLoader 负责加载classpath中指定的jar包及 Djava.class.path 所指定目录下的类和jar包。
- Custom ClassLoader 通过java.lang.ClassLoader的子类自定义加载class,属于应用程序根据自身需要自定义的ClassLoader,如tomcat、jboss都会根据j2ee规范自行实现ClassLoader。
加载过程中会先检查类是否被已加载,检查顺序是自底向上,从Custom ClassLoader到BootStrap ClassLoader逐层检查,只要某个classloader已加载,就视为已加载此类,保证此类只所有ClassLoader加载一次。而加载的顺序是自顶向下,也就是由上层来逐层尝试加载此类。
4. Tomcat类加载模型
Tomcat的类加载模型则稍有不同,如下图所示:
- Bootstrap:加载JVM启动所需的类,以及其标准扩展类(位于/jre/lib/ext下)
- System:加载tomcat启动类(位于CATALINA_HOME/bin下),例如tomcat/bin/bootstrap.jar
- Common:加载tomcat应用通用的一些类(位于CATALINA_HOME/lib下),例如servlet-api.jar
- Webapp:每个应用在部署后,都会创建一个唯一的类加载器,即Webapp类加载器。该类加载器会加载位于 WEB-INF/lib下的jar和 WEB-INF/classes下的class文件。
Webapp类加载器,相对于传统的Java的类加载器,最主要的区别是子优先。也就是说,在Web应用内,需要加载一个类的时候,不是先委托给parent,而是先自己加载,在自己的类路径上找不到才会再委托parent。
但是此处的子优先有些地方需要注意的是,Java的基础类不允许其重新加载,以及servlet-api也不允许重新加载。
那为什么要先child之后再parent呢?我们前面说是Servlet规范规定的。但确实也是实际需要。假如我们两个应用内使用了相同命名空间里的一个class,一个使用的是Spring 2.x,一个使用的
是Spring 3.x。如果是parent先加载的话,在第一个应用加载后,第二个应用再需要的时候,就直接从parent里拿到了,但是却不符合需要。
另外,各个Web应用的类加载器,是相互独立的,即WebappClassloader的多个实例,只有这样,多个应用之间才可能使用不同版本的相同命令空间下的类库,而不互相受影响。