前言
最近遇到一个类加载死锁的问题，于是梳理了一下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只会使定义类加载器缓存生效。
