热加载必须打破双亲委派机制，通过自定义类加载器重写loadClass方法、跳过父委托、新建实例隔离加载新字节码，并配合引用释放与框架适配才能生效。
自定义类加载器实现热加载，关键不是绕过安全约束，而是让每次修改后的类能被重新加载进 JVM。这必须打破双亲委派——否则旧类早已被 AppClassLoader 加载并缓存，新版本根本没机会入场。
热加载为什么必须打破双亲委派
默认情况下，JVM 会把类加载请求层层上抛，最终由 AppClassLoader 加载并长期持有。一旦某个类（比如 UserService.class）被它加载过，后续所有同名请求都会直接返回已加载的 Class 实例，不会重新读取字节码。热加载要替换这个实例，就必须让新字节码走一条“不经过 AppClassLoader”的路径——也就是自己加载、自己定义、自己控制生命周期。
核心操作：重写 loadClass，跳过父委托
只重写 findClass 不够，它只是“怎么加载”，而 loadClass 才决定“谁来加载”。热加载类加载器需覆盖整个加载入口：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 先调用 findLoadedClass(name) 检查是否已加载（避免重复定义）
- **不调用 super.loadClass()**，直接执行自己的 findClass(name)，从指定路径（如 target/classes 或临时目录）读取最新 .class 字节流
- 调用 defineClass() 将字节码转为 Class 对象，完成定义
- 仅当本地找不到时，才 fallback 到父加载器（可选，通常用于加载 JDK 类）
配合 ClassLoader 实例隔离才能真正生效
一个 ClassLoader 实例只能 defineClass 同一个类一次，重复调用会抛 LinkageError。所以热加载不是“刷新同一个加载器”，而是：
- 每次编译后，新建一个独立的类加载器实例（如 NewHotSwapClassLoader）
- 用它加载更新后的类，生成全新的 Class 对象
- 老对象逐步被 GC（需确保原实例、原 Class 引用全部释放）
- 业务代码通过反射或接口统一调用新类实例，完成切换
实际使用中的关键细节
热加载不是改完代码就自动生效，还依赖几个隐性条件：
- 被热更的类不能是 JDK 核心类（如 java.lang.String），这些类受 JVM 保护，无法被自定义加载器替换
- 类中引用的其他类，如果也变了，需保证它们被同一新加载器加载，否则出现 NoClassDefFoundError
- 静态字段和初始化块会在 defineClass 后重新执行，但原有静态状态不会自动迁移
- 若使用 Spring 等框架，需配合其 RefreshScope 或自定义 Bean 替换逻辑，否则容器仍持旧引用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
