元空间被撑爆的根本原因是动态模块卸载不彻底，导致类加载器及其加载的Proxy、EnhancerByCGLIB等类长期被强引用而无法卸载；需通过jcmd/jmap确认类加载器泄漏，并强制清理线程、ThreadLocal、静态引用及调用close()，同时禁用反射膨胀与优化CGLIB代理策略。
元空间被撑爆，根本不在“线程没销毁”，而在于动态模块加载后，其类加载器和生成的类一直被强引用住，无法卸载。弹性工作线程只是表象，真正钉在 metaspace 里的，是它背后加载的那些 $proxy、enhancerbycglib、generatedmethodaccessor 类——只要对应的 classloader 活着，这些类元数据就赖着不走。
关键不是杀线程，而是切断类加载器的存活链。
? 先确认是不是动态模块引发的类加载器泄漏
执行以下命令快速验证：
jcmd $PID VM.classloader_stats
关注 loadedClassCount 持续上涨、unloadedClassCount 几乎为 0 → 表明类卸载卡死，极大概率是模块卸载不干净。
再筛动态类：
jmap -histo:live $PID | grep -E "(Proxy|Enhancer|Generated|Accessor)"
如果出现大量 com.example.module.*$$EnhancerByCGLIB$$[a-z0-9]+ 或 sun.reflect.GeneratedMethodAccessor\d+，说明模块内用了 CGLIB 或反射膨胀，且未清理。
? 动态模块场景下类加载器常驻的典型原因
- 模块使用自定义
ClassLoader（如URLClassLoader）加载，但卸载时未显式close()，也未清除对它的静态/全局引用 - 模块中注册了监听器、回调、定时任务、线程局部变量（
ThreadLocal<SomeClass>），而SomeClass来自该模块类加载器 → 强引用锁死整个加载器树 - Spring Boot 的
@EventListener或ApplicationRunner在模块内定义，但容器未感知其生命周期，导致 Bean 实例长期存活 - 工作线程（如
Executors.newCachedThreadPool()）复用期间，Thread.currentThread().setContextClassLoader(moduleCL)后忘记重置，使线程持续持有模块类加载器
✅ 真正有效的解决动作
强制模块类加载器可被回收
卸载模块前，确保：
• 所有由该加载器创建的线程已终止（不只是 interrupt，要 join 或 awaitTermination）
• 清空所有ThreadLocal变量（调用remove()，尤其注意第三方库如 Logback、FastJSON 的隐式持有）
• 解除所有静态字段、单例、缓存（如 Guava Cache、Caffeine）对该模块类或实例的引用
• 调用URLClassLoader.close()（JDK7+），并置moduleClassLoader = null-
禁用反射膨胀，避免生成海量
GeneratedMethodAccessor
启动参数加：-Dsun.reflect.noInflation=true
这让反射跳过“先走 JNI 慢路径、再生成字节码快路径”的机制，统一走
NativeMethodAccessorImpl，不再动态产类。 限制 CGLIB 代理生成，改用静态增强或接口代理
若模块内用到 Spring AOP：
• 避免proxy-target-class=true（强制 CGLIB）；优先用 JDK Proxy（需接口）
• 使用@Scope("prototype")+ 显式销毁 Bean，而非依赖容器自动清理
• 对高频代理场景，改用编译期代理（如 MapStruct、Lombok@Delegate）-
启用并验证类卸载机制
根据 GC 类型配对应参数：- G1：
-XX:+UnlockExperimentalVMOptions -XX:+ClassUnloading - CMS：
-XX:+CMSClassUnloadingEnabled - Parallel GC：不支持类卸载 → 必须换 GC
然后压测模块反复加载/卸载，用jstat -gc $PID 2000观察MU是否随 Full GC 下降。若不降，说明仍有强引用未断。
- G1：
类卸载失败不是配置问题，是代码契约问题。动态模块的“按需加载”必须配套“按需解绑”——线程、监听器、上下文类加载器、静态缓存，一个都不能漏。
