How threadlocal is different from method level variable

Question

If I use the threadlocal variable, each thread gets a local copy of the variable. My first question is: if each thread mutates a variable, will the changed value remain in its local copy? Or at some point he will also try to update the "global variable", and we will encounter concurrency problems?

My other question is: if I declare a variable in a method, then each thread executing the method on its own stack will get its own copy. So, do we declare the level variable of the method the same as its threadlocal?

Answer 1

First question: each thread updates its copy of the threadlocal variable, the global state is not shared between threads.

The second question: if you declare a local variable, it behaves similarly to threadlocal - each thread has its own copy, but you do not have global access to it, for example. in another method - that when threadlocal is useful.

Answer 2

The easiest way to look at a ThreadLocal<T> object is Map<Thread, T> , where a call to ThreadLocal#get() will look for the correct value by calling Map#get(Thread.currentThread()) in the base Map . Note that this is not an actual implementation, but the easiest way to look at it.

ThreadLocal variables are only useful as members, which can actually be accessed by multiple threads at the same time. Local variable declarations in a method are simply local and therefore not available to other threads. I would not say that they are "the same", but that they are both thread safe.

A typical application would be a member variable of an instance of a singleton object or a static member variable of a class in a multi-threaded environment.

Basically, you will see what they used to transmit request request information in the servlet environment.

Answer 3

If I use the threadlocal variable, then each thread receives a local copy of the variable

I think there is some cunfusion regarding the term local copy of a variable. No copy. Each thread gets its own variable; they are independent of each other. This does not mean, however, that they cannot contain a link to a shared object. Thus, just using threadlocal variables alone will not save you from concurrency issues.

Regarding your second question: None. Local variables and threadlocal variables are different. Local variables are not available outside the block in which they are defined. Therefore, for example, calling the same method twice will result in a different value each time. Threadlocal variables, on the other hand, retain their values ​​as long as the thread exists.

Basically, threadlocal variables are kind of “static” variables for a single thread.

Answer 4

An important point in the ThreadLocal variable is global access. It can be accessed from anywhere in the stream. In any case, which causes this thread context.

If you want to save one instance of a variable for all instances of the class, you will use member variables of the static class for this. If you want to maintain a variable instance for each thread, you will use local thread variables. ThreadLocal variables differ from ordinary variables in that each thread has its own individually initialized instance of the variable, which it accesses through the get () or set () methods.

Suppose you are developing a multi-threaded code tracer whose purpose is to uniquely identify each flow path through your code. The problem is that you need to coordinate multiple methods in multiple classes across multiple threads. Without ThreadLocal, this would be a difficult problem. When the thread started executing, it will need to create a unique token to identify it in the tracer, and then pass this unique token to each method in the trace.

With ThreadLocal, everything is simpler. A thread initializes a local thread variable at the start of execution, and then accesses it from each method in each class with the confidence that the variable will only contain trace information for the current executable thread. When this is done, the thread can send its trace, depending on the thread, to the control object responsible for maintaining all the traces.

Using ThreadLocal makes sense when you need to store instances of variables on each thread.