java.lang.NumberFormatException: multiple points异常的解决

结论

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原生的。

总结

写一些工具类、处理类，一定要考虑线程安全的问题。其次再是高并发下的性能问题。