SimpleDateFormat類的線程安全問題和解決方案（問題篇）

首先問下大家：你使用的SimpledateFormat類還安全嗎？為什么說SimpledateFormat類不是線程安全的？帶著問題從本文中尋求答案。

提起SimpleDateFormat類，想必做過Java開發的童鞋都不會感到陌生。沒錯，它就是Java中提供的日期時間的轉化類。這里，為什么說SimpleDateFormat類有線程安全問題呢？有些小伙伴可能會提出疑問：我們生產環境上一直在使用SimpleDateFormat類來解析和格式化日期和時間類型的數據，一直都沒有問題啊！我的回答是：沒錯，那是因為你們的系統達不到SimpleDateFormat類出現問題的并發量，也就是說你們的系統沒啥負載！

接下來，我們就一起看下在高并發下SimpleDateFormat類為何會出現安全問題，以及如何解決SimpleDateFormat類的安全問題。

重現SimpleDateFormat類的線程安全問題

為了重現SimpleDateFormat類的線程安全問題，一種比較簡單的方式就是使用線程池結合Java并發包中的CountDownLatch類和Semaphore類來重現線程安全問題。

有關CountDownLatch類和Semaphore類的具體用法和底層原理與源碼解析在【高并發專題】后文會深度分析。這里，大家只需要知道CountDownLatch類可以使一個線程等待其他線程各自執行完畢后再執行。而Semaphore類可以理解為一個計數信號量，必須由獲取它的線程釋放，經常用來限制訪問某些資源的線程數量，例如限流等。

好了，先來看下重現SimpleDateFormat類的線程安全問題的代碼，如下所示。

package io.binghe.concurrent.lab06; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Semaphore; /** * @author binghe * @version 1.0.0 * @description 測試SimpleDateFormat的線程不安全問題 */ public class SimpleDateFormatTest01 { //執行總次數 private static final int EXECUTE_COUNT = 1000; //同時運行的線程數量 private static final int THREAD_COUNT = 20; //SimpleDateFormat對象 private static SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd"); public static void main(String[] args) throws InterruptedException { final Semaphore semaphore = new Semaphore(THREAD_COUNT); final CountDownLatch countDownLatch = new CountDownLatch(EXECUTE_COUNT); ExecutorService executorService = Executors.newCachedThreadPool(); for (int i = 0; i < EXECUTE_COUNT; i++){ executorService.execute(() -> { try { semaphore.acquire(); try { simpleDateFormat.parse("2020-01-01"); } catch (ParseException e) { System.out.println("線程：" + Thread.currentThread().getName() + " 格式化日期失敗"); e.printStackTrace(); System.exit(1); }catch (NumberFormatException e){ System.out.println("線程：" + Thread.currentThread().getName() + " 格式化日期失敗"); e.printStackTrace(); System.exit(1); } semaphore.release(); } catch (InterruptedException e) { System.out.println("信號量發生錯誤"); e.printStackTrace(); System.exit(1); } countDownLatch.countDown(); }); } countDownLatch.await(); executorService.shutdown(); System.out.println("所有線程格式化日期成功"); } }

可以看到，在SimpleDateFormatTest01類中，首先定義了兩個常量，一個是程序執行的總次數，一個是同時運行的線程數量。程序中結合線程池和CountDownLatch類與Semaphore類來模擬高并發的業務場景。其中，有關日期轉化的代碼只有如下一行。

simpleDateFormat.parse("2020-01-01");

當程序捕獲到異常時，打印相關的信息，并退出整個程序的運行。當程序正確運行后，會打印“所有線程格式化日期成功”。

運行程序輸出的結果信息如下所示。

Exception in thread "pool-1-thread-4" Exception in thread "pool-1-thread-1" Exception in thread "pool-1-thread-2" 線程：pool-1-thread-7 格式化日期失敗 線程：pool-1-thread-9 格式化日期失敗 線程：pool-1-thread-10 格式化日期失敗 Exception in thread "pool-1-thread-3" Exception in thread "pool-1-thread-5" Exception in thread "pool-1-thread-6" 線程：pool-1-thread-15 格式化日期失敗 線程：pool-1-thread-21 格式化日期失敗 Exception in thread "pool-1-thread-23" 線程：pool-1-thread-16 格式化日期失敗 線程：pool-1-thread-11 格式化日期失敗 java.lang.ArrayIndexOutOfBoundsException 線程：pool-1-thread-27 格式化日期失敗 at java.lang.System.arraycopy(Native Method) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:597) at java.lang.StringBuffer.append(StringBuffer.java:367) at java.text.DigitList.getLong(DigitList.java:191)線程：pool-1-thread-25 格式化日期失敗 at java.text.DecimalFormat.parse(DecimalFormat.java:2084) at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) 線程：pool-1-thread-14 格式化日期失敗 at java.text.DateFormat.parse(DateFormat.java:364) at io.binghe.concurrent.lab06.SimpleDateFormatTest01.lambda$main$0(SimpleDateFormatTest01.java:47) 線程：pool-1-thread-13 格式化日期失敗 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 線程：pool-1-thread-20 格式化日期失敗 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:2084) 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 io.binghe.concurrent.lab06.SimpleDateFormatTest01.lambda$main$0(SimpleDateFormatTest01.java:47) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 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:2084) at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) at java.text.DateFormat.parse(DateFormat.java:364) Process finished with exit code 1

說明，在高并發下使用SimpleDateFormat類格式化日期時拋出了異常，SimpleDateFormat類不是線程安全的！！！

接下來，我們就看下，SimpleDateFormat類為何不是線程安全的。

SimpleDateFormat類為何不是線程安全的？

那么，接下來，我們就一起來看看真正引起SimpleDateFormat類線程不安全的根本原因。

通過查看SimpleDateFormat類的源碼，我們得知：SimpleDateFormat是繼承自DateFormat類，DateFormat類中維護了一個全局的Calendar變量，如下所示。

/** * The {@link Calendar} instance used for calculating the date-time fields * and the instant of time. This field is used for both formatting and * parsing. * *

Subclasses should initialize this field to a {@link Calendar} * appropriate for the {@link Locale} associated with this * DateFormat. * @serial */ protected Calendar calendar;

從注釋可以看出，這個Calendar對象既用于格式化也用于解析日期時間。接下來，我們再查看parse()方法接近最后的部分。

@Override public Date parse(String text, ParsePosition pos){ ################此處省略N行代碼################## Date parsedDate; try { parsedDate = calb.establish(calendar).getTime(); // If the year value is ambiguous, // then the two-digit year == the default start year if (ambiguousYear[0]) { if (parsedDate.before(defaultCenturyStart)) { parsedDate = calb.addYear(100).establish(calendar).getTime(); } } } // An IllegalArgumentException will be thrown by Calendar.getTime() // if any fields are out of range, e.g., MONTH == 17. catch (IllegalArgumentException e) { pos.errorIndex = start; pos.index = oldStart; return null; } return parsedDate; }

可見，最后的返回值是通過調用CalendarBuilder.establish()方法獲得的，而這個方法的參數正好就是前面的Calendar對象。

接下來，我們再來看看CalendarBuilder.establish()方法，如下所示。

Calendar establish(Calendar cal) { boolean weekDate = isSet(WEEK_YEAR) && field[WEEK_YEAR] > field[YEAR]; if (weekDate && !cal.isWeekDateSupported()) { // Use YEAR instead if (!isSet(YEAR)) { set(YEAR, field[MAX_FIELD + WEEK_YEAR]); } weekDate = false; } cal.clear(); // Set the fields from the min stamp to the max stamp so that // the field resolution works in the Calendar. for (int stamp = MINIMUM_USER_STAMP; stamp < nextStamp; stamp++) { for (int index = 0; index <= maxFieldIndex; index++) { if (field[index] == stamp) { cal.set(index, field[MAX_FIELD + index]); break; } } } if (weekDate) { int weekOfYear = isSet(WEEK_OF_YEAR) ? field[MAX_FIELD + WEEK_OF_YEAR] : 1; int dayOfWeek = isSet(DAY_OF_WEEK) ? field[MAX_FIELD + DAY_OF_WEEK] : cal.getFirstDayOfWeek(); if (!isValidDayOfWeek(dayOfWeek) && cal.isLenient()) { if (dayOfWeek >= 8) { dayOfWeek--; weekOfYear += dayOfWeek / 7; dayOfWeek = (dayOfWeek % 7) + 1; } else { while (dayOfWeek <= 0) { dayOfWeek += 7; weekOfYear--; } } dayOfWeek = toCalendarDayOfWeek(dayOfWeek); } cal.setWeekDate(field[MAX_FIELD + WEEK_YEAR], weekOfYear, dayOfWeek); } return cal; }

在CalendarBuilder.establish()方法中先后調用了cal.clear()與cal.set()，也就是先清除cal對象中設置的值，再重新設置新的值。由于Calendar內部并沒有線程安全機制，并且這兩個操作也都不是原子性的，所以當多個線程同時操作一個SimpleDateFormat時就會引起cal的值混亂。類似地， format()方法也存在同樣的問題。

因此， SimpleDateFormat類不是線程安全的根本原因是：DateFormat類中的Calendar對象被多線程共享，而Calendar對象本身不支持線程安全。

那么，得知了SimpleDateFormat類不是線程安全的，以及造成SimpleDateFormat類不是線程安全的原因，那么如何解決這個問題呢？接下來，我們就一起探討下如何解決SimpleDateFormat類在高并發場景下的線程安全問題。

好了，目前我們把問題分析完了，后面我們上解決方案。

Java JDK 任務調度 多線程

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。