SimpleDateFormat线程安全问题

一、背景

项目上线前QA进行压测，出现SimpleDateFormat线程安全问题，异常如下

Exception in thread "Thread-1" java.lang.NumberFormatException: multiple points
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1082)
    at java.lang.Double.parseDouble(Double.java:510)
    at java.text.DigitList.getDouble(DigitList.java:151)
    at java.text.DecimalFormat.parse(DecimalFormat.java:1302)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1589)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1311)
    at java.text.DateFormat.parse(DateFormat.java:335)
    at com.peidasoft.orm.dateformat.DateNoStaticUtil.parse(DateNoStaticUtil.java:17)
    at com.peidasoft.orm.dateformat.DateUtilTest$TestSimpleDateFormatThreadSafe.run(DateUtilTest.java:20)
Exception in thread "Thread-0" java.lang.NumberFormatException: multiple points
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1082)
    at java.lang.Double.parseDouble(Double.java:510)
    at java.text.DigitList.getDouble(DigitList.java:151)
    at java.text.DecimalFormat.parse(DecimalFormat.java:1302)
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1589)
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1311)
    at java.text.DateFormat.parse(DateFormat.java:335)
    at com.peidasoft.orm.dateformat.DateNoStaticUtil.parse(DateNoStaticUtil.java:17)
    at com.peidasoft.orm.dateformat.DateUtilTest$TestSimpleDateFormatThreadSafe.run(DateUtilTest.java:20)

二、问题分析

SimpleDateFormat继承自DateFormat，而在最常用的parse()和format()方法的内部，会调用父类DateFormat内部的calendar，

如parse()方法内部有一段这样的代码

	start = subParse(text, start, tag, count, obeyCount,
                 ambiguousYear, pos,
                 useFollowingMinusSignAsDelimiter, calb);

其内部实现比较复杂，但很明显它调用了父类DateFormat内部的calendar对象，那就大概理解到问题了，当我们的SimpleDateFormat对象声明为static的时候，在多线程并发的时候就会共享这个format对象，也就共用了calendar这个对象。

	public static final SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");

再继续下面代码中调用了CalendarBuilder类的establish的方法

	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();
                }
            }

可以看到其内部调用了坑爹的clear()重置了一下

	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;
                }
            }
        }

于是问题出现了，有的线程clear()，有的线程getTime()，这不是搞事情嘛！

三、解决方案

其实也算不上什么解决方案了，既然问题定位到了，那解决办法自然简单，每个线程使用的对象隔离开就搞定了。

1、每个线程创建一个新的SimpleDateFormat对象，也是最简单的，但这样每次都要new对象，让人感觉很不爽

 

    /**
     * 字符串转化为Date
     * @param date
     * @return
     * @throws ParseException
     */
    public static Date parse(String date) throws ParseException {
        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");
        return format.parse(date);
    }

2、使用ThreadLocal为每个线程创建一个副本使其隔离，简单的来个饿汉方式搞定吧(毕竟我不是处女座)

    /**
     * API的格式
     */
    private static ThreadLocal<SimpleDateFormat> yyyymmdd = new ThreadLocal<SimpleDateFormat>(){
        @Override
        protected SimpleDateFormat initialValue() {
            return new SimpleDateFormat("yyyy-MM-dd");
        }
    };

四、总结

自己用的工具，一定要清楚其原理，否则一失...可就万无啊