Optimise CleaningThreadLocal orphan cleanup by caching Thread.isAlive() results

[peter-lawrey]

Reduce repeated Thread.isAlive() calls during CleaningThreadLocal orphan cleanup by caching liveness per thread for the duration of a cleanup pass.

Problem

doCleanupNonCleaningThreads() iterates over nonCleaningThreadValues, where multiple entries can belong to the same thread. Before this change, Thread.isAlive() was called for every entry, which can turn cleanup into an effective O(n * m) repetition of a non-trivial/native operation when many values are associated with fewer threads.

In practice this showed up as timeout pressure in tests, with stack traces spending significant time in Thread.isAlive() during orphan tracking cleanup.

Change

This change introduces a per-pass IdentityHashMap<Thread, Boolean> to memoise thread liveness:

• compute isAlive() at most once per Thread during a cleanup pass
• reuse the cached result for subsequent entries for the same thread
• preserve the existing cleanup/removal behaviour for dead threads

Using IdentityHashMap keeps the cache aligned with thread identity semantics.

Why

This improves efficiency by:

• avoiding repeated native/non-trivial isAlive() calls
• reducing duplicated work when multiple thread-local values map to the same thread
• lowering the risk of pathological cleanup costs and related test timeouts

Behavioural impact

No intended functional change.
The cleanup logic is unchanged; this is a performance optimisation within a single cleanup pass.

Motivation

This change is motivated by observed timeout failures such as:

• TestTimedOutException: test timed out after 60 seconds
• stack traces repeatedly blocked in java.lang.Thread.isAlive(...)
• hot path: CleaningThreadLocal.doCleanupNonCleaningThreads(...)

Implementation notes

• cache scope is limited to one cleanup pass
• thread liveness is evaluated lazily via computeIfAbsent
• thread keys are compared by identity, not equality

Expected outcome

More predictable orphan-tracking cleanup performance, especially in cases where many tracked values reference the same set of threads.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tgd]

Does this cache need to be hoisted up a level?