Transferred from: http://www.cnblogs.com/yjhrem/articles/3160864.html
How does the servlet handle multiple request accesses? The servlet container defaults to handling multiple requests in single-instance Multithreading: 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 primarily read configuration files (such as Tomcat, which can be servlet.xml by the
Sets the number of threads in the thread pool, initializes each parameter value, and so on through Web. Xml. 3. When the request arrives, the servlet container dispatches it through the dispatch thread (Dispatchaer thread) to manage the threads that are waiting to be executed in the thread pool (Worker thread) to the requestor; 4. The thread executes the servlet's service method; 5. The request ends, Put it back in the thread pool, wait for it 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, the data is inconsistent, and therefore the thread safety problem is generated) from the above can be seen: first: servlet Single instance, Reduces the overhead of generating servlets; second: The response time of the request is increased by responding to multiple requests through the line pool; third: The servlet container does not care whether the incoming Servlet requests access to the same servlet or another servlet. A new thread is assigned directly to it, and if it is multiple requests from the same servlet, the service method of the servlet will be executed concurrently in multi-threaded, and the next: Each request is accepted by the ServletRequest object. It should be requested by the Servletresponse object, and servlet/jsp technology has high execution efficiency compared with ASP and PHP, 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 then 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 as follows: Instance variables: Instance variables are allocated in the heap and shared by all threads that belong to that instance, so it is not thread-safe. The JSP system provides 8 class variables JSP used in the OUT,REQUEST,RESPONSE,SESSION,CONFIG,PAGE,PAGECONXT is thread-safe (because each thread corresponds to the Request,respone object is not the same, 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 stackSpace, 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 as a problem. Explains how its servlet container handles request issue two in a single-instance multithreading manner. 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 (Java memory model) 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 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, thus reducing the generation of sThe overhead of the Ervlet instance increases the response time to the request, and for Tomcat you can set the number of threads in the thread pool through the element in Server.xml. In terms of implementation: 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. How to develop a thread-safe servlet 1, implement the 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. Synchronization of 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 paper can ensure thread security by synchronizing block operations. The code after the 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+ "
"); } } } 3. Avoid using instance variables the thread-safety problem in this instance is caused by instance variables, which are thread-safe as long as the instance variables are 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 Res Ponse) 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. More detailed Description: 1, variable thread safety: variables here refer to fields and shared data (such as form parameter values). A, localize the parameter variables. Multithreading does not share local variables. So we want to use local variables in the servlet as much as possible. For example: String user = ""; user = Request.getparameter ("user");B, use synchronous block synchronized to prevent code blocks that might be called asynchronously. This means that threads need to be queued for processing. When using the same plate to minimize the scope of the synchronization code, do not directly in the Sevice method and response methods to use synchronization, which can seriously affect performance. 2, property of the thread-safe: Servletcontext,httpsession,servletrequest object in the properties. ServletContext: (thread is unsafe) ServletContext is capable of multithreaded simultaneous read/write properties, threads are unsafe. You want to synchronize the read and write properties or Deep Clone (). Therefore, in the context of the servlet, as little as possible to save the modified (write) data can be used in other ways to share in multiple servlets, for example, we can use a singleton mode to process the shared data. HttpSession: (thread is unsafe) the HttpSession object exists during a user session and can only be accessed in a thread that handles requests belonging to the same session, so the session object's property access is theoretically thread-safe. When a user opens multiple browser windows that belong to a process, in which the access is in the same session, multiple requests are made and multiple worker threads are required to process the request, which can result in simultaneous multithreaded read and write properties. At this point we need to synchronize the reading and writing of the properties: using the synchronization block synchronized and using a read/write to resolve. ServletRequest: (thread is secure) for each request, executed by a worker thread, a new ServletRequest object is created, so the ServletRequest object can only be accessed in one thread. ServletRequest is thread-safe. Note: The ServletRequest object is valid within the scope of the service method and does not attempt to persist a reference to the request object after the service method ends. 3, use the Synchronized collection class: Use vector instead of ArrayList, use Hashtable instead of HashMap. 4, do not create your own thread in the servlet to complete a function. The servlet itself is multithreaded, and creating threads in the servlet will complicate execution and lead to multithreading security issues. 5, in multiple Servlets for external objects (such as files) to modify the operation must be locked, to achieve mutually exclusive access. The 6,javax.servlet.singlethreadmodel interface is an identity interface, and if a servlet implements this interface, the servlet container is guaranteed to be in aOnly one thread at a time can be executed in the service method of a given servlet instance. All other requests are queued. Ps:servlet is not just a single case. When container starts, or when a client makes a request service, container is responsible for loading and instantiating a servlet as configured by the container (and can also be configured as multiple, but generally not). But generally speaking, a servlet will only have one instance. 1) The action of STRUTS2 is a prototype, not a single instance; Each request is generated with an instance of the action. 2) The Struts1 Action,spring's IOC container-managed bean defaults to single-instance. The Struts1 action is single-instance, as is spring MVC's controller. Therefore, development-time requirements must be thread-safe because only one instance of the action handles all requests. The singleton strategy limits what Struts1 action can do, and is especially careful when developing. The action resource must be thread-safe or synchronous. Spring's IOC container-managed beans are single-instance by default. The Struts2 Action object generates an instance for each request, so there is no thread safety issue. (In fact, the servlet container produces many objects that can be discarded for each request and does not cause performance and garbage collection issues). When Spring manages the Struts2 action, the bean defaults to a single instance, which can be set as a prototype by configuration parameters. (scope= "prototype) the life cycle of the servlet: 1. servlet is loaded and instantiated when the Web server starts, the container runs its Init method initialization, and the service method is run when the request arrives; 2. service operation request corresponding doxxx (Doget,dopost) method; 3. Server destroys instances, runs its Destory method, and the servlet's lifecycle is managed by the servlet container; (Three conceptual understanding: servlet container <web Container < application server?) The main task of the servlet container is to manage the life cycle of the servlet, which is also known as a Web server, the main task is to manage and deploy the Web application, the application server is very powerful, not only can manage and deploy the Web application, can also deploy EJB application, Implement container-managed transactions, etc... WEB servers are dealing with HTTP-based requests, and EJB containers are more interacting with service interfaces such as databases and transaction management, so the application server has a lot of functionality. The common Web server is tomcat, but Tomcat is also a servlet server, and the Common Application server is Weblogic,websphere, but it is charged; without a servlet container, you can access static HTML pages directly with a Web container. such as the installation of Apache, etc., if you need to display jsp/servlet, you need to install a servlet container, but the light has a servlet container is not enough, it needs to be parsed into HTML display, so you still need a Web container; We often consider the Web container and the servlet container as one, because both of them have the function of each other, there is no independent existence, such as tomcat! How does a servlet handle multiple requests while accessing it? The servlet container defaults to handling multiple requests in a single-instance multithreaded manner: 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. Container initialization servlet. The main thing is to read the configuration file (for example, Tomcat, you can initialize the thread pool by servlet.xml the number of threads, initialize each parameter value through Web. XML, and so on); 3. When a request arrives, the servlet container dispatches the thread (Worker thread) waiting to execute in the thread pool under its management through the dispatch thread (Dispatchaer thread) to the requestor; 4. Thread execution service method for servlet; 5. Request end, put back to thread pool, wait to be called; First: the servlet single instance reduces the overhead of generating servlets, and second: The response time of the request is increased by the line pool response to multiple requests; 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, and the next: Each request is received by the ServletRequest object, by SErvletresponse the object to respond to the request; The problem arises: when multiple requests from the same servlet arrive, if a member variable exists in the servlet, it can be manipulated when multiple threads concurrently access the resource, resulting in inconsistent data, resulting in thread-safety issues. Resolution: 1. Implement Singlethreadmodel interface if a servlet is specified by this interface, then the service method in this servlet will not have two threads executed concurrently, and of course there is no thread-safe problem; 2. Synchronizing the operation of shared data using the Synchronized keyword ensures that only one thread can access the protected section at a time, and the servlet can secure the thread by synchronizing the block operation. ServletRequest objects are thread-safe, but ServletContext and httpsession are not thread-safe; To use synchronous collection classes: vectors instead of arraylist,hsahtable instead of HashMap; 3. Avoid using instance variables (member variables) thread safety issues are caused by instance variables, which are thread-safe as long as the instance variables are not used in any of the methods inside the servlet. (All recommendations do not define member variables in the servlet and try to use local variables instead) to test the three methods above, indicating that the servlet program can be used to design the thread security. 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 notcan affect thread security. 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.
Servlet Singleton Multithreading
