[SUREFIRE-2186] Memory Leaks when reusing the fork

**[Clebert Suconic](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=clebertsuconic)** opened **[SUREFIRE-2186](https://issues.apache.org/jira/browse/SUREFIRE-2186?redirect=false)** and commented

It is not possible to run a very extensive test suite with the current version of surefire when you reuse the forks.

This used to work with surefire 2.22.2, and it's leaking with 3.1.2

In ActiveMQ Artemis, we have thousands of integration tests and we reuse the forks otherwise it would take an infinite amount of time to complete the test suite. and we had to revert to surefire 2.22.2 until this leak is resolved.

One obvious leak I see is org.apache.maven.surefire.api.util.internal.ClassMethod being held by ClassMethodIndexer, which is being held by Junit4RunListener.

Also, a bit scary the fact that ClassMethodIndexer is using a non static ThreadLocal. even though this is not holding ClassMethod instances, but since my complain is the test suite not being able to finish with the new SureFire maybe this is also causing issues.

I have been doing fine on pursuing leaks (even though it's not my main professional attribution :) but I created a pet project just for that purpose, if someone is interested in fixing this I will be certainly up to help fixing or even fixing it myself if I'm provided some guidance as I'm new to this codebase)

To reproduce the ClassMethod leak validation, you should follow these steps:

```java
git clone https://github.com/clebertsuconic/surefire-reproducer.git
cd surefire-reproducer
mvn install

```

The surefire-reproducer is using check-leak to count the number of ClassMethod instances in the HEAP.

Notice there might be other leaks like the one I mentioned with the non static ThreadLocal. Or even Junit4Listener itself. as I think the instance should be released at the end of the test.

BTW: Non static thread local is an anti-pattern. For example:

https://errorprone.info/bugpattern/ThreadLocalUsage

There are probably valid usecases with non static threadLocals, but I haven't seen one that couldn't be avoided.

---

**Issue Links:**
- [ARTEMIS-4359](https://issues.apache.org/jira/browse/ARTEMIS-4359) Upgrade Surefire when it stops leaking
(_**"is part of"**_)

0 votes, 6 watchers

Clone the surefire-reproducer project, enter it, and run mvn install to reproduce the heap-counting validation with check-leak. Trace the reported retention path involving ClassMethod, ClassMethodIndexer, and Junit4RunListener while reusing forks. Done means the retained ClassMethod instances no longer accumulate and the reproduction confirms the leak is resolved.

Written by the indexing model from the issue text.