关于SimpleDateFormat时间格式化线程安全问题
轉載自??關于SimpleDateFormat時間格式化線程安全問題
昨天推送的文章《關于創建和銷毀對象》一文中，2.1重復利用對象這一小節所舉的SimpleDateFormat格式化時間的例子是不合適的，因為多線程場景下，SimpleDateFormat存在線程安全問題。在此，特別感謝@利群、@Simon、@Aaron等幾位同學認真指出。
想必大家對SimpleDateFormat并不陌生。SimpleDateFormat 是 Java 中一個非常常用的類，該類用來對日期字符串進行解析和格式化輸出，但如果使用不小心會導致非常微妙和難以調試的問題，因為 DateFormat 和 SimpleDateFormat 類不都是線程安全的，在多線程環境下調用 format() 和 parse() 方法應該使用同步代碼來避免問題。下面我們通過一個具體的場景來一步步的深入學習和理解SimpleDateFormat類。
一.引子
首先，我們都知道在程序中我們應當盡量少的創建SimpleDateFormat 實例，因為創建這么一個實例需要耗費很大的代價。在一個讀取數據庫數據導出到excel文件的例子當中，每次處理一個時間信息的時候，就需要創建一個SimpleDateFormat實例對象，然后再丟棄這個對象。大量的對象就這樣被創建出來，占用大量的內存和 jvm空間。代碼如下：
public class DateUtil {public static String formatDate(Date date){SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");return sdf.format(date);}public static Date parse(String strDate) throws ParseException{SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");return sdf.parse(strDate);}}你也許會說，OK，那我就創建一個靜態的simpleDateFormat實例，然后放到一個DateUtil類（如下）中，在使用時直接使用這個實例進行操作，這樣問題就解決了。改進后的代碼如下：
public class DateUtil {private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");public static String formatDate(Date date){return sdf.format(date);}public static Date parse(String strDate) throws ParseException {return sdf.parse(strDate);} }當然，這個方法的確很不錯，在大部分的時間里面都會工作得很好。但當你在生產環境中使用一段時間之后，你就會發現這么一個事實：它不是線程安全的。在正常的測試情況之下，都沒有問題，但一旦在生產環境中一定負載情況下時，這個問題就出來了。他會出現各種不同的情況，比如轉化的時間不正確，比如報錯，比如線程被掛死等等。我們看下面的測試用例，拿事實說話：
public class DateUtilTest {public static class SimpleDateFormatThreadSafeTest extends Thread {@Overridepublic void run() {while (true) {try {this.join(2000);} catch (InterruptedException e1) {e1.printStackTrace();}try {System.out.println(this.getName() + ":" + DateUtil.parse("2016-09-13 22:00:00"));} catch (ParseException e) {e.printStackTrace();}}}}public static void main(String[] args) {for(int i = 0; i < 3; i++){new SimpleDateFormatThreadSafeTest().start();}} }執行輸出如下：
Exception in thread "Thread-2" Exception in thread "Thread-0" java.lang.NumberFormatException: multiple points
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1110)
at java.lang.Double.parseDouble(Double.java:540)
at java.text.DigitList.getDouble(DigitList.java:168)
at java.text.DecimalFormat.parse(DecimalFormat.java:1321)
at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1793)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1455)
at java.text.DateFormat.parse(DateFormat.java:355)
at com.shengfei.test.DateFormat.DateUtil.parse(DateUtil.java:31)
at com.shengfei.test.DateFormat.DateUtilTest$SimpleDateFormatThreadSafeTest.run(DateUtilTest.java:32)
java.lang.NumberFormatException: multiple points
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1110)
at java.lang.Double.parseDouble(Double.java:540)
at java.text.DigitList.getDouble(DigitList.java:168)
at java.text.DecimalFormat.parse(DecimalFormat.java:1321)
at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1793)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1455)
at java.text.DateFormat.parse(DateFormat.java:355)
at com.shengfei.test.DateFormat.DateUtil.parse(DateUtil.java:31)
at com.shengfei.test.DateFormat.DateUtilTest$SimpleDateFormatThreadSafeTest.run(DateUtilTest.java:32)
Thread-1:Mon Sep 13 22:00:00 CST 2202
Thread-1:Tue Sep 13 22:00:00 CST 2016
Thread-1:Tue Sep 13 22:00:00 CST 2016
Thread-1:Tue Sep 13 22:00:00 CST 2016
說明：Thread-2和Thread-0報java.lang.NumberFormatException: multiple points錯誤，直接掛死，沒起來；Thread-1雖然沒有掛死，但輸出的時間是有錯誤的，比如我們輸入的時間是：2016-09-13 22:00:00 ，當會輸出：Mon Sep 13 22:00:00 CST 2202 這樣的靈異事件。
二.原因
我們都知道，相比于共享一個變量的開銷要比每次創建一個新變量要小很多。上面的優化過的靜態的SimpleDateFormat版，之所在并發情況下回出現各種靈異錯誤，是因為SimpleDateFormat和DateFormat類不是線程安全的。我們之所以忽視線程安全的問題，是因為從SimpleDateFormat和DateFormat類提供給我們的接口上來看，實在讓人看不出它與線程安全有何相干。只是在JDK文檔的最下面有如下說明：
SynchronizationDate 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.翻譯一下就是：SimpleDateFormat中的日期格式不是同步的。建議為每個線程創建獨立的格式實例。如果多個線程同時訪問一個格式，則它必須保持外部同步。
下面我們通過看JDK源碼來看看為什么SimpleDateFormat和DateFormat類不是線程安全的真正原因。
SimpleDateFormat繼承了DateFormat,在DateFormat中定義了一個protected屬性的 Calendar類的對象：calendar。只是因為Calendar類的概念復雜，牽扯到時區與本地化等等，Jdk的實現中使用了成員變量來傳遞參數，這就造成在多線程的時候會出現錯誤。
在format方法里，有這樣一段代碼：
private StringBuffer format(Date date, StringBuffer toAppendTo,FieldDelegate delegate) {// Convert input date to time field listcalendar.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.setTime(date)這條語句改變了calendar，稍后，calendar還會用到（在subFormat方法里），而這就是引發問題的根源。想象一下，在一個多線程環境下，有兩個線程持有了同一個SimpleDateFormat的實例，分別調用format方法：
線程1調用format方法，改變了calendar這個字段。
中斷來了。
線程2開始執行，它也改變了calendar。
又中斷了。
線程1回來了，此時，calendar已然不是它所設的值，而是走上了線程2設計的道路。如果多個線程同時爭搶calendar對象，則會出現各種問題，時間不對，線程掛死等等。
分析一下format的實現，我們不難發現，用到成員變量calendar，唯一的好處，就是在調用subFormat時，少了一個參數，卻帶來了這許多的問題。其實，只要在這里用一個局部變量，一路傳遞下去，所有問題都將迎刃而解。
這個問題背后隱藏著一個更為重要的問題--無狀態：無狀態方法的好處之一，就是它在各種環境下，都可以安全的調用。衡量一個方法是否是有狀態的，就看它是否改動了其它的東西，比如全局變量，比如實例的字段。format方法在運行過程中改動了SimpleDateFormat的calendar字段，所以，它是有狀態的。
這也同時提醒我們在開發和設計系統的時候注意下一下三點:
1.自己寫公用類的時候，要對多線程調用情況下的后果在注釋里進行明確說明；
2.對線程環境下，對每一個共享的可變變量都要注意其線程安全性；
3.我們的類和方法在做設計的時候，要盡量設計成無狀態的。
三.解決辦法
1.需要的時候創建新實例
public class DateUtil {public static String formatDate(Date date){SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");return sdf.format(date);}public static Date parse(String strDate) throws ParseException {SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");return sdf.parse(strDate);} }說明：在需要用到SimpleDateFormat?的地方新建一個實例，不管什么時候，將有線程安全問題的對象由共享變為局部私有都能避免多線程問題，不過也加重了創建對象的負擔。在一般情況下，這樣其實對性能影響比不是很明顯的。
2.使用同步：同步SimpleDateFormat對象
public class DateUtil {private static SimpleDateFormat sdf2 = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");public static String formatDate2(Date date){synchronized(sdf2){return sdf2.format(date);}}public static Date parse2(String strDate) throws ParseException{synchronized(sdf2){return sdf2.parse(strDate);}} }說明：當線程較多時，當一個線程調用該方法時，其他想要調用此方法的線程就要block，多線程并發量大的時候會對性能有一定的影響。
3.使用ThreadLocal
public class ConcurrentDateUtil {private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {@Overrideprotected 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);} }另外一種寫法：
public class ThreadLocalDateUtil {private static final String date_format = "yyyy-MM-dd HH:mm:ss";private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>();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){return getDateFormat().format(date);}public static Date parse(String strDate) throws ParseException {return getDateFormat().parse(strDate);}}說明：使用ThreadLocal, 也是將共享變量變為獨享，線程獨享肯定能比方法獨享在并發環境中能減少不少創建對象的開銷。如果對性能要求比較高的情況下，一般推薦使用這種方法。
4.拋棄JDK，使用其他類庫中的時間格式化類：
1）使用Apache commons 里的FastDateFormat，宣稱是既快又線程安全的SimpleDateFormat, 可惜它只能對日期進行format, 不能對日期串進行解析。
2）使用Joda-Time類庫來處理時間相關問題。
做一個簡單的壓力測試，方法1最慢，方法3最快，但是就算是最慢的方法一性能也不差，一般系統方法1和方法2就可以滿足，所以說在這個點很難成為你系統的瓶頸所在。從簡單的角度來說，建議使用方法1或者方法2，如果在必要的時候，追求那么一點性能提升的話，可以考慮用方法3，用ThreadLocal做緩存。
Joda-Time類庫對時間處理方式比較完美，建議使用。
參考資料：
1.http://dreamhead.blogbus.com/logs/215637834.html
2.http://www.blogjava.net/killme2008/archive/2011/07/10/354062.html
總結
以上是生活随笔為你收集整理的关于SimpleDateFormat时间格式化线程安全问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何挑选一款合适的手机
- 下一篇： Jdk1.8 JUC源码增量解析(2)-