Java 类加载：打破双亲委派模型的精妙艺术
各位来宾，大家好！今天我们来深入探讨 Java 类加载机制中一个非常有趣且重要的主题：如何在双亲委派模型下，通过自定义类加载器来实现对委派链的精准操控。
1. 双亲委派模型回顾
在深入研究如何打破双亲委派模型之前，让我们先快速回顾一下它的核心概念。双亲委派模型是 Java 类加载器的一种层次结构，它规定了类加载器之间委托加载类的顺序。
模型结构：
- Bootstrap ClassLoader (启动类加载器): 负责加载 Java 核心类库，如
java.lang.*等，它是 JVM 自身的一部分，由 C++ 实现。 - Extension ClassLoader (扩展类加载器): 负责加载
jre/lib/ext目录下，或者由java.ext.dirs系统属性指定的目录中的 JAR 包。 - Application ClassLoader (应用程序类加载器): 负责加载应用程序classpath下的所有类。
- Custom ClassLoader (自定义类加载器): 用户根据需要自定义的类加载器。
工作流程：
- 当一个类加载器收到加载类的请求时，它不会立即尝试自己加载，而是将请求委派给其父类加载器。
- 每一层的类加载器都重复这个过程，直到到达顶层的 Bootstrap ClassLoader。
- 如果顶层类加载器可以加载该类，则加载完成。否则，依次向下尝试，直到当前类加载器。
- 如果所有父类加载器都无法加载该类，则当前类加载器尝试自己加载。
- 如果当前类加载器也无法加载，则抛出
ClassNotFoundException或NoClassDefFoundError异常。
优点：
- 安全性： 避免核心类库被篡改。即使恶意用户编写了一个名为
java.lang.String的类，由于双亲委派机制的存在，最终加载的仍然是 Bootstrap ClassLoader 加载的官方版本。 - 避免重复加载： 保证一个类只被加载一次。如果一个类已经被父类加载器加载，则子类加载器无需再次加载。
2. 为什么要打破双亲委派模型？
虽然双亲委派模型提供了安全性和避免重复加载的优势，但在某些特殊场景下，我们需要打破这种模型，以满足特定的需求。以下是一些常见的场景：
- 热部署： 在 Web 容器中，为了实现热部署，需要能够卸载和重新加载更新后的类。如果严格遵守双亲委派模型，更新后的类可能无法被加载，因为父类加载器已经加载了旧版本的类。
- SPI (Service Provider Interface) 机制： SPI 允许服务提供者在不修改核心代码的情况下扩展应用程序的功能。SPI 的实现类通常由应用程序类加载器加载，但 SPI 接口可能由 Bootstrap ClassLoader 加载。如果 SPI 实现类依赖于 SPI 接口，则会出现类加载冲突。
- 框架隔离： 在 OSGi 等模块化框架中，不同的模块可能需要使用相同类库的不同版本。为了实现模块之间的隔离，需要打破双亲委派模型，使得每个模块可以加载自己版本的类库。
- 自定义类加载策略： 在某些特殊应用场景下，可能需要完全掌控类的加载过程，例如，从网络加载类、对类进行加密解密等。
3. 打破双亲委派模型的实现方式
打破双亲委派模型并非完全颠覆，而是对原有机制进行精妙的调整。主要思路是：绕过父类加载器，直接由自定义类加载器加载类。 这可以通过以下几种方式实现：
3.1 重写 loadClass() 方法
这是最常见的也是最直接的方式。我们可以重写 ClassLoader 类的 loadClass() 方法，改变其默认的类加载行为。
public class MyClassLoader extends ClassLoader {
private String classPath;
public MyClassLoader(String classPath) {
this.classPath = classPath;
}
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 先检查是否已经被加载
Class<?> loadedClass = findLoadedClass(name);
if (loadedClass != null) {
return loadedClass;
}
// 不再委派给父类加载器，直接尝试自己加载
try {
byte[] classData = getClassData(name); // 从指定路径读取类的字节码
if (classData != null) {
loadedClass = defineClass(name, classData, 0, classData.length); // 定义类
if (resolve) {
resolveClass(loadedClass); // 解析类
}
return loadedClass;
}
} catch (IOException e) {
// 加载失败，抛出异常
e.printStackTrace();
}
// 如果自定义加载器无法加载，则委托给父类加载器
return super.loadClass(name, resolve);
}
private byte[] getClassData(String className) throws IOException {
String classFilePath = classPath + "/" + className.replace('.', '/') + ".class";
try (FileInputStream fis = new FileInputStream(classFilePath);
ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
byte[] buffer = new byte[1024];
int len;
while ((len = fis.read(buffer)) != -1) {
bos.write(buffer, 0, len);
}
return bos.toByteArray();
} catch (FileNotFoundException e) {
return null; // 如果找不到类文件，返回null
}
}
public static void main(String[] args) throws Exception {
String classPath = System.getProperty("user.dir") + "/myclasses"; // 假设类文件在myclasses目录下
MyClassLoader classLoader = new MyClassLoader(classPath);
// 假设MyClass在myclasses目录下
Class<?> myClass = classLoader.loadClass("com.example.MyClass");
Object instance = myClass.newInstance();
System.out.println(instance);
}
}代码解释：
MyClassLoader继承自ClassLoader。loadClass()方法是核心，它首先检查类是否已经被加载，如果已经加载，则直接返回。- 关键之处在于，它不再调用
super.loadClass()将加载任务委派给父类加载器，而是直接尝试自己加载。 getClassData()方法负责从文件系统中读取类的字节码。defineClass()方法将字节码转换为Class对象。resolveClass()方法用于解析类。- 如果自定义类加载器无法加载该类，则最后委托给父类加载器。
注意事项：
- 这种方式是打破双亲委派模型最常用的方法，但需要谨慎使用。如果滥用，可能会导致类加载混乱和安全问题。
- 在重写
loadClass()方法时，需要考虑线程安全问题。 - 需要确保自定义类加载器能够访问到需要加载的类文件。
3.2 重写 findClass() 方法
另一种方式是重写 ClassLoader 类的 findClass() 方法。findClass() 方法的默认实现是抛出 ClassNotFoundException 异常，它用于在类加载器自己的搜索路径中查找类。loadClass() 方法的默认实现是先委托给父类加载器，如果父类加载器无法加载，则调用 findClass() 方法。
public class MyClassLoader extends ClassLoader {
private String classPath;
public MyClassLoader(String classPath) {
this.classPath = classPath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] classData = getClassData(name); // 从指定路径读取类的字节码
if (classData != null) {
return defineClass(name, classData, 0, classData.length); // 定义类
}
} catch (IOException e) {
// 加载失败，抛出异常
e.printStackTrace();
}
// 如果自定义加载器无法加载，则抛出ClassNotFoundException
throw new ClassNotFoundException(name);
}
private byte[] getClassData(String className) throws IOException {
String classFilePath = classPath + "/" + className.replace('.', '/') + ".class";
try (FileInputStream fis = new FileInputStream(classFilePath);
ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
byte[] buffer = new byte[1024];
int len;
while ((len = fis.read(buffer)) != -1) {
bos.write(buffer, 0, len);
}
return bos.toByteArray();
} catch (FileNotFoundException e) {
return null; // 如果找不到类文件，返回null
}
}
public static void main(String[] args) throws Exception {
String classPath = System.getProperty("user.dir") + "/myclasses"; // 假设类文件在myclasses目录下
MyClassLoader classLoader = new MyClassLoader(classPath);
// 假设MyClass在myclasses目录下
Class<?> myClass = classLoader.loadClass("com.example.MyClass");
Object instance = myClass.newInstance();
System.out.println(instance);
}
}代码解释：
MyClassLoader继承自ClassLoader。findClass()方法负责在自定义的搜索路径中查找类，并将其定义为Class对象。- 如果自定义类加载器无法加载该类，则抛出
ClassNotFoundException异常。 loadClass()方法使用默认实现，它会先委托给父类加载器，如果父类加载器无法加载，则调用findClass()方法。
优点：
- 这种方式更加符合双亲委派模型的原始设计，因为它只是扩展了类加载器的搜索路径，而没有完全改变类加载的流程。
- 更容易维护和理解。
缺点：
- 如果父类加载器已经加载了该类，则
findClass()方法不会被调用。因此，这种方式只能用于加载父类加载器无法加载的类。
3.3 使用 URLClassLoader
URLClassLoader 是 Java 提供的一个方便的类加载器，它可以从指定的 URL 列表中加载类。URLClassLoader 继承自 URLClassLoader，并重写了 findClass() 方法。
import java.net.URL;
import java.net.URLClassLoader;
public class MyClassLoader {
public static void main(String[] args) throws Exception {
String classPath = System.getProperty("user.dir") + "/myclasses"; // 假设类文件在myclasses目录下
URL url = new URL("file:" + classPath + "/"); // 创建URL对象
URLClassLoader classLoader = new URLClassLoader(new URL[]{url}); // 创建URLClassLoader
// 假设MyClass在myclasses目录下
Class<?> myClass = classLoader.loadClass("com.example.MyClass");
Object instance = myClass.newInstance();
System.out.println(instance);
}
}代码解释：
URLClassLoader可以从指定的 URL 列表中加载类。- 我们可以将自定义的类路径添加到 URL 列表中。
URLClassLoader会自动搜索 URL 列表中的类文件。
优点：
- 使用简单方便。
- 支持从多个 URL 加载类。
缺点：
- 无法完全控制类加载的过程。
4. 应用场景举例
4.1 热部署
假设我们有一个 Web 应用程序，需要实现热部署功能。我们可以使用自定义类加载器来实现。
public class HotSwapClassLoader extends ClassLoader {
private String classPath;
public HotSwapClassLoader(String classPath) {
super(HotSwapClassLoader.class.getClassLoader()); // 指定父类加载器为当前类的类加载器
this.classPath = classPath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] classData = getClassData(name); // 从指定路径读取类的字节码
if (classData != null) {
return defineClass(name, classData, 0, classData.length); // 定义类
}
} catch (IOException e) {
e.printStackTrace();
}
throw new ClassNotFoundException(name);
}
private byte[] getClassData(String className) throws IOException {
String classFilePath = classPath + "/" + className.replace('.', '/') + ".class";
try (FileInputStream fis = new FileInputStream(classFilePath);
ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
byte[] buffer = new byte[1024];
int len;
while ((len = fis.read(buffer)) != -1) {
bos.write(buffer, 0, len);
}
return bos.toByteArray();
} catch (FileNotFoundException e) {
return null;
}
}
}代码解释：
HotSwapClassLoader继承自ClassLoader。findClass()方法负责从指定的类路径中加载类。- 在热部署时，我们可以创建一个新的
HotSwapClassLoader实例，并使用它来加载更新后的类。 - 由于每次热部署都会创建一个新的类加载器，因此可以避免类加载冲突。
- 将父类加载器指定为
HotSwapClassLoader自身的类加载器，保证基础类由父类加载器加载。
使用示例：
public class MyWebApp {
private HotSwapClassLoader classLoader;
private Object myServlet;
public void reloadServlet() throws Exception {
// 创建新的类加载器
classLoader = new HotSwapClassLoader("/path/to/updated/classes");
// 加载新的Servlet类
Class<?> servletClass = classLoader.loadClass("com.example.MyServlet");
// 创建Servlet实例
myServlet = servletClass.newInstance();
// ...
}
}4.2 SPI 机制
假设我们有一个 SPI 接口 com.example.MyService，它的实现类 com.example.MyServiceImpl 由应用程序类加载器加载。如果 MyServiceImpl 依赖于 MyService，则会出现类加载冲突。我们可以使用 Thread Context ClassLoader 来解决这个问题。
public class MyServiceLoader {
public static MyService loadService() throws Exception {
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
// 使用当前线程的上下文类加载器加载 SPI 实现类
Class<?> serviceImplClass = contextClassLoader.loadClass("com.example.MyServiceImpl");
return (MyService) serviceImplClass.newInstance();
}
}代码解释：
Thread.currentThread().getContextClassLoader()方法可以获取当前线程的上下文类加载器。- 上下文类加载器通常是应用程序类加载器。
- 通过设置上下文类加载器，我们可以使得 SPI 实现类由应用程序类加载器加载，从而避免类加载冲突。
5. 打破委派的潜在风险
打破双亲委派模型虽然可以解决一些特殊问题，但也带来了一些潜在的风险：
- 类加载冲突： 如果不同的类加载器加载了同一个类的不同版本，可能会导致类加载冲突，例如
ClassCastException。 - 内存泄漏： 如果类加载器没有被正确地卸载，可能会导致内存泄漏。
- 安全性问题： 如果恶意用户可以控制类加载器，可能会篡改应用程序的行为。
因此，在打破双亲委派模型时，需要仔细权衡利弊，并采取相应的安全措施。
6. 总结：灵活运用，掌控类加载
打破双亲委派模型是 Java 类加载机制中一项高级技术，它允许开发者在特定场景下对类加载过程进行精细的控制。通过重写 loadClass() 或 findClass() 方法，或者利用 URLClassLoader，我们可以实现热部署、SPI 扩展和框架隔离等功能。然而，在打破双亲委派模型时，必须谨慎权衡其带来的风险，并采取相应的安全措施，以确保应用程序的稳定性和安全性。
希望今天的讲解能帮助大家更深入地理解 Java 类加载机制，并在实际开发中灵活运用。谢谢大家！