Java类加载机制、双亲委派、Java类加载过程

前言

一个Java文件从编码完成到最终执行，一般主要包括两个过程

• 编译
• 运行

编译，即把我们写好的java文件，通过javac命令编译成字节码，也就是我们常说的.class文件。

运行，则是把编译生成的.class文件交给Java虚拟机(JVM)执行。

而我们所说的类加载过程即是指JVM虚拟机把.class文件中类信息加载进内存，并进行解析生成对应的class对象的过程。

举个通俗点的例子来说，JVM在执行某段代码时，遇到了class A， 然而此时内存中并没有class A的相关信息，于是JVM就会到相应的class文件中去寻找class A的类信息，并加载进内存中，这就是我们所说的类加载过程。

由此可见，JVM不是一开始就把所有的类都加载进内存中，而是只有第一次遇到某个需要运行的类时才会加载，且只加载一次。

一、什么是 Java 类加载机制?

Java 虚拟机一般使用 Java 类的流程为：首先将开发者编写的 Java 源代码（.java文件）编译成 Java 字节码（.class文件），然后类加载器会读取这个 .class 文件，并转换成 java.lang.Class 的实例。有了该 Class 实例后，Java 虚拟机可以利用 newInstance 之类的方法创建其真正对象了。

ClassLoader 是 Java 提供的类加载器，绝大多数的类加载器都继承自 ClassLoader，它们被用来加载不同来源的 Class 文件。

1.Class 文件有哪些来源呢?

上文提到了 ClassLoader 可以去加载多种来源的 Class，那么具体有哪些来源呢？

首先，最常见的是开发者在应用程序中编写的类，这些类位于项目目录下；

然后，有 Java 内部自带的核心类如 java.lang、java.math、java.io 等 package 内部的类，位于 $JAVA_HOME/jre/lib/ 目录下，如 java.lang.String 类就是定义在 $JAVA_HOME/jre/lib/rt.jar 文件里；

另外，还有 Java 核心扩展类，位于 $JAVA_HOME/jre/lib/ext 目录下。开发者也可以把自己编写的类打包成 jar 文件放入该目录下；

最后还有一种，是动态加载远程的 .class 文件。

既然有这么多种类的来源，那么在 Java 里，是由某一个具体的 ClassLoader 来统一加载呢？还是由多个 ClassLoader 来协作加载呢？

2.哪些 ClassLoader 负责加载上面几类 Class？

实际上，针对上面四种来源的类，分别有不同的加载器负责加载。

首先，我们来看级别最高的 Java 核心类，即$JAVA_HOME/jre/lib 里的核心 jar 文件。这些类是 Java 运行的基础类，由一个名为 BootstrapClassLoader 加载器负责加载，它也被称作 根加载器／引导加载器。注意，BootstrapClassLoader 比较特殊，它不继承 ClassLoader，而是由 JVM 内部实现；

然后，需要加载 Java 核心扩展类，即 $JAVA_HOME/jre/lib/ext 目录下的 jar 文件。这些文件由 ExtensionClassLoader 负责加载，它也被称作 扩展类加载器。当然，用户如果把自己开发的 jar 文件放在这个目录，也会被 ExtClassLoader 加载；

接下来是开发者在项目中编写的类，这些文件将由 AppClassLoader 加载器进行加载，它也被称作 系统类加载器 System ClassLoader；

最后，如果想远程加载如（本地文件／网络下载）的方式，则必须要自己自定义一个 ClassLoader，复写其中的 findClass() 方法才能得以实现。

因此能看出，Java 里提供了至少四类 ClassLoader 来分别加载不同来源的 Class。

那么，这几种 ClassLoader 是如何协作来加载一个类呢？

3.这些 ClassLoader 以何种方式来协作加载 String 类呢？

String 类是 Java 自带的最常用的一个类，现在的问题是，JVM 将以何种方式把 String class 加载进来呢？

我们来猜想下。

首先，String 类属于 Java 核心类，位于 $JAVA_HOME/jre/lib 目录下。有的朋友会马上反应过来，上文中提过了，该目录下的类会由 BootstrapClassLoader 进行加载。没错，它确实是由 BootstrapClassLoader 进行加载。但，这种回答的前提是你已经知道了 String 在 $JAVA_HOME/jre/lib 目录下。

那么，如果你并不知道 String 类究竟位于哪呢？或者我希望你去加载一个 unknown 的类呢？

有的朋友这时会说，那很简单，只要去遍历一遍所有的类，看看这个 unknown 的类位于哪里，然后再用对应的加载器去加载。

是的，思路很正确。那应该如何去遍历呢？

比如，可以先遍历用户自己写的类，如果找到了就用 AppClassLoader 去加载；否则去遍历 Java 核心类目录，找到了就用 BootstrapClassLoader 去加载，否则就去遍历 Java 扩展类库，依次类推。

这种思路方向是正确的，不过存在一个漏洞。

假如开发者自己伪造了一个 java.lang.String 类，即在项目中创建一个包java.lang，包内创建一个名为 String 的类，这完全可以做到。那如果利用上面的遍历方法，是不是这个项目中用到的 String 不是都变成了这个伪造的 java.lang.String 类吗？如何解决这个问题呢？

解决方法很简单，当查找一个类时，优先遍历最高级别的 Java 核心类，然后再去遍历 Java 核心扩展类，最后再遍历用户自定义类，而且这个遍历过程是一旦找到就立即停止遍历。

在 Java 中，这种实现方式也称作 双亲委托。其实很简单，把 BootstrapClassLoader 想象为核心高层领导人， ExtClassLoader 想象为中层干部， AppClassLoader 想象为普通公务员。每次需要加载一个类，先获取一个系统加载器 AppClassLoader 的实例（ClassLoader.getSystemClassLoader()），然后向上级层层请求，由最上级优先去加载，如果上级觉得这些类不属于核心类，就可以下放到各子级负责人去自行加载。

如下图所示：

            

真的是按照双亲委托方式进行类加载吗？

下面通过几个例子来验证上面的加载方式。

开发者自定义的类会被 AppClassLoader 加载吗？

在项目中创建一个名为 MusicPlayer 的类文件，内容如下：

package classloader;

public class MusicPlayer {   
    public void print() {
        System.out.printf("Hi I'm MusicPlayer");
    }
}

然后来加载 MusicPlayer。

private static void loadClass() throws ClassNotFoundException {
    Class<?> clazz = Class.forName("classloader.MusicPlayer");
    ClassLoader classLoader = clazz.getClassLoader();
    System.out.printf("ClassLoader is %s", classLoader.getClass().getSimpleName());
}

打印结果为：

ClassLoader is AppClassLoader

可以验证，MusicPlayer 是由 AppClassLoader 进行的加载。

验证 AppClassLoader 的双亲真的是 ExtClassLoader 和 BootstrapClassLoader 吗？

这时发现 AppClassLoader 提供了一个 getParent() 的方法，来打印看看都是什么。

private static void printParent() throws ClassNotFoundException {
        Class<?> clazz = Class.forName("classloader.MusicPlayer");
        ClassLoader classLoader = clazz.getClassLoader();
        System.out.printf("currentClassLoader is %s
", classLoader.getClass().getSimpleName());        while (classLoader.getParent() != null) {
            classLoader = classLoader.getParent();
            System.out.printf("Parent is %s
", classLoader.getClass().getSimpleName());
        }
}

打印结果为：

currentClassLoader is AppClassLoaderParent is ExtClassLoader

首先能看到 ExtClassLoader 确实是 AppClassLoader 的双亲，不过却没有看到 BootstrapClassLoader。事实上，上文就提过， BootstrapClassLoader比较特殊，它是由 JVM 内部实现的，所以 ExtClassLoader.getParent() = null。

如果把 MusicPlayer 类挪到 $JAVA_HOME/jre/lib/ext 目录下会发生什么？

上文中说了，ExtClassLoader 会加载$JAVA_HOME/jre/lib/ext 目录下所有的 jar 文件。那来尝试下直接把 MusicPlayer 这个类放到 $JAVA_HOME/jre/lib/ext 目录下吧。

利用下面命令可以把 MusicPlayer.java 编译打包成 jar 文件，并放置到对应目录。

javac classloader/MusicPlayer.java
jar cvf MusicPlayer.jar classloader/MusicPlayer.classmv MusicPlayer.jar $JAVA_HOME/jre/lib/ext/

这时 MusicPlayer.jar 已经被放置与 $JAVA_HOME/jre/lib/ext 目录下，同时把之前的 MusicPlayer 删除，而且这一次刻意使用 AppClassLoader 来加载：

private static void loadClass() throws ClassNotFoundException {
    ClassLoader appClassLoader = ClassLoader.getSystemClassLoader(); // AppClassLoader
    Class<?> clazz = appClassLoader.loadClass("classloader.MusicPlayer");
    ClassLoader classLoader = clazz.getClassLoader();
    System.out.printf("ClassLoader is %s", classLoader.getClass().getSimpleName());
}

打印结果为：

ClassLoader is ExtClassLoader

说明即使直接用 AppClassLoader 去加载，它仍然会被 ExtClassLoader 加载到。

4.从源码角度真正理解双亲委托加载机制

上面已经通过一些例子了解了双亲委托的一些特性了，下面来看一下它的实现代码，加深理解。

打开 ClassLoader 里的 loadClass() 方法，便是需要分析的源码了。这个方法里做了下面几件事：

1. 检查目标class是否曾经加载过，如果加载过则直接返回；
2. 如果没加载过，把加载请求传递给 parent 加载器去加载；
3. 如果 parent 加载器加载成功，则直接返回；
4. 如果 parent 未加载到，则自身调用 findClass() 方法进行寻找，并把寻找结果返回。

代码如下：

protected Class<?> loadClass(String name, boolean resolve)   throws ClassNotFoundException{    
       synchronized (getClassLoadingLock(name)) {        
       // 1. 检查是否曾加载过
       Class<?> c = findLoadedClass(name);        
       if (c == null) {            
              long t0 = System.nanoTime();            
              try {                
                       if (parent != null) {                   
                         // 优先让 parent 加载器去加载
                         c = parent.loadClass(name, false);
                        } else {                    
                              // 如无 parent，表示当前是 BootstrapClassLoader，调用 native 方法去 JVM 加载
                        c = findBootstrapClassOrNull(name);
                        }
               } catch (ClassNotFoundException e) {                
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }            
           if (c == null) {                // 如果 parent 均没有加载到目标class，调用自身的 findClass() 方法去搜索
                long t1 = System.nanoTime();
                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;
    }
}// BootstrapClassLoader 会调用 native 方法去 JVM 加载private native Class<?> findBootstrapClass(String name);        

看完实现源码相信能够有更完整的理解。

5.类加载器最酷的一面：自定义类加载器

前面提到了 Java 自带的加载器 BootstrapClassLoader、AppClassLoader和ExtClassLoader，这些都是 Java 已经提供好的。

而真正有意思的，是 自定义类加载器，它允许我们在运行时可以从本地磁盘或网络上动态加载自定义类。这使得开发者可以动态修复某些有问题的类，热更新代码。

下面来实现一个网络类加载器，这个加载器可以从网络上动态下载 .class 文件并加载到虚拟机中使用。

后面我还会写作与 热修复／动态更新 相关的文章，这里先学习 Java 层 NetworkClassLoader 相关的原理。

1. 作为一个 NetworkClassLoader，它首先要继承 ClassLoader；
2. 然后它要实现ClassLoader内的 findClass() 方法。注意，不是loadClass()方法，因为ClassLoader提供了loadClass()（如上面的源码），它会基于双亲委托机制去搜索某个 class，直到搜索不到才会调用自身的findClass()，如果直接复写loadClass()，那还要实现双亲委托机制；
3. 在 findClass() 方法里，要从网络上下载一个 .class 文件，然后转化成 Class 对象供虚拟机使用。

具体实现代码如下：

/**
 * Load class from network
 */public class NetworkClassLoader extends ClassLoader {    @Override
   protected Class<?> findClass(String name) throws ClassNotFoundException {        byte[] classData = downloadClassData(name); // 从远程下载
        if (classData == null) {            super.findClass(name); // 未找到，抛异常
        } else {            return defineClass(name, classData, 0, classData.length); // convert class byte data to Class<?> object
        }        return null;
    }    
　　private byte[] downloadClassData(String name) {        // 从 localhost 下载 .class 文件
        String path = "http://localhost" + File.separatorChar + "java" + File.separatorChar + name.replace('.', File.separatorChar) + ".class"; 
        try {
            URL url = new URL(path);
            InputStream ins = url.openStream();
            ByteArrayOutputStream baos = new ByteArrayOutputStream();            
　　        int bufferSize = 4096;            
　　　　　　　byte[] buffer = new byte[bufferSize];            
　　　　　　　int bytesNumRead = 0;            
　　　　　　  while ((bytesNumRead = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesNumRead); // 把下载的二进制数据存入 ByteArrayOutputStream
            }            
　　　　　　  return baos.toByteArray();
        } catch (Exception e) {
            e.printStackTrace();
        }        
　　　　　　return null;
    } 
   　　
　　public String getName() {
        System.out.printf("Real NetworkClassLoader
");        
　　　　  return "networkClassLoader";
    }
}

这个类的作用是从网络上（这里是本人的 local apache 服务器 http://localhost/java 上）目录里去下载对应的 .class 文件，并转换成 Class<?> 返回回去使用。

下面我们来利用这个 NetworkClassLoader 去加载 localhost 上的 MusicPlayer 类：

1. 首先把 MusicPlayer.class 放置于 /Library/WebServer/Documents/java （MacOS）目录下，由于 MacOS 自带 apache 服务器，这里是服务器的默认目录；
2. 执行下面一段代码：
   

   String className = "classloader.NetworkClass";
   NetworkClassLoader networkClassLoader = new NetworkClassLoader();
   Class<?> clazz = networkClassLoader.loadClass(className);

3. 正常运行，加载 http://localhost/java/classloader/MusicPlayer.class成功。

可以看出 NetworkClassLoader 可以正常工作，如果读者要用的话，只要稍微修改 url 的拼接方式即可自行使用

二、Java 类加载过程

类加载

类加载的过程主要分为三个部分：

• 加载
• 链接
• 初始化

而链接又可以细分为三个小部分：

• 验证
• 准备
• 解析

 

       

1.加载

简单来说，加载指的是把class字节码文件从各个来源通过类加载器装载入内存中。

这里有两个重点：

• 字节码来源。一般的加载来源包括从本地路径下编译生成的.class文件，从jar包中的.class文件，从远程网络，以及动态代理实时编译
• 类加载器。一般包括启动类加载器，扩展类加载器，应用类加载器，以及用户的自定义类加载器。

注：为什么会有自定义类加载器？

• 一方面是由于java代码很容易被反编译，如果需要对自己的代码加密的话，可以对编译后的代码进行加密，然后再通过实现自己的自定义类加载器进行解密，最后再加载。
• 另一方面也有可能从非标准的来源加载代码，比如从网络来源，那就需要自己实现一个类加载器，从指定源进行加载。

2.1验证

主要是为了保证加载进来的字节流符合虚拟机规范，不会造成安全错误。

包括对于文件格式的验证，比如常量中是否有不被支持的常量？文件中是否有不规范的或者附加的其他信息？

对于元数据的验证，比如该类是否继承了被final修饰的类？类中的字段，方法是否与父类冲突？是否出现了不合理的重载？

对于字节码的验证，保证程序语义的合理性，比如要保证类型转换的合理性。

对于符号引用的验证，比如校验符号引用中通过全限定名是否能够找到对应的类？校验符号引用中的访问性（private，public等）是否可被当前类访问？

2.2准备

主要是为类变量（注意，不是实例变量）分配内存，并且赋予初值。

特别需要注意，初值，不是代码中具体写的初始化的值，而是Java虚拟机根据不同变量类型的默认初始值。

比如8种基本类型的初值，默认为0；引用类型的初值则为null；常量的初值即为代码中设置的值，final static tmp = 456， 那么该阶段tmp的初值就是456

2.3解析

将常量池内的符号引用替换为直接引用的过程。

两个重点：

• 符号引用。即一个字符串，但是这个字符串给出了一些能够唯一性识别一个方法，一个变量，一个类的相关信息。
• 直接引用。可以理解为一个内存地址，或者一个偏移量。比如类方法，类变量的直接引用是指向方法区的指针；而实例方法，实例变量的直接引用则是从实例的头指针开始算起到这个实例变量位置的偏移量

举个例子来说，现在调用方法hello()，这个方法的地址是1234567，那么hello就是符号引用，1234567就是直接引用。

在解析阶段，虚拟机会把所有的类名，方法名，字段名这些符号引用替换为具体的内存地址或偏移量，也就是直接引用。

3.初始化

这个阶段主要是对类变量初始化，是执行类构造器的过程。

换句话说，只对static修饰的变量或语句进行初始化。

如果初始化一个类的时候，其父类尚未初始化，则优先初始化其父类。

如果同时包含多个静态变量和静态代码块，则按照自上而下的顺序依次执行。

本文主要摘自知乎：https://www.zhihu.com/collection/512567639，https://www.zhihu.com/collection/512567639