is the servlet thread-safe by default?

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 the operation of the system, as shown in 1.

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.

There are also many ways to solve this class

1, implement Singlethreadmodel interface (will cause a lot of system overhead)

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 is the only way to inherit this interface.

public class XXXXX extends HttpServlet implements Singlethreadmodel {       ...}

Javax.servlet.SingleThreadModel API and its translation

Ensures that servlets handle only one request at a time. This interface has no methods.

Ensure that the servlet processes only one request at a time. The interface does not contain methods.

If a servlet implements this interface, you is guaranteed that no, the threads would execute concurrently in the servlet's Service method. The servlet container can make this guarantee by synchronizing access to a single instance of the Servlets, or by Maintaini ng a pool of servlets instances and dispatching each new request to a free servlet.

If the servlet implements the interface, it ensures that no two threads are executing the servlet's service method at the same time. The servlet container is guaranteed by synchronizing access to a single instance of the servlet, or by maintaining the instance pool of the servlet and assigning the new request to an idle servlet.

Note that Singlethreadmodel does isn't solve all thread safety issues. For example, session attributes and static variables can still is accessed by multiple requests on multiple threads at the Same time, even when Singlethreadmodel servlets is used. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such a s avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. This interface was deprecated in Servlet API version 2.4.

Note:Singlethreadmodel does not address all of the thread safety implications . For example, session properties and static variables can still be accessed simultaneously by multi-threaded multiple requests, even if the Singlethreadmodel servlet is used. It is recommended that developers take other measures to address these issues, rather than implementing the interface, such as avoiding the use of instance variables or synchronizing blocks of code while accessing resources. This interface will not be recommended in servlet API 2.4.

2, synchronous operation of the shared data: The synchronized code block 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

Using the Synchronized keyword ensures that only one thread can access the protected section at a time, and in this paper, the synchronization block operation can be used to ensure the thread safety of the servlet. The code after synchronization is as follows:

public class XXXXXX extends HttpServlet {      

3. Avoid using instance variables

Some of the 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.

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.

Reference:

Http://www.cnblogs.com/gw811/archive/2012/09/07/2674859.html

Http://developer.51cto.com/art/200907/133827.htm

is the servlet thread-safe by default?