反射机制不能实现热部署，其作用仅限于新类加载后的实例创建、方法调用与字段访问；热部署依赖自定义类加载器隔离、运行时实例替换及代理层转发。
反射机制本身不能直接实现热部署或类重载，它只是执行环节的“桥梁”——真正起作用的是类加载器隔离 + 运行时新类实例替换 + 逻辑与数据分离。JVM禁止同一个ClassLoader重复定义同名类，也禁止替换已加载类的字节码。所以靠Class.forName("X").getMethod("run").invoke()改完代码再编译，是完全无效的。
反射在热部署中只负责调用，不负责加载
反射的作用很明确：在新类已由新ClassLoader加载成功后，帮你创建实例、调用方法、访问字段。它不参与文件监听、不触发类重载、也不管理类加载器生命周期。
- 用
newLoader.loadClass("com.example.ServiceImpl")加载新类（不是反射，是类加载器行为） - 用
clazz.getDeclaredConstructor().newInstance()创建新实例（反射参与） - 用
method.invoke(instance, args)执行业务逻辑（反射核心用途） - 若需重置状态或注入依赖，可配合
field.setAccessible(true); field.set(oldObj, newValue)（反射辅助过渡）
必须搭配自定义类加载器才能生效
每次更新类，都要新建一个独立的ClassLoader（如URLClassLoader），让它从磁盘读取修改后的.class文件。旧ClassLoader及其加载的所有类仍驻留内存，但不再被使用；新ClassLoader加载的新类与旧类在JVM中视为完全不同类型（==为false）。
- 不能复用已有ClassLoader调用
defineClass()重载同一类——会抛LinkageError: attempted duplicate class definition - 确保旧ClassLoader无强引用（如静态变量持有、线程局部变量未清理），否则无法被GC，导致PermGen/Metaspace溢出
- 推荐按模块粒度隔离：每个Service对应一个ClassLoader，便于单独卸载
需要代理层统一转发调用
外部代码不能硬编码调用具体实现类，而应面向接口或抽象基类。所有请求经由一个代理对象中转，该代理内部维护当前生效的实例引用，并在热更后原子替换。
立即学习“Java免费学习笔记（深入）”；
- 代理类持有
Object instance和Class> clazz，所有public方法都通过反射转发到instance - 热更流程：监听文件变化 → 创建新ClassLoader → 加载新类 → 实例化 → 替换代理中的
instance字段 - 关键点：替换过程要线程安全（如用
AtomicReference），避免调用中途出现半新半旧状态
注意注解和Spring容器的兼容性问题
如果类上有@Scheduled、@EventListener等运行时注解，单纯靠反射+新ClassLoader重载会导致这些注解失效——因为Spring容器注册的是旧Class的Method引用，新Class虽同名但身份不同。
- 避免在热更类上放关键框架注解；把定时任务、事件监听拆到不热更的稳定模块中
- 如必须支持，可在热更后主动触发重新扫描：例如调用
taskScheduler.schedule(...)手动注册，或监听ContextRefreshedEvent做兜底注册 - JRebel等商业工具内部做了大量适配，但纯手写方案建议绕开注解依赖，改用显式API调用
