在 java 对象序列化中，自定义 classloader 的处理核心在于实现 readresolve 方法或重写 objectinputstream 的 resolveclass 方法。当反序列化发生时，jvm 默认使用当前线程上下文 classloader 来加载类定义，这可能导致与序列化时使用的 classloader 不一致，进而引发 invalidclassexception 或类型转换错误。通过拦截类的解析过程，可以强制指定特定的 classloader 来确保类定义的同一性。
如何重写 ObjectInputStream 以指定 ClassLoader？
直接回答：通过继承 ObjectInputStream 并重写 resolveClass 方法，可以在反序列化过程中动态替换用于加载类的 ClassLoader。这样做的结果是，即使传入的字节流是由另一个 ClassLoader 序列化的，也能在当前环境中正确还原对象，前提是目标类在指定的 ClassLoader 中可访问。
import java.io.*;
public class CustomClassLoaderObjectInputStream extends ObjectInputStream {
private final ClassLoader targetClassLoader;
public CustomClassLoaderObjectInputStream(InputStream in, ClassLoader loader) throws IOException {
super(in);
this.targetClassLoader = loader;
}
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
// 如果目标 ClassLoader 不为空，则使用它来加载类
if (targetClassLoader != null) {
try {
return Class.forName(desc.getName(), false, targetClassLoader);
} catch (ClassNotFoundException e) {
// 如果目标 ClassLoader 找不到，回退到默认行为
return super.resolveClass(desc);
}
}
return super.resolveClass(desc);
}
}
// 使用示例
// InputStream is = new FileInputStream("data.ser");
// ClassLoader myLoader = new MyCustomClassLoader();
// ObjectInputStream ois = new CustomClassLoaderObjectInputStream(is, myLoader);
// Object obj = ois.readObject();上述代码展示了如何创建一个包装器。关键在于 resolveClass 的重写。当 ObjectInputStream 遇到一个需要加载的类描述符时，它会调用此方法。我们优先尝试使用传入的 targetClassLoader 进行加载。如果加载失败，则抛出异常或回退到默认的 ClassLoader（通常是父级 ClassLoader），以保证程序的健壮性。这种方式适用于那些需要在特定隔离环境中加载类的场景，比如插件系统或热更新模块。
立即学习“Java免费学习笔记（深入）”；
为什么 readResolve 不能解决 ClassLoader 不一致问题？
直接回答：readResolve 方法是在对象已经成功实例化之后调用的，它主要用于控制对象的返回实例（例如实现单例模式或替换为代理对象）。它无法干预类的加载过程。如果类本身因为 ClassLoader 不同而导致 class 对象不匹配，反序列化会在 readResolve 之前就因为类型检查失败而抛出异常。因此，处理 ClassLoader 问题必须在类解析阶段解决，而不是在对象构建后。
import java.io.*;
public class SerializableExample implements Serializable {
private static final long serialVersionUID = 1L;
private String data;
public SerializableExample(String data) {
this.data = data;
}
// 这个方法在反序列化后调用，但此时类已经加载完毕
protected Object readResolve() throws ObjectStreamException {
System.out.println("readResolve called");
return this;
}
}
// 测试 ClassLoader 冲突
// ClassLoader loaderA = new URLClassLoader(new URL[]{new File("libA.jar").toURI().toURL()});
// ClassLoader loaderB = new URLClassLoader(new URL[]{new File("libB.jar").toURI().toURL()});
//
// // 假设两个 JAR 中有同名同包但不同实现的 SerializableExample
// // 用 loaderA 序列化对象
// ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("test.ser"));
// oos.writeObject(loaderA.loadClass("SerializableExample").getDeclaredConstructor(String.class).newInstance("test"));
// oos.close();
//
// // 用 loaderB 反序列化，如果不重写 resolveClass，会报错
// // 因为 loaderB 加载的 SerializableExample 与序列化时的类不是同一个 Class 对象这段代码演示了 readResolve 的存在并不能阻止 ClassLoader 引发的 InvalidClassException。当 ObjectInputStream 尝试将字节流中的类描述符与当前 JVM 中已加载的类进行比对时，如果发现类签名（如 serialVersionUID）一致但 Class 对象来自不同的 ClassLoader，且没有显式指定 ClassLoader 解析策略，JVM 可能会认为这是两个不同的类定义，从而导致失败。特别是在 OSGi 或模块化应用中，这种隔离性是常见的痛点。因此，必须结合前文提到的 resolveClass 重写方案，才能彻底解决跨 ClassLoader 的反序列化问题。
在插件系统中如何处理动态加载类的序列化？
直接回答：在插件系统中，通常需要将插件的 ClassLoader 传递给反序列化器，以确保插件内部的自定义对象能被正确识别。具体做法是将插件 ClassLoader 作为参数传入自定义的 ObjectInputStream，并在 resolveClass 中优先使用该 ClassLoader。这样可以保证插件内的类定义与序列化时保持一致，避免类版本冲突或找不到类的错误。
