线程上下文类加载器和SPI问题

1、SPI(Service privider interface)服务提供者接口；比如连接数据库的JDBC；Driver、Connect都是接口，具体的实现是由各个厂商完成的。
这样会出现一个问题，java.sql.Driver在核心库中，由 启动类加载器加载；而具体实现jar包放在classpth下，由系统加载器AppClassLoader加载，根据双亲委托机制，启动类加载器无法委托系统类加载器去加载SPI接口的实现类。而实际上，对于SPI接口来说，就是启动类加载器去委托上下文类加载器去加载实现类，这打破了双亲委托机制。
JDBC/JNDI都存在这个问题，而通过给当前线程设置上下文类加载器，由父加载器委托上下文类加载器来实现对于接口实现类的加载。

线程上下文类加载器的意义：
打破了双亲委托机制
双亲委派的委派方向是：
AppClassLoader -> ExtendClassLoader -> BootstrapClassLoader
而SPI的实现的加载反过来：
启动类加载器无法加载接口实现类(个厂商提供)，向下委派给上下文类加载器加载

当高层提供了同一的接口，同时高层加载底层时，就必须通过上下文类加载器来帮助高层ClassLoader找到并加载实现类。

默认的上下文类加载器都是系统类加载器AppClassLoader；这是在Launder构造方法中获得AppClassLoader后，调用Thread.CurrentThead().setContextClassLoader()设置的。所以jdbc的实现类也都是由系统类加载器加载的。

2、热部署原理：
在不重启服务器的情况下，修改class后立刻生效。就是热部署
如果要使修改后的class生效，则修改后的class就要被类加载器加载，如何才能使修改过的class被类加载器加载？
由于虚拟机中已经存在一个名称相同的类对象，修改后的类无法再次被加载；如果可以卸载该类，并重新加载修改后的类，问题就解决了。
热部署原理就是将该类的类加载器删除，然后再新创建一个类加载器实例去加载修改过的class文件