疑惑
以前在看源码的时候，总是会遇到框架里的代码使用thread.currentthread.getcontextclassloader()获取当前线程的context类加载器，通过这个context类加载器去加载类。
我们平时在程序中写代码的时候，遇到要动态加载类的时候，一般使用class.forname()的方式加载我们需要的类。比如最常见的，当我们进行jdbc编程的时候，我们通过class.forname()去加载jdbc的驱动。
|
1
2
3
4
5
|
try { return class.forname("oracle.jdbc.driver.oracledriver");} catch (classnotfoundexception e) { // skip} |
那么为什么当我们使用class.forname()的方式去加载类的时候，如果类找不到，我们还要尝试用thread.currentthread.getcontextloader()获取的类加载器去加载类呢？比如我们可能会碰到下面这种代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
try { return class.forname(classname);} catch (classnotfoundexception e) { // skip}classloader ctxclassloader = thread.currentthread().getcontextclassloader();if (ctxclassloader != null) { try { clazz = ctxclassloader.loadclass(classname); } catch (classnotfoundexception e) { // skip }} |
这里加粗的部分，就是使用了thread.currentthread.getcontextloader()获取的加载器去加载类。显然，class.forname()加载类的时候使用的类加载器可能和thread.currentthread.getcontextloader()获取的类加载器是不同的。那么为什么会出现不同呢？
java的类加载器
要理解为什么会用到thread.currentthread.getcontextloader()获取的这个类加载器之前，我们先来了解下jvm里使用的类加载器（classloader）。
jvm默认有三种类加载器：
- bootstrap class loader
- extension class loader
- system class loader
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路径下的那些应用程序级别的类的。
下面的代码列举出了这三个类加载器：
|
1
2
3
4
5
6
7
|
public class mainclass { public static void main(string[] args) { system.out.println(integer.class.getclassloader()); system.out.println(logging.class.getclassloader()); system.out.println(mainclass.class.getclassloader()); }} |
其中获取bootstrap类加载器永远返回null值
|
1
2
3
|
null # bootstrap类加载器sun.misc.launcher$extclassloader@5e2de80c # extension类加载器sun.misc.launcher$appclassloader@18b4aac2 # system类加载器 |
双亲委派模型
上面介绍的三种类加载器，并不是孤立的，他们之间有一个层次关系：
三个类加载器之间通过这个层次关系协同工作，一起负责类的加载工作。上面的这种层次模型称为类加载器的“双亲委派”模型。双亲委派模型要求，除了最顶层的bootstrap类加载器之外，所有的类加载器都必须有一个parent加载器。当类加载器加载类的时候，首先检查缓存中是否有已经被加载的类。如果没有，则优先委托它的父加载器去加载这个类，父加载器执行和前面子加载器一样的工作，直到请求达到顶层的bootstrap类加载器。如果父加载器不能加载需要的类，那么这个时候才会让子加载器自己去尝试加载这个类。工作原理类似于下面这种方式：
我们可以通过jdk里classloader里面的代码一窥双亲委派机制的实现方式，代码实现在classloader.loadclass()里面
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
rotected class<?> loadclass(string name, boolean resolve) throws classnotfoundexception synchronized (getclassloadinglock(name)) { // first, check if the class has already been loaded class<?> c = findloadedclass(name); if (c == null) { long t0 = system.nanotime(); try { if (parent != null) { c = parent.loadclass(name, false); } else { c = findbootstrapclassornull(name); } } catch (classnotfoundexception e) { // classnotfoundexception thrown if class not found // from the non-null parent class loader } if (c == null) { // if still not found, then invoke findclass in order // to find the class. long t1 = system.nanotime(); c = findclass(name); // this is the defining class loader; record the stats sun.misc.perfcounter.getparentdelegationtime().addtime(t1 - t0); sun.misc.perfcounter.getfindclasstime().addelapsedtimefrom(t1); sun.misc.perfcounter.getfindclasses().increment(); } } if (resolve) { resolveclass(c); } return c; } |
采用双亲委派的方式组织类加载器，一个好处是为了安全。如果我们自己定义了一个string类，希望将这个string类替换掉默认java中的java.lang.string的实现。
我们将自己实现的string类的class文件放到classpath路径下，当我们使用类加载器去加载我们实现的string类的时候，首先，类加载器会将请求委托给父加载器，通过层层委派，最终由bootstrap类加载器加载rt.jar包里的string类型，然后一路返回给我们。在这个过程中，我们的类加载器忽略掉了我们放在classpath中自定义的string类。
如果没有采用双亲委派机制，那么system类加载器可以在classpath路径中找到string的class文件并加载到程序中，导致jdk中的string实现被覆盖。所以类加载器的这种工作方式，在一定程度上保证了java程序可以安全稳定的运行。
线程上下文类加载器
上面讲了那么多类加载器相关的内容，可还是没有讲到今天的主题，线程上下文类加载器。
到这里，我们已经知道java提供了三种类加载器，并且按照严格的双亲委派机制协同工作。表面上，似乎很完美，但正是这种严格的双亲委派机制导致在加载类的时候，存在一些局限性。
当我们更加基础的框架需要用到应用层面的类的时候，只有当这个类是在我们当前框架使用的类加载器可以加载的情况下我们才能用到这些类。换句话说，我们不能使用当前类加载器的子加载器加载的类。这个限制就是双亲委派机制导致的，因为类加载请求的委派是单向的。
虽然这种情况不多，但是还是会有这种需求。比较典型的，jndi服务。jndi提供了查询资源的接口，但是具体实现由不同的厂商实现。这个时候，jndi的代码是由jvm的bootstrap类加载器加载，但是具体的实现是用户提供的jdk之外的代码，所以只能由system类加载器或者其他用户自定义的类加载器去加载，在双亲委派的机制下，jndi获取不到jndi的spi的实现。
为了解决这个问题，引入了线程上下文类加载器。通过java.lang.thread类的setcontextclassloader()设置当前线程的上下文类加载器（如果没有设置，默认会从父线程中继承，如果程序没有设置过，则默认是system类加载器）。有了线程上下文类加载器，应用程序就可以通过java.lang.thread.setcontextclassloader()将应用程序使用的类加载器传递给使用更顶层类加载器的代码。比如上面的jndi服务，就可以利用这种方式获取到可以加载spi实现的类加载器，获取需要的spi实现类。
可以看到，引入线程类加载器实际是对双亲委派机制的破坏，但是却提供了类加载的灵活性。
解惑
回到开头，框架的代码为了加载框架之外用户实现的类，由于这些类可能没法通过框架使用的类加载器进行加载，为了绕过类加载器的双亲委派模型，采用thread.getcontextclassloader()的方式去加载这些类。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持服务器之家。
原文链接：http://www.cnblogs.com/duke2016/p/9164058.html
