Java Code Quality Improvement: using Threadlocal to maintain thread internal variables

In the above, "Java Code Quality Improvement: Selection of Synchronization Objects", we present a scenario: the train station has 3 ticket windows and 100 seats for a train. We completed the above function by locking a reliable synchronization object.

Now, let's turn, each window is responsible for a ride. For example, a window on the 1th train ticket, second window on the sale of the Ticket No. 2nd. But they need to start selling tickets at the same time.

A: Threadlocal's simplest application

First of all, since it is sold by the train, then, there is no need to synchronize. The code then returns to:

But the current code is definitely wrong, and each thread accesses the same train ticket, and there is an oversold phenomenon. To ensure that every new window comes out, there is a train, and we can use the Threadlocal object.

Let's replace the ticket variable first, instead:

Then, the ticket code is changed to:

Although ticket is still a static variable, run the program you will find that a new thread, different threads will still have their own ticket, will not interfere with each other. That is to achieve the goal of each window to sell their own train.

Two: ThreadLocal VS instance variables

Every programmer should be a bar-fine. Why, because we have come back to God, we find that as long as we go back to the first piece of code and remove the static from the ticket, we can achieve the same goal:

Try the above code, is it possible to achieve the purpose of each sale?

We are the head by the door squeeze, just want to come out a theadlocal such a complex solution?

If you simply say the above code, yes. However, there are many occasions, is the authorizing of threadlocal. For example, we do not always use extends thead way to write multi-threading, we may also use implements Runnable way to write multithreading (PS: There are more ways of writing OH), as follows:

In this case, we have to use the theadlocal, here does not release the code, you can try.

Even further, are we able to put the ticket variable inside the method, if we put it in the method

Internally, we also have to use threadlocal to achieve the goal, as follows:

In short, simply put: When the code to be run is not easily accessible to the current thread instance, it is threadlocal.

Three: Threadlocal's application scenario

Threadlocal has such scenarios as connection pooling management, session management, and so on.

In the management of the connection pool, when we need to get a connection, we should give a different connection for each fetch. In a Web application, a request is managed by a thread pool, which means that the behavior of getting a connection is not a single-threaded behavior, so we'd better design a different thread to not get the same connection, and to be sure that you can do so, you should use threadlocal.

One might say that it cannot be designed as an instance variable? The answer is: No. Because, in a Web application, threads are not managed by ourselves, the best practice is to use threadlocal. A standard practice is as follows:

Finally, as a supplement, let's look at the application of threadlocal in Hibernate:

The following is the ad time: most courses (http://zuikc.com) are recruiting Java Employment Class students, if you want to learn more Java high-quality code writing skills, please contact us oh.

Java Code Quality Improvement: using Threadlocal to maintain thread internal variables