引子：
类加载器（classloader）是独立于虚拟机之外，可以独立实现的代码模块。
OSGi使用了类加载器的这一特点实现其热插拔的特性
Java同C++等语言不通，其连接操作不是在编译期间进行的，而是在程序运行期间进行的，这也就为java的动态扩展的语言特性提供了基础。
首先介绍下虚拟机的类加载机制：
类加载的时机：
类被从加载到虚拟机内存开始，到卸出内存为止，整个生命周期包括了以下七个过程：
加载 - 验证 - 准备 - 解析 - 初始化 - 使用 - 卸载
加载：
1. 通过一个类的全限定名获取定义此类的二进制流（决定了这个类的二进制流可以从zip包、jar包、计算时生成、网络甚至数据库中读取）
2. 将字节流代表的静态存储结构转化为方法区的运行时数据结构
3. 在java堆中生成一个代表该类的class对象
验证：
首先java编译器会对代码进行验证，不合要求的指令不会通过编译，但虚拟机因执行字节码，也需要对字节码进行验证。
不同的虚拟机实现对验证有着不同的定义
准备、解析、初始化
下面是类加载器：
类加载器在Java虚拟机外部去实现，以便让应用程序自己去获取所需要的类。
类加载器虽然只用于实现类的加载动作，但都需要类加载器和类本身来共同确认两个类是否相同，也就是说如果同一个class类被不同的类加载器加载，这两个类仍然是不同的
双亲委派模型：
从java虚拟机的角度来看，只有两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），该加载器由C++实现，是虚拟机的一部分
另外一种就是其他的类加载器，这些加载器由Java实现，独立于虚拟机外并且全部继承自抽象类java.lang.ClassLoader
如果更为细分，可以分为如下三种：
启动类加载器（BootStrap ClassLoader） 该类负责加载存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数制定的，并且是虚拟机识别（文件名唯一识别，否则不加载，即使放到了对应目录下）的类库加载到虚拟机内存中去，该启动类无法被Java程序直接引用。
扩展类加载器（Extension ClassLoader） 该加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的类库，可以直接使用
应用程序类加载器（Application ClassLoader） 由sun.misc.Lanucher$AppClassLoader实现，该加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称系统类加载器。负责加载用户路径（-classpath）上的类库，开发者可以直接使用该加载器，如果没有显示定义，一般情况下使用的就是该类加载器
下图为类加载器的双亲委派模型：
双亲委派模型除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类实现，该实现不是通过继承来实现的，而是通过组合来实现的，通过这样的层次关系，实现了类加载的优先级。
破坏双亲委派模型：
双亲委派模型并非强制性约束，而是java设计者推荐的类加载器实现模型。破坏双亲委派模型的两个典型是：
JDNI和OSGi
OSGi实现其热部署的关键是其自定义类加载器的实现，每个程序模块（Bundle）都有自己的一个实现，当需要替换bundle时，会将类加载器一同替换以实现热替换。OSGi中的类加载器已经不再具有双亲委派这种具有典型层次结构特征了，而是更加类似于网状结构。