类加载双亲委派机制

类加载核心流程

类加载的入口和初始化

类加载程序的入口是Launcher类。这一步的调用是由JVM的C++代码进行调用的。
通过Launcher的getClassLoader方法获取类加载器对象。

private ClassLoader loader;
public ClassLoader getClassLoader() {
    return this.loader;
}

这个loader对象是在Launcher类实例化的时候进行初始化的,是一个ApplicationClassLoader

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
     // 这个var1是一个ExtClassLoader（扩展类加载器）
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }

    try {
       // 可以看到这里这个loader对象就是一个AppClassLoader(应用程序类加载器)
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }

    Thread.currentThread().setContextClassLoader(this.loader);

}

注意var1这一个ExtClassLoader对象，上面在构建AppClassLoader的时候作为了入参

try {
    this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
    throw new InternalError("Could not create application class loader", var9);
}

我们一直跟代码，跟到最后会发现这个extClassLoader赋值给了一个parent属性

public abstract class ClassLoader {
    // The parent class loader for delegation
    // Note: VM hardcoded the offset of this field, thus all new fields
    // must be added *after* it.
    private final ClassLoader parent;
   private ClassLoader(Void unused, ClassLoader parent) {
        this.parent = parent;
        if (ParallelLoaders.isRegistered(this.getClass())) {
        ... ...
    }
}

我们可以生成出这两个类和ClassLoader的关系图

ApplicationClassLoader和ExtClassLoader都会继承ClassLoader类，所以也会继承这个属性。
从这里发现了AppClassLoader的parent属性是ExtClassLoader。
我们再回到Launcher类的构造方法，构造ExtClassLoader对象的那块。

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }
   ... ...
}

那么它的parent属性是什么呢？看super方法，第二个参数为null。

public ExtClassLoader(File[] var1) throws IOException {
    super(getExtURLs(var1), (ClassLoader)null, Launcher.factory);
    SharedSecrets.getJavaNetAccess().getURLClassPath(this).initLookupCache(this);
}

跟到super方法，发现了最后parent赋值是个null。

private ClassLoader(Void unused, ClassLoader parent) {
    this.parent = parent;
    ... ...
}

说到这里，就会发现如果抛开继承关系，只看parent属性的话，我们AppClassLoader的父亲是ExtClassLoader;
那这个ExtClassLoader的parent为什么为null，说好的双亲委派机制呢，怎么只有一个亲？
这个时候我们要看类加载的具体过程了。

向上委派查找是否加载过该类

入口方法就是loader.loadClass()方法，直接看最后一行。super.loadClass()

public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException {
    int var3 = var1.lastIndexOf(46);
    if (var3 != -1) {
       ... ...
    } else {
        return super.loadClass(var1, var2);
    }
}

直接点进去一直跟；
最后会进入由ClassLoader类实现的loadClass方法，这个方法就是双亲委派的核心方法。
可以看到第一步

First, check if the class has already been loaded

检查当前要加载的类是否已经加载过，如果已经加载过，则直接返回。
如果没有加载过，则进行加载。我们第一次进入肯定是没有加载过的，所以c为null。

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 (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

这样就会进入这个if里面。我们这里的parent属性就是ExtClassLoader对象。
因为在Launcher的构造方法中设置到了AppClassLoader的parent属性中了。

            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
            }

然后ExtClassLoader就会尝试去加载这个类。同样会进入到这个方法。
先检查是否加载过，加载过就返回，没加载过进行加载。
如果没加载过。c == null。

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

又会进入到这个if里面。和AppClassLoader几乎一样。
但是，有区别的是，我们看过了ExtClassLoader的parent属性是个null。
所以会进入到else里面。那么
findBootstrapClassOrNull(name);是什么呢？

         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
            }

我们跟到最后发现是个native本地方法。这个方法呢，就是传说中的引导类加载器。
由引导类加载器尝试去加载这个类。

// return null if not found
private native Class<?> findBootstrapClass(String name);

所以我们会发现，先由AppClassLoader去尝试加载，找不到就委托ExtClassLoader去加载
还找不到就会变相的委托Bootstrap去加载。

而为什么ExtClassLoader的parent为null。是因为我们的bootstrapClassLoader是由c++实现的，并不是我们java对象。
所以设计了这么个parent为null的逻辑进行调用。

这就是我们的类加载的双亲委派机制
中的一半，为什么是一半呢。因为只说完了向上委派查找的逻辑。而向下委派加载的逻辑还没说。

向下委派去加载该类

那我们的bootstrap会加载这个类嘛？并不会。
因为他只会加载自己jre/lib里面的核心类包,非这些类并不加载。
所以这个findBootstrapClass()方法的返回值是个空。
所以c依然为null,那我们回到loadClass()就会进入到如下的逻辑中。
他的核心加载逻辑就是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();
}

我们进入到findClass方法，会发现这是一个受保护的空方法。既然这样设计了，那说明具体的加载是有子类自己去实现的。

protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}

当前这个调用对象应该是ExtClassLoader.所以我们去找ExtClassLoader的findClass()；
然后会发现哎，为什么没有这个方法呢？
因为这个方法在父类URLClassLoader中实现的。（可以查看类继承图谱）

做的事情就是拿到class文件资源交给defineClass()方法去加载；
而我们的ExtClassLoader在加载我们自己的类时候会加载吗？并不会，后面讲。
所以这一步:res 为 null
Resource res = ucp.getResource(path, false);
直接return;

protected Class<?> findClass(final String name)
    throws ClassNotFoundException
{
    final Class<?> result;
    try {
        result = AccessController.doPrivileged(
            new PrivilegedExceptionAction<Class<?>>() {
                public Class<?> run() throws ClassNotFoundException {
                    // 这个方法就是把.替换成/追加一个.class
                    // name.dancer.Test => name/dancer/Test.class
                    String path = name.replace('.', '/').concat(".class");
                    Resource res = ucp.getResource(path, false);
                    if (res != null) {
                        try {
                            // 这个defineClass()就是我们加载类的具体执行者,最后是个native方法。
                            return defineClass(name, res);
                        } catch (IOException e) {
                            throw new ClassNotFoundException(name, e);
                        }
                    } else {
                        return null;
                    }
                }
            }, acc);
    } catch (java.security.PrivilegedActionException pae) {
        throw (ClassNotFoundException) pae.getException();
    }
    if (result == null) {
        throw new ClassNotFoundException(name);
    }
    return result;
}

让我们在回到loadClass()这个核心方法；
我们看一下这个loadClass()的时序图；

ext的这个方法return的是个null。按照时序图就会执行AppClassLoader的findClass();

synchronized (getClassLoadingLock(name)) {
     ... ...    
        if (c == null) {
            // If still not found, then invoke findClass in order
            // to find the class.
            long t1 = System.nanoTime();
            c = findClass(name);
       ... ...
        }
    }
    ... ...
    return c;
}

这里可能就会产生一个问题，每个类加载器加载目录是在哪里设置的呢？
答案是在初始化这个类加载对象的时候；
我们先看AppClassLoader；
在Launcher的构造方法中,调用的是getAppClassLoader(var1);

try {
    this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
    throw new InternalError("Could not create application class loader", var9);
}

我们看这个getAppClassLoader(var1);这个方法；
是从一个系统变量中获取的System.getProperty(“java.class.path”);
这个里面就包含了我们的~/target/classes，自己项目的类。当然也包含jdk的类路径。但是jdk的类路径对这个类加载器是无用的。因为有双亲委派机制。
jdk的类已经由父类加载过了。

public static ClassLoader getAppClassLoader(final ClassLoader var0) throws IOException {
    final String var1 = System.getProperty("java.class.path");
    final File[] var2 = var1 == null ? new File[0] : Launcher.getClassPath(var1);
    return (ClassLoader)AccessController.doPrivileged(new PrivilegedAction<Launcher.AppClassLoader>() {
        public Launcher.AppClassLoader run() {
            URL[] var1x = var1 == null ? new URL[0] : Launcher.pathToURLs(var2);
            return new Launcher.AppClassLoader(var1x, var0);
        }
    });
}

我们再看ExtClassLoader的构建过程,点进去

Launcher.ExtClassLoader var1;
try {
    var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
    throw new InternalError("Could not create extension class loader", var10);
}

我们看到了getExtClassLoader()这个方法中的createExtClassLoader()方法，创建instance的视乎

private static volatile Launcher.ExtClassLoader instance;

public static Launcher.ExtClassLoader getExtClassLoader() throws IOException {
    if (instance == null) {
        Class var0 = Launcher.ExtClassLoader.class;
        synchronized(Launcher.ExtClassLoader.class) {
            if (instance == null) {
                instance = createExtClassLoader();
            }
        }
    }

    return instance;
}

执行了一个
File[] var1 = Launcher.ExtClassLoader.getExtDirs();
点进去

private static Launcher.ExtClassLoader createExtClassLoader() throws IOException {
    try {
        return (Launcher.ExtClassLoader)AccessController.doPrivileged(new PrivilegedExceptionAction<Launcher.ExtClassLoader>() {
            public Launcher.ExtClassLoader run() throws IOException {
                File[] var1 = Launcher.ExtClassLoader.getExtDirs();
                int var2 = var1.length;

                for(int var3 = 0; var3 < var2; ++var3) {
                    MetaIndex.registerDirectory(var1[var3]);
                }

                return new Launcher.ExtClassLoader(var1);
            }
        });
    } catch (PrivilegedActionException var1) {
        throw (IOException)var1.getException();
    }
}

会发现加载的是
System.getProperty(“java.ext.dirs”);
这个系统变量。默认加载的就是jdk下的核心包。

private static File[] getExtDirs() {
    String var0 = System.getProperty("java.ext.dirs");
    File[] var1;
    if (var0 != null) {
        StringTokenizer var2 = new StringTokenizer(var0, File.pathSeparator);
        int var3 = var2.countTokens();
        var1 = new File[var3];

        for(int var4 = 0; var4 < var3; ++var4) {
            var1[var4] = new File(var2.nextToken());
        }
    } else {
        var1 = new File[0];
    }

    return var1;
}

至此，就是我们完成的类加载双亲委派机制。
为什么要设置双亲委派机制呢？就是为了防止我们jdk的核心class被用户恶意篡改。