Java 类加载器：双亲委派、SPI 扩展与线程上下文类加载器的挑战
大家好，今天我们来聊聊 Java 类加载器，一个看似基础但实际上非常重要的概念。我们会深入探讨双亲委派模型，它如何影响 SPI 扩展，以及线程上下文类加载器如何打破这种模型，并最终触及 OSGi 模块化的一些问题。
一、类加载器与双亲委派模型
首先，什么是类加载器？简单来说，类加载器负责将 .class 文件中的字节码加载到 JVM 中，并创建对应的 java.lang.Class 对象。Java 中有多种类加载器，最主要的包括：
- Bootstrap ClassLoader: 负责加载 JVM 核心类库，比如
java.lang.*等，通常由 C++ 实现，是所有类加载器的父类。 - Extension ClassLoader: 负责加载扩展目录下的类库，比如
jre/lib/ext。 - System/Application ClassLoader: 负责加载应用 classpath 下的类库，是我们编写的大部分代码都由它加载。
- Custom ClassLoader: 我们可以自定义类加载器，实现一些特殊的加载需求，比如从网络加载类，或者对类进行加密解密。
这些类加载器之间存在一种层级关系，这就是双亲委派模型。
双亲委派模型的工作原理：
- 当一个类加载器收到加载类的请求时，它不会立即自己去加载，而是将这个请求委托给它的父类加载器去执行。
- 每一层的类加载器都依次递归地向上委托，直到到达顶层的 Bootstrap ClassLoader。
- 如果父类加载器可以完成类的加载，就成功返回。如果父类加载器无法加载，子类加载器才会尝试自己去加载。
双亲委派模型的优点：
- 安全性： 可以防止恶意代码替换 JVM 核心类库，例如，你自己写一个
java.lang.String类，由于 Bootstrap ClassLoader 已经加载了官方的String类，你的类永远不会被加载，保证了核心类库的安全性。 - 避免重复加载： 确保一个类只会被加载一次，避免了类的冲突。
代码示例：
public class ClassLoaderDemo {
public static void main(String[] args) throws ClassNotFoundException {
// 获取当前类的类加载器
ClassLoader classLoader = ClassLoaderDemo.class.getClassLoader();
System.out.println("ClassLoaderDemo's ClassLoader: " + classLoader);
// 获取父类加载器
ClassLoader parentClassLoader = classLoader.getParent();
System.out.println("ClassLoaderDemo's Parent ClassLoader: " + parentClassLoader);
// 获取祖父类加载器 (Bootstrap ClassLoader) - 返回 null
ClassLoader grandParentClassLoader = parentClassLoader.getParent();
System.out.println("ClassLoaderDemo's GrandParent ClassLoader: " + grandParentClassLoader);
// 加载 java.lang.String 类
Class<?> stringClass = Class.forName("java.lang.String");
System.out.println("String's ClassLoader: " + stringClass.getClassLoader()); // 输出 null，表示由 Bootstrap ClassLoader 加载
}
}这段代码演示了如何获取类加载器及其父类加载器。 关键点是 java.lang.String 的类加载器是 null，这表明它是被 Bootstrap ClassLoader 加载的。
二、SPI 扩展与双亲委派模型的冲突
SPI (Service Provider Interface) 是一种服务发现机制。它允许接口的实现类在运行时被发现和加载，从而实现松耦合和可扩展性。常见的 SPI 应用包括 JDBC 驱动、日志框架 (SLF4J)、Servlet 容器等。
SPI 的工作原理：
- 定义一个接口 (Service Interface)。
- 提供多个接口的实现类 (Service Provider)，这些实现类通常放在不同的 jar 包中。
- 在
META-INF/services目录下创建一个以接口全限定名命名的文件，文件中列出所有实现类的全限定名。 - 使用
ServiceLoader.load(ServiceInterface.class)方法加载接口的实现类。
问题来了： ServiceLoader.load() 方法通常由 JDK 核心类库提供，也就是由 Bootstrap ClassLoader 加载。而 SPI 的实现类通常位于应用程序的 classpath 下，由 System ClassLoader 加载。
由于双亲委派模型，ServiceLoader.load() 只能使用 Bootstrap ClassLoader 加载类。 Bootstrap ClassLoader 无法加载 System ClassLoader 下的类，这就导致 SPI 机制无法正常工作。
举例：JDBC 驱动
假设我们使用 JDBC 连接数据库。JDBC 接口 ( java.sql.Driver ) 由 JDK 提供，也就是由 Bootstrap ClassLoader 加载。而 JDBC 驱动的实现类 (比如 MySQL Connector/J) 位于应用程序的 classpath 下，由 System ClassLoader 加载。
按照双亲委派模型，ServiceLoader.load(java.sql.Driver.class) 只能使用 Bootstrap ClassLoader 加载类，它无法找到 MySQL Connector/J 的实现类。
三、线程上下文类加载器（Thread Context ClassLoader）
为了解决 SPI 扩展与双亲委派模型的冲突，Java 引入了线程上下文类加载器 (Thread Context ClassLoader)。
线程上下文类加载器的工作原理：
- 每个线程都有一个关联的上下文类加载器。
- 如果没有显式设置，线程的上下文类加载器默认是父线程的上下文类加载器。如果父线程是主线程，则上下文类加载器默认是 System ClassLoader。
- 当需要加载类时，如果当前类加载器无法完成加载，可以尝试使用线程上下文类加载器。
如何使用线程上下文类加载器解决 SPI 问题：
在 SPI 的实现中，通常会使用 Thread.currentThread().getContextClassLoader() 来获取线程上下文类加载器，并使用它来加载 SPI 的实现类。
代码示例：
public class SPIDemo {
public static void main(String[] args) {
ServiceLoader<MyService> serviceLoader = ServiceLoader.load(MyService.class);
for (MyService service : serviceLoader) {
System.out.println("Service implementation: " + service.getClass().getName());
service.doSomething();
}
}
}
interface MyService {
void doSomething();
}
// 实现类 1
class MyServiceImpl1 implements MyService {
@Override
public void doSomething() {
System.out.println("MyServiceImpl1 is doing something.");
}
}
// 实现类 2
class MyServiceImpl2 implements MyService {
@Override
public void doSomething() {
System.out.println("MyServiceImpl2 is doing something.");
}
}
//META-INF/services/MyService 文件内容：
//MyServiceImpl1
//MyServiceImpl2在这个例子中，SPIDemo 类使用 ServiceLoader.load(MyService.class) 加载 MyService 接口的实现类。 ServiceLoader 内部会使用线程上下文类加载器来加载 MyServiceImpl1 和 MyServiceImpl2。
JDBC 的例子：
在 JDBC 的实现中， DriverManager 类会使用 Thread.currentThread().getContextClassLoader() 来加载 JDBC 驱动。 这样，即使 DriverManager 由 Bootstrap ClassLoader 加载，它仍然可以加载位于应用程序 classpath 下的 JDBC 驱动。
四、线程上下文类加载器的破坏性与 OSGi 模块化
虽然线程上下文类加载器解决了 SPI 扩展的问题，但也打破了双亲委派模型的约定。它允许子类加载器 (比如 System ClassLoader) 加载父类加载器 (比如 Bootstrap ClassLoader) 无法加载的类，这在某些情况下可能会导致问题。
OSGi 模块化：
OSGi (Open Service Gateway Initiative) 是一种动态模块化系统，它允许将应用程序分解为多个独立的模块 (bundles)，这些模块可以在运行时动态安装、启动、停止和卸载。
OSGi 的类加载机制：
OSGi 定义了自己的类加载机制，每个 bundle 都有自己的类加载器。Bundle 之间通过 Import-Package 和 Export-Package 机制来声明依赖关系，从而实现模块间的隔离。
线程上下文类加载器与 OSGi 的冲突：
如果 OSGi 环境中的代码使用线程上下文类加载器来加载类，可能会破坏 OSGi 的模块化隔离。
例如，假设 Bundle A 声明依赖于 Bundle B 的某个类。 如果 Bundle A 中的代码使用 Thread.currentThread().getContextClassLoader() 来加载这个类，而线程上下文类加载器被设置为 System ClassLoader，那么 Bundle A 可能会直接从 classpath 下加载这个类，而不是从 Bundle B 中加载。 这就破坏了 OSGi 的模块化隔离，可能导致版本冲突和其他问题。
解决 OSGi 中线程上下文类加载器的问题：
在 OSGi 环境中，应该避免使用线程上下文类加载器。 如果必须使用，应该谨慎设置线程上下文类加载器，确保它指向正确的 Bundle 的类加载器。
可以使用 OSGi 提供的 BundleContext.getBundle().adapt(ClassLoading.class).getClassLoader() 方法来获取 Bundle 的类加载器，并将其设置为线程上下文类加载器。
代码示例 (简化):
// 假设在 OSGi Bundle 中
BundleContext bundleContext = FrameworkUtil.getBundle(this.getClass()).getBundleContext();
ClassLoader bundleClassLoader = bundleContext.getBundle().adapt(ClassLoading.class).getClassLoader();
Thread.currentThread().setContextClassLoader(bundleClassLoader);
// 现在可以使用线程上下文类加载器加载类了，但是要确保加载的是 Bundle 内部的类五、总结
我们回顾一下今天讨论的关键点：
- 双亲委派模型保证了类加载的安全性和避免重复加载，但也限制了 SPI 扩展。
- 线程上下文类加载器解决了 SPI 扩展的问题，但也打破了双亲委派模型。
- 在 OSGi 这样的模块化环境中，需要谨慎使用线程上下文类加载器，以避免破坏模块化隔离。
六、表格总结
| 特性 | 双亲委派模型 | 线程上下文类加载器 | OSGi 模块化 |
|---|---|---|---|
| 核心思想 | 类加载请求委托给父类加载器，保证类加载的安全性与唯一性 | 允许子类加载器加载父类加载器无法加载的类，解决 SPI 问题 | 模块化，模块间隔离，动态安装、启动、停止和卸载 |
| 优点 | 安全性、避免重复加载 | 解决 SPI 扩展问题 | 模块化、隔离性、动态性 |
| 缺点 | 限制 SPI 扩展 | 打破双亲委派模型，可能导致类冲突 | 复杂性，可能与线程上下文类加载器冲突 |
| 适用场景 | 大部分 Java 应用 | SPI 扩展 | 大型应用，需要模块化和动态部署 |
| 与 SPI 的关系 | 阻碍 SPI 扩展 | 解决 SPI 扩展问题 | 需要谨慎使用线程上下文类加载器，避免破坏模块化隔离 |
| 与 OSGi 的关系 | – | 可能破坏 OSGi 模块化隔离 | 定义自己的类加载机制，需要与线程上下文类加载器协同工作 |
| 使用注意事项 | – | 谨慎设置线程上下文类加载器 | 避免滥用线程上下文类加载器 |
希望今天的讲解能够帮助大家更深入地理解 Java 类加载器的工作机制，以及它在 SPI 扩展和模块化环境中的应用。 理解类加载器对于深入理解 Java 运行机制和设计复杂的系统至关重要。