Java热更新本质是新建ClassLoader加载新类，而非重载已加载类；因JVM禁止重复定义同名类，且Instrumentation仅支持方法体修改，故必须绕过双亲委派、每次新建加载器实例，并警惕静态变量、ThreadLocal和JNI导致的内存泄漏。
Java 动态类加载是热部署和热修复的唯一可行基础，但 JVM 本身不支持“替换已加载类”，所有所谓“热更新”本质都是用新 ClassLoader 加载新版本类，旧类靠 GC 间接卸载——这不是魔法，是权衡。
为什么不能直接 reload 一个已加载的 class
当你调用 ClassLoader.defineClass() 第二次定义同一个全限定名的类时，JVM 会抛出 java.lang.LinkageError: attempted duplicate class definition。这是硬性限制，不是配置问题。JVM 的类模型要求“一个类加载器 + 一个类名 = 唯一 Class 对象”，重复定义直接拒绝。
- 系统类加载器（如
AppClassLoader）内部缓存了所有已加载的Class，你无法绕过它清空缓存 -
Instrumentation.redefineClasses()虽然能改字节码，但只允许修改方法体，不能增删字段/方法、不能改签名——对业务代码基本不可用 - 真正能“换掉”逻辑的，只有新建一个自定义
ClassLoader实例，用它加载新字节码，再通过反射或接口代理切换引用
自定义 ClassLoader 是热部署的最小可行单元
写一个能热加载的 ClassLoader，关键不在重写 loadClass()，而在彻底绕过双亲委派、控制字节码来源，并确保旧加载器可被回收。
- 必须重写
findClass(String name)，而不是loadClass()：前者是你加载字节码的入口；后者默认走双亲委派，会先委托给AppClassLoader，导致你永远加载不到自己的新版 - 字节码来源要可控：从文件系统读取
.class文件（比如监听target/classes/）、或从内存编译器（JavaCompiler）获取，别依赖getResourceAsStream()——它走的是当前线程上下文类加载器，容易串包 - 每次热更新必须 new 一个新加载器实例：旧加载器里所有
Class和其实例都会变成“孤立对象”，GC 才可能回收；复用同一个加载器实例等于白干
示例核心片段：
public class HotSwappingClassLoader extends ClassLoader {<br> private final String classDir;<br><br> public HotSwappingClassLoader(String classDir) {<br> super(null); // parent == null，彻底切断双亲委派<br> this.classDir = classDir;<br> }<br><br> @Override<br> protected Class<?> findClass(String name) throws ClassNotFoundException {<br> byte[] bytes = loadClassBytes(name); // 自己读 .class 文件<br> return defineClass(name, bytes, 0, bytes.length);<br> }<br>}
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
热部署 ≠ 热修复，它们的约束完全不同
热部署（如 Spring Boot DevTools）本质是进程级重启：它检测到类变更后，停掉老 ApplicationContext，销毁所有 Bean，再用新 ClassLoader 启动新上下文。而热修复（如 Android Tinker、Java Agent 方案）目标是“不重启、不中断用户操作”，代价是极度受限。
- 热部署可改任意代码，但用户请求会短暂 503；热修复只能打补丁：通常只允许替换某个具体方法（靠字节码插桩），且必须保证新旧方法签名完全一致
- Spring Boot DevTools 的自动重启依赖于两个条件：
spring.devtools.restart.enabled=true（默认 true），且 IDE 必须开启Build project automatically—— 缺一不可，否则改了代码也没反应 - 真实生产环境的热修复几乎都依赖 Java Agent（
Instrumentation）+ 字节码增强（如 Byte Buddy），不是靠反复 new ClassLoader：因为后者会导致Metaspace持续增长，最终java.lang.OutOfMemoryError: Metaspace
最容易被忽略的三个内存陷阱
动态加载玩得越熟，越容易栽在内存上。不是代码逻辑错，而是类加载器生命周期没管住。
- 静态变量持有旧
Class或其对象引用：比如private static Map<String, Object> cache = new HashMap<>();里存了旧类实例，GC 就永远无法回收那个ClassLoader - 线程局部变量（
ThreadLocal）未清理：尤其在线程池场景下，worker 线程复用，ThreadLocal里的旧类引用会常驻内存 - JNI 或 NIO Direct Buffer 绑定旧类：一旦 native 层持有 Java 对象指针，JVM GC 完全无能为力，只能靠显式释放（如
cleaner或sun.misc.Unsafe）
验证是否泄漏？用 jcmd <pid> VM.native_memory summary 看 Metaspace 是否持续上涨；用 jmap -clstats <pid> 查看不同 ClassLoader 实例数量是否只增不减。
