01性能调优专题01-类加载机制深度解析
从JDK源码级别分析JVM类加载机制
我们都知道,运行一个Java文件,最终实际上运行的是它的字节码。那么整个底层实现是怎样的呢?
当我们用一个java指令运行java代码时,会首先通过类加载器把主类加载到Java虚拟机(JVM)中。
在这之前,JVM的创建其实是通过C++语言实现的,这个我们不用关心,C++创建了一个引导类加载器,然后由它负责加载Launcher类来创建其它类加载器,通过这些类加载器调用加载器里面的loadClass方法,去加载磁盘上的字节码文件。
这是一个大体的过程,下面我们重点讲类加载的过程,就是类究竟如何加载进JVM.
一、类加载过程
loadClass的类加载过程有如下几步:
加载 --> 验证 --> 准备 --> 解析 --> 初始化 --> 使用 --> 卸载
1.加载
- 加载:在硬盘上查找并通过IO读入字节码文件,使用到类时才会加载,例如调用类的main()方法,new对象等等,在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
大家都知道,Test.class类是放在磁盘上的,项目里显示在target目录下。这个类先要被加载JVM内存中去。那么第一步,就是把class文件丢到Java虚拟机的内存区域,也就是为之创建一个java.lang.Class对象,然后就要进入链接阶段。
2.链接
- 验证:校验字节码文件的正确性
验证的过程其实就是校验字节码文件里的格式是否符合java语言的规范
- 准备:给类的静态变量分配内存,并赋予默认值
默认值是java虚拟机规定的,比如整形赋值为0,boolean型赋为false, 对象可能是null,它不是最终值
- 解析:将符号引用替换成直接引用,该阶段会把一些静态方法(符号引用,比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用),这是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用
在类加载过程中完成解析的是静态链接。有些代码在加载的时候不一定会解析成内存地址,只有运行到这一行代码时,才会解析这个符号。
3.初始化
- 初始化:对类的静态变量初始化为指定的值,执行静态代码块
初始化是为类的静态变量赋予正确的初始值,准备阶段和初始化阶段看似有点矛盾,其实是不矛盾的,如果类中有语句:private static int a = 10,它的执行过程是这样的,首先字节码文件被加载到内存后,先进行链接的验证这一步骤,验证通过后准备阶段,给a分配内存,因为变量a是static的,所以此时a等于int类型的默认初始值0,即a=0,然后到解析(后面在说),到初始化这一步骤时,才把a的真正的值10赋给a,此时a=10。
类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的
引用、对应class实例的引用等信息。
类加载器的引用:这个类到类加载器实例的引用
对应class实例的引用:类加载器在加载类信息放到方法区中后,会创建一个对应的Class 类型的
对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意,主类在运行过程中如果使用到其它类,会逐步加载这些类。****
jar包或war包里的类不是一次性全部加载的,是使用到时才加载。
注意,主类在运行过程中如果使用到其它类,会逐步加载这些类。jar包或war包里的类不是一次性全部加载的,是使用到时才加载。
二、类加载时机
1.创建类的实例,也就是new 一个对象
2.访问某个类或接口的静态变量,或者对该静态变量赋值
3.调用类的静态方法
4.反射(Class.forName(“com.zk.Math”))
5.初始化一个类的子类(会首先初始化子类的父类)
6.JVM启动时标明的启动类,即文件名和类名相同的那个类
除此之外,下面几种情形需要特别指出: 对于一个final类型的静态变量,如果该变量的值在编译时就可以确定下来,那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值,因此即使程序使用该静态变量,也不会导致该类的初始化。反之,如果final类型的静态Field的值不能在编译时确定下来,则必须等到运行时才可以确定该变量的值,如果通过该类来访问它的静态变量,则会导致该类被初始化。
注意:JVM中的类加载是懒加载,它的加载机制是用的时候才去加载。主类在运行过程中如果使用到其它类,会逐步加载这些类。jar包或war包里的类不是一次性全部加载的,是使用到时才加载。
比方说一个war包里面可能有很多类,引入了很多第三方的依赖包,包括类似于SpringBoot jar包一样,它里面可能都有很多的依赖包,当web应用启动war包的时候,不会全部加载
看下面代码:
public class ClaassLoadTest {
static {
System.out.println("=======load static=======");
}
public static void main(String[] args) {
new A();
System.out.println("=======load=======");
B b = null;
}
}
class A {
static {
System.out.println("=======load A static=======");
}
public A() {
System.out.println("=======load A construction=======");
}
}
class B {
static {
System.out.println("=======load B static=======");
}
public B() {
System.out.println("=======load B construction=======");
}
}
运行结果:
=======load static=======
=======load A static=======
=======load A construction=======
=======load=======
分析结果:
首先load主类,然后new A(), 先调用静态代码块,因为构造方法是在类加载完之后才进行,而类加载过程里,有个初始化的阶段,会执行静态代码块。B没有加载,因为只是定义了,并没有使用,即没有 new B(),当然如果这个类有静态方法,你去调用了,也算使用,只要使用了,就会加载。
三、类加载器
上文提到的类加载过程主要是通过类加载器来实现的,Java里有如下几种类加载器
- 引导类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的核心类库,比如rt.jar、charsets.jar等
- 扩展类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
- 应用程序类加载器:负责加载ClassPath路径下的类包,主要就是加载你自己写的那些类
- 自定义加载器:负责加载用户自定义路径下的类包
看一个类加载器示例:
public class ClassLoaderTest {
public static void main(String[] args) {
//三种类:String, AccessBridge以及自定义的User类, 分别所属的类加载器
System.out.println(String.class.getClassLoader());
System.out.println(com.sun.java.accessibility.AccessBridge.class.getClassLoader());
System.out.println(User.class.getClassLoader());
System.out.println();
//层级关系
ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
ClassLoader extClassLoader = appClassLoader.getParent();
ClassLoader bootstrapLoader = extClassLoader.getParent();
System.out.println("bootstrapLoader:"+bootstrapLoader);
System.out.println("extClassLoader:"+extClassLoader);
System.out.println("appClassLoader:"+appClassLoader);
System.out.println();
}
}
运行结果:
null
sun.misc.Launcher$ExtClassLoader@677327b6
sun.misc.Launcher$AppClassLoader@18b4aac2
bootstrapLoader:null
extClassLoader:sun.misc.Launcher$ExtClassLoader@677327b6
appClassLoader:sun.misc.Launcher$AppClassLoader@18b4aac2
类加载器初始化过程
下面看下整个加载器的一个流程图,帮助理解:
通过Java命令执行代码的大体流程如下:
通过上图类运行全过程可知其中会创建JVM启动器sun.misc.Launcher。
sun.misc.Launcher初始化使用了单例模式设计,保证一个JVM虚拟机内只有一sun.misc.Launcher实例。在Launcher构造方法内部,其创建了两个类加载器,分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
而上面提到的类加载过程:加载,链接,初始化,就是图里loadClass加载类的过程。
再来看看Launcher内部源码:
// Launcher类的构造方法
public Launcher {
Launcher.ExtClassLoader var1;
try {
// 构造扩展类加载器,在构造过程中将其父加载器设置为null
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
// 构造应用程序类加载器,在构造过程中将其父加载器设置为ExtClassLoader
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
// 默认AppClassLoader
Thread.currentThread().setContextClassLoader(this.loader);
String var2 = System.getProperty("java.security.manager");
......
}
四、双亲委派机制
JVM类加载器是有上下级层级的,如下图
当某个类加载器需要加载某个.class文件时,它首先把这个任务委托给他的上级类加载器,递归这个操作,如果上级的类加载器没有加载,自己才会去加载这个类。具体流程如下:
我们来看下应用程序类加载器AppClassLoader加载类的双亲委派机制源码,AppClassLoader
的loadClass方法最终会调用其父类ClassLoader的loadClass方法,该方法的大体逻辑如下:
-
首先,检查一下指定名称的类是否已经加载过,如果加载过了,就不需要再加载,直接
返回。 -
如果此类没有加载过,那么,再判断一下是否有父加载器;如果有父加载器,则由父加
载器加载(即调用parent.loadClass(name, false);).或者是调用bootstrap类加载器来加
载。 -
如果父加载器及bootstrap类加载器都没有找到指定的类,那么调用当前类加载器的
findClass方法来完成类加载。
//ClassLoader的loadClass方法,里面实现了双亲委派机制
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 检查当前类加载器是否已经加载了该类
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) { //如果当前父加载器不为空则委托父加载器加载该类
c = parent.loadClass(name, false);
} else { //如果当前父加载器为空则委托引导类加载器加载该类
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//都会调用URLClassLoade的findClass方法在加载器的类路径里查找并加载该类
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
为什么设计这种机制?
- 沙箱安全机制:自己写的java.lang.String.class类不会被加载,这样便可以防止核心API库被随意篡改
- 避免类的重复加载:当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次,保证被加载类的唯一性
全盘负责委托机制
“全盘负责”是指当一个ClassLoder装载一个类时,除非显示的使用另外一个ClassLoder,该类所依赖及引用的类也由这个ClassLoder载入。
自定义类加载器示例
自定义类加载器只需要继承 java.lang.ClassLoader 类,该类有两个核心方法,一个是loadClass(String, boolean),实现了双亲委派机制,还有一个方法是findClass,默认实现是空方法,所以我们自定义类加载器主要是重写findClass方法。
打破双亲委派机制
所谓的打破双亲委派机制,就是用自定义类加载器加载自定义目录下的类,而不去委托父级类加载器,这样做,有什么用处呢。比如我们想加载自己实现的 java.lang.String.class。那么根据加载器的源码,我们可以重写loadClass(String, boolean)方法,将里面递归调用父级加载器的逻辑注释掉,那么久不会委托父级类加载器了,会直接返回,进行findClass方法的执行