如何看待Spring下單例模式與線程安全的矛盾

前言

有多少人在使用Spring框架時，不少時候不知道或者忽視了多線程的問題？

  由於寫程序時，或作單元測試時，很難有機會碰到多線程的問題，由於沒有那麼容易模擬多線程測試的環境。那麼當多個線程調用同一個bean的時候就會存在線程安全問題。若是是Spring中bean的建立模式爲非單例的，也就不存在這樣的問題了。

  但若是不去考慮潛在的漏洞，它就會變成程序的隱形殺手，在你不知道的時候爆發。並且，一般是程序交付使用時，在生產環境下觸發，會是很麻煩的事。

---

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. 須要的時候建立新實例：

  說明：在須要用到 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<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {
        @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);
    }
}

  或

ThreadLocal<DateFormat>(); 
 
    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 ，使用其餘類庫中的時間格式化類：

• 使用 Apache commons  裏的 FastDateFormat ，宣稱是既快又線程安全的SimpleDateFormat,  惋惜它只能對日期進行 format,  不能對日期串進行解析。
• 使用 Joda-Time 類庫來處理時間相關問題

  作一個簡單的壓力測試，方法一最慢，方法三最快，可是就算是最慢的方法一性能也不差，通常系統方法一和方法二就能夠知足，因此說在這個點很難成爲你係統的瓶頸所在。從簡單的角度來講，建議使用方法一或者方法二，若是在必要的時候，追求那麼一點性能提高的話，能夠考慮用方法三，用 ThreadLocal 作緩存。

  Joda-Time 類庫對時間處理方式比較完美，建議使用。

總結

  回到文章開頭的問題：《有多少人在使用Spring框架時，不少時候不知道或者忽視了多線程的問題？》

  其實代碼誰都會寫，爲何架構師寫的代碼效果和你的天差地別呢？應該就是此類你沒考慮到的小問題而架構師都考慮到了。

  架構師知識面更廣，見識到的具體狀況更多，解決各種問題的經驗更豐富。只要你養成架構師的思惟和習慣，那你離架構師還會遠嗎？