针对类加载器的分类与说明
一.类加载器的分类:
1.系统提供的类加载器
1.BootStarp(引导类加载器):负责加载java核心类库，不继承自ClassLoader加载器；
2.Extension(扩展类加载器)：负责加载java扩展库(例如sun公司专门为连接数据库设计的JDBC的一组API)
3.Application(系统类加载器): 负责加载普通用户编写的java应用类
备注:1.BootStrap加载器是由原生代码(C++)编写而成的，因此不继承自ClassLoader加载器，其他的类加载都必须继承自 ClassLoader加载器
2.以上三个加载器是从表面理念上来说是父子关系，但事实并非继承关系，而是组合的关系
2.自定义类加载器:必须继承自ClassLoader加载器
例如:Tomcat里面的web加载器
二.类加载器内部加载机制的分类:
1.J2SE：采用的是全盘委托机制（也称双亲委派机制）
机制:双亲委派机制
结构:.树状结构
备注:加载一个类的时候:自下而上检查，在上而下加载，双亲委派机制保证了核心库的类型安全
2.J2EE:
1.在Tomcat中 抛弃了双亲委派机制，而是自定义了web加载器，采用的也是代理模式，在加载一个类的时候:自下而上检查，自下而上加载
2.每个文本应用项目都对应自己独立的一个web类加载器
备注:同一个类被不同的类加载加载,JVM也认为是不同的类
三.由于java编程的设计思想是面向接口编程，
接口+实现
1.sun公司都是某个功能的设计者:SPI接口 sun公司自己设计的接口属于核心库，必须由BootStrap类加载器加载
2.其他公司才是这个功能的实现者:SPI实现类 实现公司写的实现类属于普通java应用类，必须由Application类加载加载
备注:由于双亲委派机制一般都设计为同一个类中所关联的其他类都要让当前类的加载器加载，所以和上面的这种设计理念又发生了冲突，所以提出了
线程上下文类加载器的概念，果断抛弃了双亲委派机制，让其同时加载接口和实现类
代码:Thread.currentThread().setClassLoader(自定义类加载器); 自定义加载器就可以随意改为自己的加载模式了
四.OSGI(Open Service Gateway Initative)面向java的动态模块的系统
OSGi旨在为实现Java程序的模块化编程提供基础条件，基于OSGi的程序很可能可以实现模块级的热插拔功能，当程序升级更新时，可以只停用、重新安装然后启动程序的其中一部分，这对企业级程序开发来说是非常具有诱惑力的特性。
OSGi描绘了一个很美好的模块化开发目标，而且定义了实现这个目标的所需要服务与架构，同时也有成熟的框架进行实现支持。但并非所有的应用都适合采用OSGi作为基础架构，它在提供强大功能同时，也引入了额外的复杂度，因为它不遵守了类加载的双亲委托模型。
原文地址：https://www.cnblogs.com/songanwei/p/9417277.html