类加载时机：
加载、验证、准备、解析、初始化、使用、卸载。
加载：通过一个类的全限定名来获取此类的二进制字节流。将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构。在内存中生成一个代表这个类的java.lang.class对象，作为方法区这个类的各种数据访问入口。
验证：1.文件格式验证 2.元数据验证 3.字节码验证 4.符号引用验证
准备：准备阶段是正式为类中定义的变量分配内存并设置类变量初始值的阶段。
解析：解析阶段是java虚拟机将常量池内符号引用替换为直接引用的过程。符号引用：符号引用是以一组符号来描述所引用的目标。符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。直接引用：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能直接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的。
初始化：在进行准备阶段的时候，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。初始化就是执行类构造器《clinit》方法的过程。clinit是javac编译器的自动生成物。
类加载器：对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。也就是比较两个类是否相等只有在这两个类是由同一个类加载器加载的前提下才有意义。
类加载器分为两种：一种是启动类加载器（Bootstrap ClassLoader）；另一种是其他所有的类加载器。从java开发人员的角度，java一直保持着三层类加载器、双亲委派的类加载架构。
三层类加载器：
1.启动类加载器（Bootstrap Class Loader），负责加载存放在java——home/lib目录。
2.扩展类加载器（Extension Class Loader），负责加载JAVA_Home\lib\ext目录中。jdk的开发团队允许用户将具有通用性的类库放置在ext目录下以扩展java SE的功能。
3.应用程序类加载器（application Class Loader），负责加载用户类路径classpath上所有的类库。
双亲委派模型：各种类加载器之间的层次关系被称为类加载的”双亲委派模型“。双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应有自己的父类加载器。不过这里的父子关系一般不是以继承的关系实现的，而是通常使用组合关系来复用父加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。
使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。比如object，无论那一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此object类在程序的各种类加载器环境中都能够保证是同一个类。反之如果自定义object且没有这个模型则会变的很混乱。
**双亲委派模型的实现：
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 首先，检查请求的类是否已经被加载过了 Class c = findLoadedClass(name); if (c == null) {
try {
if (parent != null) {
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; }
**先检查请求加载的类型是否加载过，若没有则调用父加载器的loadclass方法，若父加载器为空则默认使用启动类加载器作为父加载器。若父加载器加载失败，抛出classNoyFoundExecption异常的话，才调用自己的findClass方法尝试进行加载。
破坏双亲委派模式：1.在双亲委派模式之前，jdk1.2之前，使用protected方法的find class。如果父类加载失败，会自动调用自己的find class方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派模型规则的。
2.自身缺陷导致的，比如出现有基础类型要调用回用户的代码。比如JNDI服务。为了解决这样的问题，引入了线程上下文加载器（thread Context ClassLoader），如果创建线程时还未设置，它就会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
3.用户对于程序动态性的追求导致比如代码热替换、模块热部署。OSGi实现模块化热部署的关键就是它自定义了类加载器机制的实现。
OSGi的机制：
1)将以java.*开头的类，委派给父类加载器加载。
2)否则，将委派列表名单内的类，委派给父类加载器加载。
3)否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
4)否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5)否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6)否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7)否则，类查找失败。
