Java-类的加载机制介绍

Java Comments

在开始介绍类的加载机制之前我们先看一个有趣的例子。
新建一个 apk 工程，然后修改其中的 MainActivity 代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
package net.qiushao.classloadertest;
import androidx.appcompat.app.AppCompatActivity;
import android.content.Context;
import android.os.Bundle;
import android.os.IBinder;
import android.os.ServiceManager;
import android.util.Log;
public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //下面两行代码是我们添加的
        IBinder binder = ServiceManager.getService(Context.POWER_SERVICE);
        Log.d("qiushao", "binder = " + binder);
    }
}

我们知道 ServiceManager 这个类是 hide 的，在 sdk 里面是没有这个类的，因此上面的代码会提示找不到 ServiceManager 这个类。我们来加点魔法。在工程里新建一个包 android.os，　然后在这个包下面新建一个 ServiceManager 类：

1
2
3
4
5
6
7
8
package android.os;
import android.util.Log;
public class ServiceManager {
    public static IBinder getService(String name) {
        Log.d("qiushao", "qiushao define ServiceManager");
        return null;
    }
}

这样就没有错误提示了。同学们猜测一下 Log.d("qiushao", "qiushao define ServiceManager"); 这行代码会不会被执行？　IBinder binder = ServiceManager.getService(Context.POWER_SERVICE);　获取到的服务会不会是 null？ 我们来运行一下 apk，看下 log

1
2
3
4
5
130|generic_x86:/ $ logcat -c;logcat -s qiushao
--------- beginning of main
--------- beginning of system
02-17 22:27:44.932  9324  9324 D qiushao : binder = android.os.BinderProxy@6cfb07c
130|generic_x86:/ $

神奇的事情发生了，ServiceManager.getService(Context.POWER_SERVICE) 的返回结果竟然不是 null。如果你没有了解过 java 的类加载机制的话，肯定会一脸懵逼。但你看完下面对类的加载机制介绍之后应该就会明白其中的原理了。

1. 类加载机制基本概念

我们首先从宏观上回顾一下 java 类的编译执行的流程，大概如下图:
java编译执行流程

java 虚拟机把描述类的数据从 .class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 java 类型，这就是虚拟机的加载机制。
.class 文件由类装载器装载后，在 JVM 中将形成一份描述 Class 结构的元信息对象，通过该元信息对象可以获知 Class 的结构信息：如构造函数，属性和方法等，Java允许用户借由这个Class 相关的元信息对象间接调用 Class 对象的功能, 这里就是我们经常能见到的 Class 类。如果你有看过前两篇文章关于反射的介绍，你就知道，我们在反射中用到的 Class 对象其实就是从这里来的了。

本文主要介绍的就是其中的 类加载器 的工作。

2. 类的加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。这七个阶段的发生顺序如下图所示：
类的加载过程

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段，这五个阶段的工作分别如下：

2.1. 加载：查找并加载类的二进制数据

加载是类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

  1. 通过一个类的全限定名来获取定义此类的的二进制字节流。
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
  3. 在内存中生成一个代表这个类的 java.lang.Class 对象， 作为方法区这个类的各种数据的访问入口。

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。下面我们会着重讲解类加载器这部分内容。加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个　java.lang.Class　类的对象，这样便可以通过该对象访问方法区中的这些数据。

2.2. 校验：检查载入Class文件数据的正确性

验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：

  1. 文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
  2. 元数据的验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
  3. 字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
  4. 符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

2.3. 准备：给类的静态变量分配存储空间

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

  1. 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 java 堆中。
  2. 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在 java 代码中被显式地赋予的值。
    假设一个类变量的定义为:
    1
    public static int value = 3；
    那么变量 value 在准备阶段过后的初始值为 0，而不是 3，因为这时候尚未开始执行任何 java 方法，后面的初始化阶段会执行这个赋值语句，将 value 赋值为 3。
  3. 如果类字段的字段属性表中存在常量属性，即同时被 final 和 static 修饰，那么在准备阶段变量 value 就会被初始化为常量属性所指定的值。
    假设上面的类变量 value 被定义为： 
    1
    public static final int value = 3；
    编译时 javac 将会为 value 生成常量属性，在准备阶段虚拟机就会根据常量的设置将 value 赋值为 3。

2.4. 解析：将符号引用转成直接引用

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

2.5. 初始化：对类的静态变量，静态代码块执行初始化操作

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的 java 程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器 <clinit>() 方法的过程。
这里简单说明下 <clinit>() 方法的执行规则:

  1. <clinit>() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。
  2. <clinit>() 方法与实例构造器 <init>() 方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的 <clinit>() 方法执行之前，父类的 <clinit>() 方法已经执行完毕。因此，在虚拟机中第一个被执行的 <clinit>() 方法的类肯定是 java.lang.Object。
  3. <clinit>() 方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成 <clinit>() 方法。
  4. 接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成 <clinit>() 方法。但是接口与类不同的是：执行接口的 <clinit>() 方法不需要先执行父接口的 <clinit>() 方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的 <clinit>() 方法。
  5. 虚拟机会保证一个类的 <clinit>() 方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的 <clinit>() 方法，其他线程都需要阻塞等待，直到活动线程执行 <clinit>() 方法完毕。如果在一个类的 <clinit>() 方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

3. 触发类加载的条件

虚拟机规范严格规定了有且只有5中情况（jdk1.7）必须对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

  1. 遇到 new,getstatic,putstatic,invokestatic 这些字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的 java 代码场景是：使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段（被 final 修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
  2. 使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
  3. 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
  4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
  5. 当使用 jdk1.7 动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getstatic, REF_putstatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。

4. 类加载器　

在 java 中内置有三类 ClassLoader：启动类加载器（Bootstrap ClassLoader）、扩展类加载器（ExtClassLoader）、应用类加载器（AppClassLoader）。不同的类加载器负责不同区域的类的加载。

  • 启动类加载器：这个加载器不是一个 java 类，而是由底层c++实现的，负责加载存放在 $JAVA_HOME/jre/lib 目录中的类库，或者被 -Xbootclasspath 参数所指定的路径中的类库，比如 rt.jar。因为启动类加载器不属于 java 类库，无法被 java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用 null 代替即可。
  • 扩展类加载器：由 sun.misc.Launcher$ExtClassLoader 实现。负责加载 $JAVA_HOME/jre/lib/ext 目录下的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
  • 应用类加载器：由 sun.misc.Launcher$AppClassLoader 实现的。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader 方法的返回值，所以也叫系统类加载器。它负责加载用户类路径(CLASSPATH)上所指定的类库，可以被直接使用。如果未自定义类加载器，默认为该类加载器。

我们可以通过这种方式打印加载路径及相关jar：

1
2
3
4
5
6
7
8
9
package qiushao.net;

public class App {
    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
        System.out.println("boot:" + System.getProperty("sun.boot.class.path"));
        System.out.println("ext:" + System.getProperty("java.ext.dirs"));
        System.out.println("app:" + System.getProperty("java.class.path"));
    }
}

4.1 双亲委派模型

类加载器查找 Class（也就是在loadClass时）所采用的是双亲委托模式，所谓双亲委托模式就是:

  1. 首先判断该 Class 是否已经加载
  2. 如果没有加载则委托给父加载器进行查找，这样依次的进行递归，直到委托到最顶层的 Bootstrap ClassLoader
  3. 如果 Bootstrap ClassLoader 找到了该 Class，就会直接返回
  4. 如果没找到，则继续依次向下查找，如果还没找到则最后会交由自身去查找

具体流程见下图：
双亲委派模型
（图片来自http://liuwangshu.cn/application/classloader/1-java-classloader-.html）

  • 红色虚线的箭头代表向上委托的方向，如果当前的类加载器没有从缓存中找到这个 Class 对象，就会请求父加载器进行操作。直到 Bootstrap ClassLoader。
  • 黑色虚线的箭头代表的是查找方向，若 Bootstrap ClassLoader 可以从 $JAVA_HOME/jre/lib目录或者 -Xbootclasspath 指定目录查找到，就直接返回该对象，否则就让 ExtClassLoader 去查找。
  • ExtClassLoader 就会从 $JAVA_HOME/jre/lib/ext 或者 -Djava.ext.dir 指定位置中查找，找不到时就交给 AppClassLoader。
  • App ClassLoade 查找 CLASSPATH 目录下或者 -Djava.class.path 选项所指定的目录下的 jar 包和 .class文件，如果找到就返回，找不到交给我们自定义的类加载器 CustomClassLoader。
  • CustomClassLoader 是我们自定义的加载器，就要看我们怎么实现自定义 ClassLoader 的 findClass 方法了。

双亲委派模型是为了保证 java 核心库的类型安全。所有 java 应用都至少需要引用 java.lang.Object 类，在运行时这个类需要被加载到 java 虚拟机中。如果该加载过程由自定义类加载器来完成，可能就会存在多个版本的 java.lang.Object 类，而且这些类之间是不兼容的。通过双亲委派模型，对于 java 核心库的类的加载工作由启动类加载器来统一完成，保证了 java 应用所使用的都是同一个版本的 java 核心库的类，是互相兼容的。

下面我们来看一下双亲委派模型的代码是如何实现的。其实非常简单，相关的代码在 ClassLoader 类的 loadClass 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{    
        //首先判断指定类是否已经被加载过
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    //如果当前类没有被加载且父类加载器不为null，则请求父类加载器进行加载操作
                    c = parent.loadClass(name, false);
                } else {
                    //如果当前类没有被加载且父类加载器为null，则请求根类加载器进行加载操作
                    c = findBootstrapClassOrNull(name);
                }    
            } catch (ClassNotFoundException e) { 
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }    

            if (c == null) {
                //如果父类加载器加载失败，则由当前类加载器进行加载
                c = findClass(name);
            }    
        }    
        return c;
}

4.2 自定义类加载器

系统提供的类加载器只能够加载系统配置目录下的 jar 包和 .class文件, 如果想要加载网络上或者指定的目录下的 jar 包或者 class 文件，我们可以实现一个自己的类加载器。自定义类加载器只需要继承 java.lang.ClassLoader 类，然后重写 findClass(String name) 方法即可，在方法中指明如何获取类的字节码流。下面来写个 Demo 试试看。
我们先编写一个测试类，用来被我们自定义的类加载器加载：

1
2
3
4
5
6
package qiushao.net;
public class Person {
    public void say() {
        System.out.println("hello class loader");
    }
}

我们编译这个类生成 Person.class 文件，把这个文件放到 /home/qiushao/test/classloader/qiushao/net　目录下，然后删除 Person.java 源文件。
接下来我们就定义一个可以从指定目录加载 .class 文件的类加载器　TestClassloader:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
package qiushao.net;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

public class TestClassloader extends ClassLoader {
    String mClassPath;
    public TestClassloader(String classPath) {
        mClassPath = classPath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = getClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        }
        else {
            return defineClass(name, classData, 0, classData.length);
        }
    }

    //很简单，其实就是把文件数据读取到 byte[] data　而已。
    //如果有需求，我们可以把 class 文件加密，或者从网上下载，以免被别人破解核心代码。
    private byte[] getClassData(String name) {
        name = name.replaceAll("\\.", "/");
        FileInputStream fis = null;
        byte[] data = null;
        try {
            fis = new FileInputStream(mClassPath + "/" + name + ".class");
            int len = fis.available();
            data = new byte[len];
            fis.read(data);
            fis.close();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return data;
    }
}

接下来我们就可以使用这个自定义的类加载器来加载我们之前编译的 .class了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package qiushao.net;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class App {
    public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        TestClassloader classloader = new TestClassloader("/home/qiushao/test/classloader");
        Class<?> claz = classloader.loadClass("qiushao.net.Person");
        Object obj = claz.newInstance();
        Method method = claz.getMethod("say");
        method.invoke(obj);
        System.out.println("qiushao.net.Person is loaded by:" + obj.getClass().getClassLoader());
    }
}

结果如下：

1
2
hello class loader
qiushao.net.Person is loaded by:qiushao.net.TestClassloader@5e2de80c

的确加载到了我们指定路径下的 Class。

5. 开篇问题解答

看到这里，大家可以思考一下我们开头提出来的问题了：为什么我们自己定义的 ServiceManager 类不起作用？
答案就是双亲委派加载。这里给点提示，大家自己思考一下。

  • framework.jar 中有一个 android.os.ServiceManager 类。
  • framework.jar 在 BOOTCLASSPATH 中。这个可以 adb shell env 查看一下环境变量确认。
  • Bootstrap ClassLoader 会加载 $BOOTCLASSPATH 路径下的类。

以上大部分知识来源于 周志明老师的 <深入理解 Java 虚拟机>，这本书买了几年了，为了写这篇文章，又翻出来看了几遍。这本书写的是真不错，感兴趣的同学可以买来研究一下。

秋少Android system developer