双亲委派被打破是常态，jdbc、tomcat、osgi、spring boot均主动打破以解决类隔离或热加载需求；重写loadclass()需优先委派系统类，再加载自定义类，否则易触发noclassdeffounderror。
双亲委派被打破是常态，不是例外
可以，而且在真实项目里几乎每天都在发生。双亲委派只是 ClassLoader.loadClass() 的默认实现逻辑，只要你重写这个方法、不调用 super.loadClass()，或者绕过它（比如直接调用 defineClass()），委派链就断了。JDBC 的 DriverManager、Tomcat 的 WebAppClassLoader、OSGi、Spring Boot 的 LaunchedURLClassLoader 全都主动打破了它——不是为了炫技，而是为了解决类隔离或热加载这类刚需。
重写 loadClass() 时最容易触发的 NoClassDefFoundError
很多人以为“重写 loadClass() 就是自己 new byte[] 然后 defineClass()”，结果一跑就崩。根本原因是：你没处理好系统类（如 java.lang.String）和接口类（如 java.util.List）的加载。这些类必须由启动类加载器或扩展类加载器提供，你自己定义出来的会因类加载器不同而无法赋值、强制转型失败。
正确做法是：先判断是否为系统类/核心类，优先委派给父加载器；再处理自定义路径的类；最后才 fallback 到自己的 findClass()。示例关键片段：
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
if (name.startsWith("java.") || name.startsWith("javax.")) {
return super.loadClass(name, resolve); // 必须走默认委派
}
Class<?> c = findLoadedClass(name);
if (c == null) {
c = findClass(name); // 自己加载
}
if (resolve) resolveClass(c);
return c;
}
Tomcat 和 Spring Boot 的自定义 ClassLoader 差在哪
两者都打破双亲委派，但动机和边界完全不同：
立即学习“Java免费学习笔记（深入）”；
-
Tomcat 的
WebAppClassLoader：优先从WEB-INF/classes和WEB-INF/lib加载，仅当找不到时才委派给父类加载器。这是典型的“逆向委派”，目的是让应用类覆盖容器提供的同名类（比如不同版本的 commons-collections）。 -
Spring Boot 的
LaunchedURLClassLoader：把BOOT-INF/classes和BOOT-INF/lib放在委派链最前面，但对org.springframework.*这类核心包仍会委派给父加载器（即 AppClassLoader），避免启动类被重复加载或冲突。
关键差异在 getResource() 和 getResources() 的实现：Tomcat 会屏蔽父加载器的同名资源，Spring Boot 则保留父加载器结果并合并——这直接影响 ServiceLoader 是否能发现 META-INF/services 下的实现类。
自定义 ClassLoader 后，Class.forName() 和 ClassLoader.getSystemClassLoader() 会出什么问题
这两个是隐形陷阱高发区：
-
Class.forName("com.example.Foo")默认使用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()），不是当前类所在加载器。如果你没显式设置上下文类加载器，它很可能还是AppClassLoader，导致你的自定义类根本加载不到。 -
ClassLoader.getSystemClassLoader()永远返回 JVM 启动时的系统类加载器（通常是AppClassLoader），它跟你的自定义实例完全无关。别指望用它来加载你自己的 jar 包。 - 反射调用
newInstance()或getMethod()时，如果参数类型来自不同类加载器，哪怕类名、字节码一模一样，也会报IllegalArgumentException或NoSuchMethodException——因为 JVM 认为它们是“不同的类”。
真正可控的方式只有两个：显式传入你的 ClassLoader 实例调用 loadClass()，或者提前设置线程上下文类加载器：Thread.currentThread().setContextClassLoader(myCl)。
类加载器边界比 package 名称更硬，跨加载器的 instanceof、强制转型、异常捕获全都会失效。这点一旦忽略，调试成本远高于写加载逻辑本身。
