1 SimpleDateFormat 之坑

1.1 格式化

1.1.1 案例

• 初始化一个Calendar，设置日期2020年12月29日
  

• 日志
  

这是由于混淆SimpleDateFormat的各种格式化模式：

• 小写y是年
• 大写Y是week year，即所在的周属于哪一年

一年第一周的判断方式

从getFirstDayOfWeek()开始，完整的7天，并且包含那一年至少getMinimalDaysInFirstWeek()天。
该计算方式和区域相关，对zh_CN区域，2020年第一周条件：从周日开始的完整7天，2020年包含1天即 可。显然，2019年12月27日周日到2020年1月2日周六是2020年第一周，得出的week year就是2021年。

若把区域改为法国

Locale.setDefault(Locale.FRANCE);

  

 

  
1
 

则week yeay就还是2020年，因为一周的第一天从周一开始算，2020年的第一周是2019年12月28日周一开始，27日还是属于去年：

小结

无特殊需求，针对年份的日期格式化，应该一律使用 “y” 而非 “Y”。

线程安全问题

使用一个100线程的线程池，循环20次把时间格式化任务提交到线程池处理，每个任务中又循环10次解析2020-01-01 11:12:13这样一个时间表示：

• 运行程序后大量报错，即使没有报错的输出结果也不正常，比如2020年解析成57728年
  

SimpleDateFormat 用于定义解析和格式化日期时间的模式。看起来是一次性工作，应该复用，但它的解析和格式化操作都非线程安全。

分析源码

SimpleDateFormat继承自DateFormat，DateFormat有字段Calendar；

• SimpleDateFormat#parse调用CalendarBuilder#establish构建Calendar
  

establish方法内部先清空Calendar再构建Calendar，整个操作没有加锁。

显然，若使用线程池调用parse，即多线程并发操作一个Calendar，就可能会产生一个线程还没来得及处理Calendar就被另一个线程清空。format方法同理，不再赘述。因此只能在同一个线程复用SimpleDateFormat，

解决方案

通过ThreadLocal来存放SimpleDateFormat：

• 日志输出全部正确

1.2 当需要解析的字符串和格式不匹配，SimpleDateFormat还是能得到结果

案例

使用yyyyMM解析20160901字符串：

• 居然输出2112年，这是因为把 1111当成月份

对于SimpleDateFormat的这些坑，使用Java 8中的DateTimeFormatter即可避免。

2 Java 8中的DateTimeFormatter

2.1 格式化字符串

首先，使用DateTimeFormatterBuilder定义格式化字符串，无需死记大写Y还是小写y，大写M还是小写m：

2.2 线程安全

可定义为static使用

2.3 待解析字符串和格式不匹配时就报错

• 日志

2020/11/11 11:11:11.789
Exception in thread "main" java.time.format.DateTimeParseException: Text '20201111' could not be parsed at index 0
	at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
	at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1777)
	at org.javaedge.time.commonmistakes.datetime.dateformat.CommonMistakesApplication.better(CommonMistakesApplication.java:96)
	at org.javaedge.time.commonmistakes.datetime.dateformat.CommonMistakesApplication.main(CommonMistakesApplication.java:47)

  

 

  
1
  
2
  
3
  
4
  
5
  
6
 

3 Java8计算日期时间

• 有人喜欢使用时间戳进行计算，比如希望得到当前时间后30天:把new Date().getTime得到的时间戳加30天对应毫秒数
  
• 得到的日期居然比当前日期还要早，根本不是后30天
  

因为int发生了溢出！。

• 应将30改为30L，使其为long：
  

• 正确输出
  

• Java 8前代码，建议使用Calendar：
  

• 使用Java 8的日期时间类型，可以直接进行各种计算，更加简洁和方便：
  

对日期时间做计算操作，日期时间API会比Calendar功能强大很多。

3.1 minus/plus直接对日期加减

3.2 with快捷时间调节

• TemporalAdjusters.firstDayOfMonth得到当前月的第一天
• TemporalAdjusters.firstDayOfYear()得到当前年的第一天
• TemporalAdjusters.previous(DayOfWeek.SATURDAY)得到上一个周六
• TemporalAdjusters.lastInMonth(DayOfWeek.FRIDAY)得到本月最后一个周五

3.3 使用lambda自定义的时间调整

• 为当前时间增加100天以内的随机天数：
  

判断日期是否符合某个条件

query查询是否匹配条件

使用Java 8操作和计算日期时间虽然方便，但计算两个日期差时可能会踩坑：Java 8中有一个专门的类Period定义了日期间隔，通过Period.between得到了两个LocalDate的差，返回的是两个日期差几年零几月零几天。
如果希望得知两个日期之间差几天，直接调用Period的getDays()方法得到的只是最后的“零几天”，而不是算总的间隔天数。

比如，计算2020年12月12日和2020年10月1日的日期间隔，很明显日期差是2个月零11天，但获取getDays方法得到的结果只是11天，而不是72天：

可使用ChronoUnit.DAYS.between解决这个问题：

4 总结

也许你认为java.util.Date类似于新API中的LocalDateTime。其实不是，虽然它们都没时区概念

• java.util.Date类是因为使用UTC表示，所以没有时区概念，其本质是时间戳
• LocalDateTime，严格上可以认为是一个日期时间的表示，而不是一个时间点

因此，在把Date转换为LocalDateTime的时候，需要通过Date的toInstant方法得到一个UTC时间戳进行转换，并需要提供当前的时区，这样才能把UTC时间转换为本地日期时间（的表示）。反过来，把LocalDateTime的时间表示转换为Date时，也需要提供时区，用于指定是哪个时区的时间表示，也就是先通过atZone方法把LocalDateTime转换为ZonedDateTime，然后才能获得UTC时间戳：

Date in = new Date();
LocalDateTime ldt = LocalDateTime.ofInstant(in.toInstant(), ZoneId.systemDefault());
Date out = Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant());

  

 

  
1
  
2
  
3
 

有人说新API很麻烦，还需要考虑时区，真麻烦。但并非因为API强行设计繁琐，而是UTC时间要变为当地时间，必须考虑时区！

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/110003369