热部署关键在“准”和“稳”，需监听ENTRY_CREATE、ENTRY_MODIFY（可选ENTRY_DELETE），配合去抖、绕过双亲委派的自定义类加载器及实例生命周期管理，确保类隔离与资源清理。
用 WatchService 配合自定义类加载器做热部署，关键不在“快”，而在“准”和“稳”——避免类重复加载、静态字段污染、线程泄漏，同时确保只重载真正变更的类。JDK 原生 WatchService 轻量可靠，比轮询高效，比第三方监听库更可控，适合嵌入到自研工具链中。
WatchService 监听哪些事件才真正有用？
不是所有文件事件都需要响应。热部署关注的是「可执行字节码」的最终就绪状态，因此只需监听三类事件：
- ENTRY_CREATE：.class 文件首次生成（如编译完成）
- ENTRY_MODIFY：.class 文件内容被覆盖（常见于增量编译或 IDE 自动保存）
- ENTRY_DELETE（可选）：用于清理已卸载类的缓存引用，防止内存泄漏
注意：ENTRY_CREATE 和 ENTRY_MODIFY 可能高频触发（尤其在 IntelliJ 的「Build project automatically」模式下），建议加 200ms 去抖（debounce），等文件写入真正稳定后再处理。
自定义类加载器必须绕过双亲委派，但不能全盘放弃
直接继承 ClassLoader 并重写 loadClass(String, boolean) 是基础，但关键细节在于：
- 不调用
super.loadClass()，避免委托给 AppClassLoader 加载旧版本 - 只通过
findClass()从指定目录（如target/classes）读取字节码，自行defineClass() - 为每个热更类维护独立的
ClassLoader实例（或至少隔离的命名空间），确保新旧版本 Class 对象不共存 - 显式调用
clearAssertionStatus()和close()（若实现为URLClassLoader子类）释放资源
类替换不能只靠“重新 define”，得配合实例生命周期管理
光加载新 Class 没用——老对象还在运行，方法调用仍走旧字节码。必须主动干预运行时上下文：
- 对被热更的类，提前约定其 Bean 实例由工厂托管（如 Spring 中用
@Scope("prototype")+ 自定义ObjectFactory） - 监听到 .class 变更后，先销毁旧实例（调用
DisposableBean.destroy()或自定义钩子） - 用新 ClassLoader 创建新实例，并刷新依赖它的其他组件（如 Controller 中注入的服务）
- 避免直接替换单例 Bean，否则易引发
IncompatibleClassChangeError或状态错乱
实战小技巧：让 WatchService 真正“极速”响应
默认 WatchService 在 Windows 上可能延迟明显。优化方式包括：
- 监听粒度设为具体输出目录（如
target/classes/com/example/），而非整个项目根目录 - 注册时使用
StandardWatchEventKinds.ENTRY_CREATE和.ENTRY_MODIFY，禁用.ENTRY_DELETE（除非你真要清理） - 用
Thread.setDaemon(true)启动监听线程，避免阻塞 JVM 退出 - 对 .java 文件不做监听——交由 IDE 或构建工具触发编译；只盯住 .class，这是热更的唯一信源
不复杂但容易忽略：每次 defineClass 前校验字节码魔数（bytes[0]==(byte)0xCA && bytes[1]==(byte)0xFE...），防止误加载非 class 文件导致崩溃。
