起因

sonar 是一個代碼質量管理工具，SonarQube是一個用于代碼質量管理的開放平臺。

為項目提供可視化報告，連續(xù)追蹤項目質量演化過程。

通過插件機制，Sonar可以集成不同的測試工具，代碼分析工具，以及持續(xù)集成工具。

對結果進行再加工處理，通過量化的方式度量代碼質量的變化。

某天它揭露了代碼里這樣一個級別為嚴重的違規(guī)。

SimpleDateFormat 源碼解析

根據 sonar 的提示，SimpleDateFormat 的 format 方法可能存在線程安全的問題，那么來看下SimpleDateFormat 的源碼，看看是否如此

// Called from Format after creating a FieldDelegate
    private StringBuffer format(Date date, StringBuffer toAppendTo,
                                FieldDelegate delegate) {
        // Convert input date to time field list
        calendar.setTime(date);
        boolean useDateFormatSymbols = useDateFormatSymbols();
        for (int i = 0; i < compiledPattern.length; ) {
            int tag = compiledPattern[i] >>> 8;
            int count = compiledPattern[i++] & 0xff;
            if (count == 255) {
                count = compiledPattern[i++] << 16;
                count |= compiledPattern[i++];
            }
            switch (tag) {
            case TAG_QUOTE_ASCII_CHAR:
                toAppendTo.append((char)count);
                break;
            case TAG_QUOTE_CHARS:
                toAppendTo.append(compiledPattern, i, count);
                i += count;
                break;
            default:
                subFormat(tag, count, delegate, toAppendTo, useDateFormatSymbols);
                break;
            }
        }
        return toAppendTo;
    }

當看到高亮的那行代碼時，就基本可以認定 SimpleDateFormat.format() 不是線程安全的：在多線程環(huán)境下，每次調用 format 方法時，calendar 都會將時間設置為傳入的時間，這樣如果上一個線程的 format 方法還在執(zhí)行中，肯定會導致輸出的結果不正確。

如何做到線程安全

那么怎么做才能線程安全呢？

不用靜態(tài)屬性

每次需要格式化日期時，new 一個 DateFormat，保證線程安全，我們可以這樣“優(yōu)化”一下

String inputValue = game.getId() + new SimpleDateFormat( "yyyyMMdd" ).format( new Date() );

雖然線程安全了，但是這樣性能就下降了，如果這段代碼頻繁的調用，不僅 new 一個 DateFormat 對象的代價有點大，而且頻繁的 new 也會導致 gc 的壓力增大

同步或者加鎖

既然 format() 方法線程不安全，那就在調用時采用同步或加鎖，例如

private static SimpleDateFormat df = new SimpleDateFormat( "yyyyMMdd" );// 設置日期格式
	private static final Lock LOCK = new ReentrantLock();
	@Override
	public void addGame( Game game ) {
		......
		LOCK.lock();
		try {
			String inputValue = game.getId() + df.format( new Date() );
		} finally {
			LOCK.unlock();
		}
		......
	}

DateFormat 池

加鎖是解決了線程安全的問題，也不會因為 new 出太多的 DateFormat 增加 gc 的負擔，但是很顯然并發(fā)性能大大的降低了，如果在并發(fā)性要求較高的場合，還不如 new 一個的性能高呢，那有什么辦法再優(yōu)化一下嗎

可以實現(xiàn)一個 DateFormat 池，實現(xiàn)如下功能

1. 設定池的大小，在池實例化的同時，實例化一批 DateFormat

2. 每個 DateFormat 都有一個狀態(tài)，表明當前是空閑還是忙，初始狀態(tài)為空閑

3. 當需要格式化日期時，從池里取出一個空閑的 DateFormat，同時將其標記為忙

4. 池里的 DateFormat 的 format 方法需要重寫，在 format 完成后將其狀態(tài)標記為空閑

用池的優(yōu)勢很明顯：只要設定合適的池大小，就不用擔心并發(fā)性能；并且也不存在增加 gc 負擔的問題；當然池的實現(xiàn)比較復雜，而且池內部也要解決線程安全問題，可以考慮采用一些開源的池框架例如 Apache commons pool 來做

ThreadLocal<DateFormat>

在引入 ThreadLocal 之前，思考一下這個問題：如果只有一個線程，format 方法還存在線程安全問題嗎？ 顯然不會，如果只有一個線程，那么 format 方法實際上是串行執(zhí)行的，絕無可能并行執(zhí)行；那么，如果在多線程環(huán)境下，給每個線程都分配一個固定的 DateFormat 來執(zhí)行 format 方法，顯然也不會有線程安全的問題了 ThreadLocal 就是用于這種思路的一個解決方案：為每個使用該變量的線程提供獨立的變量副本，所以每一個線程都可以獨立地改變自己的副本，而不會影響其它線程所對應的副本。 ThreadLocal 的使用如下

private static final String DATE_FORMAT = "yyyy-MM-dd";
private static final ThreadLocal<DateFormat> SDF  = new ThreadLocal<DateFormat>() {
    protected synchronized DateFormat initialValue() {
        return new SimpleDateFormat(
            DATE_FORMAT);
                }
        };
            ......
album.setReleaseDate(SDF.get().parse(show.getReleasedate().substring(0, 10))); // 發(fā)布日期

先看每次都 new 一個新對象和 ThreaLocal之間的差別，假設有 1 個線程要執(zhí)行 n 次 format

1. new：n 個實例

2. ThreadLocal：1 個實例.但是，如果是 n 個線程，每個線程只執(zhí)行 1 次 format 呢？

 new：n 個實例

 ThreadLocal：n 個實例

很顯然，如果使用 ThreadLocal 的話，線程應該是能復用的，否則和 new 的效果是一樣滴

再看加鎖和池的差別，主要表現(xiàn)在并發(fā)性能方面，加鎖實際導致了串行化，不滿足高并發(fā)的場合

再看下池和 ThreadLocal的差別

3. 并發(fā)性能上2者都很優(yōu)秀

4. 相對來說 ThreadLocal 的實現(xiàn)更簡單，而且完全不需要加鎖或同步，而池在管理池內的元素時免不了需要加鎖或同步

5. 池的復用性最好，而 ThreadLocal 的復用性則完全取決于其宿主線程的復用性

到此這篇關于Java中的SimpleDateFormat的線程安全問題詳解的文章就介紹到這了,更多相關SimpleDateFormat線程安全問題內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論