JVM 类加载机制以及双亲委派模型

类加载机制

类加载器
  JVM主张把类加载阶段”通过一个类的全限定名来获取此类的二进制字节流”这个动作放到JVM外部去实现，以便让应用程序决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

类与类加载器
  类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用却远远不限定于类加载阶段。对于任意一个类，都需要有加载它的类加载器和这个类本身一同确立其在JVM中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。即：比较两个类是否相等，只有这两个类有同一类加载器加载的前提下才有意义，否则即使这两个类源于统一class文件，同一个JVM加载，只要加载它们的类加载器不一样，这两个类就不相等。这里的相等，包括代表类的class对象的equals方法、isAssignableFrom方法、isInstance方法的返回结果；还有instanceof关键字的判定情况。

  类加载机制：虚拟机将描述类的数据从class文件加载到内存中，对加载的数据进行验证，解析，初始化，最后得到虚拟机认可后转化为直接可以使用的java类型的过程
  类加载机制一共有七个阶段：加载，验证，准备，解析，初始化，使用，卸载，其中：验证，准备，解析合称为连接阶段。

如何判断一个类是否加载？
在方法区是否存在该类的.class文件或者堆区是否有java.lang.Class对象

类加载时机
1、创建类的实例，也就是new一个对象
2、访问某个类或接口的静态变量，或者对该静态变量赋值
3、调用类的静态方法
4、反射（Class.forName(“com.lyj.load”)）
5、初始化一个类的子类（会首先初始化子类的父类）
6、JVM启动时标明的启动类，即文件名和类名相同的那个类

双亲委派模型

类加载器种类

  从Java虚拟机的角度，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分；另一种就是所有其他的类加载器，独立于虚拟机外部，并且全部继承自java.lang.ClassLoader。类加载器可以细分为：

• 启动（Bootstrap）类加载器：负责将 Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作
• 标准扩展（Extension）类加载器：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器
• 应用程序（Application）类加载器：是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。

除此之外，还有自定义的类加载器，它们之间的层次关系被称为类加载器的双亲委派模 。该模型要求除了顶层的启动类加载器外，其余的类加载器都应该有自己的父类加载器，而这种父子关系一般通过组合（Composition）关系来实现，而不是通过继承（Inheritance）。

双亲委派模型

双亲委派模型过程

  双亲委派模型的式作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完全这个加载请求时，子加载器才会尝试自己去加载。
  使用双亲委派模型的好处在于Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存在在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的Bootstrap ClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有双亲委派模型而是由各个类加载器自行加载的话，如果用户编写了一个java.lang.Object的同名类并放在ClassPath中，那系统中将会出现多个不同的Object类，程序将混乱。因此，如果开发者尝试编写一个与rt.jar类库中重名的Java类，可以正常编译，但是永远无法被加载运行。

双亲委派模型的系统实现

  在java.lang.ClassLoader的loadClass()方法中，先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
    //check the class has been loaded or not
    Class c = findLoadedClass(name);
    if(c == null){
        try{
            if(parent != null){
                c = parent.loadClass(name,false);
            }else{
                c = findBootstrapClassOrNull(name);
            }
        }catch(ClassNotFoundException e){
            //if throws the exception ,the father can not complete the load
        }
        if(c == null){
            c = findClass(name);
        }
    }
    if(resolve){
        resolveClass(c);
    }
    return c;
}

大多数的类加载器都遵循这个模型，但是JDK中也有较大规模破坏双亲模型的情况，例如线程上下文类加载器（Thread Context ClassLoader）的出现。

为什么需要双亲委派模型

（1）主要是为了安全性，避免用户自己编写的类动态替换 Java的一些核心类，比如 String。
（2）同时也避免了类的重复加载，防止内存中出现多份同样的字节码。使用委托机制，会递归的向父类查找，也就是首选用Bootstrap尝试加载，如果找不到再向下。就能在Bootstrap中找到然后加载，如果此时Bootstrap发现已经加载过了，那么直接返回内存中类即可而不需要重新加载，这样内存中就只有一份字节码了。

破坏双亲委派模型

  JNDI服务的代码有启动类加载器去加载，但JNDI的目的就是对资源进行集中管理和查找，它需要调用有独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码，单启动类加载器不可能“认识”这些代码。为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这个行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都是采用这种方式，例如：JNDI、JDBC、JCE、JAXB、和JBI等。