根本原因是类卸载条件未满足：旧类实例未清空、ClassLoader对象不可达、无强引用持有类或加载器；热部署易致RestartClassLoader等“活死人”，因线程上下文类加载器残留、静态缓存、JNI/JMX强引用等导致无法回收。
Java中元空间在热部署期间爆满，根本原因不是类太多，而是旧类根本卸不掉——类卸载的前提必须同时满足三个条件：该类所有实例已全部死亡、加载它的ClassLoader对象本身已不可达、且没有任何地方（包括静态引用、JNI句柄、JVM内部缓存）还持有对该类或其类加载器的引用。Spring Boot DevTools、Tomcat redeploy、OSGi等热部署机制，恰恰容易打破这三者中的任意一环。
为什么热部署会让类加载器“活死人”
每次热重启时，框架会新建一个独立的ClassLoader（如RestartClassLoader、WebAppClassLoader）来加载新版本类，但旧ClassLoader并未被GC回收。常见卡点有：
- 线程上下文类加载器（Thread.currentThread().setContextClassLoader）仍指向旧加载器，尤其在线程池未清理或异步任务未结束时
- 静态字段缓存了旧类的实例或Class对象（例如Spring的CachedIntrospectionResults、Jackson的BeanDescriptionCache）
- JNI回调、JMX注册、日志框架（如Logback的LoggerContext）内部持有了旧ClassLoader的强引用
- 第三方库主动调用ClassLoader.getSystemClassLoader()并缓存，导致整个加载器链无法释放
快速验证是否为ClassLoader泄漏
不用等OOM，启动时加参数实时观测：
- -XX:+TraceClassLoading -XX:+TraceClassUnloading：看日志里Loaded数量飙升但Unloaded长期为0
- jcmd <pid> VM.class_hierarchy -all：统计不同ClassLoader实例数，若RestartClassLoader出现10+个且每个只加载几十个类，基本坐实泄漏
- jmap -clstats <pid>：重点关注DelegatingClassLoader、RestartClassLoader的实例数和平均加载类数，超过200个实例就是危险信号
从代码和配置层面切断泄漏链
热部署本身没问题，问题出在“没打扫干净”。关键动作要落在应用侧：
立即学习“Java免费学习笔记（深入）”；
- 禁用DevTools生产环境：Maven中用
<scope>runtime</scope>隔离，或启动时加--spring.devtools.restart.enabled=false - 主动清理静态缓存：在Spring的
@EventListener(ContextClosedEvent.class)里清空CachedIntrospectionResults.clear()、BeanUtils.copyProperties相关缓存 - 避免在static块或@PostConstruct中直接new GroovyShell()、AviatorEvaluator.newInstance()，改用单例+脚本缓存
- Tomcat部署时确保
antiJARLocking="true" antiResourceLocking="true"，并在context.xml中设置clearReferencesStatic="true"
让元空间回收真正生效的JVM参数组合
光开-XX:+ClassUnloading不够，G1下需配套启用并发类卸载：
- -XX:+UseG1GC -XX:+ClassUnloadingWithConcurrentMark（JDK9+默认开启，JDK8需显式加）
- -XX:MaxMetaspaceSize=256m：强制暴露问题，避免吃光系统内存
- -XX:MetaspaceSize=128m：设首次GC阈值，比默认值更早触发回收
- 不推荐
-XX:+CMSClassUnloadingEnabled：CMS已废弃，且仅配合CMS GC有效
热部署不是原罪，类加载器泄漏才是元空间崩盘的推手。重点不在压住报错，而在确保每次重启后旧ClassLoader能被真正回收——这需要框架配置、代码习惯和JVM参数三者协同。
