博客 / 詳情

返回

SimpleDateFormat 線程安全問題修復方案 | 京東物流技術團隊

問題介紹

在日常的開發過程中，我們不可避免地會使用到 JDK8 之前的 Date 類，在格式化日期或解析日期時就需要用到 SimpleDateFormat 類，但由於該類並不是線程安全的，所以我們常發現對該類的不恰當使用會導致日期解析異常，從而影響線上服務可用率。

以下是對 SimpleDateFormat 類不恰當使用的示例代碼：

package com.jd.threadsafe;

import java.text.SimpleDateFormat;
import java.util.concurrent.atomic.AtomicBoolean;

/**
 * @Date: 2023/7/25 10:47
 * @Desc: SimpleDateFormat 線程安全問題復現
 * @Version: V1.0
 **/
public class SimpleDateFormatTest {
    private static final AtomicBoolean STOP = new AtomicBoolean();
    private static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-M-d"); // 非線程安全

    public static void main(String[] args) {
        Runnable runnable = () -> {
            int count = 0;
            while (!STOP.get()) {
                try {
                    FORMATTER.parse("2023-7-15");
                } catch (Exception e) {
                    e.printStackTrace();
                    if (++count > 3) {
                        STOP.set(true);
                    }
                }
            }
        };

        new Thread(runnable).start();
        new Thread(runnable).start();
    }
}

以上代碼模擬了多線程併發使用 SimpleDateFormat 實例的場景，此時可觀察到如下異常輸出：

java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Long.parseLong(Long.java:601)
    at java.lang.Long.parseLong(Long.java:631)
    at java.text.DigitList.getLong(DigitList.java:195)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2082)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at com.jd.threadsafe.SimpleDateFormatTest.lambda$main$0(SimpleDateFormatTest.java:21)
    at java.lang.Thread.run(Thread.java:750)
java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Long.parseLong(Long.java:601)
    at java.lang.Long.parseLong(Long.java:631)
    at java.text.DigitList.getLong(DigitList.java:195)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2082)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at com.jd.threadsafe.SimpleDateFormatTest.lambda$main$0(SimpleDateFormatTest.java:21)
    at java.lang.Thread.run(Thread.java:750)
java.lang.NumberFormatException: multiple points
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1890)
    at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
    at java.lang.Double.parseDouble(Double.java:538)
    at java.text.DigitList.getDouble(DigitList.java:169)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2087)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at com.jd.threadsafe.SimpleDateFormatTest.lambda$main$0(SimpleDateFormatTest.java:21)
    at java.lang.Thread.run(Thread.java:750)
java.lang.NumberFormatException: multiple points
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1890)
    at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
    at java.lang.Double.parseDouble(Double.java:538)
    at java.text.DigitList.getDouble(DigitList.java:169)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2087)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at com.jd.threadsafe.SimpleDateFormatTest.lambda$main$0(SimpleDateFormatTest.java:21)
    at java.lang.Thread.run(Thread.java:750)
java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Long.parseLong(Long.java:601)
    at java.lang.Long.parseLong(Long.java:631)
    at java.text.DigitList.getLong(DigitList.java:195)
    at java.text.DecimalFormat.parse(DecimalFormat.java:2082)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
    at java.text.DateFormat.parse(DateFormat.java:364)
    at com.jd.threadsafe.SimpleDateFormatTest.lambda$main$0(SimpleDateFormatTest.java:21)
    at java.lang.Thread.run(Thread.java:750)

以上異常的根本原因是因為 SimpleDateFormat 是有狀態的，如 SimpleDateFormat 類中含有非線程安全的 NumberFormat 成員變量：

/**
 * The number formatter that <code>DateFormat</code> uses to format numbers
 * in dates and times.  Subclasses should initialize this to a number format
 * appropriate for the locale associated with this <code>DateFormat</code>.
 * @serial
 */
protected NumberFormat numberFormat;

從 NumberFormat 的 Java Doc 中能看到如下描述：

Synchronization Number formats are generally 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.

從 SimpleDateFormat 的 Java Doc 中能看到如下描述：

Synchronization 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.

修復方案一：加鎖（不推薦）

package com.jd.threadsafe;

import java.text.SimpleDateFormat;
import java.util.concurrent.atomic.AtomicBoolean;

/**
 * @Date: 2023/7/25 10:47
 * @Desc: SimpleDateFormat 線程安全修復方案：加鎖
 * @Version: V1.0
 **/
public class SimpleDateFormatLockTest {
    private static final AtomicBoolean STOP = new AtomicBoolean();
    private static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-M-d"); // 非線程安全

    public static void main(String[] args) {
        Runnable runnable = () -> {
            int count = 0;
            while (!STOP.get()) {
                try {
                    synchronized (FORMATTER) {
                        FORMATTER.parse("2023-7-15");
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                    if (++count > 3) {
                        STOP.set(true);
                    }
                }
            }
        };

        new Thread(runnable).start();
        new Thread(runnable).start();
    }

}

首先我們能想到的最簡單的解決線程安全問題的修復方案即加鎖，如以上修復方案，使用 synchronized 關鍵字對 FORMATTER 實例進行加鎖，此時多線程進行日期格式化時退化為串行執行，保證了正確性但犧牲了性能，不推薦。

修復方案二：棧封閉（不推薦）

如果按照文檔中的推薦用法，可知推薦為每個線程創建獨立的 SimpleDateFormat 實例，一種最簡單的方式就是在方法調用時每次創建 SimpleDateFormat 實例，以實現棧封閉的效果，如以下示例代碼：

package com.jd.threadsafe;

import java.text.SimpleDateFormat;
import java.util.concurrent.atomic.AtomicBoolean;

/**
 * @Date: 2023/7/25 10:47
 * @Desc: SimpleDateFormat 線程安全修復方案：棧封閉
 * @Version: V1.0
 **/
public class SimpleDateFormatStackConfinementTest {
    private static final AtomicBoolean STOP = new AtomicBoolean();

    public static void main(String[] args) {
        Runnable runnable = () -> {
            int count = 0;
            while (!STOP.get()) {
                try {
                    new SimpleDateFormat("yyyy-M-d").parse("2023-7-15");
                } catch (Exception e) {
                    e.printStackTrace();
                    if (++count > 3) {
                        STOP.set(true);
                    }
                }
            }
        };

        new Thread(runnable).start();
        new Thread(runnable).start();
    }

}

即將共用的 SimpleDateFormat 實例調整為每次創建新的實例，該修復方案保證了正確性但每次方法調用需要創建 SimpleDateFormat 實例，並未複用 SimpleDateFormat 實例，存在 GC 損耗，所以並不推薦。

修復方案三：ThreadLocal（推薦）

如果日期格式化操作是應用裏的高頻操作，且需要優先保證性能，那麼建議每個線程複用 SimpleDateFormat 實例，此時可引入 ThreadLocal 類來解決該問題：

package com.jd.threadsafe;

import java.text.SimpleDateFormat;
import java.util.concurrent.atomic.AtomicBoolean;

/**
 * @Date: 2023/7/25 10:47
 * @Desc: SimpleDateFormat 線程安全修復方案：ThreadLocal
 * @Version: V1.0
 **/
public class SimpleDateFormatThreadLocalTest {
    private static final AtomicBoolean STOP = new AtomicBoolean();
    private static final ThreadLocal<SimpleDateFormat> SIMPLE_DATE_FORMAT_THREAD_LOCAL = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-M-d"));

    public static void main(String[] args) {
        Runnable runnable = () -> {
            int count = 0;
            while (!STOP.get()) {
                try {
                    SIMPLE_DATE_FORMAT_THREAD_LOCAL.get().parse("2023-7-15");
                } catch (Exception e) {
                    e.printStackTrace();
                    if (++count > 3) {
                        STOP.set(true);
                    }
                }
            }
        };

        new Thread(runnable).start();
        new Thread(runnable).start();
    }

}

執行上述代碼，不會再觀察到異常輸出，因為已為每個線程創建了獨立的 SimpleDateFormat 實例，即在線程維度複用了 SimpleDateFormat 實例，在線程池等池化場景下相比上方棧封閉的修復方案降低了 GC 損耗，同時也規避了線程安全問題。

以上使用 ThreadLocal 在線程維度複用非線程安全的實例可認為是一種通用的模式，可在 JDK 及不少開源項目中看到類似的模式實現，如在 JDK 最常見的 String 類中，對字符串進行編解碼所需要用到的 StringDecoder 及 StringEncoder 即使用了 ThreadLocal 來規避線程安全問題：

/**
 * Utility class for string encoding and decoding.
 */
class StringCoding {

    private StringCoding() { }

    /** The cached coders for each thread */
    private final static ThreadLocal<SoftReference<StringDecoder>> decoder =
        new ThreadLocal<>();
    private final static ThreadLocal<SoftReference<StringEncoder>> encoder =
        new ThreadLocal<>();

    // ...
}

參考：JDK8 - StringCoding

在 Dubbo 的 ThreadLocalKryoFactory 類中，在對非線程安全類 Kryo 的使用中，也使用了 ThreadLocal 類來規避線程安全問題：

package org.apache.dubbo.common.serialize.kryo.utils;

import com.esotericsoftware.kryo.Kryo;

public class ThreadLocalKryoFactory extends AbstractKryoFactory {

    private final ThreadLocal<Kryo> holder = new ThreadLocal<Kryo>() {
        @Override
        protected Kryo initialValue() {
            return create();
        }
    };

    @Override
    public void returnKryo(Kryo kryo) {
        // do nothing
    }

    @Override
    public Kryo getKryo() {
        return holder.get();
    }
}

參考：Dubbo - ThreadLocalKryoFactory

類似地，在 HikariCP 的 ConcurrentBag 類中，也用到了 ThreadLocal 類來規避線程安全問題，此處不再進一步展開。

修復方案四：FastDateFormat（推薦）

針對 SimpleDateFormat 類的線程安全問題，apache commons-lang 提供了 FastDateFormat 類。其部分 Java Doc 如下：

FastDateFormat is a fast and thread-safe version ofSimpleDateFormat. To obtain an instance of FastDateFormat, use one of the static factory methods:getInstance(String, TimeZone, Locale),getDateInstance(int, TimeZone, Locale),getTimeInstance(int, TimeZone, Locale), orgetDateTimeInstance(int, int, TimeZone, Locale) Since FastDateFormat is thread safe, you can use a static member instance: private static final FastDateFormat DATE_FORMATTER = FastDateFormat.getDateTimeInstance(FastDateFormat.LONG, FastDateFormat.SHORT); This class can be used as a direct replacement toSimpleDateFormatin most formatting and parsing situations. This class is especially useful in multi-threaded server environments.SimpleDateFormatis not thread-safe in any JDK version, nor will it be as Sun have closed the bug/RFE. All patterns are compatible with SimpleDateFormat (except time zones and some year patterns - see below).

該修復方案相對來説代碼改造最小，僅需在聲明靜態 SimpleDateFormat 實例代碼處將 SimpleDateFormat 實例替換為 FastDateFormat 實例，示例代碼如下：

package com.jd.threadsafe;

import org.apache.commons.lang3.time.FastDateFormat;

import java.util.concurrent.atomic.AtomicBoolean;

/**
 * @Date: 2023/7/6 20:05
 * @Desc: SimpleDateFormat 線程安全修復方案：FastDateFormat
 * @Version: V1.0
 **/
public class FastDateFormatTest {
    private static final AtomicBoolean STOP = new AtomicBoolean();
    private static final FastDateFormat FORMATTER = FastDateFormat.getInstance("yyyy-M-d");

    public static void main(String[] args) {
        Runnable runnable = () -> {
            int count = 0;
            while (!STOP.get()) {
                try {
                    FORMATTER.parse("2023-7-15");
                } catch (Exception e) {
                    e.printStackTrace();
                    if (++count > 3) {
                        STOP.set(true);
                    }
                }
            }
        };

        new Thread(runnable).start();
        new Thread(runnable).start();
    }

}

執行上述代碼，不會再觀察到異常輸出，因為 FastDateFormat 是線程安全的實現，支持多線程併發調用。

總結

無論使用哪種修復方案，都需要在修改後進行充分的測試，保證修復後不影響原有業務邏輯，如通過單元測試、流量回放等方式來保證本次修復的正確性。

思考

代碼裏使用 SimpleDateFormat 類的原因是因為日期使用了 Date 類，與 Date 相配套的 JDK 格式化類即 SimpleDateFormat 類，如果我們在處理日期時使用 JDK8 引入的 LocalDateTime 等不可變日期類，那麼格式化將使用配套的線程安全的 DateTimeFormatter 類，從根源上規避掉對非線程安全類 SimpleDateFormat 類的使用。

作者：京東物流 劉建設 張九龍 田爽

來源：京東雲開發者社區 自猿其説Tech 轉載請註明來源

線程池 , 線程安全 , JAVA , simpledateformat , 後端
user avatar zhengcaiyunqianduantuandui 頭像
1 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.