热部署核心是可控中断双亲委派链，通过自定义classloader绑定独立路径（如hotdeploy/xxx.jar）、重写loadclass跳过父委派、利用tccl注入上下文，并确保类隔离与可卸载。
要实现服务架构的动态热部署，核心不是“绕开”双亲委派，而是有控制地、可追溯地“中断委派链条”，让特定类由更灵活的加载器负责——这本质上是重构类加载的决策路径，而非简单 bypass。
热部署依赖的物理加载路径必须隔离
标准双亲委派下，所有 class 都经 Application → Extension → Bootstrap 向上透传，一旦加载即锁定在方法区，无法卸载或替换。热部署要求同一类名能被多次加载、旧实例可回收、新版本可即时生效——这就必须打破“全盘负责+不可卸载”的默认行为。
关键物理路径约束：
- 每个热更新模块（如一个 Spring Boot 的 starter 或微服务子模块）需绑定独立的自定义 ClassLoader 实例，其 parent 显式设为 ApplicationClassLoader，但不复用其 loadClass 逻辑；
- 该 ClassLoader 的字节码来源不能是 classpath 标准路径，而必须指向可变位置：如 ./hotdeploy/com.example.service-v2.jar 或内存中的 byte[]；
- 类加载后生成的 Class 对象必须与旧版本 Class 对象处于不同 ClassLoader 命名空间，否则 JVM 视为同一类，instanceof 判定失败、类型强转报 ClassCastException。
线程上下文类加载器（TCCL）是委派链的“可控断点”
双亲委派是“向上查”，但 TCCL 提供了向下注入能力——它不参与委派流程，而是作为运行时上下文被显式读取。Spring、Tomcat、Dubbo 等框架均依赖此机制实现插件/模块隔离。
典型物理路径操作：
- 启动时通过 Thread.currentThread().setContextClassLoader(customLoader) 将当前线程绑定到新加载器；
- 框架内关键入口（如 Servlet 初始化、BeanFactory 创建）会主动调用 Thread.currentThread().getContextClassLoader().loadClass(...)，跳过默认委派；
- JDBC Driver 加载就是经典案例：Bootstrap 加载的 DriverManager 调用 ServiceLoader，后者内部使用 TCCL 加载 com.mysql.cj.Driver，从而让应用级驱动脱离 rt.jar 范围限制。
自定义 loadClass 是破坏委派的硬性入口
继承 ClassLoader 后，不调用 super.loadClass()，也不调用 parent.loadClass()，才是真正切断委派。重点不在 findClass，而在 loadClass 的控制权归属。
最小可行实现要点：
- 重写 loadClass(String name, boolean resolve)，完全跳过父类委派逻辑；
- 自行调用 findClass(name) 从指定路径读取字节码（支持 jar/zip/file/url），再用 defineClass() 注入 JVM；
- 若类依赖其他类（如 new XxxService()），需确保这些依赖也走同一套加载路径，或显式委托给 TCCL —— 否则触发 NoClassDefFoundError；
- 类卸载前提：该 ClassLoader 实例不可达（无强引用）、其所加载的所有 Class 实例已不可达、JVM 执行 Full GC（仅当使用 CMS/G1 且开启 ClassUnloading 时才可能真正卸载）。
真实热部署场景中的路径闭环示例
以一个 Web 模块热更新为例，物理路径流转如下：
- 运维上传新包 → 存入 /app/modules/user-service-1.2.0-hot.jar；
- 管理端触发 reload → 创建新 CustomClassLoader，parent=AppClassLoader，资源路径指向该 jar；
- 通过 TCCL 加载主配置类 UserServiceConfig.class，并反射初始化新 ApplicationContext；
- 旧 ApplicationContext 中的 Bean 实例逐步被 GC 回收，新实例接管请求流量；
- 旧 ClassLoader 对象失去引用，下次 Full GC 后其加载的所有类元数据从方法区清除。
这个过程不修改 JVM 底层，不 hack 类加载器层级，只在应用层重建委派边界——破坏的是机制执行路径，不是机制存在本身。
