system.gc()不能可靠触发类卸载或运行期注入，仅是gc建议；真正实现需类加载器隔离、可卸载性保障与动态字节码加载，并通过生命周期管理（如spring boot沙箱）控制注入节奏。
System.gc() 本身不能可靠触发类卸载，更不能直接用于“运行期注入”——它只是向 JVM 发出一次垃圾回收建议，是否执行、何时执行、执行哪类 GC，完全由 JVM 决定。真正实现运行期注入的关键，是类加载器隔离 + 可卸载性保障 + 动态字节码加载，System.gc() 在其中仅是一个（不推荐依赖的）辅助观察手段。
下面直击重点，讲清楚怎么做：
类加载器沙箱是注入的前提
必须让每次新版本的类走独立的 ClassLoader 实例（如 URLClassLoader 或自定义 SecureClassLoader），且确保：
- 该加载器不被任何静态引用、线程、
ThreadLocal或缓存持有 - 它加载的所有类实例（包括单例对象）已全部脱离 GC Roots
- 加载器自身无强引用（例如不要赋值给
static字段）
// ✅ 正确：局部作用域 + 显式释放
ClassLoader loader = new URLClassLoader(urls, null);
Class> newService = loader.loadClass("com.example.NewServiceImpl");
Object instance = newService.getDeclaredConstructor().newInstance();
// 使用完毕后，显式切断引用（loader 是局部变量，方法退出即不可达）
// 同时确保 instance 不被其他地方缓存
注入 ≠ 热替换，而是“旧退新进”
JVM 不支持对已加载类的字段/方法原地修改。所谓“注入”，本质是：
- 卸载旧类加载器（连带其所有类和实例）
- 创建新类加载器，加载新版字节码
- 用新类构造新实例，替换旧引用
这要求业务层设计为可重入、无状态或可迁移状态。例如：
- 避免
static final持有业务对象 - 用
ServiceRegistry.replace(Service.class, newImpl)替代硬编码new ServiceImpl() - 状态尽量外置（如 Redis、DB），而非堆内单例
System.gc() 的真实用途：仅用于调试验证
你可以在卸载前手动触发 GC，再检查 Metaspace 是否收缩、jcmd <pid> VM.native_memory summary</pid> 是否回落，来确认类卸载是否发生。但生产环境严禁调用 System.gc() 控制流程，原因包括：
- 它可能触发 Full GC，造成秒级 STW
- OpenJDK 17+ 默认禁用显式 GC（需
-XX:+ExplicitGCInvokesConcurrent） - 即使 GC 运行，也不保证卸载——类加载器若仍有弱引用（如
WeakHashMap中的 key），就不会被回收
真正可控的注入节奏靠的是“生命周期管理”
推荐做法是结合 Spring Boot 4.0 的轻量沙箱机制或自定义 RuntimeContext：
# application.properties spring.sandbox.enabled=true spring.sandbox.plugins=hotswap spring.sandbox.classloader.strategy=isolated
此时框架会在 ApplicationContextRefreshedEvent 后接管类加载，提供 SandboxClassLoader，并自动在模块更新时：
- 关闭旧
ClassLoader的资源（数据库连接、线程池等） - 等待所有实例完成处理（优雅下线）
- 触发一次并发 GC（非
System.gc()，而是ManagementFactory.getMemoryMXBean().gc()+ 回调钩子） - 加载新类，发布新 Bean
这种机制下，你不需要写 System.gc()，只需调用 sandboxManager.reloadModule("payment-core")。
不复杂但容易忽略。
