為什麼SimpleDateFormat不是線程安全的?

點擊上方小偉後端筆記關注公眾號

一、前言日期的轉換與格式化在項目中應該是比較常用的了，最近同事小剛出去面試實在是沒想到被 SimpleDateFormat 給擺了一道...

👨‍💻面試官：項目中的日期轉換怎麼用的？SimpleDateFormat 用過嗎？能說一下 SimpleDateFormat 線程安全問題嗎，以及如何解決？

🙋同事小剛：用過的，平時就是在全局定義一個 static 的 SimpleDateFormat，然後在業務處理方法中直接使用的，至於線程安全... 這個... 倒是沒遇到過線程安全問題。

哎，面試官的考察點真的是難以捉摸，吐槽歸吐槽，一起來看看這個類吧。

二、概述SimpleDateFormat 類主要負責日期的轉換與格式化等操作，在多線程的環境中，使用此類容易造成數據轉換及處理的不正確，因為 SimpleDateFormat 類並不是線程安全的，但在單線程環境下是沒有問題的。

SimpleDateFormat 在類注釋中也提醒大家不適用於多線程場景：

Date formats are not synchronized.
It is recommended to create separate format instances for each thread.
If multiple threads access a format concurrently, it must be synchronized
externally.

日期格式不同步。
建議為每個線程創建單獨的格式實例。 
如果多個線程同時訪問一種格式，則必須在外部同步該格式。
來看看阿里巴巴 java 開發規範是怎麼描述 SimpleDateFormat 的：
三、模擬線程安全問題無碼無真相，接下來我們創建一個線程來模擬 SimpleDateFormat 線程安全問題：
創建 MyThread.java 類：
public class MyThread extends Thread{
  
    private SimpleDateFormat simpleDateFormat;
  // 要轉換的日期字符串
    private String dateString;

    public MyThread(SimpleDateFormat simpleDateFormat, String dateString){
        this.simpleDateFormat = simpleDateFormat;
        this.dateString = dateString;
    }

    @Override
    public void run() {
        try {
            Date date = simpleDateFormat.parse(dateString);
            String newDate = simpleDateFormat.format(date).toString();
            if(!newDate.equals(dateString)){
                System.out.println("ThreadName=" + this.getName()
                    + " 報錯了，日期字符串：" + dateString
                    + " 轉換成的日期為：" + newDate);
            }
        }catch (ParseException e){
            e.printStackTrace();
        }
    }
}
創建執行類 Test.java 類：
public class Test {

    // 一般我們使用SimpleDateFormat的時候會把它定義為一個靜態變量，避免頻繁創建它的對象實例
    private static SimpleDateFormat simpleDateFormat = new SimpleDateFormat("YYYY-MM-dd");

    public static void main(String[] args) {

        String[] dateStringArray = new String[] { "2020-09-10", "2020-09-11", "2020-09-12", "2020-09-13", "2020-09-14"};

        MyThread[] myThreads = new MyThread[5];

        // 創建線程
        for (int i = 0; i < 5; i++) {
            myThreads[i] = new MyThread(simpleDateFormat, dateStringArray[i]);
        }

        // 啟動線程
        for (int i = 0; i < 5; i++) {
            myThreads[i].start();
        }
    }
}
執行截圖如下：
從控制臺列印的結果來看，使用單例的 SimpleDateFormat 類在多線程的環境中處理日期轉換，極易出現轉換異常（java.lang.NumberFormatException:multiple points）以及轉換錯誤的情況。
四、線程不安全的原因這個時候就需要看看源碼了，format() 格式轉換方法：
// 成員變量 Calendar
protected Calendar calendar;

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;
}
我們把重點放在 calendar ，這個 format 方法在執行過程中，會操作成員變量  calendar 來保存時間  calendar.setTime(date) 。
但由於在聲明 SimpleDateFormat 的時候，使用的是 static 定義的，那麼這個 SimpleDateFormat 就是一個共享變量，SimpleDateFormat 中的 calendar 也就可以被多個線程訪問到，所以問題就出現了，舉個例子：
假設線程 A 剛執行完 calendar.setTime(date) 語句，把時間設置為 2020-09-01，但線程還沒執行完，線程 B 又執行了 calendar.setTime(date) 語句，把時間設置為 2020-09-02，這個時候就出現幻讀了，線程 A 繼續執行下去的時候，拿到的 calendar.getTime 得到的時間就是線程B改過之後的。
除了 format() 方法以外，SimpleDateFormat 的 parse() 方法也有同樣的問題。
至此，我們發現了 SimpleDateFormat 的弊端，所以為了解決這個問題就是不要把 SimpleDateFormat 當做一個共享變量來使用。
五、如何解決線程安全1、每次使用就創建一個新的 SimpleDateFormat
創建全局工具類 DateUtils.java
public class DateUtils {
    public static Date parse(String formatPattern, String dateString) throws ParseException {
        return new SimpleDateFormat(formatPattern).parse(dateString);
    }

    public static String  format(String formatPattern, Date date){
        return new SimpleDateFormat(formatPattern).format(date);
    }
}
所有用到 SimpleDateFormat 的地方全部用 DateUtils 替換，然後看一下執行結果：
好傢夥，異常+錯誤終於是沒了，這種解決處理錯誤的原理就是創建了多個 SimpleDateFormat 類的實例，在需要用到的地方創建一個新的實例，就沒有線程安全問題，不過也加重了創建對象的負擔，會頻繁地創建和銷毀對象，效率較低。
2、synchronized 鎖
synchronized 就不展開介紹了，不了解的小夥伴請移步 > synchronized的底層原理？
變更一下 DateUtils.java
public class DateUtils {

    private static final SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    public static Date parse(String formatPattern, String dateString) throws ParseException {
        synchronized (simpleDateFormat){
            return simpleDateFormat.parse(dateString);
        }
    }

    public static String format(String formatPattern, Date date) {
        synchronized (simpleDateFormat){
            return simpleDateFormat.format(date);
        }
    }
}
簡單粗暴，synchronized 往上一套也可以解決線程安全問題，缺點自然就是並發量大的時候會對性能有影響，因為使用了 synchronized 加鎖後的多線程就相當於串行，線程阻塞，執行效率低。
3、ThreadLocal（最佳MVP）
ThreadLocal 是 java 裡一種特殊的變量，ThreadLocal 提供了線程本地的實例，它與普通變量的區別在於，每個使用該線程變量的線程都會初始化一個完全獨立的實例副本。
繼續改造 DateUtils.java
public class DateUtils {

    private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>(){
        @Override
        protected DateFormat initialValue() {
            return new SimpleDateFormat("yyyy-MM-dd");
        }
    };

    public static Date parse(String formatPattern, String dateString) throws ParseException {
        return threadLocal.get().parse(dateString);
    }

    public static String format(String formatPattern, Date date) {
        return threadLocal.get().format(date);
    }
}
ThreadLocal 可以確保每個線程都可以得到單獨的一個 SimpleDateFormat 的對象，那麼就不會存在競爭問題。
如果項目中還在使用 SimpleDateFormat 的話，推薦這種寫法，但這樣就結束了嗎？
顯然不是...
六、項目中推薦的寫法上邊提到的阿里巴巴 java 開發手冊給出了說明：如果是 JDK8 的應用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方給出的解釋：simple beautiful strong immutable thread-safe。
日期轉換，SimpleDateFormat 固然好用，但是現在我們已經有了更好地選擇，Java 8 引入了新的日期時間 API，並引入了線程安全的日期類，一起來看看。
LocalDate：本地日期，不包含具體時間 例如：2014-01-14 可以用來記錄生日、紀念日、加盟日等。LocalDateTime：組合了日期和時間，但不包含時差和時區信息。ZonedDateTime：最完整的日期時間，包含時區和相對UTC或格林威治的時差。
新API還引入了 ZoneOffSet 和 ZoneId 類，使得解決時區問題更為簡便。
解析、格式化時間的 DateTimeFormatter 類也進行了全部重新設計。
例如，我們使用 LocalDate 代替 Date，使用 DateTimeFormatter 代替 SimpleDateFormat，如下所示:
// 當前日期和時間
String DateNow = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss")); 
System.out.println(DateNow);
這樣就避免了 SimpleDateFormat 的線程不安全問題啦。
此時的 DateUtils.java
public class DateUtils {

    public static final DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd");

    public static LocalDate parse(String dateString){
        return LocalDate.parse(dateString, DATE_TIME_FORMATTER);
    }

    public static String format(LocalDate target) {
        return target.format(DATE_TIME_FORMATTER);
    }
}
七、最後總結
SimpleDateFormart 線程不安全問題
SimpleDateFormart 繼承自 DateFormart，在 DataFormat 類內部有一個 Calendar 對象引用，SimpleDateFormat 轉換日期都是靠這個 Calendar 對象來操作的，比如 parse(String)，format(date) 等類似的方法，Calendar 在用的時候是直接使用的，而且是改變了 Calendar 的值，這樣情況在多線程下就會出現線程安全問題，如果 SimpleDateFormart 是靜態的話，那麼多個 thread 之間就會共享這個 SimpleDateFormart，同時也會共享這個 Calendar 引用，那麼就出現數據賦值覆蓋情況，也就是線程安全問題。(現在項目中用到日期轉換，都是使用的 java 8 中的 LocalDate，或者 LocalDateTime，本質是這些類是不可變類，不可變一定程度上保證了線程安全)。
解決方式
在多線程下可以使用 ThreadLocal 修飾 SimpleDateFormart，ThreadLocal 可以確保每個線程都可以得到單獨的一個 SimpleDateFormat 的對象，那麼就不會存在競爭問題。
項目中推薦的寫法
java 8 中引入新的日期類 API，這些類是不可變的，且線程安全的。
以後面試官再問項目中怎麼使用日期轉換的，就不要說 SimpleDateFormat 了~