深入理解JVM类加载器

在我的深入理解JVM类加载机制中，类加载器的部分我只谈了一点点内容，这篇文章将深入了解Java中的类加载器是如何工作的。

类加载器

类加载的第一个阶段就需要通过一个类的全限定名来获取描述此类的二进制字节流，实现这个动作的模块就是类加载器。

类加载器虽然只是实现类的加载动作，但是在Java程序中的作用远不止于此。在Java中一个类的唯一性不仅仅是看类本身，还要看它的加载器。通俗地说：比较两个类是否相等，只有在两个类时由同一个类加载器加载的前提下才有意义，否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要类加载器不同，两个类也不相等。

下面看周志明老师那本书上例举的一段代码：

import java.io.IOException;
import java.io.InputStream;

public class ClassLoaderTest {

    public static void main(String[] args) throws Exception{
        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try {
                    String fileName = name.substring(name.lastIndexOf(".") + 1)+".class";
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is==null) {
                        return super.loadClass(name);
                    }
                    byte[] b =new byte[is.available()];
                    is.read(b);
                    return defineClass(name,b,0,b.length);
                } catch (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };
        Object obj = myLoader.loadClass("ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());  //class ClassLoaderTest
        System.out.println(obj instanceof  ClassLoaderTest);  //false
    }
}

注释后打印了输出内容，我们使用自己定义的类加载器去加载本身产生的class文件，产生Class类，再实例化产生了obj对象。从打印的第一句看出，obj确实是ClassLoaderTest实例化的对象，但第二句返回了false，因为系统内存在两个ClassLoaderTest类，一个是系统应用程序类加载器加载的，一个是我们自定义的类加载器加载的，虽然来自于同一个class文件，但是却是两个类。

上面我们提到了应用程序加载器，自定义类加载器什么的，别急，继续往下看。

双亲委派模型

什么是双亲委派模型想必也是面试中的常问考点。之前我们也提到过在JVM中，只存在两种类加载器：

• 启动类加载器(Bootstrap ClassLoader): C++实现，虚拟机的一部分
• 用户自定义类加载器(User-Defined Class Loader)： Java语言实现，独立于虚拟机外部，并且都是继承与java.lang.ClassLoader

一般来说，在讨论类加载器时，我们会划分的更细，我们可以看下图：

类加载器

下面的讨论都将基于这幅图。

绝大部分的Java程序都会使用到以下3种系统提供的类加载器。

• 启动类加载器(Bootstrap ClassLoader): 这个类将负责把<JAVA_HOME>\lib\目录中的，或者-Xbootclasspath参数指定的目录所指定的路径中的，并且是虚拟机识别的的类库加载到虚拟机内存中，如rt.jar，识别仅按照文件名识别，如果名字不符合，即使在这个目录下，也不会被加载。启动类加载器无法被java程序直接引，用户如果在编写自定义的类加载器时，如果需要把加载请求委托给引导类加载器，那么直接用null代替即可。
• 扩展类加载器(Extension ClassLoader): 这个类加载器由sun.misc.Launcher $ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。
• 应用程序加载类(Application ClassLoader): 这个类加载器是由sun.misc.Launcher $App-ClassLoader实现。该加载器是由ClassLoader的getSystemClassLoader()方法返回，所以一般称它为系统类加载器。一般它加载用户类路径(ClassPath)所指定的类库，开发者一般直接使用这个类加载器，如果没有定义自己的类加载器，那么这个应用程序加载类就是程序中默认的类加载器。

我们来解释下什么是双亲委派模型？

双亲委派模型要求除了顶层的Bootstrap ClassLoader外，其它所有类加载器都要有自己的父类加载器。这里的父子关系一般不会议继承实现，而是通过组合实现。它的基本工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器完成，每个层次的类加载器都是如此，因此最后所有的请求都会传递到顶层的启动类加载器中，只有当父加载器返回自己无法完成这个加载请求（即它的搜索范围内没有找到所需要的类），子加载器才会尝试去自己加载。

使用双亲委派模型的好处呢？

使用双亲委派模型最直接的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，例如jaba.lang.Object类，它存放在rt.jar中，无论哪一个类加载器要加载这个类，最终都要委派给最上层的boostrap ClassLoader，所以Object类在程序的各种类加载器环境中都是同一个类。假如没有使用双亲委派模型，由各个类各自加载Object，那么系统里将会出现各种版本的Object类，导致整个系统的混乱。

下面我们从ClassLoader的源码来看看双亲委派模式：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name); //检查该类是否加载过了
            if (c == null) {//没加载过的情况
                long t0 = System.nanoTime();  
                try {
                    if (parent != null) {
                        //如果自定义的类加载器的parent不为null,就调用parent的loadClass进行加载类 
                        c = parent.loadClass(name, false);   
                    } else {
                        //否则就去找bootstrap ClassLoader
                        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();
                    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;
        }
    }

从上面的代码来看，使用指定名称加载类分为以下3步：

1. 调用findLoadedClass(String)来检查类是否已经被加载；
2. 调用父类的loadClass方法，如果父类为空，就调用虚拟机内置的引导类加载器加载；
3. 调用findClass(String)来查找该类。

因为loadClass封装了双亲委派模型，所以在开发自己的类加载器时，Java标准提覆写findClass()方法。

通常情况下，Java虚拟机都是从文件系统里load一个class，但是有一些类不一定来自一个文件，它们也可能来自别的源，比如网络，加密文件等等，假设我们写一个自己的类加载器，加载服务器下载的class文件。

示例使用代码：

ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();

在定义时，我们覆写findClass方法：

class NetworkClassLoader extends ClassLoader {
         String host;
         int port;

         public Class findClass(String name) {
             byte[] b = loadClassData(name);
             return defineClass(name, b, 0, b.length);
         }

         private byte[] loadClassData(String name) {
             // load the class data from the connection
              . . .
         }
     }

这里重要的还有个defineClass函数，用来把一组二进制字节转换为Class的实例，转换为Class后再交给后续的类加载过程解析。后续步骤就又回到深入理解JVM类加载机制中所描述的了。