Thread-safety issues caused by httpclient session retention

There is a problem on the two antennas, through the httpclient to crawl the page, the server in the page rendering when the string phenomenon occurred.

First look at the code, controller in the following code:

Request.getsession (). setattribute ("Sid", id);

The VM page then gets the parameter value via $!request.session.getattribute ("Sid"), which is common and looks like single-threaded and multithreaded concurrency, because each user's session is different. But why is there a problem when httpclient request?

Client (browser) after the first and the server to establish a connection, the server will create a session, the response will be saved with other cookie information to the client, when the client initiates the next request, The server will decide whether to create a new session based on the cookie information that is brought in (Jsessionid), and if so, it will share the previous session.

The HttpClient object, when created, is equivalent to opening a browser, multiple threads concurrency, through the HttpClient object and server-side to establish a number of connections, but because the use of the same HttpClient object, if the object has been established with the service side of the connection, Will assign a SessionID and save it to a cookie, and the server will recognize the same session according to SessionID when other threads are connected through the HttpClient object and service.

See here believe that we all understand the beginning of the string phenomenon behind the reason bar, thread safety to maintain high vigilance, as far as possible using the thread variables (created in the current thread and the variable), and reduce the use of global variables (multithreading common variables), when multiple producers, the global variable is prone to problems, Once the problem is very strange, difficult to reproduce problems, testing is generally difficult to find.