1. 类加载流程

类加载机制其实就是虚拟机把Class文件加载到内存，并对数据进行校验，转换解析和初始化，形成可以虚拟机直接使用的Java类型，即java.lang.Class。

1.1 装载

Class文件 -- >二进制字节流 -->类加载器

1）通过一个类的全限定名获取这个类的二进制字节流

2）将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构

3）在java堆中生成一个代表这个类的java.lang.Class对象，做为我们方法区的数据访问入口

1.2 链接：

1）验证：保证我们加载的类的正确性

• 文件格式验证
• 元数据验证
• 字节码验证
• 符号引用验证

2）准备

为类的静态变量分配内存，并将其初始化为当前类型的默认值。

private static int a = 1 ； 那么他在准备这个阶段 a = 0；

3）解析

解析是从运行时常量池中的符号引用动态确定具体值的过程。

把类中的符号引用转换成直接引用

1.3 初始化

执行到Clinit方法，为静态变量赋值，初始化静态代码块，初始化当前类的父类

2. 类加载层次

3. 双亲委派机制图解及代码

3.1 图解

 3.2 代码说明

在类ClassLoader的核心代码中，通过调用 "Class<?> c = findLoadedClass(name);"这个方法判断是否存在，即是否被加载；如果为空，则获取父类加载器，继续循环调用，直至加载成功。

核心是：向上检查是否加载，向下委托加载

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

4. 双亲委派机制的出现原因 

双亲委派机制向上委派机制保证先加载JDK的核心类，再加载应用程序的类，有效防止了因为应用程序中因为某个类的存在一些不安全问题，导致JVM变得不安全。

向下委派机制保证需要加载的类，都得到了加载。

例子： 不管是在哪个jar包下的类最终都会委派给启动类加载器进行加载。比如我自定义

public class StringBuffer {
      public StringBuffer(){
      }
}

如果没有向下委派一直到启动类加载器，那StringBuffer就变成我这个了。安全性出来了。 如果在JVM存在包名和类名完全相同的两个类，这个类就无法被加载。

5. 破坏双亲委派机制

JAVA SPI机制（最常见的就是各种数据库的驱动实现类）：

SPI的全名为Service Provider Interface，主要是应用于厂商自定义组件或插件中。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java SPI机制的思想：我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块、xml解析模块、jdbc模块等方案。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。 SPI具体约定： Java SPI的具体约定为：当服务的提供者提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader。

以mysql-conneator-java-5.1.37Java包说明SPI机制:

以上截图展示了SPI使用的三要素：

1. 实现类的java包位置要放在主程序的classpath中；
2. 在实现类的jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
3. 主程序通过java.util.ServiceLoder动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；

这就引申出来我们对双亲委派机制的缺陷的讨论，接口：java.sql.Driver，定义在java.sql包中，包所在的位置是：jdk\jre\lib\rt.jar中，java.sql包中还提供了其它相应的类和接口比如管理驱动的类:DriverManager类，很明显java.sql包是由BootstrapClassloader加载器加载的；而接口的实现类com.mysql.jdbc.Driver是由第三方实现的类库，由AppClassLoader加载器进行加载的，我们的问题是DriverManager再获取链接的时候必然要加载到com.mysql.jdbc.Driver类，这就是由BootstrapClassloader加载的类使用了由AppClassLoader加载的类，很明显和双亲委托机制的原理相悖，那它是怎么解决这个问题的？这就引申了我们第二个问题：如何打破双亲委派机制？

首先看下手动获取数据库连接的代码：

// 加载Class到AppClassLoader（系统类加载器），然后注册驱动类
// Class.forName("com.mysql.jdbc.Driver").newInstance(); 
String url = "jdbc:mysql://localhost:3306/testdb";    
// 通过java库获取数据库连接
Connection conn = java.sql.DriverManager.getConnection(url, "name", "password"); 

我们很惊喜的发现：加载JDBC驱动程序实现的代码Class.forName("com.mysql.jdbc.Driver").newInstance();被注释掉，代码依然能够正常运行，这很奇怪, 继续查看DriverManager.getConnection(url,"name","password");重点就是DriverManager类的静态代码块，我们都是知道调用类的静态方法会初始化该类，然后执行该类静态代码块，DriverManager的静态代码块如下：

static {
       loadInitialDrivers();
       println("JDBC DriverManager initialized");
    }

继续查看 loadInitialDrivers();如下：

private static void loadInitialDrivers() {
        String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    //获取环境变量中jdbc.drivers的列表
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }
        // If the driver is packaged as a Service Provider, load it.
        // Get all the drivers through the classloader
        // exposed as a java.sql.Driver.class service.
        // ServiceLoader.load() replaces the sun.misc.Providers()
        //如果按照spi的约定在jar包中的META-INF/services设置了文件,将会加载为服务
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {

                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();

                /* Load these drivers, so that they can be instantiated.
                 * It may be the case that the driver class may not be there
                 * i.e. there may be a packaged driver with the service class
                 * as implementation of java.sql.Driver but the actual class
                 * may be missing. In that case a java.util.ServiceConfigurationError
                 * will be thrown at runtime by the VM trying to locate
                 * and load the service.
                 *
                 * Adding a try catch block to catch those runtime errors
                 * if driver not available in classpath but it's
                 * packaged as service and that service is there in classpath.
                 */
                try{
                    while(driversIterator.hasNext()) {
                        //依次加载所有驱动
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                // Do nothing
                }
                return null;
            }
        });

        println("DriverManager.initialize: jdbc.drivers = " + drivers);       
        //如果环境变量中没有设置的驱动程序,就可以结束了
        //否则就将环境变量中的驱动程序加载一下
        if (drivers == null || drivers.equals("")) {
            return;
        }
        String[] driversList = drivers.split(":");
        println("number of Drivers:" + driversList.length);
        for (String aDriver : driversList) {
            try {
                println("DriverManager.Initialize: loading " + aDriver);
                Class.forName(aDriver, true,
                        ClassLoader.getSystemClassLoader());
            } catch (Exception ex) {
                println("DriverManager.Initialize: load failed: " + ex);
            }
        }
    }
------------------------------------------------------------------------------------
 public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

对于以上源码有几点说明：

1. 我们前文提过JAVA SPI使用的扫描服务实现类的工具类是ServiceLoader，很凑巧我们在源码中发现了这个方法，这说明DriverManager.getConnection()方法在被调用的时候就已经从classpath中去加载由第三方实现的java.sql.Driver接口的实现类了。继续查看ServiceLoader.load(Driver.class);方法发现类加载器使用的是线程上下文类加载器，这是打破双亲委托机制的关键。
2. 按照loadedDrivers.iterator()->next()->nextService()调用连查看源码最终发现c = Class.forName(cn, false, loader);这个方法是文章开头的Class.forName()被注释掉但是文章仍然能够继续运行的关键。因为在DriverManager中的初始化代码中已经注册过了。但在这里我有一个疑问1：既然驱动类已经已经在ServiceLoader.load(Driver.class)方法中被加载过了，为什么在Class.forName(cn, false, loader);方法中注册驱动类的时候还要传递一个类加载器的参数，这样做由什么意义？但是我们可以大胆的推测loader一定不是启动类加载器，因为启动类加载器没法加载classpath下的类。
3. loadInitialDrivers()加载里两个位置的驱动程序(代码中已有注释)，环境变量中jdbc.drivers的列表和类路径下符合SPI规范的jar包，前者使用的是Class.forName(aDriver,true,ClassLoader.getSystemClassLoader());进行加载，而类加载器使用的是：ClassLoader.getSystemClassLoader();后者使用的是load(Driver.class)方法中的线程上下文类加载器。接下来我们看下ClassLoader.getSystemClassLoader();源码，按照ClassLoader.getSystemClassLoader()->initSystemClassLoader();>scl= l.getClassLoader()发现ClassLoader.getSystemClassLoader()的返回值是类Launcher的一个成员变量并且在Launcher的构造方法中进行初始化，最终的返回值是this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);应用类加载器(查看下方截图1处代码)，在这里我有一个疑问2：Class.forName(aDriver,true,ClassLoader.getSystemClassLoader())；这段代码所在类的类加载器是启动类加载器，但是代码中使用了应用类加载器，这样可以使用吗？如果可以那在启动类加载器加载的类中使用应用类的时候直接指定应用类加载器去加载就可以了，为什么还要使用线程上下文类加载器？

以上两个疑问后续解决，不影响我们对如何打破双亲委托机制的讨论，现在我们已经知道，在DriverManager中去加载SPI中配置的java.sql.Driver接口的实现类使用的是线程上下文类加载器。ContextClassLoader默认存放了AppClassLoader的引用(查看下方截图2处代码)，由于它是在运行时被放在了线程中，所以不管当前程序处于何处（BootstrapClassLoader或是ExtClassLoader等），在任何需要的时候都可以用Thread.currentThread().getContextClassLoader()取出应用程序类加载器来完成加载类的操作,简单来说：在BootstrapClassLoader或ExtClassLoader加载的类A中如果使用到AppClassLoader类加载器加载的类B，由于双亲委托机制不能向下委托，那可以在类A中通过线上线程上下文类加载器获得AppClassLoader，从而去加载类B，这不是委托，说白了这是作弊，也是JVM为了解决双亲委托机制的缺陷不得已的操作！

拓展：

简单介绍一下Class.forName();这个方法由两个作用：

1. 装载一个类并对其进行实例化
2. Class.forName();使用的类加载器默认是当前类加载器，但是可以为之传递一个加载器

源码如下：

public static Class<?> forName(String className)
                throws ClassNotFoundException {
        Class<?> caller = Reflection.getCallerClass();
        return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
    }
------------------------------------------------------------------------------------------
public static Class<?> forName(String name, boolean initialize,
                                   ClassLoader loader)
        throws ClassNotFoundException
    {
        Class<?> caller = null;
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            // Reflective call to get caller class is only needed if a security manager
            // is present.  Avoid the overhead of making this call otherwise.
            caller = Reflection.getCallerClass();
            if (sun.misc.VM.isSystemDomainLoader(loader)) {
                ClassLoader ccl = ClassLoader.getClassLoader(caller);
                if (!sun.misc.VM.isSystemDomainLoader(ccl)) {
                    sm.checkPermission(
                        SecurityConstants.GET_CLASSLOADER_PERMISSION);
                }
            }
        }
        return forName0(name, initialize, loader, caller);
    }

参考文章：

浅谈双亲委派机制的缺陷及打破双亲委派机制 - 知乎