面試官經常喜歡問Spring中的bean是不是線程安全的這個問題用來考察對Spring 中Bean作用域的理解，先說結論， Spring中的Bean不是線程安全的 。
Spring容器中的Bean是否線程安全，容器本身並沒有提供Bean的線程安全策略，因此可以說Spring容器中的Bean本身不具備線程安全的特性，但是具體還是要結合具體scope的Bean去研究。
Spring 的 bean 作用域（scope）類型有5種：
線程安全這個問題，要從單例與原型Bean分別進行說明。
原型Bean 對於原型Bean,每次創建壹個新對象，也就是線程之間並不存在Bean***享，自然是不會有線程安全的問題。
單例Bean 對於單例Bean,所有線程都***享壹個單例實例Bean,因此是存在資源的競爭。
如果單例Bean,是壹個無狀態Bean，也就是線程中的操作不會對Bean的成員執行 查詢 以外的操作，那麽這個單例Bean是線程安全的。
Spring中的Bean默認是單例模式的，框架並沒有對bean進行多線程的封裝處理。實際上大部分時間Bean是無狀態的（比如Dao） 所以說在某種程度上來說Bean其實是安全的。
但是如果Bean是有狀態的 那就需要開發人員自己來進行線程安全的保證，最簡單的辦法就是改變bean的作用域 把 singleton 改為 protopyte ， 這樣每次請求Bean就相當於是 new Bean() 這樣就可以保證線程的安全了。
有狀態就是有數據存儲功能 無狀態就是不會保存數據
controller、service和dao層本身並不是線程安全的，只是如果只是調用裏面的方法，而且多線程調用壹個實例的方法，會在內存中復制變量，這是自己的線程的工作內存，是安全的。
想理解原理可以看看《深入理解JVM虛擬機》，2.2.2節：
《Java並發編程實戰》第3.2.2節：
所以其實任何無狀態單例都是線程安全的。Spring的根本就是通過大量這種單例構建起系統，以事務腳本的方式提供服務
也可以看看這篇加深理解：[關於Spring的@Controller @Service等的線程安全問題]，地址： /u012843361/article/details/84023869
首先問@Controller @Service是不是線程安全的？
答：默認配置下不是的。
為啥呢？因為默認情況下@Controller沒有加上@Scope，沒有加@Scope就是默認值singleton，單例的。意思就是系統只會初始化壹次Controller容器，所以每次請求的都是同壹個Controller容器，當然是非線程安全的。舉個栗子：
在postman裏面發三次請求，結果如下：
說明他不是線程安全的。怎麽辦呢？可以給他加上上面說的@Scope註解，如下：
這樣壹來，每個請求都單獨創建壹個Controller容器，所以各個請求之間是線程安全的，三次請求結果：
加了@Scope註解多的實例prototype是不是壹定就是線程安全的呢？
看三次請求結果：
雖然每次都是單獨創建壹個Controller但是扛不住他變量本身是static的呀，所以說呢，即便是加上 @Scope 註解也不壹定能保證Controller 100%的線程安全。所以是否線程安全在於怎樣去定義變量以及Controller的配置。所以來個全乎壹點的實驗，代碼如下：
補充Controller以外的代碼，config裏面自己定義的 Bean:User
我暫時能想到的定義變量的方法就這麽多了，三次http請求結果如下：
可以看到，在單例模式下 Controller 中只有用 ThreadLocal 封裝的變量是線程安全的。為什麽這樣說呢？
我們可以看到3次請求結果裏面只有 ThreadLocal 變量值每次都是從0+1=1的，其他的幾個都是累加的，而user對象呢，默認值是0，第二交取值的時候就已經是1了，關鍵他的 hashCode 是壹樣的，說明每次請求調用的都是同壹個user對象。
下面將TestController 上的@Scope註解的屬性改壹下改成多實例的： @Scope(value = "prototype") ，其他都不變，再次請求，結果如下：
分析這個結果發現，多實例模式下普通變量，取配置的變量還有ThreadLocal變量都是線程安全的，而靜態變量和user（看他的hashCode都是壹樣的）對象中的變量都是非線程安全的。
也就是說盡管TestController 是每次請求的時候都初始化了壹個對象，但是靜態變量始終是只有壹份的，而且這個註入的user對象也是只有壹份的。靜態變量只有壹份這是當然的咯，那麽有沒有辦法讓user對象可以每次都new壹個新的呢？當然可以：
在config裏面給這個註入的Bean加上壹個相同的註解 @Scope(value = "prototype") 就可以了，再來請求壹下看看：
可以看到每次請求的user對象的hashCode都不是壹樣的，每次賦值前取user中的變量值也都是默認值0。