Thread security issues with spring concurrent access

SPRINGMVC's controller is singleton (non-thread safe), which is probably the difference between him and struts2.

Original Address: thread security issues with spring concurrent access  

Like struts, Spring's controller defaults to Singleton, which means that every request comes in and the system is processed with the original instance, which results in two outcomes: one is that we don't have to create a controller every time, The second is to reduce the time of object creation and garbage collection; Since there is only one controller's instance, when multiple threads call it, the instance variable inside it is not thread-safe, and the problem of channeling data can occur.

Of course, in most cases, we do not need to consider thread-safety issues, such as Dao,service, unless you declare an instance variable in the bean. Therefore, when we use Spring MVC's contrller, we should avoid defining instance variables in the controller.
Such as:

public class Controller extends Abstractcommandcontroller {... protected modelandview handle (HttpServletRequest Request,httpservletresponse response,object command,bindexception errors) throws Exception {company = ........ ;} Protected Company Company;}

there is a tag company here that has a concurrency thread safety problem.
if the controller is in a singleton form, and there is a private variable A in it, all requests to the same controller, the A variable used is common, that is, if the variable A is modified in a request, the content of the modification can be read in the other request.
?
There are several workarounds:
1. Use the threadlocal variable in the controller
2. Declare scope= "prototype" in the Spring Config file controller and create a new controller each time
When you use spring to develop the web, be aware that the default controller, Dao, and service are all singleton.

"1" springmvc how to ensure the security of objects in multi-threaded environment?

Code as follows:

@RequestMapping ("/user") @ControllerClass usercontroller{@ResourceUserService userservice; @RequestMapping ("/add") public void TestA (user user) {userservice.add (user);} @RequestMapping ("/get") public void TestA (int id) {userservice.get (id);}} @Service ("UserService") Class userservice{public static map<integer,user> Userscache = new hashmap<string, User> ();p ublic void Add (user user) {userscache.put (User.getid (), user);} public void get (int id) {userscache.get (id);}}

This fragment of code, the Userscache object is thread insecure. Because it is a static global shared object. If there are multiple threads calling the Add method at the same time, it may occur that the user object is overwritten, that is, the ID corresponds to the object inconsistency, which is the most common thing in multithreaded programming. Therefore, you can use the Collections tool to synchronize the map. static Map<integer, users> Userscache = Collections.synchronizedmap (New Hashmap<integer, Users> ());

look at the source code in spring, which does a lot of encapsulation of common open source frameworks, such as hibernate in the Sessionfactory, is using the Org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean, while in In Annotationsessionfactorybean's parent class Localsessionfactorybean, a large number of threadlocal are defined to ensure the security of multithreading. &NBSP;

public class Localsessionfactorybean extends Abstractsessionfactorybean implements Beanclassloaderaware {private Static final threadlocal<datasource> Configtimedatasourceholder =new threadlocal<datasource> ();p rivate Static final threadlocal<transactionmanager> Configtimetransactionmanagerholder =new ThreadLocal< Transactionmanager> ();p rivate static final threadlocal<object> Configtimeregionfactoryholder =new Threadlocal<object> ();p rivate static final threadlocal<cacheprovider> Configtimecacheproviderholder = New Threadlocal<cacheprovider> ();p rivate static final threadlocal<lobhandler> Configtimelobhandlerholder =new threadlocal<lobhandler> ();

Thread security issues with spring concurrent access