Whether the Servlet is thread-safe to read

absrtact : This paper introduces the servlet multithreading mechanism, through an instance and the Java memory model to explain the reason that the servlet thread is unsafe, gives three kinds of solutions to ensure the servlet thread security, and explains the trade-offs of three kinds of schemes in actual development.

　　keyword : Servlet thread-safe synchronization of Java memory model instance variables

Compared with ASP and PHP, servlet/jsp technology has high execution efficiency because of its multi-threaded operation. Because servlet/jsp is executed in multithreaded mode by default, you need to take a very careful look at the security of multithreading when writing code. However, many people do not pay attention to multithreading security issues when writing servlet/jsp programs, which often results in the program written by a small number of user access without any problems, and when the concurrent users rise to a certain value, there will be a lot of trouble.

　　Multithreading mechanisms for Servlets
　
The servlet architecture is built on the Java multithreading mechanism, whose life cycle is the responsibility of the Web container. When a client requests a servlet for the first time, the servlet container instantiates the Servlet class based on the Web. XML configuration file. When a new client requests the servlet, the servlet class is typically no longer instantiated, that is, multiple threads are using the instance. The servlet container automatically uses techniques such as the thread pool to support system operation

In this way, when two or more threads access the same servlet at the same time, there may be situations where multiple threads concurrently access the same resource, and the data may become inconsistent. So if you are not aware of thread-safety issues when you build Web Apps with Servlets, you can make the servlet program you write difficult to find.

　　Thread safety issues for Servlets

The thread safety problems of servlets are mainly caused by improper use of instance variables, as illustrated by a practical example.

Import javax.servlet. *;import javax.servlet.http. *; Import java.io. *; public class Concurrent Test extends HttpServlet {printwriter output; public void Service (HttpServletRequest request, HttpServletResponse response) throws Servletexception, IOException {String username; Response.setcontenttype ("text/html; charset=gb2312 "); Username = Request.getparameter ("Username"); Output = Response.getwriter (); Try {Thread. Sleep (5000);//To highlight concurrency problems, set a delay } Catch (interrupted Exception e) {} Output.println ("Username:" + Username+ "<BR>"); } }

An instance variable output is defined in the servlet, which is assigned to the user's output in the service method. When a user accesses the servlet, the program runs normally, but when multiple users are concurrently accessing it, it is possible that other users ' information will appear on other users ' browsers. This is a serious problem. In order to highlight the concurrency problem, it is easy to test and observe, we perform a delay operation when we echo the user information. Assuming that the servlet has been registered in the Web. XML configuration file, the existing two users A and B access the servlet simultaneously (you can start two IE browsers, or concurrently on both machines), which is also entered in the browser:

A:http://localhost:8080/servlet/concurrenttest? Username=a

B:http://localhost:8080/servlet/concurrenttest? Username=b

If User B is a little slower than user a returns

As you can see from Figure 2, the Web server initiated two threads to process requests from User A and User B, but a blank screen was found on user A's browser, and user A's information was displayed on User B's browser. The servlet has a thread insecurity problem. Here we start by analyzing the memory model of the instance and observing the value of the instance variable output at different times to analyze the reason why the servlet thread is unsafe.

The memory model of Java JMM (Java memory models) JMM is primarily intended to prescribe some relationship between threads and memory. According to JMM's design, there is a main memory in the system, and all the instance variables in Java are stored in memory and shared for all threads. Each thread has its own working memory (working memory), the work is composed of two parts of the cache and the stack, the cache is a copy of the variables stored in main memory, the cache may not be the sum of main memory synchronization, that is, the changes in the cache variables may not be immediately written into main memory A thread's local variables are saved in the stack, and the variables in the stack cannot be accessed directly between the threads. According to JMM, we can abstract the memory model of the servlet instance discussed in this paper into the model shown in Figure 3.

The following is the memory model shown in Figure 3, to analyze when users A and B threads (referred to as a thread, b thread) concurrent execution, the changes involved in the servlet instance variables and the execution of the thread, 4 shows.

tune Degree of time	a thread	b thread
t1	access servlet page	 
t2		access servlet page
t3	output=a output username=a Hugh Sleep 5000 milliseconds, let out the CPU	 
t4	 	output=b output (write back to main memory) Username=b hibernate for 5000 milliseconds, yielding CPU
t5	output the value of the username of a thread on User B's browser, and a thread terminates.	 
t6	 

Figure 4 Thread scheduling scenario for a servlet instance

As can be seen clearly in Figure 4, the B thread's modification of the instance variable output overrides the change of the instance variable output by the a thread, resulting in user A's information being displayed on User B's browser. If the a thread executes the output statement, the B thread's modification to output has not been flushed to main memory, so the output shown in Figure 2 will not appear, so this is only an accidental phenomenon, but it increases the potential danger of the program.

Designing a thread-safe servlet

From the above analysis, we know that the incorrect use of instance variables is the main cause of the servlet thread insecurity. Here are three solutions for this problem and some reference suggestions for the selection of the scheme.

1. Implement Singlethreadmodel interface

This interface specifies how the system handles calls to the same servlet. If a servlet is specified by this interface, then the service method in this servlet will not have two threads being executed concurrently, and there is no thread-safe issue, of course. This method simply changes the class header definition of the previous concurrent test class to:

public class Concurrent Test extends HttpServlet implements Singlethreadmodel { ............ }

2. Synchronize the operation of the shared data

Using the Synchronized keyword ensures that only one thread can access the protected section at a time, and the servlet in this thesis can ensure thread security by synchronizing block operations. The code after synchronization is as follows:

............ public class Concurrent Test extends HttpServlet {...... Username = Request.getparameter ("Username"); Synchronized (This) { Output = Response.getwriter (); Try { Thread. Sleep (5000); } Catch (interrupted Exception e) {} Output.println ("User name:" +username+ "<BR>"); } } }

3. Avoid using instance variables

The thread safety problem in this example is caused by an instance variable, which is thread-safe as long as the instance variable is not used in any of the methods inside the servlet.

Fix the above servlet code, change the instance variable to local variable to implement the same function, the code is as follows:

... public class Concurrent Test extends HttpServlet {public void service (HttpServletRequest request, httpservletrespons E Response) throws Servletexception, IOException { Print Writer output; String username; Response.setcontenttype ("text/html; charset=gb2312 "); ... } }

The above three methods are tested to show that they can be used to design a thread-safe servlet program. However, if a servlet implements the Singlethreadmodel interface, the servlet engine will create a separate servlet instance for each new request, which will cause a lot of overhead. Singlethreadmodel is no longer advocated in Servlet2.4, and the performance of the system can be greatly reduced if synchronization is used in the program to protect the shared data to be used. This is because the code block that is being synchronized can only have one thread executing it at the same time, making it handle the throughput of customer requests at the same time, and many customers are in a blocking state. In addition, in order to ensure the consistency of the contents of main memory and the data of the thread, the cache can be refreshed frequently, which will greatly affect the performance of the system. Therefore, in the actual development should also avoid or minimize the synchronization code in the servlet, in Serlet to avoid the use of instance variables is the best choice to ensure that the servlet thread security. From the Java memory model It is also known that the temporary variables in the method are allocated space on the stack, and each thread has its own private stack space, so they do not affect the thread's security.

　　Summary

A servlet's thread-safety problem is only apparent when there is a lot of concurrent access, and it is difficult to find, so pay special attention when writing a servlet program. Thread-safety issues are primarily caused by instance variables, so you should avoid using instance variables in Servlets. If application design cannot avoid using instance variables, use synchronization to protect the instance variables to be used, but to ensure the best performance of the system, you should synchronize the code path with the least availability.

Ext.: http://blog.sina.com.cn/s/blog_6448959f0100kct7.html

Whether the Servlet is thread-safe to read