摘要：線程安全問題都是由全局變量及靜態(tài)變量引起的。常量始終是線程安全的，因為只存在讀操作。局部變量是線程安全的。有狀態(tài)對象，就是有實例變量的對象，可以保存數(shù)據(jù)，是非線程安全的。

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

??因為寫程序時，或做單元測試時，很難有機會碰到多線程的問題，因為沒有那么容易模擬多線程測試的環(huán)境。那么當(dāng)多個線程調(diào)用同一個bean的時候就會存在線程安全問題。如果是Spring中bean的創(chuàng)建模式為非單例的，也就不存在這樣的問題了。

??但如果不去考慮潛在的漏洞，它就會變成程序的隱形殺手，在你不知道的時候爆發(fā)。而且，通常是程序交付使用時，在生產(chǎn)環(huán)境下觸發(fā)，會是很麻煩的事。

??我們知道在一般情況下，只有無狀態(tài)的Bean才可以在多線程環(huán)境下共享，在Spring中，絕大部分Bean都可以聲明為singleton作用域。就是因為Spring對一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非線程安全狀態(tài)采用ThreadLocal進(jìn)行處理，讓它們也成為線程安全的狀態(tài)，因為有狀態(tài)的Bean就可以在多線程中共享了。

??一般的Web應(yīng)用劃分為展現(xiàn)層、服務(wù)層和持久層三個層次，在不同的層中編寫對應(yīng)的邏輯，下層通過接口向上層開放功能調(diào)用。在一般情況下，從接收請求到返回響應(yīng)所經(jīng)過的所有程序調(diào)用都同屬于一個線程

??ThreadLocal是解決線程安全問題一個很好的思路，它通過為每個線程提供一個獨立的變量副本解決了變量并發(fā)訪問的沖突問題。在很多情況下，ThreadLocal比直接使用synchronized同步機制解決線程安全問題更簡單，更方便，且結(jié)果程序擁有更高的并發(fā)性。

??如果你的代碼所在的進(jìn)程中有多個線程在同時運行，而這些線程可能會同時運行這段代碼。如果每次運行結(jié)果和單線程運行的結(jié)果是一樣的，而且其他的變量的值也和預(yù)期的是一樣的，就是線程安全的。 或者說:一個類或者程序所提供的接口對于線程來說是原子操作或者多個線程之間的切換不會導(dǎo)致該接口的執(zhí)行結(jié)果存在二義性,也就是說我們不用考慮同步的問題。線程安全問題都是由全局變量及靜態(tài)變量引起的。

??若每個線程中對全局變量、靜態(tài)變量只有讀操作，而無寫操作，一般來說，這個全局變量是線程安全的；若有多個線程同時執(zhí)行寫操作，一般都需要考慮線程同步，否則就可能影響線程安全。
　　1） 常量始終是線程安全的，因為只存在讀操作。
　　2）每次調(diào)用方法前都新建一個實例是線程安全的，因為不會訪問共享的資源。
　　3）局部變量是線程安全的。因為每執(zhí)行一個方法，都會在獨立的空間創(chuàng)建局部變量，它不是共享的資源。局部變量包括方法的參數(shù)變量和方法內(nèi)變量。

??有狀態(tài)就是有數(shù)據(jù)存儲功能。有狀態(tài)對象(Stateful Bean)，就是有實例變量的對象 ，可以保存數(shù)據(jù)，是非線程安全的。在不同方法調(diào)用間不保留任何狀態(tài)。

??無狀態(tài)就是一次操作，不能保存數(shù)據(jù)。無狀態(tài)對象(Stateless Bean)，就是沒有實例變量的對象 .不能保存數(shù)據(jù)，是不變類，是線程安全的。

　　有狀態(tài)對象:

??無狀態(tài)的Bean適合用不變模式，技術(shù)就是單例模式，這樣可以共享實例，提高性能。有狀態(tài)的Bean，多線程環(huán)境下不安全，那么適合用Prototype原型模式。Prototype: 每次對bean的請求都會創(chuàng)建一個新的bean實例。

??Struts2默認(rèn)的實現(xiàn)是Prototype模式。也就是每個請求都新生成一個Action實例，所以不存在線程安全問題。需要注意的是，如果由Spring管理action的生命周期， scope要配成prototype作用域

??SimpleDateFormat(?下面簡稱?sdf)?類內(nèi)部有一個?Calendar?對象引用?,?它用來儲存和這個?sdf?相關(guān)的日期信息?,?例如?sdf.parse(dateStr),?sdf.format(date)??諸如此類的方法參數(shù)傳入的日期相關(guān)?String,?Date?等等?,??都是交友?Calendar?引用來儲存的?.?這樣就會導(dǎo)致一個問題?,?如果你的?sdf?是個?static?的?,??那么多個?thread??之間就會共享這個?sdf,?同時也是共享這個?Calendar?引用?,??并且?,??觀察??sdf.parse()??方法?,?你會發(fā)現(xiàn)有如下的調(diào)用?:

 Date parse() {
   calendar.clear(); // 清理calendar
   ... // 執(zhí)行一些操作, 設(shè)置 calendar 的日期什么的
   calendar.getTime(); // 獲取calendar的時間
 }

??這里會導(dǎo)致的問題就是?,??如果?線程?A??調(diào)用了??sdf.parse(),??并且進(jìn)行了?calendar.clear()?后還未執(zhí)行?calendar.getTime()?的時候?,?線程?B?又調(diào)用了?sdf.parse(),?這時候線程?B?也執(zhí)行了?sdf.clear()?方法?,??這樣就導(dǎo)致線程?A?的的?calendar?數(shù)據(jù)被清空了?(?實際上?A,B?的同時被清空了?).??又或者當(dāng)??A??執(zhí)行了?calendar.clear()??后被掛起?,??這時候?B??開始調(diào)用?sdf.parse()?并順利?i?結(jié)束?,??這樣??A??的??calendar?內(nèi)存儲的的?date?變成了后來?B?設(shè)置的?calendar?的?date

??這個問題背后隱藏著一個更為重要的問題?--?無狀態(tài)：無狀態(tài)方法的好處之一，就是它在各種環(huán)境下，都可以安全的調(diào)用。衡量一個方法是否是有狀態(tài)的，就看它是否改動了其它的東西，比如全局變量，比如實例的字段。?format?方法在運行過程中改動了SimpleDateFormat?的?calendar?字段，所以，它是有狀態(tài)的。

??這也同時提醒我們在開發(fā)和設(shè)計系統(tǒng)的時候注意下以下三點?:

自己寫公用類的時候，要對多線程調(diào)用情況下的后果在注釋里進(jìn)行明確說明

對線程環(huán)境下，對每一個共享的可變變量都要注意其線程安全性

我們的類和方法在做設(shè)計的時候，要盡量設(shè)計成無狀態(tài)的

??說明：在需要用到?SimpleDateFormat??的地方新建一個實例，不管什么時候，將有線程安全問題的對象由共享變?yōu)榫植克接卸寄鼙苊舛嗑€程問題，不過也加重了創(chuàng)建對象的負(fù)擔(dān)。在一般情況下，這樣其實對性能影響比不是很明顯的。

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);
        }
    } 
}

??說明：當(dāng)線程較多時，當(dāng)一個線程調(diào)用該方法時，其他想要調(diào)用此方法的線程就要block ，多線程并發(fā)量大的時候會對性能有一定的影響。

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);
    }
}

??或

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,??也是將共享變量變?yōu)楠毾恚€程獨享肯定能比方法獨享在并發(fā)環(huán)境中能減少不少創(chuàng)建對象的開銷。如果對性能要求比較高的情況下，一般推薦使用這種方法。

使用?Apache?commons??里的?FastDateFormat?，宣稱是既快又線程安全的SimpleDateFormat,??可惜它只能對日期進(jìn)行?format,??不能對日期串進(jìn)行解析。

使用?Joda-Time?類庫來處理時間相關(guān)問題

??做一個簡單的壓力測試，方法一最慢，方法三最快，但是就算是最慢的方法一性能也不差，一般系統(tǒng)方法一和方法二就可以滿足，所以說在這個點很難成為你系統(tǒng)的瓶頸所在。從簡單的角度來說，建議使用方法一或者方法二，如果在必要的時候，追求那么一點性能提升的話，可以考慮用方法三，用?ThreadLocal?做緩存。

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

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

??其實代碼誰都會寫，為什么架構(gòu)師寫的代碼效果和你的天差地別呢？應(yīng)該就是此類你沒考慮到的小問題而架構(gòu)師都考慮到了。

??架構(gòu)師知識面更廣，見識到的具體情況更多，解決各類問題的經(jīng)驗更豐富。只要你養(yǎng)成架構(gòu)師的思維和習(xí)慣，那你離架構(gòu)師還會遠(yuǎn)嗎？