打破双亲委派模型的核心做法是重写 classloader 类的 loadclass() 方法，并在其中自定义类加载逻辑。默认情况下，classloader 会委托父加载器尝试加载类，若要打破这一机制，开发者需要实现自己的 classloader 子类，覆盖默认的委托行为，改为优先从特定路径（如网络、数据库或加密存储）加载字节码，或者在父加载器失败时采取其他策略。这样做可以让应用实现热部署、代码加密解密加载或隔离不同版本的依赖库。
如何重写 loadClass() 实现自定义加载逻辑
要打破双亲委派，最直接的方法是继承 java.lang.ClassLoader 并重写 findClass() 方法，但更彻底的打破方式是重写 loadClass() 方法本身。因为 loadClass() 包含了检查缓存和委托父加载器的逻辑，如果只重写 findClass()，仍然会遵循双亲委派的顺序。通过重写 loadClass()，我们可以完全控制加载流程，例如先尝试从非标准源加载，如果成功则直接返回，不再委托给父加载器。
import java.io.ByteArrayOutputStream;
import java.io.FileInputStream;
import java.io.IOException;
public class CustomClassLoader extends ClassLoader {
private String classPath;
public CustomClassLoader(String classPath) {
this.classPath = classPath;
}
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
if (name != null && name.startsWith("com.example.custom.")) {
try {
byte[] data = loadData(name);
Class<?> c = defineClass(name, data, 0, data.length);
if (resolve) {
resolveClass(c);
}
return c;
} catch (IOException e) {
throw new ClassNotFoundException("Failed to load custom class", e);
}
}
// 对于非自定义包，仍使用双亲委派
return super.loadClass(name, resolve);
}
private byte[] loadData(String name) throws IOException {
String path = classPath + name.replace('.', '/') + ".class";
try (FileInputStream fis = new FileInputStream(path);
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();
}
}
public static void main(String[] args) throws Exception {
CustomClassLoader cl = new CustomClassLoader("/tmp/classes/");
Class<?> clazz = cl.loadClass("com.example.custom.MyClass");
System.out.println("Loaded by: " + clazz.getClassLoader().getClass().getName());
}
}上述代码展示了一个简单的自定义类加载器。它首先检查类名是否以 com.example.custom. 开头，如果是，则直接从指定路径读取 .class 文件并调用 defineClass 进行定义，从而绕过了父加载器的委托链。如果不是，则调用 super.loadClass 保持双亲委派。运行该程序后，控制台将输出 Loaded by: CustomClassLoader，证明该类是由自定义加载器加载的，而非其父加载器。
立即学习“Java免费学习笔记（深入）”；
为什么某些场景下必须打破双亲委派？
双亲委派模型虽然保证了类的唯一性和安全性，但在某些特定场景下，它反而会成为障碍。例如，JDBC 驱动的管理就需要打破双亲委派。JDBC 接口位于 rt.jar 中，由 Bootstrap ClassLoader 加载，而具体的驱动实现（如 MySQL Connector/J）位于应用classpath中，由 Application ClassLoader 加载。如果严格遵循双亲委派，Bootstrap ClassLoader 无法加载 Application ClassLoader 才能看到的驱动类，导致 Class.forName() 失败。因此，JDBC 使用了线程上下文类加载器（Thread Context ClassLoader）来逆向获取类，这实际上是一种对双亲委派的“打破”或补充。
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class JdbcExample {
public static void main(String[] args) {
try {
// 这里利用了线程上下文类加载器机制
// DriverManager 内部会使用 Thread.currentThread().getContextClassLoader()
// 来加载驱动，而不是使用双亲委派
Connection conn = DriverManager.getConnection(
"jdbc:mysql://localhost/test",
"user",
"password"
);
System.out.println("Connection established successfully.");
} catch (SQLException e) {
e.printStackTrace();
}
}
}在上述 JDBC 示例中，DriverManager.getConnection() 方法内部会遍历已注册的驱动。这些驱动通常是在静态块中通过 Class.forName() 注册的。由于 DriverManager 本身由 Bootstrap 加载，它无法直接看到应用层的驱动类。因此，JDBC 规范允许驱动程序注册时使用线程上下文类加载器，或者在 getConnection 时由应用类加载器去加载驱动。这种机制允许底层 API（由高层类加载器加载）去调用上层实现（由低层类加载器加载），从而解决了服务提供者接口（SPI）的实现问题。如果不打破或绕过双亲委派，这种跨层级的服务发现将无法正常工作。
自定义类加载器中 defineClass() 的作用是什么
在自定义类加载器的实现中，defineClass() 是一个关键的原生方法，负责将字节数组转换为 Class 对象。无论采用何种加载策略，最终都必须通过 defineClass() 来完成类的定义。这个方法由 JVM 提供，确保了类加载的安全性和一致性。在重写 loadClass() 后，开发者需要从某个来源（如文件系统、网络、内存）获取类的字节码，然后将其传递给 defineClass()。如果字节码格式错误或包含非法指令，defineClass() 会抛出 ClassFormatError。此外，defineClass() 还会处理类的符号引用解析，如果 resolve 参数为 true，它会立即解析常量池中的引用；否则，解析会延迟到类首次被使用时。在实际开发中，通常建议在获取字节码后立即调用 defineClass，并在确认无误后再调用 resolveClass，以避免不必要的资源消耗。
