之所以将线程上下文类加载器（Thread Context ClassLoader）单独拿出来写，确实是因为它涉及的东西比较多，既然带有线程两个字，一定也是非常重要的一个东西。

我们首先来回顾一下类加载器的双亲委派模型。

在上一章《虚拟机类加载机制（2）——类加载器》中我们解释了何为类加载器的“双亲委派模型”，知道了双亲委派模型给我们带了一个好处就是Java类随着它的类一起具备了一种带有优先级的层次关系。简单的例子就是Object类在程序的各种类加载环境中都会由启动类加载器来加载，换言之，它无论在什么环境中都是同一个Object类。但是有时候我们可能需要“打破”双亲委派模型。双亲委派模型让我们加载基础类的时候都是同一个基础类，但我们有时候可能需要在基础类中回调用户代码怎么办呢？“基础类中回调用户代码”可能不大好理解，我们列举一个例子来说明：Java提供了很多服务提供者接口（SPI，Service Provider Interface），允许独立厂商（第三方）为此提供实现。常见的SPI有：JNDI、JDBC、JAXP等。这些接口由Java的核心库来提供，所以问题就在于，SPI的接口是Java核心库的一部分，它们是由启动类加载器来加载的。SPI实现的Java类一般是由应用程序类加载器（Application ClassLoader）来加载的。启动类无法找到SPI的实现类，因为它只加载核心库（SPI的实现类由第三方提供）。它也不能代理给应用程序类加载器，因为它又是应用程序类加载器的父类，双亲委派模型又会将它交给启动类来加载。所以在这个时候我们就要“打破”这个“双亲委派模型”。

这个时候，线程上下文类加载器（Thread Context ClassLoader）很好地解决了这个问题。Thread类中有getContextClassLoader()和setContextClassLoader(ClassLoader cl)方法用来获取和设置上下文类加载器，如果没有setContextClassLoader(ClassLoader cl)方法通过设置类加载器，那么线程将继承父线程的上下文类加载器，如果在应用程序的全局范围内都没有设置的话，那么这个上下文类加载器默认就是应用程序类加载器（Application ClassLoader），换句话说Java默认的线程上下文类加载器就是应用程序类加载器(AppClassLoader)。通过线程上下文来加载第三方库jndi实现，而不依赖于双亲委派。大部分Java Application服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务（所以理解线程上下文类加载器，更能让我们理解Tomcat等服务器的实现原理、工作方式）。

虚拟机的这几个部分确实有难度，本人经验知识有限也在努力学习中，尚不能给出专业且详尽的分析，这里有一篇介绍上下文类加载的文章可以研读此文。http://blog.csdn.net/zhoudaxia/article/details/35897057

虚拟机类加载机制（3）——线程上下文类加载器