透过现象看本质：Java 类动态加载和热替换

摘要：本文主要介绍类加载器、自定义类加载器及类的加载和卸载等内容，并举例介绍了 Java 类的热替换。

 

最近，遇到了两个和 Java 类的加载和卸载相关的问题：

 

1) 是一道关于 Java 的判断题：一个类被首次加载后，会长期留驻 JVM，直到 JVM 退出。这个说法，是不是正确的？

 

2) 在开发的一个集成平台中，需要集成类似接口的多种工具，并且工具可能会有新增，同时在不同的环境部署会有裁剪（例如对外提供服务的应用，不能提供特定的采购的工具），如何才能更好地实现？

 

针对上面的第 2 点，我们采用 Java 插件化开发实现。上面的两个问题，都和 Java 的类加载和热替换机制有关。

 

1. Java 的类加载器和双亲委派模型

 

1.1 Java 类加载器

 

类加载器，顾名思义，就是用来实现类的加载操作。每个类加载器都有一个独立的类名称空间，就是说每个由该类加载器加载的类，都在自己的类名称空间，如果要比较两个类是否“相等”，首先这两个类必须在相同的类命名空间，即由相同的类加载器加载（即对于任何一个类，都必须由该类本身和加载它的类加载器一起确定其在 JVM 中的唯一性），不是同一个类加载器加载的类，不会相等。

 

在 Java 中，主要有如下的类加载器：

 

image

 

图 1.1 Java 类加载器

 

下面，简单介绍上面这几种类加载器：

 

  • 启动类加载器（Bootstrap Class Loader）：这个类使用 C++开发（所有的类加载器中，唯一使用 C++开发的类加载器），用来加载<JAVA_HOME>/lib 目录中 jar 和 tools.jar 或者使用 -Xbootclasspath 参数指定的类。

  • 扩展类加载器（Extension Class Loader）：定义为 misc.Launcher$ExtClassLoader，用来加载<JAVA_HOME>/lib/ext 目录或者使用 java.ext.dir 指定的类。

  • 应用程序类加载器（Application Class Loader）：定义为 misc.Launcher$AppClassLoader，用来加载用户类路径下面（classpath）下面所有的类，一般情况下，该类是应用程序默认的类加载器。

  • 用户自定义类加载器（User Class Loader）：用户自定义类加载器，一般没有必要，后面我们会专门来一部分介绍该类型的类加载器。

 

1.2 双亲委派模型

 

双亲委派模型，是从 Java1.2 开始引入的一种类加载器模式，在 Java 中，类的加载操作通过 java.lang.ClassLoader 中的 loadClass()方法完成，咱们首先看看该方法的实现（直接从 Java 源码中捞出来的）：

 

 

 

我们结合上面的注释，来解释下双亲委派模型的内容：

 

1) 接收到一个类加载请求后，首先判断该类是否有加载，如果已经加载，则直接返回；

 

2) 如果尚未加载，首先获取父类加载器，如果可以获取父类加载器，则调用父类的 loadClass()方法来加载该类，如果无法获取父类加载器，则调用启动器加载器来加载该类；

 

3) 判断该类是否被父类加载器或者启动类加载器加载，如果已经加载完成则返回，如果未成功加载，则自己尝试来加载该类。

 

上面的描述，说明了 loadClass()方法的实现，我们进一步对上面的步骤进行解释：

 

  • 因为类加载器首先调父类加载器来进行加载，从 loadClass()方法的实现，我们知道父类加载器会尝试调自己的父类加载器，直到启动类加载器，所以，任何一个类的加载，都会最终委托到启动类加载器来首先加载；

  • 在前面有进行介绍，启动类加载器、扩展类加载器、应用程序类加载器，都有自己加载的类的范围，例如启动类加载器只加载 JDK 核心库，因此并不是父类加载器就可以都加载成功，父类加载器无法加载（一般如上面代码，抛出来 ClassNotFoundException），此时会由自己加载。

 

最后啰嗦一下，再进行一下总结：

 

双亲委派模型：如果一个类加载器收到类加载请求，会首先把加载请求委派给父类加载器完成，每个层次的类加载器都是这样，最终所有的加载请求都传动到最根的启动类加载器来完成，如果父类加载器无法完成该加载请求（即自己加载的范围内找不到该类），子类加载器才会尝试自己加载。

 

这样的双亲委派模型有个好处：就是所有的类都尽可能由顶层的类加载器加载，保证了加载的类的唯一性，如果每个类都随机由不同的类加载器加载，则类的实现关系无法保证，对于保证 Java 程序的稳定运行意义重大。

 

2. Java 的类动态加载和卸载

 

2.1 Java 类的卸载

 

在 Java 中，每个类都有相应的 Class Loader，同样的，每个实例对象也会有相应的类，当满足如下三个条件时，JVM 就会卸载这个类：

 

1) 该类所有实例对象不可达

 

2) 该类的 Class 对象不可达

 

3) 该类的 Class Loader 不可达

 

那么，上面示例对象、Class 对象和类的 Class Loader 直接是什么关系呢？

 

在类加载器的内部实现中，用一个 Java 集合来存放所加载类的引用。而一个 Class 对象总是会引用它的类加载器，调用 Class 对象的 getClassLoader()方法，就能获得它的类加载器。所以，Class 实例和加载它的加载器之间为双向引用关系。

 

一个类的实例总是引用代表这个类的 Class 对象。在 Object 类中定义了 getClass()方法，这个方法返回代表对象所属类的 Class 对象的引用。此外，所有的 Java 类都有一个静态属性 class，它引用代表这个类的 Class 对象。

 

Java 虚拟机自带的类加载器（前面介绍的三种类加载器）在 JVM 运行过程中，会始终存在，而这些类加载器则会始终引用它们所加载的类的 Class 对象，因此这些 Class 对象始终是可触及的。因此，由 Java 虚拟机自带的类加载器所加载的类，在虚拟机的生命周期中，始终不会被卸载。

 

那么，我们是不是就完全不能在 Java 程序运行过程中，动态修改我们使用的类了吗？答案是否定的！根据上面的分析，通过 Java 虚拟机自带的类加载器加载的类无法卸载，我们可以自定义类加载器来加载 Java 程序，通过自定义类加载器加载的 Java 类，是可以被卸载的。

 

2.2 自定义类加载器

 

前面介绍到，类加载的双亲委派模型，是推荐模型，在 loadClass 中实现的，并不是必须使用的模型。我们可以通过自定义类加载器，直接加载我们需要的 Java 类，而不委托给父类加载器。

 

image

 

图 2.1 自定义类加载器

 

如上图所示，我们有自定义的类加载器 MyClassLoader，用来加载类 MyClass，则在 JVM 中，会存在上面三类引用（上图忽略这三种类型对象对其他的对象的引用）。如果我们将左边的三个引用变量，均设置为 null，那么此时，已经加载的 MyClass 将会被卸载。

 

2.3 动态卸载存在的问题

 

动态卸载需要借助于 JVM 的垃圾收集功能才可以做到，但是我们知道，JVM 的垃圾回收，只有在堆内存占用比较高的时候，才会触发。即使我们调用了 System.gc()，也不会立即执行垃圾回收操作，而只是告诉 JVM 需要执行垃圾回收，至于什么时候垃圾回收，则要看 JVM 自己的垃圾回收策略。

 

但是我们不需要悲观，即使动态卸载不是那么牢靠，但是实现动态的 Java 类的热替换还是有希望的。

 

3. Java 类的热替换

 

下面通过代码来介绍 Java 类的热替换方法（代码简陋，主要为了说明问题）：

 

如下面的代码：

 

首先定义一个自定义类加载器：

 

查看代码 
 package zmj;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;

public class FileClassLoader extends ClassLoader {

  private String fileName;

  public void setFileName(String fileName) {
    this.fileName = fileName;
  }

  public Class loadClass(String name) throws ClassNotFoundException {

    if (name.startsWith("java")) {
      return getSystemClassLoader().loadClass(name);
    }
    Class cls = null;
    File classF = new File(fileName);
    try {
      cls = instantiateClass(name, new FileInputStream(classF), classF.length());
    } catch (IOException e) {
      e.printStackTrace();
    }
    return cls;
  }

  private Class instantiateClass(String name, InputStream fin, long len) throws IOException {
    byte[] raw = new byte[(int) len];
    fin.read(raw);
    fin.close();
    return defineClass(name, raw, 0, raw.length);
  }
}

 

上面在 loadClass 时，先判断类 name（包含 package 的全限定名）是否以 java 开始，如果是 java 开始，则使用 JVM 自带的类加载器加载。

 

然后定义一个简单的动态加载类：

 

 
查看代码 
 public class SayHello {

  public void say() {
    System.out.println("hello zmj...");
    // System.out.println("hello ping...");
  }
}

在执行过程中，会动态修改打印内容，测试类的热加载。

 

然后定义一个调用类：

 

image

 

 当我们运行上面 Main 程序过程中，我们动态修改执行内容（SayHello 中，从 hello zmj... 更改为 hello ping...），最终展示的内容如下：

 

image

 

4. 总结

 

本文主要介绍类加载器、自定义类加载器及类的加载和卸载等内容，并举例介绍了 Java 类的热替换实现。

 

其实，最近在开发项目中，需要裁剪特性，就想用 pf4j 来做插件化开发，了解了一些类加载机制，整理一下。

 

主要参考《深入 Java 虚拟机：JVM 高级特性与最佳实践》。

透过现象看本质：Java类动态加载和热替换_Java_华为云开发者联盟_InfoQ写作社区

ClassLoader翻译过来就是类加载器，普通的java开发者其实用到的不多，但对于某些框架开发者来说却非常常见。理解ClassLoader的加载机制，也有利于我们编写出更高效的代码。ClassLoader的具体作用就是将class文件加载到jvm虚拟机中去，程序就可以正确运行了。但是，jvm启动的时候，并不会一次性加载所有的class文件，而是根据需要去动态加载。想想也是的，一次性加载那么多jar包那么多class，那内存不崩溃。本文的目的也是学习ClassLoader这种加载机制。

备注：本文篇幅比较长，但内容简单，大家不要恐慌，安静地耐心翻阅就是

Class文件的认识

我们都知道在Java中程序是运行在虚拟机中，我们平常用文本编辑器或者是IDE编写的程序都是.java格式的文件，这是最基础的源码，但这类文件是不能直接运行的。如我们编写一个简单的程序HelloWorld.java

public class HelloWorld{

	public static void main(String[] args){
		System.out.println("Hello world!");
	}
}

如图：
这里写图片描述
然后，我们需要在命令行中进行java文件的编译

javac HelloWorld.java

这里写图片描述
可以看到目录下生成了.class文件

我们再从命令行中执行命令：

java HelloWorld

这里写图片描述

上面是基本代码示例，是所有入门JAVA语言时都学过的东西，这里重新拿出来是想让大家将焦点回到class文件上，class文件是字节码格式文件，java虚拟机并不能直接识别我们平常编写的.java源文件，所以需要javac这个命令转换成.class文件。另外，如果用C或者PYTHON编写的程序正确转换成.class文件后，java虚拟机也是可以识别运行的。更多信息大家可以参考这篇。

了解了.class文件后，我们再来思考下，我们平常在Eclipse中编写的java程序是如何运行的，也就是我们自己编写的各种类是如何被加载到jvm(java虚拟机)中去的。

你还记得java环境变量吗？

初学java的时候，最害怕的就是下载JDK后要配置环境变量了，关键是当时不理解，所以战战兢兢地照着书籍上或者是网络上的介绍进行操作。然后下次再弄的时候，又忘记了而且是必忘。当时，心里的想法很气愤的，想着是–这东西一点也不人性化，为什么非要自己配置环境变量呢？太不照顾菜鸟和新手了，很多菜鸟就是因为卡在环境变量的配置上，遭受了太多的挫败感。

因为我是在Windows下编程的，所以只讲Window平台上的环境变量，主要有3个：JAVA_HOME、PATH、CLASSPATH。

JAVA_HOME

指的是你JDK安装的位置，一般默认安装在C盘，如

C:\Program Files\Java\jdk1.8.0_91

PATH

将程序路径包含在PATH当中后，在命令行窗口就可以直接键入它的名字了，而不再需要键入它的全路径,比如上面代码中我用的到javac和java两个命令。
一般的

PATH=%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;%PATH%;

也就是在原来的PATH路径上添加JDK目录下的bin目录和jre目录的bin.

CLASSPATH

CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar

一看就是指向jar包路径。
需要注意的是前面的.;，.代表当前目录。

环境变量的设置与查看

设置可以右击我的电脑，然后点击属性，再点击高级，然后点击环境变量，具体不明白的自行查阅文档。

查看的话可以打开命令行窗口


echo %JAVA_HOME%

echo %PATH%

echo %CLASSPATH%

好了，扯远了，知道了环境变量，特别是CLASSPATH时，我们进入今天的主题Classloader.

JAVA类加载流程

Java语言系统自带有三个类加载器:

  • Bootstrap ClassLoader 最顶层的加载类，主要加载核心类库，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。比如java -Xbootclasspath/a:path被指定的文件追加到默认的bootstrap路径中。我们可以打开我的电脑，在上面的目录下查看，看看这些jar包是不是存在于这个目录。
  • Extention ClassLoader 扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。
  • Appclass Loader也称为SystemAppClass 加载当前应用的classpath的所有类。

我们上面简单介绍了3个ClassLoader。说明了它们加载的路径。并且还提到了-Xbootclasspath和-D java.ext.dirs这两个虚拟机参数选项。

加载顺序？

我们看到了系统的3个类加载器，但我们可能不知道具体哪个先行呢？
我可以先告诉你答案

  1. Bootstrap CLassloder
  2. Extention ClassLoader
  3. AppClassLoader

为了更好的理解，我们可以查看源码。
看sun.misc.Launcher,它是一个java虚拟机的入口应用。

public class Launcher {
    private static Launcher launcher = new Launcher();
    private static String bootClassPath =
        System.getProperty("sun.boot.class.path");

    public static Launcher getLauncher() {
        return launcher;
    }

    private ClassLoader loader;

    public Launcher() {
        // Create the extension class loader
        ClassLoader extcl;
        try {
            extcl = ExtClassLoader.getExtClassLoader();
        } catch (IOException e) {
            throw new InternalError(
                "Could not create extension class loader", e);
        }

        // Now create the class loader to use to launch the application
        try {
            loader = AppClassLoader.getAppClassLoader(extcl);
        } catch (IOException e) {
            throw new InternalError(
                "Could not create application class loader", e);
        }

        //设置AppClassLoader为线程上下文类加载器，这个文章后面部分讲解
        Thread.currentThread().setContextClassLoader(loader);
    }

    /*
     * Returns the class loader used to launch the main application.
     */
    public ClassLoader getClassLoader() {
        return loader;
    }
    /*
     * The class loader used for loading installed extensions.
     */
    static class ExtClassLoader extends URLClassLoader {}

/**
     * The class loader used for loading from java.class.path.
     * runs in a restricted security context.
     */
    static class AppClassLoader extends URLClassLoader {}

源码有精简，我们可以得到相关的信息。

  1. Launcher初始化了ExtClassLoader和AppClassLoader。
  2. Launcher中并没有看见BootstrapClassLoader，但通过System.getProperty("sun.boot.class.path")得到了字符串bootClassPath,这个应该就是BootstrapClassLoader加载的jar包路径。

我们可以先代码测试一下sun.boot.class.path是什么内容。

System.out.println(System.getProperty("sun.boot.class.path"));

得到的结果是：

C:\Program Files\Java\jre1.8.0_91\lib\resources.jar;
C:\Program Files\Java\jre1.8.0_91\lib\rt.jar;
C:\Program Files\Java\jre1.8.0_91\lib\sunrsasign.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jsse.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jce.jar;
C:\Program Files\Java\jre1.8.0_91\lib\charsets.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jfr.jar;
C:\Program Files\Java\jre1.8.0_91\classes

可以看到，这些全是JRE目录下的jar包或者是class文件。

ExtClassLoader源码

如果你有足够的好奇心，你应该会对它的源码感兴趣

/*
     * The class loader used for loading installed extensions.
     */
    static class ExtClassLoader extends URLClassLoader {

        static {
            ClassLoader.registerAsParallelCapable();
        }

        /**
         * create an ExtClassLoader. The ExtClassLoader is created
         * within a context that limits which files it can read
         */
        public static ExtClassLoader getExtClassLoader() throws IOException
        {
            final File[] dirs = getExtDirs();

            try {
                // Prior implementations of this doPrivileged() block supplied
                // aa synthesized ACC via a call to the private method
                // ExtClassLoader.getContext().

                return AccessController.doPrivileged(
                    new PrivilegedExceptionAction<ExtClassLoader>() {
                        public ExtClassLoader run() throws IOException {
                            int len = dirs.length;
                            for (int i = 0; i < len; i++) {
                                MetaIndex.registerDirectory(dirs[i]);
                            }
                            return new ExtClassLoader(dirs);
                        }
                    });
            } catch (java.security.PrivilegedActionException e) {
                throw (IOException) e.getException();
            }
        }

        private static File[] getExtDirs() {
            String s = System.getProperty("java.ext.dirs");
            File[] dirs;
            if (s != null) {
                StringTokenizer st =
                    new StringTokenizer(s, File.pathSeparator);
                int count = st.countTokens();
                dirs = new File[count];
                for (int i = 0; i < count; i++) {
                    dirs[i] = new File(st.nextToken());
                }
            } else {
                dirs = new File[0];
            }
            return dirs;
        }
 
......
    }

我们先前的内容有说过，可以指定-D java.ext.dirs参数来添加和改变ExtClassLoader的加载路径。这里我们通过可以编写测试代码。

System.out.println(System.getProperty("java.ext.dirs"));

结果如下：

C:\Program Files\Java\jre1.8.0_91\lib\ext;C:\Windows\Sun\Java\lib\ext

AppClassLoader源码

/**
     * The class loader used for loading from java.class.path.
     * runs in a restricted security context.
     */
    static class AppClassLoader extends URLClassLoader {


        public static ClassLoader getAppClassLoader(final ClassLoader extcl)
            throws IOException
        {
            final String s = System.getProperty("java.class.path");
            final File[] path = (s == null) ? new File[0] : getClassPath(s);

     
            return AccessController.doPrivileged(
                new PrivilegedAction<AppClassLoader>() {
                    public AppClassLoader run() {
                    URL[] urls =
                        (s == null) ? new URL[0] : pathToURLs(path);
                    return new AppClassLoader(urls, extcl);
                }
            });
        }

        ......
    }

可以看到AppClassLoader加载的就是java.class.path下的路径。我们同样打印它的值。

System.out.println(System.getProperty("java.class.path"));

结果：

D:\workspace\ClassLoaderDemo\bin

这个路径其实就是当前java工程目录bin，里面存放的是编译生成的class文件。

好了，自此我们已经知道了BootstrapClassLoader、ExtClassLoader、AppClassLoader实际是查阅相应的环境属性sun.boot.class.path、java.ext.dirs和java.class.path来加载资源文件的。

接下来我们探讨它们的加载顺序，我们先用Eclipse建立一个java工程。
这里写图片描述
然后创建一个Test.java文件。

public class Test{}

然后，编写一个ClassLoaderTest.java文件。


public class ClassLoaderTest {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
	
		ClassLoader cl = Test.class.getClassLoader();
		
		System.out.println("ClassLoader is:"+cl.toString());
		
	}

}

我们获取到了Test.class文件的类加载器，然后打印出来。结果是：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93

也就是说明Test.class文件是由AppClassLoader加载的。

这个Test类是我们自己编写的，那么int.class或者是String.class的加载是由谁完成的呢？
我们可以在代码中尝试

public class ClassLoaderTest {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
	
		ClassLoader cl = Test.class.getClassLoader();
		
		System.out.println("ClassLoader is:"+cl.toString());
		
		cl = int.class.getClassLoader();
		
		System.out.println("ClassLoader is:"+cl.toString());
		
	}

}

运行一下，却报错了

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93
Exception in thread "main" java.lang.NullPointerException
	at ClassLoaderTest.main(ClassLoaderTest.java:15)

提示的是空指针，意思是int.class这类基础类没有类加载器加载？

当然不是！
int.class是由Bootstrap ClassLoader加载的。要想弄明白这些，我们首先得知道一个前提。

每个类加载器都有一个父加载器

每个类加载器都有一个父加载器，比如加载Test.class是由AppClassLoader完成，那么AppClassLoader也有一个父加载器，怎么样获取呢？很简单，通过getParent方法。比如代码可以这样编写：

ClassLoader cl = Test.class.getClassLoader();
		
System.out.println("ClassLoader is:"+cl.toString());
System.out.println("ClassLoader\'s parent is:"+cl.getParent().toString());

运行结果如下：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93
ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742

这个说明，AppClassLoader的父加载器是ExtClassLoader。那么ExtClassLoader的父加载器又是谁呢？

System.out.println("ClassLoader is:"+cl.toString());
System.out.println("ClassLoader\'s parent is:"+cl.getParent().toString());
System.out.println("ClassLoader\'s grand father is:"+cl.getParent().getParent().toString());

运行如果：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93
Exception in thread "main" ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742
java.lang.NullPointerException
	at ClassLoaderTest.main(ClassLoaderTest.java:13)

又是一个空指针异常，这表明ExtClassLoader也没有父加载器。那么，为什么标题又是每一个加载器都有一个父加载器呢？这不矛盾吗？为了解释这一点，我们还需要看下面的一个基础前提。

父加载器不是父类

我们先前已经粘贴了ExtClassLoader和AppClassLoader的代码。

static class ExtClassLoader extends URLClassLoader {}
static class AppClassLoader extends URLClassLoader {}

可以看见ExtClassLoader和AppClassLoader同样继承自URLClassLoader，但上面一小节代码中，为什么调用AppClassLoader的getParent()代码会得到ExtClassLoader的实例呢？先从URLClassLoader说起，这个类又是什么？
先上一张类的继承关系图
这里写图片描述

URLClassLoader的源码中并没有找到getParent()方法。这个方法在ClassLoader.java中。

public abstract class ClassLoader {

// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
private final ClassLoader parent;
// The class loader for the system
    // @GuardedBy("ClassLoader.class")
private static ClassLoader scl;

private ClassLoader(Void unused, ClassLoader parent) {
    this.parent = parent;
    ...
}
protected ClassLoader(ClassLoader parent) {
    this(checkCreateClassLoader(), parent);
}
protected ClassLoader() {
    this(checkCreateClassLoader(), getSystemClassLoader());
}
public final ClassLoader getParent() {
    if (parent == null)
        return null;
    return parent;
}
public static ClassLoader getSystemClassLoader() {
    initSystemClassLoader();
    if (scl == null) {
        return null;
    }
    return scl;
}

private static synchronized void initSystemClassLoader() {
    if (!sclSet) {
        if (scl != null)
            throw new IllegalStateException("recursive invocation");
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
        if (l != null) {
            Throwable oops = null;
            //通过Launcher获取ClassLoader
            scl = l.getClassLoader();
            try {
                scl = AccessController.doPrivileged(
                    new SystemClassLoaderAction(scl));
            } catch (PrivilegedActionException pae) {
                oops = pae.getCause();
                if (oops instanceof InvocationTargetException) {
                    oops = oops.getCause();
                }
            }
            if (oops != null) {
                if (oops instanceof Error) {
                    throw (Error) oops;
                } else {
                    // wrap the exception
                    throw new Error(oops);
                }
            }
        }
        sclSet = true;
    }
}
}

我们可以看到getParent()实际上返回的就是一个ClassLoader对象parent，parent的赋值是在ClassLoader对象的构造方法中，它有两个情况：

  1. 由外部类创建ClassLoader时直接指定一个ClassLoader为parent。
  2. 由getSystemClassLoader()方法生成，也就是在sun.misc.Laucher通过getClassLoader()获取，也就是AppClassLoader。直白的说，一个ClassLoader创建时如果没有指定parent，那么它的parent默认就是AppClassLoader。

我们主要研究的是ExtClassLoader与AppClassLoader的parent的来源，正好它们与Launcher类有关，我们上面已经粘贴过Launcher的部分代码。

public class Launcher {
    private static URLStreamHandlerFactory factory = new Factory();
    private static Launcher launcher = new Launcher();
    private static String bootClassPath =
        System.getProperty("sun.boot.class.path");

    public static Launcher getLauncher() {
        return launcher;
    }

    private ClassLoader loader;

    public Launcher() {
        // Create the extension class loader
        ClassLoader extcl;
        try {
            extcl = ExtClassLoader.getExtClassLoader();
        } catch (IOException e) {
            throw new InternalError(
                "Could not create extension class loader", e);
        }

        // Now create the class loader to use to launch the application
        try {
	    //将ExtClassLoader对象实例传递进去
            loader = AppClassLoader.getAppClassLoader(extcl);
        } catch (IOException e) {
            throw new InternalError(
                "Could not create application class loader", e);
        }

public ClassLoader getClassLoader() {
        return loader;
    }
static class ExtClassLoader extends URLClassLoader {

        /**
         * create an ExtClassLoader. The ExtClassLoader is created
         * within a context that limits which files it can read
         */
        public static ExtClassLoader getExtClassLoader() throws IOException
        {
            final File[] dirs = getExtDirs();

            try {
                // Prior implementations of this doPrivileged() block supplied
                // aa synthesized ACC via a call to the private method
                // ExtClassLoader.getContext().

                return AccessController.doPrivileged(
                    new PrivilegedExceptionAction<ExtClassLoader>() {
                        public ExtClassLoader run() throws IOException {
                            //ExtClassLoader在这里创建
                            return new ExtClassLoader(dirs);
                        }
                    });
            } catch (java.security.PrivilegedActionException e) {
                throw (IOException) e.getException();
            }
        }


        /*
         * Creates a new ExtClassLoader for the specified directories.
         */
        public ExtClassLoader(File[] dirs) throws IOException {
            super(getExtURLs(dirs), null, factory);
           
        }
        }
 }

我们需要注意的是

ClassLoader extcl;
        
extcl = ExtClassLoader.getExtClassLoader();

loader = AppClassLoader.getAppClassLoader(extcl);

代码已经说明了问题AppClassLoader的parent是一个ExtClassLoader实例。

ExtClassLoader并没有直接找到对parent的赋值。它调用了它的父类也就是URLClassLoder的构造方法并传递了3个参数。

public ExtClassLoader(File[] dirs) throws IOException {
            super(getExtURLs(dirs), null, factory);   
}

对应的代码

public  URLClassLoader(URL[] urls, ClassLoader parent,
                          URLStreamHandlerFactory factory) {
     super(parent);
}

答案已经很明了了，ExtClassLoader的parent为null。

上面张贴这么多代码也是为了说明AppClassLoader的parent是ExtClassLoader，ExtClassLoader的parent是null。这符合我们之前编写的测试代码。

不过，细心的同学发现，还是有疑问的我们只看到ExtClassLoader和AppClassLoader的创建，那么BootstrapClassLoader呢？

还有，ExtClassLoader的父加载器为null,但是Bootstrap CLassLoader却可以当成它的父加载器这又是为何呢？

我们继续往下进行。

Bootstrap ClassLoader是由C++编写的。

Bootstrap ClassLoader是由C/C++编写的，它本身是虚拟机的一部分，所以它并不是一个JAVA类，也就是无法在java代码中获取它的引用，JVM启动时通过Bootstrap类加载器加载rt.jar等核心jar包中的class文件，之前的int.class,String.class都是由它加载。然后呢，我们前面已经分析了，JVM初始化sun.misc.Launcher并创建Extension ClassLoader和AppClassLoader实例。并将ExtClassLoader设置为AppClassLoader的父加载器。Bootstrap没有父加载器，但是它却可以作用一个ClassLoader的父加载器。比如ExtClassLoader。这也可以解释之前通过ExtClassLoader的getParent方法获取为Null的现象。具体是什么原因，很快就知道答案了。

双亲委托

双亲委托。
我们终于来到了这一步了。
一个类加载器查找class和resource时，是通过“委托模式”进行的，它首先判断这个class是不是已经加载成功，如果没有的话它并不是自己进行查找，而是先通过父加载器，然后递归下去，直到Bootstrap ClassLoader，如果Bootstrap classloader找到了，直接返回，如果没有找到，则一级一级返回，最后到达自身去查找这些对象。这种机制就叫做双亲委托。
整个流程可以如下图所示：
这里写图片描述
这张图是用时序图画出来的，不过画出来的结果我却自己都觉得不理想。

大家可以看到2根箭头，蓝色的代表类加载器向上委托的方向，如果当前的类加载器没有查询到这个class对象已经加载就请求父加载器（不一定是父类）进行操作，然后以此类推。直到Bootstrap ClassLoader。如果Bootstrap ClassLoader也没有加载过此class实例，那么它就会从它指定的路径中去查找，如果查找成功则返回，如果没有查找成功则交给子类加载器，也就是ExtClassLoader,这样类似操作直到终点，也就是我上图中的红色箭头示例。
用序列描述一下：

  1. 一个AppClassLoader查找资源时，先看看缓存是否有，缓存有从缓存中获取，否则委托给父加载器。
  2. 递归，重复第1部的操作。
  3. 如果ExtClassLoader也没有加载过，则由Bootstrap ClassLoader出面，它首先查找缓存，如果没有找到的话，就去找自己的规定的路径下，也就是sun.mic.boot.class下面的路径。找到就返回，没有找到，让子加载器自己去找。
  4. Bootstrap ClassLoader如果没有查找成功，则ExtClassLoader自己在java.ext.dirs路径中去查找，查找成功就返回，查找不成功，再向下让子加载器找。
  5. ExtClassLoader查找不成功，AppClassLoader就自己查找，在java.class.path路径下查找。找到就返回。如果没有找到就让子类找，如果没有子类会怎么样？抛出各种异常。

上面的序列，详细说明了双亲委托的加载流程。我们可以发现委托是从下向上，然后具体查找过程却是自上至下。

我说过上面用时序图画的让自己不满意，现在用框图，最原始的方法再画一次。
这里写图片描述

上面已经详细介绍了加载过程，但具体为什么是这样加载，我们还需要了解几个个重要的方法loadClass()、findLoadedClass()、findClass()、defineClass()。

重要方法

loadClass()

JDK文档中是这样写的，通过指定的全限定类名加载class，它通过同名的loadClass(String,boolean)方法。

protected Class<?> loadClass(String name,
                             boolean resolve)
                      throws ClassNotFoundException

上面是方法原型，一般实现这个方法的步骤是

  1. 执行findLoadedClass(String)去检测这个class是不是已经加载过了。
  2. 执行父加载器的loadClass方法。如果父加载器为null，则jvm内置的加载器去替代，也就是Bootstrap ClassLoader。这也解释了ExtClassLoader的parent为null,但仍然说Bootstrap ClassLoader是它的父加载器。
  3. 如果向上委托父加载器没有加载成功，则通过findClass(String)查找。

如果class在上面的步骤中找到了，参数resolve又是true的话，那么loadClass()又会调用resolveClass(Class)这个方法来生成最终的Class对象。 我们可以从源代码看出这个步骤。

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) {
                    	//父加载器不为空则调用父加载器的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();
                    //父加载器没有找到，则调用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()
                resolveClass(c);
            }
            return c;
        }
    }

代码解释了双亲委托。

另外，要注意的是如果要编写一个classLoader的子类，也就是自定义一个classloader，建议覆盖findClass()方法，而不要直接改写loadClass()方法。
另外

if (parent != null) {
	//父加载器不为空则调用父加载器的loadClass
    c = parent.loadClass(name, false);
} else {
	//父加载器为空则调用Bootstrap Classloader
    c = findBootstrapClassOrNull(name);
}

前面说过ExtClassLoader的parent为null，所以它向上委托时，系统会为它指定Bootstrap ClassLoader。

自定义ClassLoader

不知道大家有没有发现，不管是Bootstrap ClassLoader还是ExtClassLoader等，这些类加载器都只是加载指定的目录下的jar包或者资源。如果在某种情况下，我们需要动态加载一些东西呢？比如从D盘某个文件夹加载一个class文件，或者从网络上下载class主内容然后再进行加载，这样可以吗？

如果要这样做的话，需要我们自定义一个classloader。

自定义步骤

  1. 编写一个类继承自ClassLoader抽象类。
  2. 复写它的findClass()方法。
  3. 在findClass()方法中调用defineClass()。

defineClass()

这个方法在编写自定义classloader的时候非常重要，它能将class二进制内容转换成Class对象，如果不符合要求的会抛出各种异常。

注意点：

**一个ClassLoader创建时如果没有指定parent，那么它的parent默认就是AppClassLoader。 **

上面说的是，如果自定义一个ClassLoader，默认的parent父加载器是AppClassLoader，因为这样就能够保证它能访问系统内置加载器加载成功的class文件。

自定义ClassLoader示例之DiskClassLoader。

假设我们需要一个自定义的classloader,默认加载路径为D:\lib下的jar包和资源。

我们写编写一个测试用的类文件，Test.java

Test.java
package com.frank.test;

public class Test {
	
	public void say(){
		System.out.println("Say Hello");
	}

}

然后将它编译过年class文件Test.class放到D:\lib这个路径下。

DiskClassLoader

我们编写DiskClassLoader的代码。

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


public class DiskClassLoader extends ClassLoader {
	
	private String mLibPath;
	
	public DiskClassLoader(String path) {
		// TODO Auto-generated constructor stub
		mLibPath = path;
	}

	@Override
	protected Class<?> findClass(String name) throws ClassNotFoundException {
		// TODO Auto-generated method stub
		
		String fileName = getFileName(name);
		
		File file = new File(mLibPath,fileName);
		
		try {
			FileInputStream is = new FileInputStream(file);
			
			ByteArrayOutputStream bos = new ByteArrayOutputStream();
			int len = 0;
	        try {
	            while ((len = is.read()) != -1) {
	            	bos.write(len);
	            }
	        } catch (IOException e) {
	            e.printStackTrace();
	        }
	        
	        byte[] data = bos.toByteArray();
	        is.close();
	        bos.close();
	        
	        return defineClass(name,data,0,data.length);
			
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
		return super.findClass(name);
	}

	//获取要加载 的class文件名
	private String getFileName(String name) {
		// TODO Auto-generated method stub
		int index = name.lastIndexOf('.');
		if(index == -1){ 
			return name+".class";
		}else{
			return name.substring(index+1)+".class";
		}
	}
	
}

我们在findClass()方法中定义了查找class的方法，然后数据通过defineClass()生成了Class对象。

测试

现在我们要编写测试代码。我们知道如果调用一个Test对象的say方法，它会输出"Say Hello"这条字符串。但现在是我们把Test.class放置在应用工程所有的目录之外，我们需要加载它，然后执行它的方法。具体效果如何呢？我们编写的DiskClassLoader能不能顺利完成任务呢？我们拭目以待。

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

public class ClassLoaderTest {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
	
		//创建自定义classloader对象。
		DiskClassLoader diskLoader = new DiskClassLoader("D:\\lib");
		try {
			//加载class文件
			Class c = diskLoader.loadClass("com.frank.test.Test");
			
			if(c != null){
				try {
					Object obj = c.newInstance();
					Method method = c.getDeclaredMethod("say",null);
					//通过反射调用Test类的say方法
					method.invoke(obj, null);
				} catch (InstantiationException | IllegalAccessException 
						| NoSuchMethodException
						| SecurityException | 
						IllegalArgumentException | 
						InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
	}

}

我们点击运行按钮，结果显示。

这里写图片描述

可以看到，Test类的say方法正确执行，也就是我们写的DiskClassLoader编写成功。

回首

讲了这么大的篇幅，自定义ClassLoader才姗姗来迟。 很多同学可能觉得前面有些啰嗦，但我按照自己的思路，我觉得还是有必要的。因为我是围绕一个关键字进行讲解的。

关键字是什么？

关键字 路径

  • 从开篇的环境变量
  • 到3个主要的JDK自带的类加载器
  • 到自定义的ClassLoader

它们的关联部分就是路径，也就是要加载的class或者是资源的路径。
BootStrap ClassLoader、ExtClassLoader、AppClassLoader都是加载指定路径下的jar包。如果我们要突破这种限制，实现自己某些特殊的需求，我们就得自定义ClassLoader，自已指定加载的路径，可以是磁盘、内存、网络或者其它。

所以，你说路径能不能成为它们的关键字？

当然上面的只是我个人的看法，可能不正确，但现阶段，这样有利于自己的学习理解。

自定义ClassLoader还能做什么？

突破了JDK系统内置加载路径的限制之后，我们就可以编写自定义ClassLoader，然后剩下的就叫给开发者你自己了。你可以按照自己的意愿进行业务的定制，将ClassLoader玩出花样来。

玩出花之Class解密类加载器

常见的用法是将Class文件按照某种加密手段进行加密，然后按照规则编写自定义的ClassLoader进行解密，这样我们就可以在程序中加载特定了类，并且这个类只能被我们自定义的加载器进行加载，提高了程序的安全性。

下面，我们编写代码。

1.定义加密解密协议

加密和解密的协议有很多种，具体怎么定看业务需要。在这里，为了便于演示，我简单地将加密解密定义为异或运算。当一个文件进行异或运算后，产生了加密文件，再进行一次异或后，就进行了解密。

2.编写加密工具类

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


public class FileUtils {
	
	public static void test(String path){
		File file = new File(path);
		try {
			FileInputStream fis = new FileInputStream(file);
			FileOutputStream fos = new FileOutputStream(path+"en");
			int b = 0;
			int b1 = 0;
			try {
				while((b = fis.read()) != -1){
					//每一个byte异或一个数字2
					fos.write(b ^ 2);
				}
				fos.close();
				fis.close();
			} catch (IOException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		} catch (FileNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}

}

我们再写测试代码

FileUtils.test("D:\\lib\\Test.class");

这里写图片描述
然后可以看见路径D:\\lib\\Test.class下Test.class生成了Test.classen文件。

编写自定义classloader，DeClassLoader

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;


public class DeClassLoader extends ClassLoader {
	
	private String mLibPath;
	
	public DeClassLoader(String path) {
		// TODO Auto-generated constructor stub
		mLibPath = path;
	}

	@Override
	protected Class<?> findClass(String name) throws ClassNotFoundException {
		// TODO Auto-generated method stub
		
		String fileName = getFileName(name);
		
		File file = new File(mLibPath,fileName);
		
		try {
			FileInputStream is = new FileInputStream(file);
			
			ByteArrayOutputStream bos = new ByteArrayOutputStream();
			int len = 0;
			byte b = 0;
	        try {
	            while ((len = is.read()) != -1) {
	            	//将数据异或一个数字2进行解密
	            	b = (byte) (len ^ 2);
	            	bos.write(b);
	            }
	        } catch (IOException e) {
	            e.printStackTrace();
	        }
	        
	        byte[] data = bos.toByteArray();
	        is.close();
	        bos.close();
	        
	        return defineClass(name,data,0,data.length);
			
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
		return super.findClass(name);
	}

	//获取要加载 的class文件名
	private String getFileName(String name) {
		// TODO Auto-generated method stub
		int index = name.lastIndexOf('.');
		if(index == -1){ 
			return name+".classen";
		}else{
			return name.substring(index+1)+".classen";
		}
	}
	
}

测试

我们可以在ClassLoaderTest.java中的main方法中如下编码：

DeClassLoader diskLoader = new DeClassLoader("D:\\lib");
		try {
			//加载class文件
			Class c = diskLoader.loadClass("com.frank.test.Test");
			
			if(c != null){
				try {
					Object obj = c.newInstance();
					Method method = c.getDeclaredMethod("say",null);
					//通过反射调用Test类的say方法
					method.invoke(obj, null);
				} catch (InstantiationException | IllegalAccessException 
						| NoSuchMethodException
						| SecurityException | 
						IllegalArgumentException | 
						InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

查看运行结果是：

这里写图片描述

可以看到了，同样成功了。现在，我们有两个自定义的ClassLoader:DiskClassLoader和DeClassLoader，我们可以尝试一下，看看DiskClassLoader能不能加载Test.classen文件也就是Test.class加密后的文件。

我们首先移除D:\\lib\\Test.class文件，只剩下一下Test.classen文件，然后进行代码的测试。

DeClassLoader diskLoader1 = new DeClassLoader("D:\\lib");
		try {
			//加载class文件
			Class c = diskLoader1.loadClass("com.frank.test.Test");
			
			if(c != null){
				try {
					Object obj = c.newInstance();
					Method method = c.getDeclaredMethod("say",null);
					//通过反射调用Test类的say方法
					method.invoke(obj, null);
				} catch (InstantiationException | IllegalAccessException 
						| NoSuchMethodException
						| SecurityException | 
						IllegalArgumentException | 
						InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
		DiskClassLoader diskLoader = new DiskClassLoader("D:\\lib");
		try {
			//加载class文件
			Class c = diskLoader.loadClass("com.frank.test.Test");
			
			if(c != null){
				try {
					Object obj = c.newInstance();
					Method method = c.getDeclaredMethod("say",null);
					//通过反射调用Test类的say方法
					method.invoke(obj, null);
				} catch (InstantiationException | IllegalAccessException 
						| NoSuchMethodException
						| SecurityException | 
						IllegalArgumentException | 
						InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
	}

运行结果：
这里写图片描述

我们可以看到。DeClassLoader运行正常，而DiskClassLoader却找不到Test.class的类,并且它也无法加载Test.classen文件。

Context ClassLoader 线程上下文类加载器

前面讲到过Bootstrap ClassLoader、ExtClassLoader、AppClassLoader，现在又出来这么一个类加载器，这是为什么？

前面三个之所以放在前面讲，是因为它们是真实存在的类，而且遵从”双亲委托“的机制。而ContextClassLoader其实只是一个概念。

查看Thread.java源码可以发现

public class Thread implements Runnable {

/* The context ClassLoader for this thread */
   private ClassLoader contextClassLoader;
   
   public void setContextClassLoader(ClassLoader cl) {
       SecurityManager sm = System.getSecurityManager();
       if (sm != null) {
           sm.checkPermission(new RuntimePermission("setContextClassLoader"));
       }
       contextClassLoader = cl;
   }

   public ClassLoader getContextClassLoader() {
       if (contextClassLoader == null)
           return null;
       SecurityManager sm = System.getSecurityManager();
       if (sm != null) {
           ClassLoader.checkClassLoaderPermission(contextClassLoader,
                                                  Reflection.getCallerClass());
       }
       return contextClassLoader;
   }
}

contextClassLoader只是一个成员变量，通过setContextClassLoader()方法设置，通过getContextClassLoader()设置。

每个Thread都有一个相关联的ClassLoader，默认是AppClassLoader。并且子线程默认使用父线程的ClassLoader除非子线程特别设置。

我们同样可以编写代码来加深理解。
现在有2个SpeakTest.class文件，一个源码是

package com.frank.test;

public class SpeakTest implements ISpeak {

	@Override
	public void speak() {
		// TODO Auto-generated method stub
		System.out.println("Test");
	}

}

它生成的SpeakTest.class文件放置在D:\\lib\\test目录下。
另外ISpeak.java代码

 package com.frank.test;

public interface ISpeak {
	public void speak();

}

然后，我们在这里还实现了一个SpeakTest.java

package com.frank.test;

public class SpeakTest implements ISpeak {

	@Override
	public void speak() {
		// TODO Auto-generated method stub
		System.out.println("I\' frank");
	}

}

它生成的SpeakTest.class文件放置在D:\\lib目录下。

然后我们还要编写另外一个ClassLoader，DiskClassLoader1.java这个ClassLoader的代码和DiskClassLoader.java代码一致，我们要在DiskClassLoader1中加载位置于D:\\lib\\test中的SpeakTest.class文件。

测试代码：

DiskClassLoader1 diskLoader1 = new DiskClassLoader1("D:\\lib\\test");
Class cls1 = null;
try {
//加载class文件
 cls1 = diskLoader1.loadClass("com.frank.test.SpeakTest");
System.out.println(cls1.getClassLoader().toString());
if(cls1 != null){
	try {
		Object obj = cls1.newInstance();
		//SpeakTest1 speak = (SpeakTest1) obj;
		//speak.speak();
		Method method = cls1.getDeclaredMethod("speak",null);
		//通过反射调用Test类的speak方法
		method.invoke(obj, null);
	} catch (InstantiationException | IllegalAccessException 
			| NoSuchMethodException
			| SecurityException | 
			IllegalArgumentException | 
			InvocationTargetException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
}
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
	
DiskClassLoader diskLoader = new DiskClassLoader("D:\\lib");
System.out.println("Thread "+Thread.currentThread().getName()+" classloader: "+Thread.currentThread().getContextClassLoader().toString());
new Thread(new Runnable() {
	
	@Override
	public void run() {
		System.out.println("Thread "+Thread.currentThread().getName()+" classloader: "+Thread.currentThread().getContextClassLoader().toString());
		
		// TODO Auto-generated method stub
		try {
			//加载class文件
		//	Thread.currentThread().setContextClassLoader(diskLoader);
			//Class c = diskLoader.loadClass("com.frank.test.SpeakTest");
			ClassLoader cl = Thread.currentThread().getContextClassLoader();
			Class c = cl.loadClass("com.frank.test.SpeakTest");
			// Class c = Class.forName("com.frank.test.SpeakTest");
			System.out.println(c.getClassLoader().toString());
			if(c != null){
				try {
					Object obj = c.newInstance();
					//SpeakTest1 speak = (SpeakTest1) obj;
					//speak.speak();
					Method method = c.getDeclaredMethod("speak",null);
					//通过反射调用Test类的say方法
					method.invoke(obj, null);
				} catch (InstantiationException | IllegalAccessException 
						| NoSuchMethodException
						| SecurityException | 
						IllegalArgumentException | 
						InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
}).start();

结果如下：
这里写图片描述

我们可以得到如下的信息：

  1. DiskClassLoader1加载成功了SpeakTest.class文件并执行成功。
  2. 子线程的ContextClassLoader是AppClassLoader。
  3. AppClassLoader加载不了父线程当中已经加载的SpeakTest.class内容。

我们修改一下代码，在子线程开头处加上这么一句内容。

Thread.currentThread().setContextClassLoader(diskLoader1);

结果如下：
这里写图片描述

可以看到子线程的ContextClassLoader变成了DiskClassLoader。

继续改动代码：

Thread.currentThread().setContextClassLoader(diskLoader);

结果：
这里写图片描述

可以看到DiskClassLoader1和DiskClassLoader分别加载了自己路径下的SpeakTest.class文件，并且它们的类名是一样的com.frank.test.SpeakTest，但是执行结果不一样，因为它们的实际内容不一样。

Context ClassLoader的运用时机

其实这个我也不是很清楚，我的主业是Android，研究ClassLoader也是为了更好的研究Android。网上的答案说是适应那些Web服务框架软件如Tomcat等。主要为了加载不同的APP，因为加载器不一样，同一份class文件加载后生成的类是不相等的。如果有同学想多了解更多的细节，请自行查阅相关资料。

总结

  1. ClassLoader用来加载class文件的。
  2. 系统内置的ClassLoader通过双亲委托来加载指定路径下的class和资源。
  3. 可以自定义ClassLoader一般覆盖findClass()方法。
  4. ContextClassLoader与线程相关，可以获取和设置，可以绕过双亲委托的机制。

下一步

  1. 你可以研究ClassLoader在Web容器内的应用了，如Tomcat。
  2. 可以尝试以这个为基础，继续学习Android中的ClassLoader机制。
  1. grepcode ClassLoader源码
  2. http://blog.csdn.net/xyang81/article/details/7292380
  3. http://blog.csdn.net/irelandken/article/details/7048817
  4. https://docs.oracle.com/javase/7/docs/api/java/net/URLClassLoader.html

一看你就懂，超详细java中的ClassLoader详解-CSDN博客

Class 文件在 Java 体系结构中的位置和作用

 

在上一篇博客中， 大致讲解了 Java 虚拟机的体系结构和执行原理。 本篇博客主要讲解能够被 JVM 识别， 加载并执行的 class 文件的格式。

 

对于理解 JVM 和深入理解 Java 语言， 学习并了解 class 文件的格式都是必须要掌握的功课。 原因很简单， JVM 不会理解我们写的 Java 源文件， 我们必须把 Java 源文件编译成 class 文件， 才能被 JVM 识别， 对于 JVM 而言， class 文件相当于一个接口， 理解了这个接口， 能帮助我们更好的理解 JVM 的行为；另一方面， class 文件以另一种方式重新描述了我们在源文件中要表达的意思， 理解 class 文件如何重新描述我们编写的源文件， 对于深入理解 Java 语言和语法都是很有帮助的。 另外， 不管是什么语言， 只要能编译成 class 文件， 都能被 JVM 识别并执行， 所以 class 文件不仅是跨平台的基础， 也是 JVM 跨语言的基础， 理解了 class 文件格式， 对于我们学习基于 JVM 的其他语言会有很大帮助。 

 

总之， 在整个 Java 技术体系结构中， class 文件处于中间的位置， 对于理解整个体系有着承上启下的作用。 如图所示：

 

Class 文件格式概述

 
class 文件是一种 8 位字节的二进制流文件， 各个数据项按顺序紧密的从前向后排列， 相邻的项之间没有间隙， 这样可以使得 class 文件非常紧凑， 体积轻巧， 可以被 JVM 快速的加载至内存， 并且占据较少的内存空间。 我们的 Java 源文件， 在被编译之后， 每个类（或者接口）都单独占据一个 class 文件， 并且类中的所有信息都会在 class 文件中有相应的描述， 由于 class 文件很灵活， 它甚至比 Java 源文件有着更强的描述能力。
 
class 文件中的信息是一项一项排列的， 每项数据都有它的固定长度， 有的占一个字节， 有的占两个字节， 还有的占四个字节或 8 个字节， 数据项的不同长度分别用 u1, u2, u4, u8 表示， 分别表示一种数据项在 class 文件中占据一个字节， 两个字节， 4 个字节和 8 个字节。 可以把 u1, u2, u3, u4 看做 class 文件数据项的 “类型” 。
 
class 文件中存在以下数据项 (该图表参考自《深入 Java 虚拟机》)：
 
类型 名称 数量
u4 magic 1
u2 minor_version 1
u2 major_version 1
u2 constant_pool_count 1
cp_info constant_pool constant_pool_count - 1
u2 access_flags 1
u2 this_class 1
u2 super_class 1
u2 interfaces_count 1
u2 interfaces interfaces_count
u2 fields_count 1
field_info fields fields_count
u2 methods_count 1
method_info methods methods_count
u2 attribute_count 1
attribute_info attributes attributes_count


下面对 class 文件中的每一项进行详细的解释。

 

class 文件中的魔数和版本号

 

（1） magic

在 class 文件开头的四个字节， 存放着 class 文件的魔数， 这个魔数是 class 文件的标志，他是一个固定的值： 0XCAFEBABE 。 也就是说他是判断一个文件是不是 class 格式的文件的标准， 如果开头四个字节不是 0XCAFEBABE， 那么就说明它不是 class 文件， 不能被 JVM 识别。

 

（2）minor_version 和 major_version

紧接着魔数的四个字节是 class 文件的此版本号和主版本号。 随着 Java 的发展， class 文件的格式也会做相应的变动。 版本号标志着 class 文件在什么时候， 加入或改变了哪些特性。 举例来说， 不同版本的 javac 编译器编译的 class 文件， 版本号可能不同， 而不同版本的 JVM 能识别的 class 文件的版本号也可能不同， 一般情况下， 高版本的 JVM 能识别低版本的 javac 编译器编译的 class 文件， 而低版本的 JVM 不能识别高版本的 javac 编译器编译的 class 文件。 如果使用低版本的 JVM 执行高版本的 class 文件， JVM 会抛出 java.lang.UnsupportedClassVersionError 。具体的版本号变迁这里不再讨论， 需要的读者自行查阅资料。 

 

class 文件中的常量池概述

 

在 class 文件中， 位于版本号后面的就是常量池相关的数据项。 常量池是 class 文件中的一项非常重要的数据。 常量池中存放了文字字符串， 常量值， 当前类的类名， 字段名， 方法名， 各个字段和方法的描述符， 对当前类的字段和方法的引用信息， 当前类中对其他类的引用信息等等。 常量池中几乎包含类中的所有信息的描述， class 文件中的很多其他部分都是对常量池中的数据项的引用，比如后面要讲到的 this_class, super_class, field_info, attribute_info 等， 另外字节码指令中也存在对常量池的引用， 这个对常量池的引用当做字节码指令的一个操作数。  此外， 常量池中各个项也会相互引用。

 

class 文件中的项 constant_pool_count 的值为 1, 说明每个类都只有一个常量池。 常量池中的数据也是一项一项的， 没有间隙的依次排放。常量池中各个数据项通过索引来访问， 有点类似与数组， 只不过常量池中的第一项的索引为 1, 而不为 0, 如果 class 文件中的其他地方引用了索引为 0 的常量池项， 就说明它不引用任何常量池项。class 文件中的每一种数据项都有自己的类型， 相同的道理，常量池中的每一种数据项也有自己的类型。 常量池中的数据项的类型如下表：

常量池中数据项类型 类型标志 类型描述
CONSTANT_Utf8 1 UTF-8 编码的 Unicode 字符串
CONSTANT_Integer 3 int 类型字面值
CONSTANT_Float 4 float 类型字面值
CONSTANT_Long 5 long 类型字面值
CONSTANT_Double 6 double 类型字面值
CONSTANT_Class 7 对一个类或接口的符号引用
CONSTANT_String 8 String 类型字面值
CONSTANT_Fieldref 9 对一个字段的符号引用
CONSTANT_Methodref 10 对一个类中声明的方法的符号引用
CONSTANT_InterfaceMethodref 11 对一个接口中声明的方法的符号引用
CONSTANT_NameAndType 12 对一个字段或方法的部分符号引用


每个数据项叫做一个 XXX_info 项， 比如， 一个常量池中一个 CONSTANT_Utf8 类型的项， 就是一个 CONSTANT_Utf8_info 。除此之外， 每个 info 项中都有一个标志值（tag）， 这个标志值表明了这个常量池中的 info 项的类型是什么， 从上面的表格中可以看出， 一个 CONSTANT_Utf8_info 中的 tag 值为 1， 而一个 CONSTANT_Fieldref_info 中的 tag 值为 9 。

Java 程序是动态链接的， 在动态链接的实现中， 常量池扮演者举足轻重的角色。 除了存放一些字面量之外， 常量池中还存放着以下几种符号引用：

（1） 类和接口的全限定名

（2） 字段的名称和描述符

（3） 方法的名称和描述符

在详细讲解常量池中的各个数据项之前， 我们有必要先了解一下 class 文件中的特殊字符串， 因为在常量池中， 特殊字符串大量的出现，这些特殊字符串就是上面说的全限定名和描述符。 要理解常量池中的各个数据项， 必须先了解这些特殊字符串。

 

对于 class 文件的讲解会在后续博文中继续， 欢迎关注。

 

posted @ 2024-06-25 14:40  CharyGao  阅读(28)  评论(0)  编辑  收藏  举报