Java Metaspace leaks due to Pipeline code

Last Reviewed:2025-10-16()
1 minute readKnowledge base

Issue

When using @Grab then using import for third party libraries, or using ConfigSlurper, or Eval in Pipeline code, you may encounter a Java Metaspace leak. This issue arises because each time the Pipeline is executed, the Pipeline code to clean up classes was only cleaning up Groovy classes, not Java classes. Over time, these accumulate in the Java Metaspace, causing a memory leak.

An example of the Pipeline code that can cause this issue from https://github.com/jenkinsci/pipeline-groovy-lib-plugin/pull/199 is:

@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1')
import groovyx.net.http.RESTClient
▼

Another example related to ConfigSlurper from https://github.com/jenkinsci/workflow-cps-plugin/pull/122 is:

new ConfigSlurper().parse(...)
▼

Another example that causes Metaspace leaks is using Eval in Pipeline code:

Eval.me("...")
▼

Environment

Resolution

The ideal resolution is to avoid using @Grab, ConfigSlurper, or Eval in Pipeline code. Instead use sh or bat steps to call external scripts, as per Using third-party libraries.

The fix for @Grab is resolved in CloudBees CI version 2.528.1.29783.

Tested product/plugin versions

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.