Java类加载器干嘛的_Java类加载器原理

ClassLoader介绍

类加载器是负责加载类的一个对象，ClassLoader是一个抽象类。最常见的加载策略是根据的类的全名，然后找到这个类的class文件，然后从文件读取这个类的数据加载到JVM。每个类都能通过getClassLoader方法获取加载这个类的类加载器。

数组类的类对象不是由类加载器创建的，而是根据Java运行时的需要自动创建的。 Class#getClassLoader()返回的数组类的类加载器与其元素类型的类加载器相同;如果元素类型是基本类型，则数组类没有类加载器。

应用程序可以继承 ClassLoader来自定义自己的累加器 ，以便扩展Java虚拟机动态加载类的方式。

类使用双亲委派模型来加载类，ClassLoader的每个实例都有一个父类加载器。当一个类加载加载类时，它会把这个类加载请求委派给它的父类加载器来加载。JVM的内置类加载器是"bootstrap class loader"”，它的parent为null，但可以作为ClassLoader实例的父级。

通常，Java虚拟机以与平台相关的方式从本地文件系统加载类。例如，在UNIX系统上，虚拟机从CLASSPATH环境变量定义的目录中加载类。 但是，某些类可能不是来自文件，它们可能来自其他来源，例如网络，或者它们可以由应用程序构建。方法defineClass(String，byte []，int，int)将字节数组转换为类Class的实例，也可以使用 Class＃newInstance创建此新定义的类的实例。

例如，应用程序可以创建网络类加载器以从服务器下载类文件。示例代码可能如下所示：

ClassLoader loader = new NetworkClassLoader(host,port);

Object main = loader.loadClass("Main", true).newInstance();

NetworkClassLoader必须实现 findClass方法来加载类,以及自定义加载动作通过loadClassData()方法从网络加载类。一旦下载了构成类的字节，它应该使用defineClass方法 来创建一个类实例。示例实现是：

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

*

* }

* }

findClass方法参数name要符合JVM定义的规范，以下这些都是合法的类名称：

1 "java.lang.String"

2 "javax.swing.JSpinner$DefaultEditor"

3 "java.security.KeyStore$Builder$FileBuilder$1"

4 "java.net.URLClassLoader$3$1"

何时出发类加载动作？

类加载的触发可以分为隐式加载和显示加载。

隐式加载

隐式加载包括以下几种情况：

遇到new、getstatic、putstatic、invokestatic这4条字节码指令时

对类进行反射调用时

当初始化一个类时，如果其父类还没有初始化，优先加载其父类并初始化

虚拟机启动时，需指定一个包含main函数的主类，优先加载并初始化这个主类

显示加载

显示加载包含以下几种情况：

通过ClassLoader的loadClass方法

通过Class.forName

通过ClassLoader的findClass方法

被加载的类存放在哪里？

JDK8之前会加载到内存中的方法区。

从JDK8到现在为止，会加载到元数据区。

都有哪些ClassLoader？

整个JVM平台提供三类ClassLoader。

Bootstrap ClassLoader

加载JVM自身工作需要的类，它由JVM自己实现。它会加载JAVA_HOME/jre/lib下的文件

ExtClassLoader

它是JVM的一部分，由sun.misc.Launcher.ExtClassLoader实现，他会加载JAVA_HOME/jre/lib/ext目录中的文件(或由System.getProperty("java.ext.dirs")所指定的文件)。

AppClassLoader

应用类加载器，我们工作中接触最多的也是这个类加载器，它由sun.misc.Launcher.AppClassLoader实现。它加载由System.getProperty("java.class.path")指定目录下的文件，也就是我们通常说的classpath路径。

双亲委派模型

双亲委派模型原理

从JDK1.2之后，类加载器引入了双亲委派模型，其模型图如下：

其中，两个用户自定义类加载器的父加载器是AppClassLoader，AppClassLoader的父加载器是ExtClassLoader，ExtClassLoader是没有父类加载器的，在代码中，ExtClassLoader的父类加载器为null。BootstrapClassLoader也并没有子类，因为他完全由JVM实现。

双亲委派模型的原理是：当一个类加载器接收到类加载请求时，首先会请求其父类加载器加载，每一层都是如此，当父类加载器无法找到这个类时(根据类的全限定名称)，子类加载器才会尝试自己去加载。

此模型解决的问题

为什么要使用双亲委派模型呢？它可以解决什么问题呢？

亲委派模型是JDK1.2之后引入的。根据双亲委派模型原理，可以试想，没有双亲委派模型时，如果用户自己写了一个全限定名为java.lang.Object的类，并用自己的类加载器去加载，同时BootstrapClassLoader加载了rt.jar包中的JDK本身的java.lang.Object，这样内存中就存在两份Object类了，此时就会出现很多问题，例如根据全限定名无法定位到具体的类。

有了双亲委派模型后，所有的类加载操作都会优先委派给父类加载器，这样一来，即使用户自定义了一个java.lang.Object，但由于BootstrapClassLoader已经检测到自己加载了这个类，用户自定义的类加载器就不会再重复加载了。

所以，双亲委派模型能够保证类在内存中的唯一性。

双亲委派模型实现原理

下面从源码的角度看一下双亲委派模型的实现。

JVM在加载一个class时会先调用classloader的loadClassInternal方法，该方法源码如下

// This method is invoked by the virtual machine to load a class.

private Class> loadClassInternal(String name)

throws ClassNotFoundException

{

// For backward compatibility, explicitly lock on 'this' when

// the current class loader is not parallel capable.

if (parallelLockMap == null) {

synchronized (this) {

return loadClass(name);

}

} else {

return loadClass(name);

}

}

该方法里面做的事儿就是调用了loadClass方法，loadClass方法的实现如下

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) {

c = parent.loadClass(name, false);

} else {

// 如果父类加载器为null，说明ExtClassLoader也没有找到目标类，则调用BootstrapClassLoader来查找

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

// ClassNotFoundException thrown if class not found

// from the non-null parent class loader

}

// 如果都没有找到，调用findClass方法，尝试自己加载这个类

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;

}

}

源码中已经给出了几个关键步骤的说明。

代码中调用BootstrapClassLoader的地方实际是调用的native方法。

由此可见，双亲委派模型实现的核心就是这个loadClass方法。

实现自己的类加载器

类加载器的作用

类加载器有啥作用呢？我们再回到上面的源码。

从上文我们知道JVM通过loadClass方法来查找类，所以，他的第一个作用也是最重要的：在指定的路径下查找class文件(各个类加载器的扫描路径在上文已经给出)。

然后，当父类加载器都说没有加载过目标类时，他会尝试自己加载目标类，这就调用了findClass方法，可以看一下findClass方法的定义：

protected Class> findClass(String name) throws ClassNotFoundException {

throw new ClassNotFoundException(name);

}

可以发现他要求返回一个Class对象实例，这里我通过一个实现类sun.rmi.rmic.iiop.ClassPathLoader来说明一下findClass都干了什么。

protected Class findClass(String var1) throws ClassNotFoundException {

// 从指定路径加载指定名称的class的字节流

byte[] var2 = this.loadClassData(var1);

// 通过ClassLoader的defineClass来创建class对象实例

return this.defineClass(var1, var2, 0, var2.length);

}

他做的事情在注释中已经给出，可以看到，最终是通过defineClass方法来实例化class对象的。

另外可以发现，class文件字节的获取和处理我们是可以控制的。所以，第二个作用：我们可以在字节流解析这一步做一些自定义的处理。 例如，加解密。

protected final Class> defineClass(String name, byte[] b, int off, int len)

throws ClassFormatError

{

return defineClass(name, b, off, len, null);

}

被final掉了，没办法覆写，所以这里看似不能做什么事儿了。

小结一下：

通过loadClass在指定的路径下查找文件。

通过findClass方法解析class字节流，并实例化class对象。

什么时候需要自己实现类加载器

当JDK提供的类加载器实现无法满足我们的需求时，才需要自己实现类加载器。

根据上述类加载器的作用，可能有以下几个场景需要自己实现类加载器

当需要在自定义的目录中查找class文件时(或网络获取)

class被类加载器加载前的加解密(代码加密领域)

如何实现自己的类加载器

接下来，实现一个在自定义class类路径中查找并加载class的自定义类加载器。

package com.lordx.sprintbootdemo.classloader;

import java.io.ByteArrayOutputStream;

import java.io.File;

import java.io.FileInputStream;

import java.io.InputStream;

/**

* 自定义ClassLoader

* 功能：可自定义class文件的扫描路径

* @author zhiminxu

*/

// 继承ClassLoader，获取基础功能

public class TestClassLoader extends ClassLoader {

// 自定义的class扫描路径

private String classPath;

public TestClassLoader(String classPath) {

this.classPath = classPath;

}

// 覆写ClassLoader的findClass方法

protected Class> findClass(String name) throws ClassNotFoundException {

// getDate方法会根据自定义的路径扫描class，并返回class的字节

byte[] classData = getDate(name);

if (classData == null) {

throw new ClassNotFoundException();

} else {

// 生成class实例

return defineClass(name, classData, 0, classData.length);

}

}

private byte[] getDate(String name) {

// 拼接目标class文件路径

String path = classPath + File.separatorChar + name.replace('.', File.separatorChar) + ".class";

try {

InputStream is = new FileInputStream(path);

ByteArrayOutputStream stream = new ByteArrayOutputStream();

byte[] buffer = new byte[2048];

int num = 0;

while ((num = is.read(buffer)) != -1) {

stream.write(buffer, 0 ,num);

}

return stream.toByteArray();

} catch (Exception e) {

e.printStackTrace();

}

return null;

}

}

使用自定义的类加载器

package com.lordx.sprintbootdemo.classloader;

public class MyClassLoader {

public static void main(String[] args) throws ClassNotFoundException {

// 自定义class类路径

String classPath = "/Users/zhiminxu/developer/classloader";

// 自定义的类加载器实现：TestClassLoader

TestClassLoader testClassLoader = new TestClassLoader(classPath);

// 通过自定义类加载器加载

Class> object = testClassLoader.loadClass("ClassLoaderTest");

// 这里的打印应该是我们自定义的类加载器：TestClassLoader

System.out.println(object.getClassLoader());

}

}

跟ClassLoader相关的几个异常

ClassNotFoundException

这个异常，相信大家经常遇到。

那么，到底啥原因导致抛出这个异常呢？

看一下ClassLoader的源码，在JVM调用loadClassInternal的方法中，就会抛出这个异常。

其声明如下：

// This method is invoked by the virtual machine to load a class.

private Class> loadClassInternal(String name)

throws ClassNotFoundException

{

// For backward compatibility, explicitly lock on 'this' when

// the current class loader is not parallel capable.

if (parallelLockMap == null) {

synchronized (this) {

return loadClass(name);

}

} else {

return loadClass(name);

}

}

这里面loadClass方法会抛出这个异常，再来看loadClass方法

public Class> loadClass(String name) throws ClassNotFoundException {

return loadClass(name, false);

}

调用了重写的loadClass方法

protected Class> loadClass(String name, boolean resolve)

throws ClassNotFoundException

{

synchronized (getClassLoadingLock(name)) {

// First, check if the class has already been loaded

// 查看findLoadedClass的声明，没有抛出这个异常

Class> c = findLoadedClass(name);

if (c == null) {

long t0 = System.nanoTime();

try {

if (parent != null) {

// 这里会抛，但同样是调loadClass方法，无需关注

c = parent.loadClass(name, false);

} else {

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

// catch住没有抛，因为要在下面尝试自己获取class

// 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;

}

}

再来看findClass方法

/**

* Finds the class with the specified binary name.

* This method should be overridden by class loader implementations that

* follow the delegation model for loading classes, and will be invoked by

* the {@link #loadClass loadClass} method after checking the

* parent class loader for the requested class. The default implementation

* throws a ClassNotFoundException.

*

* @param name

* The binary name of the class

*

* @return The resulting Class object

*

* @throws ClassNotFoundException

* If the class could not be found

*

* @since 1.2

*/

protected Class> findClass(String name) throws ClassNotFoundException {

throw new ClassNotFoundException(name);

}

果然这里抛出的，注释中抛出这个异常的原因是说：当这个class无法被找到时抛出。这也就是为什么在上面自定义的类加载器中，覆写findClass方法时，如果没有找到class要抛出这个异常的原因。

至此，这个异常抛出的原因就明确了：在双亲委派模型的所有相关类加载器中，目标类在每个类加载器的扫描路径中都不存在时，会抛出这个异常。

NoClassDefFoundError

这也是个经常会碰到的异常，而且不熟悉的同学可能经常搞不清楚什么时候抛出ClassNotFoundException，什么时候抛出NoClassDefFoundError。

我们还是到ClassLoader中搜一下这个异常，可以发现在defineClass方法中可能抛出这个异常，defineClass方法源码如下：

/**

* ... 忽略注释和参数以及返回值的说明，直接看异常声明

*

* @throws ClassFormatError

* If the data did not contain a valid class

*

* 在这里。由于NoClassDefFoundError是Error下的，所以不用显示throws

* @throws NoClassDefFoundError

* If name is not equal to the binary

* name of the class specified by b

*

* @throws IndexOutOfBoundsException

* If either off or len is negative, or if

* off+len is greater than b.length.

*

* @throws SecurityException

* If an attempt is made to add this class to a package that

* contains classes that were signed by a different set of

* certificates than this class, or if name begins with

* "java.".

*/

protected final Class> defineClass(String name, byte[] b, int off, int len,

ProtectionDomain protectionDomain)

throws ClassFormatError

{

protectionDomain = preDefineClass(name, protectionDomain);

String source = defineClassSourceLocation(protectionDomain);

Class> c = defineClass1(name, b, off, len, protectionDomain, source);

postDefineClass(c, protectionDomain);

return c;

}

继续追踪里面的方法，可以发现是preDefineClass方法抛出的，这个方法源码如下：

/* Determine protection domain, and check that:

- not define java.* class,

- signer of this class matches signers for the rest of the classes in

package.

*/

private ProtectionDomain preDefineClass(String name,

ProtectionDomain pd)

{

// 这里显示抛出，可发现是在目标类名校验不通过时抛出的

if (!checkName(name))

throw new NoClassDefFoundError("IllegalName: " + name);

// Note: Checking logic in java.lang.invoke.MemberName.checkForTypeAlias

// relies on the fact that spoofing is impossible if a class has a name

// of the form "java.*"

if ((name != null) && name.startsWith("java.")) {

throw new SecurityException

("Prohibited package name: " +

name.substring(0, name.lastIndexOf('.')));

}

if (pd == null) {

pd = defaultDomain;

}

if (name != null) checkCerts(name, pd.getCodeSource());

return pd;

}

这个校验的源码如下

// true if the name is null or has the potential to be a valid binary name

private boolean checkName(String name) {

if ((name == null) || (name.length() == 0))

return true;

if ((name.indexOf('/') != -1)

|| (!VM.allowArraySyntax() && (name.charAt(0) == '[')))

return false;

return true;

}

所以，这个异常抛出的原因是：类名校验未通过。

但这个异常其实不止在ClassLoader中抛出，其他地方，例如框架中，web容器中都有可能抛出，还要具体问题具体分析。

参考