Threadlocal objects used in the process of easy to sink into the pit

The Threadlocal object helps us to manage the objects within the thread, ensuring that the objects are isolated from each other.

The pit we met today is like this:

Index01.html page load will be sent once a request, and then click on the attachment upload will send an upload request B, upload success will send a download request C,

Where a request passes through the Interceptor01 Interceptor, the Interceptor01 internally passes the Module_name parameter of a request to the local thread variable, the B request does not go through the interceptor, and the C request passes through the interceptor, but the module_name is not passed. The thread variable is then stored in an empty module_name.

The specific phenomenon is this, enter the Index01.html page, the first click upload attachment, download attachment can be successful, but as long as not close the browser to reopen the page, all subsequent clicks of the upload request will not succeed, and reported Module_name is empty error, Module_ Name is obtained from the local thread variable.

Therefore, it is suspected that the module_name parameter is not stored in the local thread, after several queries found that the B request does not go through the interceptor, so the B request can not get module_name is normal, but it is strange that the B request to get the local thread variable in the other property values, The truth is not solvable, because it can be determined that thread variables are initialized and assigned only in the Interceptor Interceptor01!

Let us comb again, the B request does not go through the interceptor, then the local thread variable is not initialized, but in the B request to take the local thread variable, can be taken, but only module_name not get.

OK, you can be sure that thread variables can only be obtained in this thread, then there is only one explanation, that is, the B request shared the same thread with other requests! In other words, not every request, the Web container uses a different thread to handle. In order to confirm this idea, I printed out the threadid of the request of A, B and C, and found it to be the same.

This can explain the above problems:

When we first enter the Index01.html page, a request goes through the interceptor, then initializes the thread variable and deposits the module_name;

Then the B request will not go through the interceptor, but because and a request is using the same thread, so the module_name can be removed normally, and successfully uploaded;

Then the C request passes through the interceptor, but does not pass the module_name, so the module_name in the thread is empty;

Finally, when we upload the B request again, there is no module_name in the thread.

Here's why 3 requests share a thread, yes, because the keep-alive in the http1.1 protocol is turned on by default, and the limited requests in the same session are shared with a long connection.

Threadlocal objects used in the process of easy to sink into the pit