类加载器
1.通过一个类的全限定名来获取描述该类的二进制字节流——类加载器
2.对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。比较两个类是否相等：必须由同一个类加载器加载。否则就是两个独立的类。
双亲委派模型
- 两类不同的类加载器：一种是启动类加载器——用C++语言实现、另外一种是其他所有的类加载器——用Java实现，独立于虚拟机外部，并且全部继承来自抽象类java.lang.ClassLoader
- 启动类加载器、扩展类加载器、应用程序类加载器。
工作过程：如果一个类加载器收到了类加载的请求，把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器，只有当父类加载器反馈自己无法完成这个加载请求，子类加载器才尝试加载。
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;
}
破坏双亲委派模型
第一次破坏：还没有引入双亲委派模型时，已经存在的类加载器，JDK1.2之后java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写自己的类加载逻辑时尽可能去重写这个方法，而不是在loadClass中编写代码。这样的修改保证写出来的类加载器是符合双亲委派规则的。
第二次破坏：例JNDI ,它的代码是由启动类加载器加载完成的，它存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI接口的代码，问题就是启动类加载器绝对不认识这些代码。线程上下文加载器：加载所需要的SPI服务代码，这是一种父类加载器去请求子类加载器完成加载的行为，这种行为实际上打通了双亲委派模型来逆向使用类加载器。JDK6时，以META-INF/services中的配置信息，辅以责任链模式，合理解决SPI加载。
第三次破坏：用户对程序动态性追求导致，代码热替换、模块热部署等。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）否则，类查找失败
上面的加载顺序，只有一二符合双亲委派模型，其余都是在平级的类加载器中进行的。-
模块化下的类加载器。
扩展类加载器被平台类加载器取代。
当平台及应用程序类加载器收到类加载请求，在委派给父类加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器加载完成。其中启动、平台、应用程序加载器各负责一些模块加载。
OSGI
- 在OSGi中Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖。
- OSGi类加载器之间只有规则，没有固定的委派关系，各个BUndle都是平级关系
- 例如：Bundle A：声明发布了packsgeA，依赖java.;
BundleB：声明依赖了packageA和packageC，同时也依赖了java.的包
BundleC：声明发布了packageC，依赖了packageA
用户对程序动态性追求导致，代码热替换、模块热部署等。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）否则，类查找失败
上面的加载顺序，只有一二符合双亲委派模型，其余都是在平级的类加载器中进行的。
