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容器中都有可能抛出,还要具体问题具体分析。
参考