Performance optimization in CloseableThreadContext.closeMap() #2292
Description
Description
Excess work is performed in CloseableThreadContext.closeMap() that shows up as a production hotspot in our client-facing, latency-sensitive application. Specifically, the use of multiple calls to ThreadContext.remove() and ThreadContext.put() causes multiple copy-and-modify operations in the underlying ThreadContextMap. The attached java files compare the performance of the original code vs. a modification that groups keys by remove vs. replace, and makes zero or one calls to ThreadContext.remove() and ThreadContext.put().
On my system, tests with thread locals disabled (Constants.ENABLE_THREADLOCALS == false) show a 40% improvement:
Done with old in 521
Done with old in 535
Done with old in 537
Done with old in 516
Done with old in 516
Done with new in 284
Done with new in 285
Done with new in 284
Done with new in 301
Done with new in 292
With thread locals enabled (Constants.ENABLE_THREADLOCALS == true) show a 20% improvement:
Done with old in 386
Done with old in 388
Done with old in 386
Done with old in 389
Done with old in 408
Done with new in 308
Done with new in 309
Done with new in 307
Done with new in 307
Done with new in 313
The impact of the thread locals flag is because of the different implementations of ThreadContextMap. However, both cases demonstrate substantial improvement.
Configuration
Version: 2.20
Operating system: Affects all - tested on Linux and Windows
JDK: Tested on OpenJDK 8 and OpenJDK 17
Logs
CloseableThreadContextSpeedTest.java.txt
Reproduction
See attached file.