SharedLock ThreadLocal threadWriters memory leak may cause CPU usage to reach 100% #3489

[tishun]

In certain cases (see #3489) the cleanup in ThreadLocalMap.expungeStaleEntry() might spike CPU usage because of excessive number of ThreadLocalMap entries.

We attempt to alleviate this problem by cleaning the ThreadLocal variable for threads that close the respective connection.

Closes #3489

Make sure that:

• You have read the contribution guidelines.
• You have created a feature request first to discuss your contribution intent. Please reference the feature request ticket number in the pull request.
• You applied code formatting rules using the mvn formatter:format target. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.

[jit-ci]

❌ The following Jit checks failed to run:

• secret-detection-trufflehog
• static-code-analysis-semgrep-pro

#jit_bypass_commit in this PR to bypass, Jit Admin privileges required.

More info in the Jit platform.

[a-TODO-rov]

Not sure this will work, because the thread that calls cleanup might not be the thread that holds the lock in its ThreadLocalMap.
I checked it in SDR context as in the users issue and seems the thread calling cleanup is Thread[#48,commons-pool-evictor,5,main] a commons-pool thread, that doesn't contain SharedLock in it's own ThreadLocal.ThreadLocalMap.
And if we see what remove does:

public void remove() {
         remove(Thread.currentThread());
}
                        ||
                        \/

private void remove(Thread t) {
         ThreadLocalMap m = getMap(t);
         if (m != null) {
             m.remove(this);
         }
}

[tishun]

Not sure this will work...

You are absolutely correct!

Should have not trusted the vibe. Let me spend some more time thinking on this.

Good catch.