230. Hooking ThreadLocal and virtual threads
In a nutshell, ThreadLocal was introduced in JDK 1.2 (in 1998) as a solution to provide dedicated memory for each thread in order to share information with untrusted code (maybe some of your code has been written externally as third-party components) or between different components (that may run in multiple threads) of your application. Basically, if you are in such a scenario, then you don’t want to (or you cannot) share information via method arguments. If you need a more in-depth introduction to the ThreadLocal API, then consider Java Coding Problems, First Edition, Chapter 11, Problem 220.
A thread-local variable is of type ThreadLocal and relies on set() to set a value and on get() to get a value. In Java Coding Problems, First Edition, it was said that: “If thread A stores the x value and thread B stores the y value in the same instance of ThreadLocal, then later on, thread A retrieves the x value and thread B retrieves...