Thread.getContextClassLoader() 返回当前线程的 contextClassLoader，默认为 AppClassLoader，需手动设置，不继承父线程；用于框架加载业务类，解决双亲委派限制；线程池中易丢失，须自定义 ThreadFactory 传递；与 getSystemClassLoader() 的静态性不同，它动态、线程绑定。
Thread.getContextClassLoader() 返回的是谁？
它返回的是当前线程的 contextClassLoader，一个可被显式设置的 ClassLoader 实例，默认值通常是 AppClassLoader（即 sun.misc.Launcher$AppClassLoader）。但注意：这个值不是继承自父线程，也不是由 JVM 自动维护的——它靠开发者或框架手动调用 Thread.setContextClassLoader() 设置。
为什么需要它？打破双亲委派时的“桥梁”
双亲委派模型保证了核心类（如 java.lang.String）不会被用户加载器重复定义，但它也带来一个问题：当高层框架（如 JNDI、JAX-WS、Tomcat、Spring）需要加载**业务方提供的类**（比如 SPI 接口实现、XML 绑定类、插件 class）时，这些类不在 Bootstrap/Ext/App 的标准路径下，而框架代码本身又运行在系统类加载器（如 AppClassLoader）里——它无法直接看到你的 WEB-INF/classes 或模块 jar。
这时就靠 contextClassLoader 来“临时切换视角”：
- Tomcat 在每个请求线程启动时，会把当前 Web 应用的
WebAppClassLoader设为该线程的 contextClassLoader - JNDI 的
InitialContext内部会调用Thread.currentThread().getContextClassLoader().loadClass(...)去加载用户注册的服务实现 - 如果没设，就会 fallback 到
AppClassLoader，大概率抛ClassNotFoundException
常见踩坑点：线程池 + contextClassLoader 丢失
这是生产环境最隐蔽的类加载失败来源之一。例如：
- 你用
Executors.newFixedThreadPool(5)创建线程池，主线程设置了 contextClassLoader，但新线程的 contextClassLoader 默认是AppClassLoader，不是你期望的那个 - 异步任务里调用
Class.forName("com.example.MyService")，结果加载的是老版本、甚至根本找不到类 - 解决方法不是全局改
Thread.setContextClassLoader()，而是在线程池构造时传入自定义ThreadFactory，在newThread里显式设置：new ThreadFactory() { public Thread newThread(Runnable r) { Thread t = new Thread(r); t.setContextClassLoader( Thread.currentThread().getContextClassLoader() ); return t; } }
它和 ClassLoader.getSystemClassLoader() 有什么区别？
ClassLoader.getSystemClassLoader() 是静态获取，永远返回启动应用时的 AppClassLoader（或其子类），不随线程变化；而 contextClassLoader 是线程绑定的、动态可变的。两者用途完全不同：
- 你写工具类要加载“当前项目里的配置类”，应该用
Thread.currentThread().getContextClassLoader() - 你要反射加载
java.*下的类，直接用Class.forName(name)就行，它走默认委派，不需要 contextClassLoader - 你在
static {}块里初始化，没有线程上下文概念，别试图读getContextClassLoader()，可能为 null
真正复杂的地方在于：它不强制生效，也不自动传播，全靠框架作者是否记得在关键路径上用它——这也是为什么很多 SPI 加载失败，查到最后发现只是某处漏了 setContextClassLoader。
