类加载器，双亲委派模型，四次模型破坏

类加载器

1.通过一个类的全限定名来获取描述该类的二进制字节流——类加载器
2.对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。比较两个类是否相等：必须由同一个类加载器加载。否则就是两个独立的类。

双亲委派模型

1. 两类不同的类加载器：一种是启动类加载器——用C++语言实现、另外一种是其他所有的类加载器——用Java实现，独立于虚拟机外部，并且全部继承来自抽象类java.lang.ClassLoader
2. 启动类加载器、扩展类加载器、应用程序类加载器。

工作过程：如果一个类加载器收到了类加载的请求，把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器，只有当父类加载器反馈自己无法完成这个加载请求，子类加载器才尝试加载。

 protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{
        //首先检查请求的类是否已经被加载过了
        Class c = findLoadedClass(name);
        if(c == null){
            try {
                if (parent != null){
                //没有则调用父类加载器的loadCLass方法
                    c= parent.loadClass(name, false);
                } else{
                //若父类加载器为空则默认使用启动类加载器作为父加载器
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e){
                //如果父类加载器抛出CLassNotFoundException
                //说明父类加载器无法完成加载请求
            }
            if(c == null){
                //在父类加载器无法加载时
                //再调用本身的findClass方法来进行类加载
                c = findClass(name);
            }
        }
        if(resolve){
            resolveClass(c);
        }
        return c;
    }

破坏双亲委派模型

1. 第一次破坏：还没有引入双亲委派模型时，已经存在的类加载器，JDK1.2之后java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写自己的类加载逻辑时尽可能去重写这个方法，而不是在loadClass中编写代码。这样的修改保证写出来的类加载器是符合双亲委派规则的。

2. 第二次破坏：例JNDI ,它的代码是由启动类加载器加载完成的，它存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI接口的代码，问题就是启动类加载器绝对不认识这些代码。线程上下文加载器：加载所需要的SPI服务代码，这是一种父类加载器去请求子类加载器完成加载的行为，这种行为实际上打通了双亲委派模型来逆向使用类加载器。JDK6时，以META-INF/services中的配置信息，辅以责任链模式，合理解决SPI加载。

3. 第三次破坏：用户对程序动态性追求导致，代码热替换、模块热部署等。OSGI实现模块化热部署的关键是它自定义的类加载机制的实现，每一个Bundle都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码热替换。在OSGI环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求，OSGi将按照下面的顺序进行类搜索：
   1）将以java.*开头的类，委派给父类加载器加载
   2）否则，将委派给列表名单内的类，委派给父类加载器加载
   3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
   4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载
   5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
   6）否则，查找Dynamic Import列表中的Bundle，委派给对应Bundle的类加载器加载
   7）否则，类查找失败
   上面的加载顺序，只有一二符合双亲委派模型，其余都是在平级的类加载器中进行的。

4. 模块化下的类加载器。
   扩展类加载器被平台类加载器取代。
   当平台及应用程序类加载器收到类加载请求，在委派给父类加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器加载完成。其中启动、平台、应用程序加载器各负责一些模块加载。