How does the servlet handle multiple request accesses?
The servlet container, by default, handles multiple requests in a single-instance multithreading way:
1. When the Web server starts (or when the client sends a request to the server), the servlet is loaded and instantiated (there is only one servlet instance);
2. The container initialization servlet is basically reading the configuration file (for example, Tomcat, you can set the thread pool number of threads through the Servlet.xml <Connector>, initialize each parameter value through Web.
3. When the request arrives, the servlet container dispatches it through the dispatch thread (Dispatchaer thread) to manage the threads (worker thread) that are waiting to be executed in the thread pool to the requestor;
4. Thread executes the servlet's service method;
5. End of request, put back to thread pool, wait to be called;
(Note: Avoid using instance variables (member variables), because if a member variable exists, it may occur when multiple threads concurrently access the resource, to manipulate it, according to inconsistent data, resulting in thread-safety issues)
As can be seen from the above:
First: The servlet single instance reduces the overhead of generating servlets;
Second: Through the line pool response to multiple requests, improve the response time of the request;
Third: The servlet container does not care whether the arriving Servlet requests access to the same servlet or another servlet, and assigns it directly to a new thread, and if it is multiple requests from the same servlet, Then the service method of the servlet will be executed concurrently in multi-threading;
IV: Each request is received by the ServletRequest object, which is requested by the Servletresponse object;
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.
Multithreading problems in JSP:
When a client requests a JSP file for the first time, the server compiles the JSP into a class file, creates an instance of the class, and creates a thread to process the client's request. If more than one client requests the JSP file at the same time, the server creates multiple threads. Each client request corresponds to a thread. Multi-threaded execution can greatly reduce the resource requirements of the system, and increase the concurrency and response time of the system.
The variables that may be used in the JSP are described below:
Instance variable: an instance variable is allocated in the heap and shared by all threads that belong to that instance, so it is not thread-safe.
8 class variables provided by the JSP system
The OUT,REQUEST,RESPONSE,SESSION,CONFIG,PAGE,PAGECONXT used in JSP is thread-safe (because the Request,respone object for each thread is different, there is no sharing problem), Application is used throughout the system, so it is not thread-safe.
Local variables: Local variables are allocated on the stack because each thread has its own stack space, so it is thread-safe.
Static classes: Static classes are not instantiated, can be used directly, and are not thread-safe.
External resources: In a program, there may be multiple threads or processes concurrently manipulating the same resource (for example, multiple threads or processes simultaneously write to a file). You should also pay attention to the synchronization problem at this point.
So that it executes in a single thread, there is still only one instance, and all client requests are executed serially. This can degrade the performance of the system
Problem
Question one. Explains how its servlet container handles requests in a single-instance multithreading way
Question two. How to ensure that a servlet is a single-instance multithreaded way to work in development (that is, how to develop thread-safe servelt).
I. How the servlet container handles multiple requests at the same time
Java memory model (JMM)
The main purpose of JMM is to specify a number of relationships 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 the figure.
Worker threads Work Thread: a set of threads that execute code.
The dispatch thread dispatcher threads: Each thread has a thread priority assigned to it, and the thread is executed according to the priority schedule.
Servlets use multithreading to handle multiple requests at the same time. The servlet relies on a line pool service request. The thread pool is actually a series of worker thread collections. The servlet uses a dispatch thread to manage worker threads.
When a container receives a servlet request, the dispatch thread selects a worker thread from the thread pool, passes the request to the worker thread, and then executes the servlet's service method by that thread. When this thread is executing, the container receives another request, and the dispatch thread also selects another worker thread from the thread pool to serve the new request. The container does not care whether the request accesses the same servlet. When the container receives multiple requests to the same servlet at the same time, the servlet's service () method executes concurrently on multiple threads.
The servlet container defaults to single-instance multithreading to handle requests, which reduces the overhead of generating servlet instances, increases response time to requests, and can be used by Tomcat in Server.xml <Connector> Element sets the number of threads in the thread pool.
As far as implementation is concerned:
The responsibility of the dispatcher thread class, such as its name, is that the responsibility of the class is to dispatch the thread, only to use its own attributes to fulfill its responsibilities. So the class is responsible, and the responsibility of the class is concentrated in the only single object. While other objects depend on the responsibility of that particular object, we need to get that particular object. That class is the implementation of a singleton pattern.
Note: Servers can use multiple instances to handle requests, instead of the benefits of a single instance of request queuing. The server creates an instance pool of multiple servlet instances of the servlet class, responds to each request-allocation servlet instance, and then puts it back into the instance pool to wait for the request. This creates a problem with concurrent access.
Local variables (fields) are also safe at this point, but are not secure for global variables and shared data and require synchronous processing. For such a multi-instance scenario, the Singlethreadmodel interface does not solve the concurrency access problem. The Singlethreadmodel interface has been deprecated in the servlet specification.
Two how to develop a thread-safe servlet
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, HttpServletResponse
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.
Servlet Single-instance multithreading
