spring中的併發訪問題：

我們知道在一般情況下，只有無狀態的Bean才可以在多執行緒環境下共享，在Spring中，絕大部分Bean都可以宣告為singleton作用域。
那麼對於有狀態的bean呢？Spring對一些（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非執行緒安全狀態的bean採用ThreadLocal進行處理，讓它們也成為執行緒安全的狀態，因此有狀態的Bean就可以在多執行緒中共享了。

如果用有狀態的bean，也可以使用用prototype模式，每次在注入的時候就重新建立一個bean，在多執行緒中互不影響。

有狀態就是有資料儲存功能。有狀態物件(Stateful Bean)，就是有例項變數的物件 ，可以儲存資料，是非執行緒安全的。在不同方法呼叫間不保留任何狀態。 無狀態就是一次操作，不能儲存資料。無狀態物件(Stateless Bean)，就是沒有例項變數的物件 .不能儲存資料，是不變類，是執行緒安全的。 無狀態的Bean適合用不變模式，技術就是單例模式，這樣可以共享例項，提高效能。

有狀態的Bean，多執行緒環境下不安全，那麼適合用Prototype原型模式。Prototype: 每次對bean的請求都會建立一個新的bean例項。

Servlet體系結構是建立在Java多執行緒機制之上的，它的生命週期是由Web 容器負責的。一個Servlet類在Application中只有一個例項存在，也就是有多個執行緒在使用這個例項。這是單例模式的應用。

如Service層、Dao層用預設singleton就行，雖然Service類也有dao這樣的屬性，但dao這些類都是沒有狀態資訊的，也就是相當於不變(immutable)類，所以不影響。Struts2中的Action因為會有User、BizEntity這樣的例項物件，是有狀態資訊的，在多執行緒環境下是不安全的，所以Struts2預設的實現是Prototype模式。在Spring中，Struts2的Action中，scope要配成prototype作用域。 （單例模式-單例登錄檔實現和threadLocal-可以處理有狀態的bean之間的關係）

還有我們的實體bean，從客戶端傳遞到後臺的controller-->service-->Dao,這一個流程中，他們這些物件都是單例的，那麼這些單例的物件在處理我們的傳遞到後臺的實體bean不會出問題嗎？
答：[實體bean不是單例的]，並沒有交給spring來管理，每次我們都手動的New出來的【如EMakeType et = new EMakeType();】，所以即使是那些處理我們提交資料的業務處理類是被多執行緒共享的，但是他們處理的資料並不是共享的，資料時每一個執行緒都有自己的一份，所以在資料這個方面是不會出現執行緒同步方面的問題的。

（在這裡補充下自己在專案開發中對於實體bean在多執行緒中的處理：1。對於實體bean一般通過方法引數的的形式傳遞（引數是區域性變數），所以多執行緒之間不會有影響。2.有的地方對於有狀態的bean直接使用prototype原型模式來進行解決。3.對於使用bean的地方可以通過new的方式來建立）

但是那些的在Dao中的xxxDao,或controller中的xxxService，這些物件都是單例那麼就會出現執行緒同步的問題。但是話又說回來了，這些物件雖然會被多個程序併發訪問，可我們訪問的是他們裡面的方法，這些類裡面通常不會含有成員變數，那個Dao裡面的ibatisDao是框架裡面封裝好的，已經被測試，不會出現執行緒同步問題了。所以出問題的地方就是我們自己系統裡面的業務物件，所以我們一定要注意這些業務物件裡面千萬不能要獨立成員變數，否則會出錯。

spring對那些個有狀態bean使用ThreadLocal維護變數[僅僅是變數,因為執行緒同步的問題就是成員變數的互斥訪問出問題]時，ThreadLocal為每個使用該變數的執行緒提供獨立的變數副本，所以每一個執行緒都可以獨立地改變自己的副本，而不會影響其它執行緒所對應的副本。

對spring併發訪問執行緒安全的兩篇部落格彙總，可以得出上述結論..............

由於Spring MVC預設是Singleton的，所以會產生一個潛在的安全隱患。根本核心是instance的變數保持狀態的問題。這意味著每個request過來，系統都會用原有的instance去處理，這樣導致了兩個結果（單例的好處）：

一是我們不用每次建立Controller，
二是減少了物件建立和垃圾收集的時間；
由於只有一個Controller的instance，當多個執行緒同時呼叫它的時候，它裡面的instance變數（可以理解為私有變數）就不是執行緒安全的了，會發生竄資料的問題。
當然大多數情況下，我們根本不需要考慮執行緒安全的問題，比如dao,service等，除非在bean中聲明瞭例項變數。因此，我們在使用spring mvc 的contrller時，應避免在controller中定義例項變數（singleton唯一的不好是單例的變數容易出現問題，下面有解決的方案）。
如：

publicclassControllerextendsAbstractCommandController{
......
protectedModelAndView handle(HttpServletRequest request,HttpServletResponse response,
Object command,BindException errors)throwsException{
company =................;
}
protectedCompany company;
}

在這裡有宣告一個變數company，這裡就存在併發執行緒安全的問題。
如果控制器是使用單例形式，且controller中有一個私有的變數a,所有請求到同一個controller時，使用的a變數是共用的，即若是某個請求中修改了這個變數a，則，在別的請求中能夠讀到這個修改的內容。。

有幾種解決方法：
1、在控制器中不使用例項變數（可以使用方法引數的形式解決，參考博文）
2、將控制器的作用域從單例改為原型，即在spring配置檔案Controller中宣告 scope="prototype"，每次都建立新的controller
3、在Controller中使用ThreadLocal變數

這幾種做法有好有壞，第一種，需要開發人員擁有較高的程式設計水平與思想意識，在編碼過程中力求避免出現這種BUG，

而第二種則是容器自動的對每個請求產生一個例項，由JVM進行垃圾回收，因此做到了執行緒安全。

使用第一種方式的好處是例項物件只有一個，所有的請求都呼叫該例項物件，速度和效能上要優於第二種，不好的地方，就是需要程式設計師自己去控制例項變數的狀態保持問題。第二種由於每次請求都建立一個例項，所以會消耗較多的記憶體空間。

所以在使用spring開發web 時要注意，預設Controller、Dao、Service都是單例的。

【1】SpringMVC多執行緒環境中如何保證物件的安全性？
程式碼如下：

@RequestMapping("/user") @Controller ClassUserController { @Resource UserService userService; @RequestMapping("/add") publicvoid testA(User user){ userService.add(user); } @RequestMapping("/get") publicvoid testA(int id){ userService.get(id); } } @Service("userService") ClassUserService{ publicstaticMap<Integer,User> usersCache =newHashMap<String,User>(); publicvoid add(User user){ usersCache.put(user.getId(),user); } publicvoidget(int id){ usersCache.get(id); } }

此段程式碼，usersCache物件就是執行緒不安全的。因為它是靜態的全域性共享物件。如果有多個執行緒同時呼叫add方法，可能會發生使用者物件被覆蓋的情況，也就是id對應物件不一致，這是多執行緒程式設計中最常發生的事情。 所以，可以使用 Collections 工具同步Map。 static Map<Integer, Users> usersCache = Collections.synchronizedMap(new HashMap<Integer, Users>()); 研究一下，Spring中的原始碼，它對常用的開源框架做了大量封裝，如，Hibernate中的sessionFactory，就使用的是 org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean，而在 AnnotationSessionFactoryBean的父類LocalSessionFactoryBean中，定義了大量的ThreadLocal來保證多執行緒的安全性。

publicclassLocalSessionFactoryBeanextendsAbstractSessionFactoryBeanimplementsBeanClassLoaderAware{ privatestaticfinalThreadLocal<DataSource> configTimeDataSourceHolder = newThreadLocal<DataSource>(); privatestaticfinalThreadLocal<TransactionManager> configTimeTransactionManagerHolder = newThreadLocal<TransactionManager>(); privatestaticfinalThreadLocal<Object> configTimeRegionFactoryHolder = newThreadLocal<Object>(); privatestaticfinalThreadLocal<CacheProvider> configTimeCacheProviderHolder = newThreadLocal<CacheProvider>(); privatestaticfinalThreadLocal<LobHandler> configTimeLobHandlerHolder = newThreadLocal<LobHandler>();

}