前言
最近遇到一个类加载死锁的问题,于是梳理了一下Java的类加载机制,最终问题得到解决,也对Java的类加载有了更深的理解。
双亲委派
下图是Java类加载的双亲委派的结构图:
总结一句话就是,在进行类加载的时候优先请求父类加载器去加载,如果加载不到再到自己的环境路径中去加载。具体的逻辑在ClassLoader.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 {
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;
}
}
整体的加载逻辑很清晰,但是findLoadedClass()
引起了我的注意,按照注释的理解就是判断这个类有没有加载过。具体怎么判断一个类有没有加载过并没有说明,而且这个方法的最终实现的native
的,没法通过java源码直接查看。
findLoadedClass 逻辑验证
为了验证findLoadedClass的逻辑分别用Class.forName()
和 ClassLoader.loadClass()
加载类,然后再调用findLoadedClass()
方法看结果,具体代码如下:
ClassLoader loader = new ClassLoader(){};
loader.loadClass("java.util.ArrayList");
Method method = ClassLoader.class.getDeclaredMethod("findLoadedClass", String.class);
method.setAccessible(true);
System.out.println(method.invoke(loader,"java.util.ArrayList"));
输出 null
ClassLoader loader = new ClassLoader(){};
Class.forName("java.util.ArrayList",true,loader);
Method method = ClassLoader.class.getDeclaredMethod("findLoadedClass", String.class);
method.setAccessible(true);
System.out.println(method.invoke(loader,"java.util.ArrayList"));
输出 class java.util.ArrayList
两种加载方式,加载的类输出结果居然一样,在stackoverflow上提问,也没有得到很好的解释,无奈直接翻看java虚拟机规范,发现里面提到了这篇论文《Dynamic Class Loading in the JavaTM Virtual Machine》。其中提到了两个概念,初始类加载器(initiating classloader)和定义类加载器(defining classloader),定义类加载器就是最终加载这个类并调用defineclass方法的类加载器,例如,java.util.String的定义类加载器就是BootstrapClassLoader,因为java.util.String类在rt.jar中,这个jar是由BootstrapClassLoader加载的。初始类加载器就是发起这次类加载的第一个类加载器,比如我们简单的写一个输出“helloworld”程序,由于“helloworld”是字符串,必然会触发对String的加载,而发起这次加载的就是AppClassLoader,并最终由定义类加载器BootstrapClassLoader完成加载,AppClassLoader就是初始类加载器。文章的4.1章节提到,JVM会在内部维护一个缓存字典(SystemDictionary),其中classLoader和className作为key,class实例作为value,大体结构如下:
<classLoader,className> | class |
---|---|
<L1,A> | A.class |
<L2,B> | B.class |
实际上,findLoadedclass查找的就是这个数据结构,当一个类加载的时候,会将
类加载过程
通过查看JVM源码,梳理了一下一个Class加载的大概流程(由于在加载一个类的过程中,会有加载、验证、准备、解析、初始化等过程,期间可能会触发一些相关类的加载,比如加载子类的过程中会加载父类等等,为了简化过程,在此图中没有描述这种关系):
从图中可以看出,上面例子的问题,只有Class.forName才会在SystemDictionary中加入
在调试过程中,还发现我们显示的声明或定义一个类的对象的时候,实际上jvm虚拟机最初调用的也是Class.forName0的native实现。所以在反射调用的尽量通过Class.forname的方式进行,这样能够保证初始类加载器和定义类加载器的缓存都生效,而ClassLoader.loadClass只会使定义类加载器缓存生效。