详解Java中的自定义类加载器实现_打破双亲委派模型的场景(如Tomcat)-java教程-PHP中文网

重写 loadClass 会破坏双亲委派，因其绕过父加载器优先加载逻辑；正确做法是仅重写 findClass 并调用 defineClass，避免直接干预委派流程。

详解java中的自定义类加载器实现_打破双亲委派模型的场景(如tomcat)

为什么重写 `loadClass` 会破坏双亲委派，但多数人其实不该动它

Java 类加载器默认走双亲委派：先让父加载器尝试加载，失败才自己加载。真正打破它的关键不是“自定义类加载器”，而是**绕过 loadClass 的默认逻辑**——比如直接重写该方法却不调用 super.loadClass(name)，或在其中插入自己的加载路径优先级。

但绝大多数场景下，你根本不需要碰 loadClass。Tomcat、OSGi、热部署框架等确实打破了委派，但它们是为了解决「隔离性」和「版本冲突」这类强约束问题，不是为了“炫技”。盲目重写只会导致 NoClassDefFoundError 或 LinkageError，尤其在反射、序列化、JDBC 驱动加载时悄无声息地崩。

正确做法：继承 ClassLoader，只重写 findClass(String name)，并在里面调用 defineClass()
错误高发点：在 loadClass 里直接 new byte[] + defineClass，却没处理 resolve 参数，导致类未链接，后续调用时报 IllegalAccessError
兼容性风险：JDK 9+ 引入模块系统后，defineClass 对非 java.* 包的类会校验 Module 和 ProtectionDomain，硬塞字节码可能被拒绝

Tomcat 的 `WebAppClassLoader` 是怎么避开双亲委派的

它没全盘否定双亲委派，而是做了「有选择的委派」：对 /WEB-INF/classes 和 /WEB-INF/lib/*.jar 中的类，**优先自己加载**；对 javax.*、org.apache.catalina.* 等核心包，则强制委派给父加载器（避免容器与应用类混用同一份实现）。

这个逻辑藏在 WebAppClassLoader.loadClass() 的 if-else 分支里，不是靠删代码，而是靠判断类名前缀 + 资源路径是否存在。

关键判断：是否匹配 delegate 配置（默认 false），以及类名是否属于 delegateLoad 白名单（如 java.、javax.）
资源定位陷阱：用 getResourceAsStream("META-INF/MANIFEST.MF") 可能拿到父加载器的 jar，但用 findResource() 才走当前类加载器路径
线程上下文加载器（Thread.currentThread().getContextClassLoader()）在这里被设为 WebAppClassLoader，所以 ServiceLoader、JDBC DriverManager 才能感知到应用自己的驱动

`defineClass` 的字节码来源必须可信，否则 JVM 直接拒绝

即使你绕过了委派，把字节码喂给 defineClass，JVM 仍会校验：name 是否与字节码中声明的类名一致、是否已由同一类加载器定义过、是否违反模块封装（JDK 9+）、是否含非法字节码结构。校验失败抛 ClassFormatError 或 SecurityException。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

常见翻车点是动态生成类（ASM/Javassist）后没清理调试信息，或从网络加载字节码却没校验签名——JDK 默认启用 SecurityManager 时，defineClass 会检查 RuntimePermission("defineClass")。

安全建议：生产环境禁用 SecurityManager 后，仍需校验字节码来源（如比对 SHA256），防止恶意注入
调试技巧：用 javap -v 检查生成类的 ConstantPool 和 Signature 属性是否合法
性能注意：反复调用 defineClass 会触发元空间（Metaspace）增长，若类不卸载，容易 OOM；Tomcat 通过 clearReferencesThreads() 清理线程引用缓解此问题

自定义类加载器和 Spring 的 `ClassLoader` 交互很脆弱

Spring 容器启动时，默认使用当前线程上下文加载器（TCCL）加载配置类、Bean 定义、注解处理器。如果你手动 new 出一个类加载器并传给 new ClassPathXmlApplicationContext(...)，Spring 内部仍可能在某些路径（如 AOP 代理生成、EL 表达式解析）回退到 Class.forName(...)，从而走系统类加载器，导致类型不匹配：同一个类名，被两个加载器加载，instanceof 返回 false，cast 报 ClassCastException。

典型症状：org.springframework.beans.factory.BeanNotOfRequiredTypeException，提示 “expected type X, but got Y”，实则是 X 和 Y 是不同加载器加载的同名类
解决思路：统一使用 Thread.currentThread().setContextClassLoader(yourLoader)，并在 Spring 上下文刷新前设置好；避免在 Bean 初始化中临时切换 TCCL
更隐蔽的坑：Spring Boot 的 LaunchedURLClassLoader 本身已打破委派（优先加载 BOOT-INF/classes），再套一层自定义加载器极易引发嵌套委派混乱

真正难的不是写个能加载类的加载器，而是让整个生态（JVM、容器、框架、第三方库）都按你的委派规则走——稍有不一致，就变成运行时类型系统崩塌，而这种问题往往只在特定环境复现，日志里连堆栈都藏得极深。