Servlet single-threaded "turn"

SOURCE Address: Servlet single-threaded

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.
A 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 not secure)
ServletContext is a multithreaded simultaneous read/write attribute, 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 not secure)
The HttpSession object exists during a user session and can only be accessed in a thread that processes requests that belong 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 a Synchronized collection class:
Using vectors 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 will ensure that only one thread can execute in the service method of a given servlet instance at a time. All other requests are queued.

Ps:
Servlets are not just singleton. 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 a servlet:

1. The 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. Doxxx (Doget,dopost) method corresponding to service operation request;

3. The server destroys the instance, runs its Destory method;

The life cycle of the servlet is managed by the servlet container;

(Three concepts of understanding:

servlet container <web Container < Application server?

The main task of the servlet container is to manage the servlet's life cycle;

Web containers are also called Web servers, and the main task is to manage and deploy Web applications;

The application server is powerful, not only to manage and deploy Web applications, but also to deploy EJB applications, implement container-managed transactions, and more ...

Web servers are dealing with HTTP-based requests, and EJB containers interact 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;

Common application servers are weblogic,websphere, but are charged;

Without a servlet container, you can access static HTML pages directly with a Web container, such as Apache, and if you need to display jsp/servlet, you need to install a servlet container, but it's not enough to have a servlet container. It needs to be parsed into an HTML display, so we still need a web container, so we often think of the web container and the servlet container as one, because both of them have the function of each other, and there is no independent existence, such as tomcat!

）

How does a servlet handle multiple requests for simultaneous access?

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. Container initialization servlet. The main thing is to read the configuration file (such as Tomcat, you can initialize the thread pool through the Servlet.xml <Connector> set threads, initialize each parameter value through Web. XML, etc.);

3. When the 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 executes the servlet's service method;

5. The request is ended, put back to the thread pool, wait until it is called;

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;

The problem arises:

When multiple requests from the same servlet come in, if a member variable exists in the servlet, it can occur when multiple threads concurrently access the resource, causing inconsistent data, resulting in thread-safety issues.

Solve:

1. Implement the Singlethreadmodel interface

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 problem;

2. Synchronizing operations on shared data

Using the Synchronized keyword ensures that only one thread can access the protected section at a time, and the servlet can ensure thread security by synchronizing block operations.

ServletRequest objects are thread-safe, but ServletContext and httpsession are not thread-safe;

To use a synchronized collection class: 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, try to replace them with local variables)

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.

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 single-threaded "turn"