Thread.currentThread().getContextClassLoader().loadClass(className)和Class.forName(className)的区别

一、正文：

　　有去看开源框架的童鞋，应该会经常看到如下代码：Thread.currentThread().getContextClassLoader().loadClass(className)，那这个和Class.forName(className)有什么区别？

　　带着这个问题，笔者查了一些资料，现整理分享如下，如果不当之处还望斧正：

　　通常情况下，一个JVM中的所有类加载器被组织成一个层次结构，使得每一个类加载器（除了启动整个JVM的原始类加载器）都有一个父加载器。当被要求加载一个类时，每一个类加载器都将先委托父加载器来加载，只有父加载器都不能成功加载时当前类加载器才会加载（即“双亲委派”机制，想了解这方面知识的，请参见“深入探讨java类加载机制”）。在这种情况下，如下的委派链中：ClassLoader A -> System class loader -> Extension class loader -> Bootstrap class loader，委派链左边的ClassLoader就可以很自然的使用右边的ClassLoader所加载的类。但如果情况要反过来，是右边的ClassLoader所加载的代码需要反过来去找委派链靠左边的ClassLoader去加载东西怎么办呢？没辙，parent delegation是单向的，没办法反过来从右边找左边的~

　　那有没有这种逆向的加载场景呢？有！通常发生在有些JVM核心代码必须动态加载由应用程序开发人员提供的资源时。以JNDI举例：它的核心内容（从J2SE1.3开始）在rt.jar中的引导类中实现了，但是这些JNDI核心类可能加载由独立厂商实现和部署在应用程序的classpath中的JNDI提供者。这个场景要求一个父类加载器（这个例子中的原始类加载器，即加载rt.jar的加载器）去加载一个在它的子类加载器（系统类加载器）中可见的类。此时通常的J2SE委托机制不能工作，解决办法是让JNDI核心类使用线程上下文加载器，从而有效建立一条与类加载器层次结构相反方向的“通道”达到正确的委托。

　　知识补充：每一个线程分配一个上下文类加载器（除非线程由本地代码创建）。该加载器是通过Thread.setContextClassLoader()方法来设置。如果你在线程构造后不调用这个方法，这个线程将会从它的父线程中继承上下文类加载器。如果你在整个应用中不做任何设置，所有线程将以系统类加载器作为它们自己的上下文加载器

二、参考链接

http://hllvm.group.iteye.com/group/topic/38709

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