ClassNotFoundException 根源在于类加载机制细节：路径错误（如误用./）、依赖版本冲突、自定义类加载器未卸载、反射被安全拦截等，导致JVM按双亲委派模型找不到或无法初始化类。
Java 类加载机制本身不难理解，但实际开发中出问题往往不是因为不懂，而是踩在几个关键细节上——比如资源路径写错、依赖版本打架、自定义类加载器没卸载、反射调用被安全拦截。这些问题一发生，就是 NoClassDefFoundError、ClassNotFoundException、NullPointerException 或诡异的 NoSuchMethodError，排查起来耗时又费力。
类加载路径与 getResourceAsStream 陷阱
90% 的资源加载失败，根源不在方法本身，而在路径写法和类加载器选择。
-
以 / 开头：从类路径（classpath）根目录查找，比如
/app.conf对应src/main/resources/app.conf -
不带 /：相对于当前类所在包路径查找，比如
Config.class.getResourceAsStream("log.xml")会找com/example/Config.class同级的log.xml -
别用 ./ 或 ../：ClassLoader 不支持相对符号，
./config.properties会被当成普通文件名，基本返回 null -
优先用上下文类加载器：框架或通用工具类中，用
Thread.currentThread().getContextClassLoader().getResourceAsStream(...)，避免因双亲委派导致资源不可见
依赖冲突引发的类加载失败
多个 JAR 引入同一依赖的不同版本，JVM 加载了旧版类，运行时调用新版才有的方法，就会崩。
- 典型表现：
NoClassDefFoundError（类存在但初始化失败）、NoSuchMethodError（方法签名不匹配） - 快速定位：启动加
-verbose:class，看具体是哪个 JAR 加载了目标类 - Maven 查依赖树：
mvn dependency:tree -Dincludes=group:artifact，确认实际生效的版本 - 解决方向：用
<exclusions></exclusions>排除传递依赖，或用<dependencymanagement></dependencymanagement>统一版本
自定义类加载器与内存泄漏
元空间 OOM 很多时候不是代码写得多，而是类加载器没回收，连带它加载的所有 Class 对象一直占着内存。
立即学习“Java免费学习笔记（深入）”；
- JVM 只有在满足三个条件时才卸载类：类实例全被回收 + 类加载器自身被回收 + Class 对象无强引用
- 系统类加载器（Bootstrap、Platform、AppClassLoader）永远不会被回收，它们加载的类也永远不卸载
- 真正能卸载的，只有你写的自定义类加载器加载的类——所以热部署、插件化场景必须确保类加载器可被 GC
- 检查手段：用
jcmd <pid> VM.native_memory summary</pid>或 MAT 分析元空间占用，重点关注ClassLoader实例数量
反射调用 private 方法的安全拦截
看似一行 setAccessible(true) 就能调，但生产环境常被静默拦住。
- SecurityManager 启用时，
setAccessible会触发ReflectPermission("suppressAccessChecks")检查 - Java 9+ 模块系统下，即使没 SecurityManager，跨模块访问 private 成员也会受限
- 建议只在测试、调试、框架内部使用；生产代码尽量避免绕过封装
- 若必须用，提前在 JVM 启动参数中加
--add-opens java.base/java.lang=ALL-UNNAMED开放模块权限
