摘自： 王法波 [email protected] <<How tomcat works>>翻译，第八章 类加载器
在每次创建一个Java类的实例时候，必须先将该类加载到内存中。Java虚拟机（JVM）使用类加载器来加载类。Java加载器在Java核心类库和CLASSPATH环境下面的所有类中查找类。如果需要的类找不到，会抛出java.lang.ClassNotFoundException异常。
从J2SE1.2开始，JVM使用了三种类加载器：bootstrap类加载器、extension类加载器和systen类加载器。这三个加载器是父子关系，其中bootstrap类加载器在顶端，而system加载器在结构的最底层。
其中bootstrap类加载器用于引导JVM，一旦调用java.exe程序，bootstrap类加载器就开始工作。因此，它必须使用本地代码实现，然后加载JVM需要的类到函数中。另外，它还负责加载所有的Java核心类，例如java.lang和java.io包。另外bootstrap类加载器还会查找核心类库如rt.jar、i18n.jar等，这些类库根据JVM和操作系统来查找。
extension类加载器负责加载标准扩展目录下面的类。这样就可以使得编写程序变得简单，只需把JAR文件拷贝到扩展目录下面即可，类加载器会自动的在下面查找。不同的供应商提供的扩展类库是不同的，Sun公司的JVM的标准扩展目录是/jdk/jre/lib/ext。
system加载器是默认的加载器，它在环境变量CLASSPATH目录下面查找相应的类。
这样，JVM使用哪个类加载器？答案在于委派模型(delegation model)，这是出于安全原因。每次一类需要加载，system马上加载类。相反，它委派该任务给它的父类-extension类加载器。extension类加载器也把任务委派给它的父类bootstrap类加载器。因此，bootstrap类加载器总是首先加载类。如果bootstrap类加载器不能找到所需要的类的extension类加载器会尝试加载类。如果扩展类加载器也失败，system类加载器将执行任务。如果系统类加载器找不到类，一个java.lang.ClassNotFoundException异常。为什么需要这样的往返模式？委派模型对于安全性是非常重要的。如你所知，可以使用安全管理器来限制访问某个目录。现在，恶意的意图有人能写出一类叫做java.lang.Object，可用于访问任何在硬盘上的目录。因为JVM的信任java.lang.Object类，它不会关注这方面的活动。因此，如果自定义java.lang.Object被允许加载的安全管理器将很容易瘫痪。幸运的是，这将不会发生，因为委派模型会阻止这种情况的发生。下面是它的工作原理。
当自定义java.lang.Object类在程序中被调用的时候，system类加载器将该请求委派给extension类加载器，然后委派给bootstrap类加载器。这样bootstrap类加载器先搜索的核心库，找到标准java.lang.Object并实例化它。这样，自定义java.lang.Object类永远不会被加载
关于在Java类加载机制的优势在于可以通过扩展java.lang.ClassLoader抽象类来扩展自己的类加载器。