01性能调优专题01-类加载机制深度解析

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方法，该方法的大体逻辑如下：

1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接
   返回。

2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加
   载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加
   载。

3. 如果父加载器及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方法的执行