1. 概述

类加载器实际定义了类的namespace。

package java.lang;

public abstract class ClassLoader {
     public Class loadClass(String name);

     protected Class defineClass(byte[] b);

     public URL getResource(String name);

     public Enumeration getResources(String name);

     public ClassLoader getParent();//
}

2.类加载方式之当前类加载器和指定类加载器

类的加载只有两种加载方式，即当前类加载器加载（JVM自动行为，无法干预）和指定类加载器加载（自己指定类加载器进行加载）。

2.1 当前类加载器

class A{
   B b;
}

B的加载会使用A的类的类加载器进行加载，A的类加载器就是当前类加载器。这种类加载方式是JVM自动进行的，无法干预。

2.2 指定类加载器

代码指定类加载器进行加载

3. 类加载器分类：定义类加载器和初始类加载器

定义类加载器
类的真实加载器，即通过class.getClassLoader()获得的类加载器。
初始类加载器
类最先是由初始类加载器进行加载，初始类加载器并不一定是真正最后加载到类的加载器。

4. 各种类加载器

BootStarpClassLoader
Bootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加载%JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。
ExtClassLoader
Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrp loader.ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载%JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
AppClassLoader
系统类加载器，加载classpath下的类库。该类是Launcher类下的内部类(包访问权限)，所以无法new 一个系统类加载器
通过ClassLoader.getSystemClassLoader()能获得该加载器，该加载器是单例的。
类加载器是有父类加载器的，默认的父类加载器是系统类加载器
线程上下文类加载器
Main线程的上下文类加载器是系统类加载器，线程的默认上下文类加载器是父线程的上下文类加载器。

得到上下文类加载器
public ClassLoader getContextClassLoader()
设置上下文类加载器
public void setContextClassLoader(ClassLoader cl)
4.1 框架中一般怎么用上下文类记载器
试想：如果一个JNDI的提供方，或者JAXP的提供方，他们的SPI是通过bootstrap加载的，但是他们的实现类必须通过应用ClassLoader甚至是更下层的ClassLoader来加载。那么在其初始化的过程中，需要考虑如果获取到部署了SPI实现的ClassLoader，而给出的方案是使用ContextClassLoader。比如。在javax.xml.parsers.DocumentBuilderFactory中。

5. 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;
        }
    }

6. Class.forName和ClassLoader.loadClass过程

6.1 Class.forName

这里讨论的Class.forName是public static Class forName(String className) throws ClassNotFoundException
这里讨论的ClassLoader.loadClass是public Class loadClass(String name) throws ClassNotFoundException

Class.forName是根据给定的类型全名从当前类加载器中加载指定的类型。
实现代码：

    @CallerSensitive
    public static Class forName(String className)
                throws ClassNotFoundException {
        Class caller = Reflection.getCallerClass();
        return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
    }

Reflection.getCallerClass()，获取到调用Class.forName方法的类，隐含意义就是当前类加载器。加载的逻辑在native方法forName0中定义，也就是forName进行的类加载行为已经脱离了Java代码的控制范围，进入到了Java运行时环境把控的阶段。
以下是JDK实现的部分代码：
Class.c中对应的实现逻辑：

JNIEXPORT jclass JNICALL
Java_java_lang_Class_forName0(JNIEnv *env, jclass this, jstring classname,
                              jboolean initialize, jobject loader)
{
    // 略
    cls = JVM_FindClassFromClassLoader(env, clname, initialize,
                                       loader, JNI_FALSE);
 done:
    if (clname != buf) {
        free(clname);
    }
    return cls;
}

实现细节在JVM_FindClassFromClassLoader中定义，可以看到调用Class.forName会使用JVM_FindClassFromClassLoader这个函数来进行类型加载，我们需要注意的是clname和loader这两个变量，一个是类的全限定名，另一个是ClassLoader，而Class.forName所使用的ClassLoader是当前类加载器。
在jvm.cpp中FindClassFromClassLoader的对应实现是：

jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, jboolean init, Handle loader, Handle protection_domain, jboolean throwError, TRAPS) {
  // Security Note:
  //   The Java level wrapper will perform the necessary security check allowing
  //   us to pass the NULL as the initiating class loader.
  klassOop klass = SystemDictionary::resolve_or_fail(name, loader, protection_domain, throwError != 0, CHECK_NULL);
  // 略
}

SystemDictionary，系统字典，这个数据结构是保存Java加载类型的数据结构，如下图所示。

image.png

上图黑色边框中的内容就是SystemDictionary，它是以类的全限定名再加上类加载器作为key，进而确定Class引用。
当在代码中调用Class.forName(String name)或者由运行时Java进行类加载，比如：

          public void m() {
               B b = new B();
          }

对类型B的加载，就是运行时Java进行的类加载。
类型加载时，以ClassLoader和需要加载的类型全限定名作为参数在SystemDictionary中进行查询，如果能够查询到则返回。如果无法找到，则调用loader.loadClass(className)进行加载，这一步将进入到Java代码中。

对于loadClass而言，基本等同于loader.defineClass(loader.getResource(file).getBytes())，它做了两件事，

第一件，通过资源定位到类文件，
第二件，将类文件的字节流数组传递给defineClass进行构造Class实例。而defineClass将再一次派发给运行时Java进行执行。
字节流数组经过ClassFileParser进行处理之后，生成了Class实例，在返回Class实例前，Java将name、loader和class的对应关系添加到SystemDictionary中，这样在后续其他类型的加载过程中，就能够快速找到这些类型，避免无谓的defineClass过程。

一个类加载的过程，在运行时Java（JVM）和java代码之间来回切换，有点复杂，我们画一个简单的图来描述主要过程，由于原有的类加载过程中还要处理并发问题，我们将这些内容都去掉，只观察类型加载的主要流程，如下图所示。

image.png

调用Class.forName(className)方法，该方法会调用native的JVM实现，调用前该方法会确定准备好需要加载的类名以及ClassLoader，将其传递给native方法
进入到JVM实现后，首先会在SystemDictionary中根据类名和ClassLoader组成hash，进行查询，如果能够命中，则返回
如果加载到则返回
如果在SystemDictionary中无法命中，将会调用Java代码：ClassLoader.loadClass(类名)，这一步将委派给Java代码，让传递的ClassLoader进行类型加载
以URLClassLoader为例，ClassLoader确定了类文件的字节流，但是该字节流如何按照规范生成Class对象，这个过程在Java代码中是没有体现的，其实也就是要求调用ClassLoader.defineClass(byte[])进行解析类型，该方法将会再次调用native方法，因为字节流对应Class对象的规范是定义在JVM实现中的
进入JVM实现，调用SystemDictionary的resolve_stream方法，接受byte[]，使用ClassFileParser进行解析
SystemDictionary::define_instance_class
如果类型被加载了，将类名、ClassLoader和类型的实例引用添加到SystemDictionary中
返回
返回
从Java实现返回到Java代码的defineClass，返回Class对象
返回给loadClass(Classname)方法
返回给Java实现的SystemDictionary，因为在resolve_class中调用的ClassLoader.loadClass。这里会做出一个判断，如果加载Class的ClassLoader并非传递给resolve_class的ClassLoader，那么会将类名、传递给resolve_class的ClassLoader以及类型的实例引用添加到SystemDictionary中
返回给Class.forName类型实例

上述的过程比较复杂，但是简化理解一下它所做的工作，我们将SystemDictionary记作缓存，Class.forName或者说Java默认的类型加载过程是：*

首先根据ClassLoader，我们称之为initialClassLoader和类名查找缓存，如果缓存有，则返回；
如果缓存没有，则调用ClassLoader.loadClass(类名)，加载到类型后，保存<类名，真实加载类的ClassLoader，类型引用>到缓存，这里真实加载类的ClassLoader我们可以叫做defineClassLoader；
返回的类型在交给Java之前，将会判断defineClassLoader是否等于initialClassLoader，如果不等，则新增<类名，initialClassLoader，类型引用>到缓存。
这里区分initialClassLoader和defineClassLoader的原因在于，调用initialClassLoader的loadClass，可能最终委派给其他的ClassLoader进行了加载。

6.2 ClassLoader.loadClass(String className)

我们在分析了Class.forName之后，再看ClassLoader.loadClass()就会变得简单很多，这个ClassLoader就是一个指定类加载器，而ClassLoader.loadClass()只是相当于一个简单的方法调用。
根据上图所示，该过程开始于第4步，没有前3步，该过程简单说就是：调用ClassLoader.loadClass(类名)，加载到类型后，保存<类名，真实加载类的ClassLoader，类型引用>到缓存，这里真实加载类的ClassLoader我们可以叫做defineClassLoader。也就是，调用ClassLoader.loadClass(类名)之后，并不一定会在缓存中生成一条<类名，ClassLoader，类型引用>的记录，但是一定会生成一条<类名，真实加载类的ClassLoader，类型引用>的记录。（自己附注：实际上最少在JDK8之后loadClass也先到系统字典中查询是否已创建）

6.3 ClassLoader.findLoadedClass(String className)

该方法是protected final修饰的方法，也就是ClassLoader的子类可以内部使用，但是无法通过ClassLoader.findLoadedClass直接调用。
这个方法一直感觉很奇怪，从名称上看就是查询这个ClassLoader加载过的Class，如果加载过了，那么就返回类型实例。

7. 怎么创建一个类加载器

URLClassLoader基本能满足一些个性的类加载需求，如果还不满足，可以实现自己的类加载器。

extend ClassLoader
覆盖protected Class findClass(String name) throws ClassNotFoundException
在findClass中实现查找类字节码的逻辑，并调用protected final Class defineClass(String name, byte[] b, int off, int len)得到类。
注意设置父类加载器。
默认的父类加载器是系统类加载器，如果设置父类加载器为null，真实的父类加载器是启动类加载器。

上面步骤的类加载器符合双亲制加载规范。Override ClassLoader.loadClass实现了双亲制和缓存细节，不建议打破。

5. Class.getResource(String path)

path不以’/'开头时，默认是从此类所在的包下取资源；
path 以’/'开头时，则是从ClassPath根下获取；
TestMain.class.getResource("/") == t.getClass().getClassLoader().getResource("")

7. 各种错误

遇到类加载器问题时，可以尝试使用下面的表格进行问题排查。

类找不到	加载了不正确的类	多于一个类被加载
ClassNotFoundException NoClassDefFoundError	IncompatibleClassChangeError NoSuchMethodError NoSuchFieldError IllegalAccessError	ClassCastException LinkageError
IDE class lookup (Ctrl+Shift+T in Eclipse) 或者 find . -name "*.jar" -exec jar -tf {} ; \	grep DateUtils 使用middelware-detector	通过在启动参数中加 `-verbose:class`，观察加载的类来自哪个jar包使用middelware-detector

7.1 ClassNotFoundException 和NoClassDefFoundError的区别

sometimes error on static initializer block can also result in NoClassDefFoundError.

7.2 LinkageError

LinkageError 需要观察哪个类被不同的类加载器加载了，在哪个方法或者调用处发生（交汇）的，然后才能想解决方法，解决方法无外乎两种。

还是不同的类加载器加载，但是相互不再交汇影响，这里需要针对发生问题的地方做一些改动，比如更换实现方式，避免出现上述问题；
冲突的类需要由一个Parent类加载器进行加载。LinkageError 和ClassCastException 本质是一样的，加载自不同类加载器的类型，在同一个类的方法或者调用中出现，如果有转型操作那么就会抛 ClassCastException ，如果是直接的方法调用处的参数或者返回值解析，那么就会产生 LinkageError 。

JVM - ClassLoader