深刻理解JVM类加载器

时间 2019-11-09

标签深刻理解 jvm 加载栏目 Java 繁體版

原文原文链接

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

类加载器

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

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

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

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中，只存在两种类加载器：ide

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

通常来讲，在讨论类加载器时，咱们会划分的更细，咱们能够看下图：函数

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

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

启动类加载器(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步：

调用findLoadedClass(String)来检查类是否已经被加载；
调用父类的loadClass方法，若是父类为空，就调用虚拟机内置的引导类加载器加载；
调用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类加载机制中所描述的了。