Java筆記備忘錄——解析Spring單例模式與執行緒安全
一、Spring單例模式與執行緒安全
Spring框架裡的bean，或者說元件，獲取例項的時候都是預設的單例模式，這是在多執行緒開發的時候要尤其注意的地方。
單例模式的意思就是隻有一個例項。單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項。這個類稱為單例類。
當多使用者同時請求一個服務時，容器會給每一個請求分配一個執行緒，這是多個執行緒會併發執行該請求多對應的業務邏輯（成員方法），此時就要注意了，如果該處理邏輯中有對該單列狀態的修改（體現為該單列的成員屬性），則必須考慮執行緒同步問題
同步機制的比較 ThreadLocal和執行緒同步機制相比有什麼優勢呢？ThreadLocal和執行緒同步機制都是為了解決多執行緒中相同變數的訪問衝突問題。
在同步機制中，通過物件的鎖機制保證同一時間只有一個執行緒訪問變數。這時該變數是多個執行緒共享的，使用同步機制要求程式慎密地分析什麼時候對變數進行讀寫，什麼時候需要鎖定某個物件，什麼時候釋放物件鎖等繁雜的問題，程式設計和編寫難度相對較大。
而ThreadLocal則從另一個角度來解決多執行緒的併發訪問。ThreadLocal會為每一個執行緒提供一個獨立的變數副本，從而隔離了多個執行緒對資料的訪問衝突。因為每一個執行緒都擁有自己的變數副本，從而也就沒有必要對該變數進行同步了。ThreadLocal提供了執行緒安全的共享物件，在編寫多執行緒程式碼時，可以把不安全的變數封裝進ThreadLocal。
由於ThreadLocal中可以持有任何型別的物件，低版本JDK所提供的get()返回的是Object物件，需要強制型別轉換。但JDK 5.0通過泛型很好的解決了這個問題，在一定程度地簡化ThreadLocal的使用
概括起來說，對於多執行緒資源共享的問題，同步機制採用了“以時間換空間”的方式，而ThreadLocal採用了“以空間換時間”的方式。前者僅提供一份變數，讓不同的執行緒排隊訪問，而後者為每一個執行緒都提供了一份變數，因此可以同時訪問而互不影響。
Spring使用ThreadLocal解決執行緒安全問題
我們知道在一般情況下，只有無狀態的Bean才可以在多執行緒環境下共享，在Spring中，絕大部分Bean都可以宣告為singleton作用域。就是因為Spring對一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非執行緒安全狀態採用ThreadLocal進行處理，讓它們也成為執行緒安全的狀態，因為有狀態的Bean就可以在多執行緒中共享了。
一般的Web應用劃分為展現層、服務層和持久層三個層次，在不同的層中編寫對應的邏輯，下層通過介面向上層開放功能呼叫。在一般情況下，從接收請求到返回響應所經過的所有程式呼叫都同屬於一個執行緒
ThreadLocal是解決執行緒安全問題一個很好的思路，它通過為每個執行緒提供一個獨立的變數副本解決了變數併發訪問的衝突問題。在很多情況下，ThreadLocal比直接使用synchronized同步機制解決執行緒安全問題更簡單，更方便，且結果程式擁有更高的併發性。
如果你的程式碼所在的程序中有多個執行緒在同時執行，而這些執行緒可能會同時執行這段程式碼。如果每次執行結果和單執行緒執行的結果是一樣的，而且其他的變數的值也和預期的是一樣的，就是執行緒安全的。 或者說:一個類或者程式所提供的介面對於執行緒來說是原子操作或者多個執行緒之間的切換不會導致該介面的執行結果存在二義性,也就是說我們不用考慮同步的問題。 執行緒安全問題都是由全域性變數及靜態變數引起的。
若每個執行緒中對全域性變數、靜態變數只有讀操作，而無寫操作，一般來說，這個全域性變數是執行緒安全的；若有多個執行緒同時執行寫操作，一般都需要考慮執行緒同步，否則就可能影響執行緒安全。
1） 常量始終是執行緒安全的，因為只存在讀操作。
2）每次呼叫方法前都新建一個例項是執行緒安全的，因為不會訪問共享的資源。
3）區域性變數是執行緒安全的。因為每執行一個方法，都會在獨立的空間建立區域性變數，它不是共享的資源。區域性變數包括方法的引數變數和方法內變數。
有狀態就是有資料儲存功能。有狀態物件(Stateful Bean)，就是有例項變數的物件 ，可以儲存資料，是非執行緒安全的。在不同方法呼叫間不保留任何狀態。
無狀態就是一次操作，不能儲存資料。無狀態物件(Stateless Bean)，就是沒有例項變數的物件 .不能儲存資料，是不變類，是執行緒安全的。
有狀態物件:
無狀態的Bean適合用不變模式，技術就是單例模式，這樣可以共享例項，提高效能。有狀態的Bean，多執行緒環境下不安全，那麼適合用Prototype原型模式。Prototype: 每次對bean的請求都會建立一個新的bean例項。
Struts2預設的實現是Prototype模式。也就是每個請求都新生成一個Action例項，所以不存線上程安全問題。需要注意的是，如果由Spring管理action的生命週期， scope要配成prototype作用域。
二、執行緒安全案例：
SimpleDateFormat(下面簡稱sdf)類內部有一個Calendar物件引用,它用來儲存和這個sdf相關的日期資訊,例如sdf.parse(dateStr), sdf.format(date) 諸如此類的方法引數傳入的日期相關String, Date等等, 都是交友Calendar引用來儲存的.這樣就會導致一個問題,如果你的sdf是個static的, 那麼多個thread 之間就會共享這個sdf, 同時也是共享這個Calendar引用, 並且, 觀察 sdf.parse() 方法,你會發現有如下的呼叫:
Date parse() {
calendar.clear(); // 清理calendar
... // 執行一些操作, 設定 calendar 的日期什麼的
calendar.getTime(); // 獲取calendar的時間
}
這裡會導致的問題就是, 如果 執行緒A 呼叫了 sdf.parse(), 並且進行了 calendar.clear()後還未執行calendar.getTime()的時候,執行緒B又呼叫了sdf.parse(), 這時候執行緒B也執行了sdf.clear()方法, 這樣就導致執行緒A的的calendar資料被清空了(實際上A,B的同時被清空了). 又或者當 A 執行了calendar.clear() 後被掛起, 這時候B 開始呼叫sdf.parse()並順利i結束, 這樣 A 的 calendar記憶體儲的的date 變成了後來B設定的calendar的date
這個問題背後隱藏著一個更為重要的問題--無狀態：無狀態方法的好處之一，就是它在各種環境下，都可以安全的呼叫。衡量一個方法是否是有狀態的，就看它是否改動了其它的東西，比如全域性變數，比如例項的欄位。format方法在執行過程中改動了SimpleDateFormat的calendar欄位，所以，它是有狀態的。
這也同時提醒我們在開發和設計系統的時候注意下一下三點:
1.自己寫公用類的時候，要對多執行緒呼叫情況下的後果在註釋裡進行明確說明
2.對執行緒環境下，對每一個共享的可變變數都要注意其執行緒安全性
3.我們的類和方法在做設計的時候，要儘量設計成無狀態的
三.解決辦法
1.需要的時候建立新例項：
說明：在需要用到SimpleDateFormat 的地方新建一個例項，不管什麼時候，將有執行緒安全問題的物件由共享變為區域性私有都能避免多執行緒問題，不過也加重了建立物件的負擔。在一般情況下，這樣其實對效能影響比不是很明顯的。
2.使用同步：同步SimpleDateFormat物件
public class DateSyncUtil {
private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static String formatDate(Date date)throws ParseException{
synchronized(sdf){
return sdf.format(date);
}
}
public static Date parse(String strDate) throws ParseException{
synchronized(sdf){
return sdf.parse(strDate);
}
}
}
說明：當執行緒較多時，當一個執行緒呼叫該方法時，其他想要呼叫此方法的執行緒就要block，多執行緒併發量大的時候會對效能有一定的影響。
3.使用ThreadLocal：
public class ConcurrentDateUtil {
private static ThreadLocal threadLocal = new ThreadLocal() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
}
};
public static Date parse(String dateStr) throws ParseException {
return threadLocal.get().parse(dateStr);
}
public static String format(Date date) {
return threadLocal.get().format(date);
}
}
或
public class ThreadLocalDateUtil {
private static final String date_format = "yyyy-MM-dd HH:mm:ss";
private static ThreadLocal threadLocal = new ThreadLocal();
public static DateFormat getDateFormat()
{
DateFormat df = threadLocal.get();
if(df==null){
df = new SimpleDateFormat(date_format);
threadLocal.set(df);
}
return df;
}
public static String formatDate(Date date) throws ParseException {
return getDateFormat().format(date);
}
public static Date parse(String strDate) throws ParseException {
return getDateFormat().parse(strDate);
}
}
說明：使用ThreadLocal, 也是將共享變數變為獨享，執行緒獨享肯定能比方法獨享在併發環境中能減少不少建立物件的開銷。如果對效能要求比較高的情況下，一般推薦使用這種方法。
4.拋棄JDK，使用其他類庫中的時間格式化類：
1.使用Apache commons 裡的FastDateFormat，宣稱是既快又執行緒安全的SimpleDateFormat, 可惜它只能對日期進行format, 不能對日期串進行解析。
2.使用Joda-Time類庫來處理時間相關問題
做一個簡單的壓力測試，方法一最慢，方法三最快，但是就算是最慢的方法一效能也不差，一般系統方法一和方法二就可以滿足，所以說在這個點很難成為你係統的瓶頸所在。從簡單的角度來說，建議使用方法一或者方法二，如果在必要的時候，追求那麼一點效能提升的話，可以考慮用方法三，用ThreadLocal做快取。
Joda-Time類庫對時間處理方式比較完美，建議使用。
最後
如果你對技術提升很感興趣，可以加入我的Java進階之路來交流學習：878249276，裡面都是同行，有資源共享。歡迎一到五年的工程師加入，合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！