为什么不建议使用Date，而是使用新的时间和日期API？

Java 8：新的时间和日期API

在Java 8之前，所有关于时间和日期的API都存在各种使用方面的缺陷，因此建议使用新的时间和日期API，分别从旧的时间和日期的API的缺点以及解决方法、Java 8 新的时间和日期API进行讲解。

旧的时间和日期的API的缺陷

Java 的 java.util.Date 和 java.util.Calendar 类易用性差，不支持时区，而且都不是线程安全的。

Date如果不格式化，打印出的日期可读性差。

可以使用 SimpleDateFormat 对时间进行格式化，但 SimpleDateFormat 是线程不安全的，SimpleDateFormat 的 format 方法源码如下：

其中 calendar 是共享变量，并且这个共享变量没有做线程安全控制。当多个线程同时使用相同的 SimpleDateFormat 对象【如用static修饰的 SimpleDateFormat 】调用format方法时，多个线程会同时调用 calendar.setTime 方法，可能一个线程刚设置好 time 值另外的一个线程马上把设置的 time 值给修改了导致返回的格式化时间可能是错误的。

在多并发情况下使用 SimpleDateFormat 需注意。

SimpleDateFormat 除了 format 是线程不安全以外，parse 方法也是线程不安全的。parse 方法实际调用 alb.establish(calendar).getTime() 方法来解析，alb.establish(calendar) 方法里主要完成了

重置日期对象cal的属性值

使用calb中中属性设置cal

返回设置好的cal对象

但是这三步不是原子操作，导致解析出来的时间可以是错误的。

Date对时间处理比较麻烦，比如想获取某年、某月、某星期，以及 n 天以后的时间，如果用Date来处理的话真是太难了，并且 Date 类的 getYear、getMonth 这些方法都被弃用了。

多线程并发如何保证线程安全

避免线程之间共享一个 SimpleDateFormat 对象，每个线程使用时都创建一次 SimpleDateFormat 对象 => 创建和销毁对象的开销大

对使用 format 和 parse 方法的地方进行加锁 => 线程阻塞性能差

使用 ThreadLocal 保证每个线程最多只创建一次 SimpleDateFormat 对象 => 较好的方法

Java 8 新的时间和日期API

Java 8的日期和时间类包含 LocalDate、LocalTime、Instant、Duration 以及 Period，这些类都包含在 java.time 包中，Java 8 新的时间API的使用方式，包括创建、格式化、解析、计算、修改，下面我们看下如何去使用。

LocalDate 只会获取年月日

LocalTime 只会获取时分秒

LocalDateTime 获取年月日时分秒，相当于 LocalDate + LocalTime

Instant 获取秒数，用于表示一个时间戳（精确到纳秒）

如果只是为了获取秒数或者毫秒数，可以使用 System.currentTimeMillis()。

Duration 表示一个时间段

修改 LocalDate、LocalTime、LocalDateTime、Instant。

LocalDate、LocalTime、LocalDateTime、Instant 为不可变对象，修改这些对象对象会返回一个副本。

增加、减少年数、月数、天数等，以LocalDateTime为例:

TemporalAdjusters 包含许多静态方法，可以直接调用，以下列举一些：

格式化时间

解析时间

总结

和 SimpleDateFormat 相比，DateTimeFormatter 是线程安全的。

Instant 的精确度更高，可以精确到纳秒级。

Duration 可以便捷得到时间段内的天数、小时数等。

LocalDateTime 能够快速地获取年、月、日、下一月等。

TemporalAdjusters 类中包含许多常用的静态方法，避免自己编写工具类。