核心是复用/缓存类并确保类加载器可回收，避免元空间因动态编译类泄漏而爆仓；需验证归因、控制类加载器生命周期、启用脚本缓存、施加硬性约束。
核心思路是：**不让每次脚本都生成新类，而是复用、缓存或预编译，同时确保类加载器可被回收**。方法区（Java 8+ 即 Metaspace）“类计数器爆仓”，本质是 JVM 中已加载的 Class 对象数量失控，而非堆内存不足。高频动态编译（如 Groovy、JRuby、自定义脚本引擎、JavaCompiler 动态编译）会持续注册新类，若类加载器未被 GC，这些类就永远驻留元空间。
确认是否真由脚本编译引发
别急着改代码，先验证归因：
- 执行 jstat -gc <pid>，观察 MU（Metaspace used）是否随脚本调用量线性上涨，且 MGCC（Metaspace GC 次数）长期为 0 或极低
- 运行 jmap -clstats <pid>，检查活跃类加载器数量——若出现成百上千个 GroovyClassLoader、DynamicClassLoader 或 URLClassLoader 实例，基本坐实问题
- 加参数 -XX:+TraceClassLoading -XX:+TraceClassUnloading（仅测试环境），看日志中是否密集出现 script_.*\.class、groovysh_.* 等命名模式的类加载记录
从类加载器生命周期入手控制
每个动态脚本类默认由独立的 ClassLoader 加载，这是泄漏根源。关键不是“少加载”，而是“能卸载”：
- 对 Groovy：不用
GroovyClassLoader实例，改用GroovyShell+ 共享CompilerConfiguration，并显式调用getClassLoader().close()（Groovy 3.0+ 支持） - 对 JavaCompiler 动态编译：自定义
JavaFileManager，复用同一套StandardJavaFileManager和缓存机制；避免每次 newDynamicClassLoader，改为单例 + 设置 parent 为应用类加载器，并在脚本执行完后主动clearCache() - 所有场景下，确保脚本对象（如
GroovyObject、CompiledScript）不被静态集合、Spring Bean 或线程局部变量（ThreadLocal）意外强引用，否则 ClassLoader 无法被 GC
启用脚本类缓存与预编译
把“每次编译”变成“按需编译+全局复用”，从源头减少类生成频率：
- Groovy：启用
CompilerConfiguration.setTargetDirectory(...)并设置setScriptBaseClass，配合ScriptEngineManager的缓存能力，相同脚本源码只编译一次 - JSR-223（如 Nashorn、GraalVM JS）：使用
Compilable接口预编译脚本，后续直接eval(compiled)，不触发新类定义 - 自研脚本引擎：在 AST 解析后生成字节码时，对相同语法结构做哈希签名，命中缓存则跳过字节码生成阶段
必要时施加硬性约束
防患于未然，用 JVM 参数和代码逻辑双保险：
- JVM 启动加 -XX:MaxMetaspaceSize=256m（根据实际压测设定），让问题提前暴露，而非静默堆积
- 代码中限制脚本最大长度、最大嵌套深度、最大执行时间，超限即拒绝编译（例如用
SecurityManager或自定义ScriptContext拦截） - 定期触发元空间 GC：通过
jcmd <pid> VM.runFinalization或在低峰期调用System.gc()（仅辅助，不依赖）
