Java类加载机制是热部署和插件化的底层核心，关键在于控制类加载器的创建、卸载与隔离；热部署通过替换ClassLoader实现，插件化则依赖自定义ClassLoader打破双亲委派以实现类隔离。
Java 类加载机制是热部署和插件化开发能落地的核心支撑，不是锦上添花的理论，而是决定“能不能做”“会不会出错”的底层能力。关键不在加载本身，而在于**控制类由谁加载、何时卸载、如何隔离**。
热部署靠的是“换加载器”，不是“重加载类”
同一个 ClassLoader 实例不能重复 defineClass 同名类，否则抛 LinkageError。所以热部署不是让旧加载器 reload 一个类，而是：
- 停止对旧类实例的引用（如 Web 应用中销毁 ServletContext、清空线程局部变量）
- 确保旧 ClassLoader 实例不再被任何对象强引用（包括静态字段、ThreadLocal、缓存等）
- 触发 GC —— 只有当 ClassLoader 被回收，它加载的类才可能被卸载（满足：类无实例、ClassLoader 无引用、Class 对象无引用）
- 创建全新 ClassLoader 实例，用它重新 loadClass 修改后的字节码
Tomcat 的 webapp classloader、Spring Boot DevTools 的 RestartClassLoader、JRebel 的动态类替换，都遵循这个逻辑。区别只在“如何安全切断引用”和“如何高效生成新字节码”。
插件化依赖类加载器的隔离与按需加载
插件系统要求各插件的类互不干扰，且能独立启停。这靠的是为每个插件分配独立的 ClassLoader，并打破双亲委派：
- 插件类加载器通常将父加载器设为 shared loader（共享基础服务），但不委托给 AppClassLoader 加载插件自身代码
- 插件内部调用自己 jar 包里的类时，由本插件 loader 直接 findClass + defineClass，避免被主程序的类覆盖（比如两个插件都含 fastjson 2.0 和 1.2，互不影响）
- 插件间通信通过父加载器提供的标准接口（如 SPI 接口或 OSGi Service），保证类型兼容性
- 卸载插件时，只需置空该插件 loader 引用，GC 后其所有类自动失效
典型例子：IDEA 的插件机制、Eclipse 的 OSGi、阿里 P3C 插件、自研 SaaS 系统的租户级功能模块隔离。
绕过双亲委派不是乱来，而是有明确目的
重写 loadClass() 并跳过 parent.loadClass()，必须清楚为什么破戒：
- 热部署：防止修改后的类被 AppClassLoader 提前加载旧版本
- 插件/沙箱：防止插件里恶意重定义 java.lang.String 等核心类（注意：Bootstrap 加载的类永远无法被替换，JVM 层有限制）
- JDBC 驱动加载：ServiceLoader 使用线程上下文类加载器（TCCL），让第三方驱动能被应用类加载器发现，而非被 Bootstrap 拦截
真正危险的不是打破委派，而是打破后没管好资源生命周期——比如忘了清理 static 缓存，导致 ClassLoader 泄漏，最终 metaspace OOM。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
