Spring's thread safety

Spring, as a Ioc/di container, helps us manage many "beans". In fact, spring does not guarantee the thread safety of these objects, and it requires the developer to write code that solves the thread-safety problem.
Spring provides a scope property for each bean to represent the scope of the bean. It is the life cycle of the bean. For example, a bean of scope singleton, when injected for the first time, is created as a singleton object that will be reused until the end of the application

Singleton: The default scope, each bean of scope Singleton is defined as a singleton object that has a life cycle that is consistent with the spring IOC container (but is created the first time it is injected).
Prototype:bean is defined to create a new object each time it is injected.

Request:bean is defined to create a singleton object in each HTTP request, which means that the singleton object is reused in a single request.
Session:bean is defined as creating a singleton object during the life cycle of a session.
Application:bean is defined as the re-use of a singleton object in the life cycle of the ServletContext.
Websocket:bean is defined as the re-use of a singleton object in the life cycle of the websocket.

Stateless objects and stateful objects:

A state is a data storage function. Stateful Object (Stateful Bean), which is an object with an instance variable, can hold data and is non-thread safe. No state is preserved between different method invocations.
Stateless is a single operation and cannot hold data. Stateless Objects (Stateless Bean), which is an object that has no instance variable. Cannot save data, is immutable class, does not cause thread safety problems because of the alternation of multiple threads.

1. I believe we have a certain understanding of the State and the state of being stateless. Stateless beans are suitable for singleton mode, which allows you to share instances and improve performance. Stateful beans, which are unsafe in multithreaded environments, are suitable for use with the prototype prototype model. Prototype: A new bean instance is created each time a request is made to the bean.

2. By default, the instance obtained from the Spring Bean Factory is singleton (the Scope property is singleton), and only one shared bean instance exists in the container.

3. Understanding the relationship between the two, the principle of scope selection is easy: The stateful Bean uses the prototype scope, and the stateless bean should use the singleton scope.

4. If the service layer, DAO layer with the default singleton line, although the service class also has a DAO such properties, but DAO these classes are no state information, that is equivalent to the invariant (immutable) class, so it does not affect. STRUTS2 action because there will be user, bizentity such instance object, is stateful information, in a multithreaded environment is not secure, so Struts2 default implementation is prototype mode. In spring, Struts2 's action, scope is to be prototype scoped.

Most of the objects that we managed by spring are actually stateless objects, and objects that do not cause state damage because of multithreading are well suited to spring's default scope (singleton). Each stateless object in a singleton is thread-safe (or as long as it is stateless, regardless of whether the singleton is thread-safe, but the single case saves the overhead of creating objects and GC after all)

One might think that I use the request scope to avoid security issues between each request? This is completely wrong, because the controller defaults to a singleton, and an HTTP request is executed by multiple threads, which returns to the thread's security issue. Of course, you can also change the controller's scope to prototype, which is actually Struts2, but one thing to note is that Spring MVC's interception granularity for requests is based on each method, and Struts2 is based on each class, Therefore, the controller is set as a number of cases will be frequently created and recycled objects, seriously affecting the performance.

Spring does not make any guarantees or measures on the bean's multithreading security. The root cause for each bean's thread-safety problem is the design of each bean itself, and do not declare any stateful instance variables or class variables in the bean.

Solution:

There are several workarounds:
1. Do not declare any stateful instance variables or class variables in the bean

2. If this is necessary, then use threadlocal to turn the variable into a thread-private

3. If the bean instance variable or class variable needs to be shared among multiple threads, then it is only possible to use synchronized, lock, CAs and other methods to implement thread synchronization.

4. Declare scope= "prototype" in the Spring Config file controller and create a new controller each time

Spring's thread safety