Single case beans in spring framework is thread-safe? __java Interview

See the question: is the single case beans in the Spring framework thread safe?

The spring framework does not encapsulate any multithreaded encapsulation of a single instance bean. Threading security and concurrency issues for a single bean need to be done by the developer themselves. But in fact, most spring beans do not have mutable states (such as the Serview class and DAO classes), so in some ways spring's single case bean is thread-safe. If your bean has multiple states (such as the View Model object), you need to keep the thread safe.

The most obvious solution is to change the scope of the polymorphic bean from "Singleton" to "prototype".

Not too read the state and stateless bean is what meaning, so Baidu, benefited.

The following is reproduced from: A column of lazy fanatics

In spring's bean configuration, there are two scenarios:

View plain copy <bean id= "Testmanager" class= "Com.sw.TestManagerImpl" scope= singleton "/> <bean ' id=" test Manager "class=" Com.sw.TestManagerImpl "scope=" prototype "/>

Of course, the scope of the value of more than these two, but also include request,session and so on. But the most used or singleton single State, prototype polymorphism.

Singleton indicates that there is only one instance of the bean globally, and that the scope of the bean in spring is singleton by default.

Prototype indicates that the bean is recreating an instance each time it is injected, which applies to stateful beans.

For the SSH architecture system, there is little concern about this, because we usually use singleton. The bean's injection is managed by spring.

For a stateful bean.

The following is a stateful bean

    View plain copy   package com.sw;      public class  testmanagerimpl implements testmanager{       private User  user;            public void deleteuser (User e)  throws Exception {           user =  e ;           //1            preparedata (e);       }           public void preparedata (user e)  throws exception {            user = getuserbyid (E.getId ());             //2            ..            //use User.getid ();                        // 3           .....            .....       }     }  

What happens if the bean is configured as Singleton.

If there are 2 user accesses, the bean is called.

assumed to be User1,user2

When User1 calls to the 1 steps in the program, the bean's private variable user is paid the value of User1

When the User1 program goes to step 2, the bean's private variable user is paid back to User1_create

Ideally, when User1 goes to step 3, the private variable user should be user1_create;

But if the user2 starts running to 1 steps before User1 calls to 3 steps, the private variable user is modified to User2 because of a single state resource share.

In this case, the User.getid () used by User1 's step 3 actually uses the User2 object.

And if it is prototype, there will be no problem of resource sharing.

For SSH, the bean's configuration is correct and configured to Singleton; This example should not use private variables. This makes the bean

From stateless to stateful beans. You should still use stateless beans as much as possible. If you have a private variable in your program, try to replace it with a parameter.
It is also a good idea to add variable incoming or through Threadlocal for each method that accesses a private variable.

The real problem of the above code is also a small number, when it appears, is generally for the purpose of drawing convenience, a lot of methods are to use the variables, if all need to use the parameters of the

Way to pass much trouble Ah, so the private variable how good, not as ugly as parameters. But ugliness does not mean that it is not good to be programmed in a way that is accustomed to

Try to avoid problems as they arise.