总的来说，当动态加载一个资源时，至少有三种类加载器可供选择：
- 系统类加载器（也被称为应用类加载器）（system classloader）
- 当前类加载器（current classloader）
- 当前线程的上下文类加载器（ the current thread context classloader）
那么这三种类加载器的使用场景分别是什么呢？
一、系统类加载器（也被称为应用类加载器）（system classloader）
这个类加载器处理classpath环境变量所指定的路径下的类和资源，可以通过ClassLoader.getSystemClassLoader()方法以编程式访问。所有的ClassLoader.getSystemXXX()API方法也是通过这个类加载器访问。大家应该很少写代码来显式调用，而是以其它的类加载器委托给系统类加载器来代替。否则，当系统类加载器是JVM创建的最后一个类加载器时你的代码将只能工作在简单的命令行应用中。只要你把代码迁移到EJB，web应用，或Java Web Start应用中肯定会出问题.
二、当前类加载器（current classloader）
当前类加载器加载和定义当前方法所属的那个类。这个类加载器在你使用带单个参数的Class.forName()方法，Class.getResource()方法和相似方法时会在运行时类的链接过程中被隐式调用。它也出现在像X.class语法的字母调用中。
三、当前线程的上下文类加载器（ the current thread context classloader）
线程上下文类加载器是在J2SE中被引进的。每一个线程分配一个上下文类加载器（除非线程由本地代码创建）。该加载器是通过Thread.setContextClassLoader()方法来设置。
如果你在线程构造后不调用这个方法，这个线程将会从它的父线程（这里的父线程是指执行创建新线程对象语句的线程）中继承上下文类加载器。如果你在整个应用中不做任何设置，所有线程将以系统类加载器作为它们自己的上下文加载器。重要的是明白自从Web和J2EE应用服务器为了像JNDI，线程池，组件热部署等特性而采用复杂的类加载器层次结构后，这（译者注：指整个应用中不做任何设置）是很少见的情况。
上下文类加载器提供了一个后门绕过在J2SE中介绍的类的加载委托机制。通常情况下，一个JVM中的所有类加载器被组织成一个层次结构，使得每一个类加载器（除了启动整个JVM的原始类加载器）都有一个父加载器。当被要求加载一个类时，每一个类加载器都将先委托父加载器来加载，只有父加载器都不能成功加载时当前类加载器才会加载。
有时这种加载顺序不能正常工作，通常发生在有些JVM核心代码必须动态加载由应用程序开发人员提供的资源时。以JNDI举例：它的核心内容（从J2SE1.3开始）在rt.jar中的引导类中实现了，但是这些JNDI核心类可能加载由独立厂商实现和部署在应用程序的classpath中的JNDI提供者。这个场景要求一个父类加载器（这个例子中的原始类加载器，即加载rt.jar的加载器）去加载一个在它的子类加载器（系统类加载器）中可见的类。此时通常的J2SE委托机制不能工作，解决办法是让JNDI核心类使用线程上下文加载器，从而有效建立一条与类加载器层次结构相反方向的“通道”达到正确的委托。
参考：http://blog.csdn.net/peter_k/article/details/1667685