前言

最近遇到一个类加载死锁的问题，于是梳理了一下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查找的就是这个数据结构，当一个类加载的时候，会将添加到这个数据结构中，同时也会把添加到这个数据结构中（但是这两个记录添加的时机不一样，最终导致了上面提到的Class.forName 和 ClassLoader.loadClass的差别，后面会详细介绍）。所以上面列举的输出“hello World”的例子中，只要第一次加载过之后，后面Appclassloader就不会再对同一个类进行双亲委派加载了，因为缓存中有了一条记录，findLoadedclass会直接返回已经加载的Class。

类加载过程

通过查看JVM源码，梳理了一下一个Class加载的大概流程（由于在加载一个类的过程中，会有加载、验证、准备、解析、初始化等过程，期间可能会触发一些相关类的加载，比如加载子类的过程中会加载父类等等，为了简化过程，在此图中没有描述这种关系）：

从图中可以看出，上面例子的问题，只有Class.forName才会在SystemDictionary中加入的记录，直接调用loadClass的话，只会把的记录加入到SystemDictionary中，所以，在初始类加载器中调用findloadedClass的时候返回null。

在调试过程中，还发现我们显示的声明或定义一个类的对象的时候，实际上jvm虚拟机最初调用的也是Class.forName0的native实现。所以在反射调用的尽量通过Class.forname的方式进行，这样能够保证初始类加载器和定义类加载器的缓存都生效，而ClassLoader.loadClass只会使定义类加载器缓存生效。