线程上下文类加载器
线程上下文类加载器
名词解释
SPI：Service Provider Interface 服务提供者接口
当前类加载器(Current ClassLoader)
每个类都会使用自己的类加载器（加载自身的类加载器）来去加载所依赖的类，如果ClassA引用了ClassB,NameClassA的类加载器就会加载ClassB（前提是ClassB没有被加载）
线程上下文类加载器(Context ClassLoader)
线程上下文类加载器是从jdk1.2开始引入的，类Thread中的getContextCLassLoader()与setContextClassLoader(ClassLoader classloader) 分别用来获取和设置上下文类加载器.如果没有通过用setContextClassLoader(ClassLoader classloader)进行设置的话，线程将继承其父线程的上下文类加载器。 Java应用运行时的初始线程的上下文加载器是系统类加载器，在线程中运行的代码可以通过该类加载器来加载类与资源 。这句话的解释就在launcher的源代码中
看一下Launcher类的源码：
public class Launcher {private static URLStreamHandlerFactory factory = new Launcher.Factory();private static Launcher launcher = new Launcher();private static String bootClassPath = System.getProperty("sun.boot.class.path");private ClassLoader loader;private static URLStreamHandler fileHandler;public static Launcher getLauncher() {return launcher;}public Launcher() {Launcher.ExtClassLoader var1;try {var1 = Launcher.ExtClassLoader.getExtClassLoader();} catch (IOException var10) {throw new InternalError("Could not create extension class loader", var10);}try {// 设置this.loader为系统类加载器this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);} catch (IOException var9) {throw new InternalError("Could not create application class loader", var9);}// 设置线程上下文类加载器是 this.loader（系统类加载器）.Thread.currentThread().setContextClassLoader(this.loader);String var2 = System.getProperty("java.security.manager");if (var2 != null) {SecurityManager var3 = null;if (!"".equals(var2) && !"default".equals(var2)) {try {var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();} catch (IllegalAccessException var5) {;} catch (InstantiationException var6) {;} catch (ClassNotFoundException var7) {;} catch (ClassCastException var8) {;}} else {var3 = new SecurityManager();}if (var3 == null) {throw new InternalError("Could not create SecurityManager: " + var2);}System.setSecurityManager(var3);}}public ClassLoader getClassLoader() {return this.loader;}
JVM双亲委托加载模型的问题
Java提供了很多的服务提供者接口（SPI），提供这些接口让第三方去实现这些接口，常见的SPI有： jdbc、JNDI、JAXP（解析XML）等。这些SPI接口是由Java核心类库提供的，而这些SPI的实现代码则是作为Java应用依赖的jar包被引入类的classpath下的，SPI接口中的代码经常需要加载具体的实现类。那么问题来了，SPI的接口是Java核心库的一部分，是由启动类加载器(Bootstrap Classloader)来加载的；SPI的实现类是由系统类加载器(System ClassLoader)来加载的。根据双亲委派类加载模型，父加载器(启动类加载器)加载的类无法访问子加载器（系统类加载器或者应用类加载器） 加载的类，所以就无法访问第三方的实现类，这是双亲委托模型的一个尴尬局面。
线程上下文类加载器的重要性
父ClassLoader可以使用当前线程Thread.currentThread().getContextClassLoader()所指定的classloader加载的类。
这就改变了父ClassLoader不能使用子ClassLoader或是其他没有直接父子关系的CLassLoader加载的类的情况，即改变了双亲委托模型。
通过JDBC看线程上下文类加载器
//举例说明jdbc获取mysql的连接
Driver driver = Class.forName("com.mysql.jdc.Driver");
Connection conn = driver.getConnection(url,username,password);
// 这是一段伪代码 我们主要看的是Class.forName()
看一下Class.forName()的源码
public static Class<?> forName(String className)throws ClassNotFoundException {Class<?> caller = Reflection.getCallerClass();// className：要加载的Class名字 | 是否初始化：此处需要初始化 |调用者的类加载器 | 调用者的Class对象return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
}
public static Class<?> forName(String name, boolean initialize,ClassLoader loader)throws ClassNotFoundException{Class<?> caller = null;SecurityManager sm = System.getSecurityManager();if (sm != null) {// Reflective call to get caller class is only needed if a security manager// is present. Avoid the overhead of making this call otherwise.//获取调用此forName方法的类的Class对象Acaller = Reflection.getCallerClass();if (sun.misc.VM.isSystemDomainLoader(loader)) {//获取A的类加载器ClassLoader ccl = ClassLoader.getClassLoader(caller);//安全检查if (!sun.misc.VM.isSystemDomainLoader(ccl)) {sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);}}}//name：要被加载的|initialize：是否初始化|loader：指定的类加载器（自定义加载器此处是系统类加载器）|caller调用者的Class对象return forName0(name, initialize, loader, caller);}//forName0是一个本地方法/** Called after security check for system loader access checks have been made. */private static native Class<?> forName0(String name, boolean initialize,ClassLoader loader,Class<?> caller)throws ClassNotFoundException;
tomcat类加载器
在Tomcat目录结构中，有三组目录（“/common/”,“/server/”和“shared/”）可以存放公用Java类库，此外还有第四组Web应用程序自身的目录“/WEB-INF/”，把java类库放置在这些目录中的含义分别是：
放置在common目录中：类库可被Tomcat和所有的Web应用程序共同使用。
放置在server目录中：类库可被Tomcat使用，但对所有的Web应用程序都不可见。
放置在shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见。
放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。
为了支持这套目录结构，并对目录里面的类库进行加载和隔离，Tomcat自定义了多个类加载器，这些类加载器按照经典的双亲委派模型来实现，如下图所示
灰色背景的3个类加载器是JDK默认提供的类加载器，这3个加载器的作用前面已经介绍过了。而 CommonClassLoader、CatalinaClassLoader、SharedClassLoader 和 WebAppClassLoader 则是 Tomcat 自己定义的类加载器，它们分别加载 /common/、/server/、/shared/* 和 /WebApp/WEB-INF/* 中的 Java 类库。其中 WebApp 类加载器和 Jsp 类加载器通常会存在多个实例，每一个 Web 应用程序对应一个 WebApp 类加载器，每一个 JSP 文件对应一个 Jsp 类加载器。从图中的委派关系中可以看出，CommonClassLoader 能加载的类都可以被 CatalinaClassLoader 和 SharedClassLoader 使用，而 CatalinaClassLoader 和 SharedClassLoader 自己能加载的类则与对方相互隔离。WebAppClassLoader 可以使用 SharedClassLoader 加载到的类，但各个 WebAppClassLoader 实例之间相互隔离。而 JasperLoader 的加载范围仅仅是这个 JSP 文件所编译出来的那一个 Class，它出现的目的就是为了被丢弃：当服务器检测到 JSP 文件被修改时，会替换掉目前的 JasperLoader 的实例，并通过再建立一个新的 Jsp 类加载器来实现 JSP 文件的 HotSwap 功能。
spring的类的加载方式
先看一下tomcat的类加载器 Tomcat 加载器的实现清晰易懂，并且采用了官方推荐的“正统”的使用类加载器的方式。那么如果有 10 个 Web 应用程序都用到了spring的话，可以把Spring的jar包放到 common 或 shared 目录下让这些程序共享。Spring 的作用是管理每个web应用程序的bean，getBean时自然要能访问到应用程序的类，而用户的程序显然是放在 /WebApp/WEB-INF 目录中的（由 WebAppClassLoader 加载），那么在 CommonClassLoader 或 SharedClassLoader 中的 Spring 容器如何去加载并不在其加载范围的用户程序（/WebApp/WEB-INF/）中的Class呢？
spring项目都要加一个listener
<listener><listener-class>org.springframework.web.context.ContextLoaderListenerlistener-class>
listener>
这个类根据名字知道是个上下文类加载的监听器，查看ContextLoaderListener的源码：
/**
引导启动和关闭spring的根WebApplicationContext的监听器。* Bootstrap listener to start up and shut down Spring's root {@link WebApplicationContext}.* Simply delegates to {@link ContextLoader} as well as to {@link ContextCleanupListener}.** This listener should be registered after {@link org.springframework.web.util.Log4jConfigListener}* in {@code web.xml}, if the latter is used.**
As of Spring 3.1, {@code ContextLoaderListener} supports injecting the root web* application context via the {@link #ContextLoaderListener(WebApplicationContext)}* constructor, allowing for programmatic configuration in Servlet 3.0+ environments.* See {@link org.springframework.web.WebApplicationInitializer} for usage examples.** @author Juergen Hoeller* @author Chris Beams* @since 17.02.2003* @see #setContextInitializers* @see org.springframework.web.WebApplicationInitializer* @see org.springframework.web.util.Log4jConfigListener*/
public class ContextLoaderListener extends ContextLoader implements ServletContextListener {public ContextLoaderListener() {}public ContextLoaderListener(WebApplicationContext context) {super(context);}/*** Initialize the root web application context.*/@Overridepublic void contextInitialized(ServletContextEvent event) {initWebApplicationContext(event.getServletContext());}/*** Close the root web application context.*/@Overridepublic void contextDestroyed(ServletContextEvent event) {closeWebApplicationContext(event.getServletContext());ContextCleanupListener.cleanupAttributes(event.getServletContext());}}
他的核心是调用父类的initWebApplicationContext
public WebApplicationContext initWebApplicationContext(ServletContext servletContext) {if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) {throw new IllegalStateException("Cannot initialize context because there is already a root application context present - " +"check whether you have multiple ContextLoader* definitions in your web.xml!");}Log logger = LogFactory.getLog(ContextLoader.class);servletContext.log("Initializing Spring root WebApplicationContext");if (logger.isInfoEnabled()) {logger.info("Root WebApplicationContext: initialization started");}long startTime = System.currentTimeMillis();try {// Store context in local instance variable, to guarantee that// it is available on ServletContext shutdown.if (this.context == null) {this.context = createWebApplicationContext(servletContext);}if (this.context instanceof ConfigurableWebApplicationContext) {ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context;if (!cwac.isActive()) {// The context has not yet been refreshed -> provide services such as// setting the parent context, setting the application context id, etcif (cwac.getParent() == null) {// The context instance was injected without an explicit parent ->// determine parent for root web application context, if any.ApplicationContext parent = loadParentContext(servletContext);cwac.setParent(parent);}configureAndRefreshWebApplicationContext(cwac, servletContext);}}servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);// 获取线程上下文类加载器，默认为WebAppClassLoaderClassLoader ccl = Thread.currentThread().getContextClassLoader();// 如果spring的jar包放在每个webapp自己的目录中 （也可以放在tomcat common目录下，）放在tocat的 // common目录本来是要用CommonClassLoader 加载器去加载的，这样怎么加载/webApp/WEB-INF/下的 // class呢，spring考虑到了自己可能被放到其他位置，所以直接用TCCL来解决所有可能面临的情况。// 放在webapp目录中线程上下文类加载器就是WebAppClassLoader。放在common目录下 // ContextLoader.class.getClassLoader()获取的就是commonClassLoader。// 此时线程上下文类加载器会与本类的类加载器（加载spring的）相同，都是WebAppClassLoaderif (ccl == ContextLoader.class.getClassLoader()) {currentContext = this.context;}else if (ccl != null) {currentContextPerThread.put(ccl, this.context);}if (logger.isDebugEnabled()) {logger.debug("Published root WebApplicationContext as ServletContext attribute with name [" +WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE + "]");}if (logger.isInfoEnabled()) {long elapsedTime = System.currentTimeMillis() - startTime;logger.info("Root WebApplicationContext: initialization completed in " + elapsedTime + " ms");}return this.context;}catch (RuntimeException ex) {logger.error("Context initialization failed", ex);servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex);throw ex;}catch (Error err) {logger.error("Context initialization failed", err);servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, err);throw err;}}
所以，spring根本不会去管自己被放在哪里，它统统使用TCCL来加载类，而TCCL默认设置为WebAppClassLoader，也就是说哪个WebApp应用调用了spring，spring就去取该应用自己的WebAppClassLoader来加载bean
总结
线程上下文加载器就是当前线程的Current ClassLoader在双亲委托模型下，类加载器由下至上的，即下层的类加载器会委托上层进行加载。但是对于SPI来说，有些接口是java核心库所提供的，而java核心库是由启动类加载器来加载的，而这些接口的实现来自于不同的jar包（厂商提供），java的启动类加载器是不会加载其他来源的jar包，这样传统的双亲委托模型就无法满足SPI的要求，而通过给当前线程设置上下文加载器就可以设置上下文类加载器来实现对于接口实现类的加载。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！