使用ClassValue时ClassLoader泄漏的根因分析及预防方案咨询

当启用-Dgroovy.use.classvalue=true时，Groovy使用GroovyClassValueJava7（继承自Java官方ClassValue类），问题核心在于JavaClassValue机制与基础类型类的生命周期绑定特性：

• 基础类型（void.class、float.class等）由启动类加载器加载，生命周期与JVM完全一致，永远不会被GC回收。
• 当Groovy为这些基础类型注册ClassValue关联时，JVM的ClassValue实现会通过JNI全局引用持有对应的GroovyClassValueJava7实例。
• GroovyClassValueJava7实例会间接持有自定义ClassLoader的引用，即便调用InvokerHelper.removeClass清除了自定义加载类的映射，基础类型的ClassValue关联仍会保留，导致JNI全局引用持续卡住自定义ClassLoader，无法被GC回收，反复测试后触发OOME。

而禁用-Dgroovy.use.classvalue=false时，Groovy使用自研的GroovyClassValuePreJava7，它通过弱引用维护类关联，不会被基础类型的全局引用绑定，因此ClassLoader能正常被回收。

• 保持禁用Java7 ClassValue实现：继续用-Dgroovy.use.classvalue=false启动测试，依赖Groovy自带的弱引用机制，从根源避免泄漏。
• 跳过基础类型的Groovy元数据注册：检查测试代码或rest-assured框架逻辑，若存在为基础类型生成扩展方法、元类的操作，手动跳过这些基础类型的处理，避免为其注册ClassValue关联。
• 复用自定义ClassLoader：若测试场景允许，不要每次测试都创建新的自定义ClassLoader实例，复用加载器可减少GC压力，避免频繁创建导致的堆积。
• 反射清理ClassValue关联（不推荐）：若必须启用Java7的ClassValue，可通过反射获取ClassValue内部存储结构（如JDK内部的ClassValueMap），移除基础类型对应的GroovyClassValueJava7条目。但此方法依赖JDK内部实现，不同版本兼容性差，风险较高。

内容的提问来源于stack exchange，提问作者Nicolas Filotto