JVM基础知识（六）-类加载机制和类加载器

        类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结构，那么负责将类加载到JVM内存空间的就是类加载器。

类的生命周期

        类的生命周期分为加载，验证，准备，解析，初始化，使用和销毁七个阶段，其中验证、准备、解析3 个部分统称为连接（Linking）。

       其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

      加载

        加载阶段虚拟机需要完成以下3 件事情：
        1）通过一个类的全限定名来获取定义此类的二进制字节流（可以是class文件，也可以是网络上的字节流）。
        2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
        3）在内存中生成一个代表这个类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

      验证

        是连接阶段的第一步，这一阶段的目的是为了确保Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害 虚拟机自身的安全。但从整体上看，验证阶段大致上会完成下面4 个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

      准备

       准备阶段是正式为类中定义的变量（被static 修饰的变量）分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。比如 private static int value = 123,在准备阶段value=0，在后续的初始化阶段才会赋值为123，如果value还同时被final修饰，则在准备阶段value=123.

      解析

        解析阶段是JVM 将常量池内的符号引用替换为直接引用的过程。

     初始化

       初始化主要是对一个class 中的static{}语句进行操作（对应字节码就是clinit 方法）。＜clinit＞（）方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成＜clinit＞（）方法。
       初始化阶段，虚拟机规范则是严格规定了有且只有6 种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

       1）遇到new、getstatic、putstatic 或invokestatic 这4 条字节码指令时，如果类没有初始化，则进行初始化，这四条指令的场景是：

             1.1 使用new 关键字实例化对象的时候。
             1.2 读取或设置一个类的静态字段（被final 修饰、已在编译期把结果放入常量池的静态字段除外）的时候
             1.3 调用一个类的静态方法的时候。

       2）使用java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

       3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

       4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

       5）当使用JDK 1.7 的动态语言支持时，如果一个java.lang.invoke.MethodHandle 实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

       6）当一个接口中定义了JDK1.8 新加入的默认方法（被default 关键字修饰的接口方法）时，如果这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

 

类加载器

类的加载是线程安全
虚拟机会保证一个类的＜clinit＞（）方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的＜clinit＞（）方法，其他线程都需要阻塞等待，直到活动线程执行＜clinit＞（）方法完毕。如果在一个类的＜clinit＞（）方法中有耗时很长的操作，就可能造成多个进程阻塞。所以类的初始化是线程安全的，项目中可以利用这点。
 

JDK 提供的三层类加载器

启动类加载器（Bootstrap ClassLoader）：JVM最顶级的加载器，负责加载java核心类库，例如 rt.jar,C++编写的。

扩展类加载器（Extention ClassLoader）：主要用于加载lib/ext 目录下的jar 包和.class 文件。

应用类加载器（Application ClassLoader）：一般用来加载classpath 下的其他所有jar 包和.class 文件，我们写的代码，会首先尝试使用这个类加载器进行加载。

自定义类加载器：我们自己实现的类加载器，可以打破双亲委派机制，或者实现一些其他功能。

 

双亲委派机制：双亲委派机制是当某个类加载器需要加载某个类文件时，它首先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，自己才会去加载这个类。优先级：启动类加载器>扩展类加载器>应用类加载器，那么这样的机制带来的好处就是核心的类能够保证全局唯一性，比如String类，用户自定义了一个String同名类，根据双亲委派机制，最后在启动类发现了JDK的String类，那么就不再加载用户自定义的String类，如果核心类还没有被加载就去加载核心类库中的String类，这样就保证了代码的健壮性。

双亲委派模型：

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

打破双亲委派：

Tomcat加载

其实Tomcat并没有真正意义上打破双亲委派机制，它的上层还是基于双亲委派机制的，只不过Tocmat自定义了WebAppClassLoader的加载器，对于一些需要加载的非基础类（WebRoot\lib路径下以及class中的类），WebAppClassLoader类加载器优先加载。等它加载不到的时候，再交给上层的ClassLoader 进行加载。这个加载器用来隔绝不同应用的.class 文件，比如你的两个应用，可能会依赖同一个第三方的不同版本，它们是相互没有影响的。

Tocmat加载顺序（保证公共类模块加载的前提下，加载不同容器内的类）

 

SPI机制（Service provider infterface服务提供接口）

是Java 提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

整体机制图如下：

Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制，核心思想就是解耦。

适用于：调用者根据实际使用需要，启用、扩展、或者替换框架的实现策略,比较常见的例子就是JDBC加载数据库驱动文件，mysql在META-INF/services 目录下，创建一个以接口全限定名为命名的文件（内容为实现类的全限定名）即可自动加载这一种实现，这就是SPI。主要使用java.util.ServiceLoader 类进行动态装载，它会去扫描META-INF/services中的配置信息，通过配置的全限定类名将实现类加载到jvm中。

像DriverManager 类和ServiceLoader 类以及Driver接口类都是rt.jar中的内容，是由启动类加载器加载的，但是数据库驱动实现却是业务代码，启动类加载器加载不了所以这里使用上下文加载器对driver的实现类进行加载，而通过代码跟踪，上下文类加载器就是一个当前线程的应用类加载器，所以这里就打破了双亲委派机制，本改由启动类加载器加载的实现类文件会交由应用类加载器去实现。

 

在实际面试中，可能前半部分的类加载顺序问的不多，但是关于双亲委派以及如何打破双亲委派被问到的概率还是很大的，打破双亲委派我们平常经常接触到的也就是tomcat类加载以及数据库驱动的SPI机制，还有一种目前基本不用OSGI，这东西有兴趣的可以去了解一下

 

参考：https://www.jianshu.com/p/46b42f7f593c