Bootstrap Class Loader
Bootstrap Class Loader类加载器是JDK自带的一款类加载器，用于加载JDK内部的类。Bootstrap类加载器用于加载JDK中$JAVA_HOME/jre/lib下面的那些类，比如rt.jar包里面的类。Bootstrap类加载器是JVM的一部分，一般采用native代码编写。
Extension Class Loader
Extension Class Loader类加载器主要用于加载JDK扩展包里的类。一般$JAVA_HOME/lib/ext下面的包都是通过这个类加载器加载的，这个包下面的类基本上是以javax开头的。
System Class Loader
System Class Loader类加载器也叫应用程序类加载器(AppClassLoader)。顾名思义，这个类加载器就是用来加载开发人员自己平时写的应用代码的类的。System类加载器是用于加载存放在classpath路径下的那些应用程序级别的类的。
类加载器之间通过这个层次关系协同工作，一起负责类的加载工作。这种层次模型称为类加载器的“双亲委派”模型。双亲委派模型要求，除了最顶层的Bootstrap类加载器之外，所有的类加载器都必须有一个parent加载器。当类加载器加载类的时候，首先检查缓存中是否有已经被加载的类。如果没有，则优先委托它的父加载器去加载这个类，父加载器执行和前面子加载器一样的工作，直到请求达到顶层的Bootstrap类加载器。如果父加载器不能加载需要的类，那么这个时候才会让子加载器自己去尝试加载这个类。这样做的是因为防止加载到一些命令和lib中名字冲突的类。
线程上下文类加载器
上面讲了那么多类加载器相关的内容，可还是没有讲到今天的主题，线程上下文类加载器。
到这里，我们已经知道Java提供了三种类加载器，并且按照严格的双亲委派机制协同工作。表面上，似乎很完美，但正是这种严格的双亲委派机制导致在加载类的时候，存在一些局限性。
当我们更加基础的框架需要用到应用层面的类的时候，只有当这个类是在我们当前框架使用的类加载器可以加载的情况下我们才能用到这些类。换句话说，我们不能使用当前类加载器的子加载器加载的类。这个限制就是双亲委派机制导致的，因为类加载请求的委派是单向的。
虽然这种情况不多，但是还是会有这种需求。比较典型的，JNDI服务。JNDI提供了查询资源的接口，但是具体实现由不同的厂商实现。这个时候，JNDI的代码是由JVM的Bootstrap类加载器加载，但是具体的实现是用户提供的JDK之外的代码，所以只能由System类加载器或者其他用户自定义的类加载器去加载，在双亲委派的机制下，JNDI获取不到JNDI的SPI的实现。
为了解决这个问题，引入了线程上下文类加载器。通过java.lang.Thread类的setContextClassLoader()设置当前线程的上下文类加载器（如果没有设置，默认会从父线程中继承，如果程序没有设置过，则默认是System类加载器）。有了线程上下文类加载器，应用程序就可以通过java.lang.Thread.setContextClassLoader()将应用程序使用的类加载器传递给使用更顶层类加载器的代码。比如上面的JNDI服务，就可以利用这种方式获取到可以加载SPI实现的类加载器，获取需要的SPI实现类。
可以看到，引入线程类加载器实际是对双亲委派机制的破坏，但是却提供了类加载的灵活性。