结论
SimpleDateFormat
是非线程安全的。
前言
2020年第一篇博客哈。最近在项目中,遇到随机性的mybatis查询问题。每次问题都是出在相同的字段上。并且类型为日期。就是莫名其妙的报java.lang.NumberFormatException
异常。
经过
bug发生的很其妙,前端大概是这样,最开始在页面中就请求一个list数据,当时没啥问题,但是在之后,前端加了个同时获取下拉框数据的请求。问题就变得很奇怪了(下拉框和列表都有日期字段)。列表中的日期会随机的抛出异常。当时很莫名其妙,但是着急就没去管它。过了一段时间,我频繁刷新页面这个异常的发生概率增大。如此频繁的发生,就不得不解决了。
定位问题
问题就是很奇怪,因为我自定义了TypeHandler对日期进行处理。偶尔在解析是会提示日期字段的值为空字符串。但是数据库是确确实实有的。直觉告诉我问题的根源应该是多线程造成的。所以我就疯狂的刷新前端页面,(这种方式相比用jmetor是有点low哈,但胜在快捷)。错误异常频繁发生了。那就可以肯定就是多线程造成的了。但是哪里会有线程问题啊?我就看了一下自定义TypeHandler的代码
private final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
private final SimpleDateFormat sdfDate = new SimpleDateFormat("yyyy-MM-dd");
看到这里我心里一万句。。。,最近在看JAVA并发编程,里面已经很明确的说了SimpleDateFormat
是非线程安全的。我居然还敢这样用,佛曰我不入地狱谁入地狱。都这样写了,我不遭谁遭。我不能坑队友,是吧。
当时在设计TypeHandle的时候没有考虑线程安全的问题。
解决
问题的根源找到了,解决就好办了。把日期解析换成线程安全就行了。
1.肯定有人想最快的方式就是把SimpleDateFormat
换成局部变量,我这能说千万别这么干!这是一时舒服,后面大坑。TypeHandler的处理,在之后必然是高并发的。SimpleDateFormat
这货的初始化带来的性能损坏自行考究。
2.使用ThradLocal封装SimpleDateFormat 。本质是每个线程初始化一个属于它的SimpleDateFormat对象。
3.使用joda
库处理日期(推荐)。如果你的项目没有joda-time库,快添加吧。
import org.joda.time.DateTime;
import org.joda.time.format.DateTimeFormat;
import org.joda.time.format.DateTimeFormatter;
private static final DateTimeFormatter dateTimeFormatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss");
private static final DateTimeFormatter dateFormatter = DateTimeFormat.forPattern("yyyy-MM-dd");
//使用DateTime解析和格式化。
//格式化
//dateTime.toString(dateFormatter)
//解析
//DateTime.parse(date,dateTimeFormatter).toDate()
注意这里的DateTimeFormatter是joda-time的不是java原生的。
总结
写一些工具类、处理类,一定要考虑线程安全的问题。其次再是高并发下的性能问题。