重写 loadClass 会失效，因为 JVM 在 new、invokestatic 等场景下不调用该方法，而是硬编码委托父加载器；真正可拦截的入口是 findClass，需确保父加载器找不到目标类且正确重写 findClass。
为什么重写 loadClass 会失效？双亲委派不是被绕过了吗
重写 loadClass 却发现自定义逻辑根本没执行，常见于直接调用 ClassLoader.loadClass(String) 后仍走系统类加载器。问题出在：JVM 在多数场景（如 new、invokestatic）触发类加载时，**不调用你重写的 loadClass，而是直接委托给父加载器**——因为双亲委派是 JVM 层硬编码的流程，不是靠 Java 方法调用链实现的。
真正能拦截的入口只有两个：findClass(String) 和 defineClass。但 findClass 默认抛异常，必须重写；而 loadClass 的默认实现里，先委派、失败后才调 findClass。所以如果你没触发“父加载器找不到”的条件，你的 findClass 就永远不会跑。
- 确保你要加载的类名不在
Bootstrap、Extension、AppClassLoader的路径下（比如别叫java.lang.String） - 不要在
loadClass里直接调defineClass，这会跳过验证和链接阶段，大概率抛LinkageError - 调试时加日志到
findClass，而不是loadClass—— 前者才是你该动的手脚
热部署时类卸载失败：ClassNotFoundException 反复出现
热部署失败的根因往往不是加载，而是卸载。JVM 规定：一个类能否被卸载，取决于它的 ClassLoader 是否可被 GC 回收。而只要这个类加载器加载过的任何类对象还活着（哪怕只是某个静态字段引用），它就无法回收。
典型陷阱是：你 new 出一个对象并把它塞进全局缓存（比如 static Map），或者注册到监听器、线程局部变量、日志框架上下文里。这些引用会让整个类加载器及其所有已加载类锁死在内存中。
- 每次热替换前，显式清空所有你控制的静态引用、线程局部变量（
ThreadLocal.remove()）、回调注册表 - 避免在自定义类加载器里持有业务对象引用（比如把
ApplicationContext存成字段） - JDK 8+ 中，
WeakReference包裹类实例对卸载帮助有限；真正关键的是切断从 GC Roots 到ClassLoader的强引用链
defineClass 报 ClassFormatError 或 NoClassDefFoundError
这两个错误看着像字节码问题，实际八成是类路径污染或资源读取不完整导致的。比如用 FileInputStream 读取 class 文件但没校验长度，或从 jar 包里解压时漏了依赖类（尤其是 module-info.class 或嵌套类的 .class）。
defineClass 不做类路径解析，只认原始字节数组。它看到非法魔数、常量池损坏、超长方法字节码，就会直接炸。而 NoClassDefFoundError 更隐蔽：它发生在链接阶段，说明类定义成功了，但某个符号引用（比如父类、接口、字段类型）在当前类加载器里找不到。
- 读取 class 字节码务必用
Files.readAllBytes(path)或确保InputStream完整读到 EOF，别信available() - 如果目标类依赖其他类，确保它们也由同一个类加载器加载（或提前放在父加载器里），否则
defineClass成功，后续首次主动使用时才报NoClassDefFoundError - 用
javap -v对比原始 class 和你读出来的字节数组是否一致，尤其看ConstantPool大小和Superclass索引
Spring Boot DevTools 热替换 vs 自定义类加载器冲突
DevTools 默认用两个类加载器：RestartClassLoader 加载应用类，BaseClassLoader 加载 Spring、Tomcat 等基础类。它靠文件监听 + 进程级重启模拟热部署，**并不依赖打破双亲委派**。如果你在同一项目里又写了自定义类加载器，很容易互相干扰。
最常见现象是：修改代码后 DevTools 检测到了，但新类没生效，还是老行为。这是因为你的自定义加载器可能缓存了旧类，或加载路径和 DevTools 的 RestartClassLoader 重叠，导致类被重复定义（LinkageError）。
- 开发阶段优先用 DevTools，别自己造轮子；真要定制，关掉
spring.devtools.restart.enabled=true，再单独启动你的加载逻辑 - 自定义类加载器的
parent显式设为Thread.currentThread().getContextClassLoader()，而不是null或ClassLoader.getSystemClassLoader()，避免脱离 Spring 的类加载上下文 - 如果必须共存，确保你的加载器只负责特定包路径（如
com.example.hot.*），并在findClass里用name.startsWith("com.example.hot.")做精准拦截
类加载器不是黑盒开关，它是 JVM 类型系统的锚点。改错一个 parent 字段、漏掉一次 ThreadLocal.remove()、多持有一个静态引用，都可能让热部署卡在最后一公里。细节不在文档里，在 GC 日志和 jcmd 的输出里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
