慎用java.text.SimpleDateFormat类

         最近在项目中遇到一个奇怪的现象，调用java服务的时候，有极低的概率出现如下异常信息：

java.lang.NumberFormatException: For input string: ""
 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Long.parseLong(Long.java:424)
 at java.lang.Long.parseLong(Long.java:461)
 at java.text.DigitList.getLong(DigitList.java:177)
 at java.text.DecimalFormat.parse(DecimalFormat.java:1298)
 at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1542)
 at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1264)
 at java.text.DateFormat.parse(DateFormat.java:335)
 at com.ydtf.ipcc.itsm.util.DateUtil.parse(DateUtil.java:24)
......

        大部分时间都是正常的，不会出现异常，后来查阅了一些关于SimpleDateFormat的资料，发现这个类不是线程安全的，当时由于项目里许多地方都用到了时间格式化，而且格式都很相似，所以我在代码里把SimpleDateFormat定义成全局静态常量了，所以在多个线程同时访问该SimpleDateFormat对象时会出现异常。后来我把SimpleDateFormat定义到单独的私有方法里就没有问题了，但项目里有很多需要格式化时间的地方，后来放弃了使用SimpleDateFormat，改为使用apache的commons-lang包的DateUtils和DateFormatUtils类，这两个类的方法是线程安全的。

       值得一提的是DateUtils类时间处理有很多特殊和方便的地方，比如"20111332"2011年13月32号这个不符合规格的年月日格式的时间如果执行parse方法，会自动计算成20120201，即当月份大于12的时候，会将月份减去12得到一个新的月份，然后把年加1，如果天超过了当月的最大天数，也会采取类似的进位转换，这个为时间处理提供了极大的便利和灵活性，比SimpleDateFormat更好用。

       通过这个事件，也让我意识到，当我们的程序在大多数情况下正常运行，如果偶尔出现一些莫名其妙的错误时，就需要考虑是否使用了一些线程不安全的全局静态变量或者常量。