虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化、最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
一、类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存位置，整个生命周期包括7个阶段：加载 → 验证 → 准备 → 解析 → 初始化 → 使用 → 卸载。其中，验证、准备、解析3个部分统称为连接。
二、类加载的过程
1.加载
相对于类加载的其他阶段，一个非数组类的加载阶段（准确的说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，可以定义自己的类加载器去控制字节流的获取方式，即重写一个类加载器的loadClass()方法即可。
而数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。但数组类的元素类型最终是要靠类加载器去创建。
在加载阶段，虚拟机需要完成以下3件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构。
- 在内存中生成一个代表这个二类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，然后在内存中实例化一个java.lang.Class类的对象，这个对象作为程序访问方法区中的这些类型数据的外部接口。
2.验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
验证阶段是一个非常重要的、但不是一定必要的阶段。如果所运行的全部代码都已经被反复使用和验证过，则可以使用-Xverify:node参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
（1）文件格式验证
验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。主要目的是保证输入的字节流能正确地解析并存储于方法区之内，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，所以后面3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。
例如：是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围、常量池中的常量是否有不被支持的常量类型（检查tag标志）等。
（2）元数据验证
这一阶段时对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。
例如：这个类是否有父类（除了java.lang.Object之外，所有的类都应该由父类）、是否继承了不允许继承的类（被final修饰的类）、如果这个类不是抽象类，是否实现了其父类或接口中要去实现的所有方法、类中的字段、方法是否与父类产生矛盾等。
（3）字节码验证
字节码验证是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。上一阶段对元数据信息中的数据类型做完校验后，这一阶段将对类的方法体进行校验分析，以保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。
例如：保证任意时刻操作数栈的数据类型与指令代码都能配合工作、保证跳转指令不会跳转到方法体以外的字节码指令上等。
（4）符号引用验证
这一阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段-解析中发生。
符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验。目的是确保解析动作能正常执行。
例如：符号引用中通过字符串描述的全限定名是否能找到对应的类、在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段、符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可以被当前类访问等。
3.准备
准备阶段时是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
这个时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
例如，一个类变量的定义为public static int value = 123；
类变量value在没有被final修饰的情况下，在准备阶段过后的初始值为0而不是123，因为这时候尚未执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法中，所以把value赋值为123的动作将在初始化阶段才会执行。
例如，一个类变量的定义为public static final int value = 123；
类字段被final修饰的情况下，在编译时javac将会为value类字段的字段属性表中生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。
4.解析
解析阶段是虚拟机将常量池内的符号引用用替换为直接引用的过程。
符号引用存放在Class文件中的常量池表（constant_pool）中，常量池中主要存放两大类常量，字面量和符号引用。字面量接近于Java语言层面的常量概念，如文本字符串、声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括三类常量：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。
Java代码在进行javac编译的时候，并不像C和C++那样有“连接”这一步骤，而是在虚拟机加载Class文件的时候进行动态连接。也就是说，在Class文件中不会保存各个方法、字段的最终内存布局信息，因此这些字段、方法的符号引用不经过运行器转换的话无法得到真正的内存入口地址，也就是无法直接被虚拟机使用。当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析、翻译到具体的内存地址之中。
- 符号引用（Sysbolic References）: 符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用于虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
- 直接引用（Direct References）: 直接引用可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必行已经在内存中存在了。
例如：org.simple.People类引用了org.simple.Language类，然而在编译的时候，People类并不知道Language类的实际内存地址，因此只能用CONSTANT_CLASS_info这个表结构中的常量来记录。在类装载器装载People类的时候，可以通过虚拟机获取Language类的实际内存地址，因此便可以将表结构中的常量符号替换成实际的内存地址，也就是直接引用地址。
对同一个符号引用进行多次解析请求是很常见的事情，除invokedynamic指令以外，虚拟机实现可以对第一次解析的结果进行缓存，也就是在运行时常量池中记录直接引用，并把常量标识为已解析状态，从而避免解析动作重复进行。无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个符号引用之前已经被成功解析过，那么后续的解析请求就应当一直成功；同样的，如果第一次解析失败了，那么其他指令对这个符号的解析请求也应该收到同样的异常。
对于invokeDynamic指令，上面的规则不成立。必须等到程序实际运行到这条指令的时候，解析动作才能进行。相对的，其余可触发解析的指令都是“静态的”，可以在刚刚完成加载阶段，还没有开始执行代码就进行解析。
5.初始化
有且仅有5中情况必须立即对类进行“初始化”：
- 遇到new（使用new关键字实例化对象）、getstatic（读取一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外））、putstatic（设置一个类的静态字段）或invokestatic（调用一个类的静态方法）这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。
- 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化
- 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
- 当虚拟机启动时，用户需要制定一个要执行的主类（包含main方法的类）、虚拟机会先初始化这个主类
- 当使用动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为方法的句柄，并且这个方法句柄对应的类没有进行初始化时，需要先触发其初始化。
类初始化时类加载过程的最后一步。到了初始化阶段，才真正开始执行类中定义的Java程序代码（即字节码）。
在准备阶段，变量已经赋值过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源。
初始化阶段是执行类构造器<clinit>()方法的过程，例如public static int value = 123；把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法中，所以把value赋值为123的动作将在初始化阶段才会执行。
<clinit>()方法生成细节：
- <clinit>()方法是由编译器自动收集类中的所有类变量（被static修饰）的赋值动作和静态语句块（static{}）中的语句合并产生的。编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的语句块可以赋值，但是不能访问。例如：
public class Test { static int i = 1; static {
i = 0;
System.out.println(i);
} public static void main(String[] args) {
}
}
上面的代码可以正常访问，输入0 public class Test { static {
i = 0; // 不报错，给变量赋值可以正常编译通过
System.out.println(i); // 报错，提示"非法向前引用"
} static int i = 1; public static void main(String[] args) {
}
} 而上面的代码就不可以被访问，但是可可以被赋值静态语句块中只能访问到定义在静态语句块之前的变量
- 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
父类中定义的静态语句块要优先于子类的变量赋值操作
public class Test { static class parent{
public static int A = 1;
static {
A = 2;
}
} static class sub extends parent{
public static int B = A;
} public static void main(String[] args) {
System.out.println(sub.B);
}
}
输出：2，而不是1父类中定义的静态语句块要优先于子类的变量赋值操作
- <clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也就没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法
- 接口中不能使用静态语句块，但是仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
public class Test { static interface parent{
public static int A = 2;
}; static interface child extends parent{
public static int B = A;
} static class test implements child{
static int C = B;
} public static void main(String[] args) {
System.out.println(test.C);
}
}子接口不需要执行父接口的()方法，接口的实现类初始化时也不会执行接口的<clinit>()方法
- 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。并且其他线程在唤醒之后不会再次进入<clinit>()方法，即同一个类加载器，一个类只会初始化一次。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进行阻塞。
public class ThreadSafeTest { static class DeadLoopClass{
static {
if (true) {
System.out.println(Thread.currentThread() + "init DeadLoopClass");
}
}
} public static void main(String[] args) {
Runnable script = new Runnable() { @Override
public void run() {
// TODO Auto-generated method stub
System.out.println(Thread.currentThread() + "start");
DeadLoopClass deadLoopClass = new DeadLoopClass();
System.out.println(Thread.currentThread() + "run over");
}
};
Thread thread1 = new Thread(script);
Thread thread2 = new Thread(script);
thread1.start();
thread2.start();
}
}()方法的线程安全性
三、类加载器
类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称为“类加载器”。
1.类与类加载器
类加载器虽然值用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确定其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。
即比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”的含义包括：类的Class对象的equals()方法、isAssignableFrom()方法，isInstance()方法和instanceof关键字做对象所属关系判定等情况。
2.双亲委派模型
（1）三种类加载器
从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且都继承自抽象类java.lang.ClassLoader
从Java开发人员的角度讲，绝大部分Java程序都会使用到以下3种系统提供的类加载器：
- 启动类加载器（Bootstrap ClassLoader）：启动类加载器负责将存放在<JAVA_HOME>\lib目录中或者被-Xbootclasspath参数所指定的路径中，并且是虚拟机是别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
- 扩展类加载器（Extension ClassLoader）：扩展类加载器负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，扩展类加载器可以直接使用
- 应用程序类加载器（Application ClassLoader）：应用程序加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称为系统类加载器。负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
（2）双亲委派模型
Java应用程序都是由上面3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器的关系一般是：
启动类加载器
↑
扩展类加载器
↑
应用程序类加载器
↑ ↑
自定义类加载器 自定义类加载器
上面展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型（Parent Delegation Model）。双亲委派模型要求除了顶层的启动类加载器之外，其他的类加载器都应当有自己的父类加载器。类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都是用组合（Composition）关系来复用父加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型的一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，例如，用户自己编写一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也会变得一片混乱。实际情况是，可以正常编译，但是永远无法被加载运行。
双亲委派模型的实现：
// name表示类的二进制名称，reslve为true表示已经加载了这个类，return c表示要查找的类对象
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// 同步锁保证类加载是线程安全的
synchronized (getClassLoadingLock(name)) {
// 查找名称为name的已经被加载过的类，返回的结果是java.lang.Class类的实例
Class<?> c = findLoadedClass(name);
if (c == null) { // 如果该类没有被加载过
long t0 = System.nanoTime();
try {
if (parent != null) { // 当前加载器存在父类加载器
c = parent.loadClass(name, false); // 使用递归，调用委派的父类加载器执行该类的加载
} else { // 当前的加载器不存在父类加载器，即本身就是引导类加载器
c = findBootstrapClassOrNull(name); // 就委派给Bootstrap ClassLoader加载器进行类的加载
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) { // 如果所有的父类加载器都加载不了
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name); // 就调用自身的类加载器来执行加载 // this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) { // 如果确认该类已经被加载，resole为true，则直接链接到指定的类
resolveClass(c);
}
return c;
}
}
用户在自定义类加载器的时候通常需要继承java.lang.ClassLoader并重写下面的findClass(String name)方法，正如上面看到的，该方法会在loadClass(String name, boolean resolve)方法内的c = findClass(name);处进行调用。
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}根据实现代码总结一下ClassLoader加载类的原理：
（1）当一个ClassLoader是需要加载某个类时，即由ClassLoader类的实例对象去调用loadClass(String name, boolean resolve)方法，其中name是要加载的类的二进制名称。
（2）首先使用findLoadedClass(name)方法查看该类是否已经被当前类加载器加载过，如果该类没有被加载过，则使用它的父类对象parent执行loadClass方法继续寻找，如果应用程序类加载器、扩展类加载器都没有加载过该类，那么就委托给引导类加载器，由于引导类加载器没有父类，因此就调用自身的类加载方法findBootstrapClassOrNull方法查看引导类加载器中该类是否被加载过。
（3）如果引导类加载器通过findBootstrapClassOrNull方法得到没有引导类加载起没有加载过该类，则调用自身的findClass方法尝试加载该类，如果无法加载到则返回null；如果扩展类加载器的父类加载器即引导类加载器无法加载该类，即c=null，然后抛出ClassNotFoundException异常，则调用自身的findClass方法尝试加载该类，如果无法加载到则返回null；如果应用程序类加载器的父类加载器即扩展类加载器无法加载到该类，即c=null，然后抛出ClassNotFoundException异常，则调用自身的findClass方法尝试加载该类，如果无法加载到则返回null；如果自定义类加载器的父类无法加载即应用程序类加载器无法加载到该类，即c=null，然后抛出ClassNotFoundException异常，则调用用户继承了java.lang.ClassLoader后重写的findClass方法区加载该类。
（4）如果成功加载了该类，令resolve为true，并直接链接到要加载的类，然后返回要加载的类的实例对象；否则，返回null。
双亲委派模型的优点是：
（1）避免重复加载，当父类加载器已经加载了需要加载的类时，就没有必要再重新加载一遍。
（2）保证了Java类在程序的各种类加载器环境中都是同一个类，确保Java核心类库的类型安全，使得程序的运行环境更加安全。
（3）不仅可以通过Class文件实例化对象，还可以通过其他方式得到字节码，然后通过字节码流也可以实例化对象。
3.破坏双亲委派模型
（1）第一次“被破坏”：双亲委派模型在JDK 1.2之后才被引入，而类加载器和抽象类java.lang.ClassLoader则是在JDK 1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，在引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK 1.2之后的java.lang.ClassLoader添加了一个新的protected方法findClass()。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass()方法。JDK 1.2之后不提倡用户去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就保证新写出来的类加载器是符合双亲委派模型的。
（2）第二次“被破坏”：双亲委派模型很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载）。“基础”是因为它们总是作为被用户代码调用的API，但是，如果基础类又要调用回用户的代码，该如何解决。
例如：JNDI服务，它的代码由启动类加载器去加载（rt.jar），但是JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI，Service Provider Interface）的代码，但启动类加载器不可能“认识”ClassPath里的代码。
解决办法是：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoaser()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
线程上下文类加载器的作用是：JNDI服务使用这个加载器去加载所需要的SPI代码，也就是父类加载器（启动类加载器）请求子类加载器（应用程序类加载器）去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器。Java中所有涉及SPI的加载动作基本都采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。
（3）第三次“被破坏”是由于用户对程序动态性的追求而导致的，即希望应用程序能像计算机外设那样，不用重启机器就能立即使用。对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下模块化热部署就对企业级软件开发者具有很大的吸引力。也就是，如果想要替换一部分代码，如果做到不重启机器就可以使机器加载新的代码并运行。
OSGI（Open Service Gateway Initiative，即面向Java的动态模型系统）是公认的Java模块化标准。OSGI实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块（OSGI中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。
OSGi中的每个模块（Bundle）与普通的Java类库区别并不大，两者一般都以JAR格式进行封装，并且内部存储的都是Java Package和Class。但是一个Bundle可以声明它所依赖的Java Package（通过Import-Package描述），也可以声明它允许导出发布的Java Package（通过Export-Package描述）。在OSGi里面，Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖，而且类库的可见性能得到非常精确的控制，一个模块里只有被Export过的Package才可以由外界访问，其他的Package和Class将会隐藏起来。除了更精确的模块划分和可见性控制外，引入OSGi的另外一个重要理由是，基于OSGi的程序很可能可以实现模块级的热插拔功能，当程序升级更新或调试出错时，可以只停用、重新安装然后启用程序的其中一部分。
在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展成为更加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行搜索。
- 将以java.*开头的类委派给父类加载器
- 否则，将委派列表名单内的类委派给父类加载器加载
- 否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载
- 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载
- 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载
- 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载
- 否则，查找类失败。
上面的查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类加载器中进行的。
并非所有的应用都适合采用OSGi作为基础架构，OSGi在提供强大功能的同时，也引入了额外的复杂度，带来了线程死锁和内存泄漏的风险。
4.Tomcat：正统的类加载器架构
Tomcat作为主流的Java Web服务器，实现了自己定义的类加载器。
一个功能健全的Web服务器要解决下面的问题：
- 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离
- 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享。
- 服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。即服务器使用的类库与应用程序的类库相互独立。
- 应该支持JSP生成类的热替换。
Tomcat目录结构中，有3组目录（/common/*、/server/*、和/shared/*）可以存放Java类库，另外加上Web应用程序自身的“/WEB_INF/*”一共4组，
- 放置在/common目录中，类库可以被Tomcat和所有的Web应用程序共同使用（对应Common类加载器）
- 放置在/server目录中，类库可被Tomcat使用，对所有的Web应用程序都不可见（对应Catalina类加载器）
- 放置在/shared目录中，类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见（对应Shared类加载器）
- 放置在/WebApp/WEB-INF目录中，类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见（对应WebApp类加载器）
Tomcat服务器的类加载架构：
WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个Jsp文件对应一个Jsp类加载器。
启动类加载器
↑
扩展类加载器
↑
应用程序类加载器
↑
Common类加载器
↑ ↑
Catalina类加载器 Shared类加载器
↑ ↑
WebApp类加载器1 WebApp类加载器2
↑ ↑ ↑ ↑
Jsp类加载器1 Jsp类加载器2 Jsp类加载器1 Jsp类加载器2