常见陷阱本质是开发者对“类定义归属”“委托边界”和“资源可见性”理解偏差；规避关键在于让代码行为与JVM加载逻辑对齐：避免多加载器重复定义类、警惕静态依赖链断裂（A引用B必由A的ClassLoader加载B）、统一单加载器链加载Bootstrap及依赖、正确使用getResourceAsStream路径、防止类加载器引发内存泄漏。
Java 类加载机制的常见陷阱，本质是开发者对“类定义归属”“委托边界”和“资源可见性”三者关系理解偏差所致。规避关键不在于绕开规则，而在于让代码行为与 JVM 的加载逻辑对齐。
别让类被多个加载器重复定义
自定义类加载器时，若直接重写 loadClass 并跳过双亲委派（比如只对特定包名调用 findClass），会导致同一类被不同加载器多次加载。JVM 视其为完全不同的类型，引发 ClassCastException 或静态字段隔离问题。
- 正确做法：优先复用双亲委派，在
findClass中做真正需要隔离的加载，如指定 JAR 路径加载 MySQL 驱动 - 务必先调用
findLoadedClass(name)检查是否已加载，避免重复定义 - 若必须打破委派，仅限白名单类（如
com.mysql.），其余一律交由父加载器处理
警惕静态依赖链断裂
当 A 类引用 B 类（字段、参数、继承等），JVM 解析该引用时，一定使用 A 的定义类加载器去加载 B —— 不是你当前线程用的加载器，也不是你显式传入的加载器。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 动态加载外部库（如 JGit）时，不要把 Bootstrap 类放在主应用类加载器里，再让它去 new 一个由 URLClassLoader 加载的类
- 推荐统一入口：用单个自定义加载器加载所有相关类（Bootstrap + 依赖库），切断跨加载器的静态引用链
- 避免在被动态加载的类中，直接 new 系统类路径下的类；如需交互，改用接口 + 回调或 ServiceLoader 机制
getResourceAsStream 找不到资源？先看调用主体和路径
资源找不到不是文件没打包，而是查找起点错了。同一个字符串路径，Class.getResourceAsStream 和 ClassLoader.getResourceAsStream 行为完全不同。
立即学习“Java免费学习笔记（深入）”；
-
MyClass.class.getResourceAsStream("a.txt")：从MyClass所在包目录找 -
MyClass.class.getResourceAsStream("/a.txt")：从 classpath 根目录找 -
MyClass.class.getClassLoader().getResourceAsStream("a.txt")：也从 classpath 根目录找，且不接受前置/ - 上线后资源为 null？检查构建产物（JAR/WAR）中资源是否真在预期位置，尤其注意 Maven 的
resources目录配置和 IDE 编译输出设置
别让类加载器变成内存泄漏源
自定义类加载器若被线程上下文长期持有（如线程池中 Worker 线程设置了 setContextClassLoader），它所加载的所有类及静态变量都无法卸载，最终触发 Metaspace OOM。
- 用完即清：在业务逻辑结束前，恢复线程原始上下文类加载器
- 避免强引用传递：不要把类加载器作为字段长期保存在单例或静态容器中
- 排查技巧：用 jcmd 或 JFR 抓取堆直方图，观察
java.lang.Class实例数是否异常增长，再关联到对应类加载器
