1.Servlet non-thread safe:
Let's start with a brief look at the servlet's life cycle, "initializing->init->service->destroy-> Offload"
As we all know here, when we define a servlet in Web. XML, we can give them a value of "Load-on-startup" if the servlet's Load-on-startup configuration item is greater than 0, then in the Context The container is instantiated when it is started, and tomcat loads and instantiates an object annotation for each servlet : that is, every servlet that our user configures in Web. XML is instantiated as a Servlet object
In other words, the Tomcat container implements a singleton schema for the servlet, and for a servlet class, there is always only one servlet object.
2.struts1 non-thread insecure:
Struts1 is a direct implementation of the Java Web servlet interface, so it inherits the Tomcat implementation of the servlet, and each action in the struts1 corresponds to a servlet class, So the action here is a singleton after being instantiated by Tomcat, so Struts1 has a multithreaded problem
So: We can't define attributes in action when we're using STRUTS1. To use only the words can only be defined in the method (single thread safety problem).
3.STRUTS2 Thread Safety:
Above we understand the Struts1 inside the multithreading problem, that Struts2 how to solve this problem? In fact, the reason is very simple, because STRTUS2 will get the user's HTTP request, and then responsible for each request to instantiate an action object, but it is noted that the action object here and Struts1 inside the action object is not a concept at all, The action class inside the STRUTS1 is a servlet class, and the action class here is just a normal Java class. This is why the action inside the STRUTS1 is thread insecure, and the action inside the STRUTS2 is a thread-safe cause.
So we look back and see how struts2 is different from the struts1 of the servlet. Readers who have read the previous analysis must know that Struts1 's action does not have any wrapper on the servlet, it is a servlet interface within the Java WEB API that is implemented directly. That's why thread safety is a problem, but the struts2 bottom helps us encapsulate the servlet so developers don't have to touch the servlet directly. The specific approach is:
Strtus2 intercepts the servlet request and then instantiates an action object for each request, destroying the action object after the request has ended. As to Strtus2 specific how to do, I do not want to be redundant, we can see the Struts2 of the relevant introduction.
In Struts2 because there is no difference between the action and the normal Java class (that is, you do not have to implement a struts interface like the one in Struts1, interested friends can see for themselves), so we can use spring to manage the action of the Struts2. , this time we have to pay attention, because when we are in spring to define the bean, spring by default is a singleton mode. So at this point, you need to modify the spring configuration file---that is, modify scope to prototype.
Brief analysis on Action thread safety of STRUTS1 and STRUTS2