ClassLoader类加载器

  总的来讲，当动态加载一个资源时，至少有三种类加载器可供选择：

• 系统类加载器（也被称为应用类加载器）（system classloader）
• 当前类加载器（current classloader）
• 当前线程的上下文类加载器（ the current thread context classloader）

 那么这三种类加载器的使用场景分别是什么呢？

1、系统类加载器（也被称为应用类加载器）（system classloader）

  这个类加载器处理classpath环境变量所指定的路径下的类和资源，能够经过ClassLoader.getSystemClassLoader()方法以编程式访问。全部的ClassLoader.getSystemXXX()API方法也是经过这个类加载器访问。你们应该不多写代码来显式调用，而是以其它的类加载器委托给系统类加载器来代替。不然，当系统类加载器是JVM建立的最后一个类加载器时你的代码将只能工做在简单的命令行应用中。只要你把代码迁移到EJB，web应用，或Java Web Start应用中确定会出问题.

2、当前类加载器（current classloader）

  当前类加载器加载和定义当前方法所属的那个类。这个类加载器在你使用带单个参数的Class.forName()方法，Class.getResource()方法和类似方法时会在运行时类的连接过程当中被隐式调用。它也出如今像X.class语法的字母调用中。

3、当前线程的上下文类加载器（ 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

          http://my.oschina.net/huzorro/blog/96791

          http://tyrion.iteye.com/blog/1958814