什么？你项目还在用Date表示时间！

为啥会有这篇文章

最近接手了一个别人的老项目，拿到代码，导入IDEA的那一瞬间，我哭出了声 . . .

我瞥了一眼代码，就知道这次肯定遇到了屎山！因为我看到了这种代码：

我擦，这都什么年代了，怎么还在用 Date来处理和表示时间！

完了完了 . . .

为啥Date遭嫌弃了

别的先不说，我们先来看几个关于 Date用法的例子，这玩意真的好用吗？

一、我想新建一个表示"此刻"的日期，打印出来：

第一行：这打印结果你第一眼能看明白？可读性忒差了

第二行：今天是2019年，你给我返回个119，没法读

第三行：现在是12月份，你给我返回个11，这也没法读

二、假如我再想构造一个指定年、月、日的时间，我尝试这么去做：

你看到啥了，连构造函数都被弃用了！

你可以再仔细瞅瞅，其实 Date里的很多方法现在都已经弃用了！

都这样了，你项目还敢用这个吗？你醒醒吧！

LocalDateTime不香吗？

自 Java8开始， JDK中其实就增加了一系列表示日期和时间的新类，最典型的就是 LocalDateTime。直言不讳，这玩意的出现就是为了干掉之前 JDK版本中的 Date老哥！

同样，我们也先来感受一下用法！

一、获取当前此刻的时间

干得漂亮！

二、构造一个指定年、月、日的时间：

比如，想构造：2019年10月12月12日9时21分32秒

没毛病！

三、修改日期

四、格式化日期

我无话可说，漂亮

五、时间反解析

给你一个陌生的字符串，你可以按照你需要的格式把时间给反解出来

tql！

零零散散举了这么些例子，我想 LocalDateTime怎么地也不输 Date吧！

线程安全性问题！

其实上面讲来讲去只讲了两者在用法上的差别，这其实倒还好，并不致命，可是接下来要讨论的线程安全性问题才是致命的！

其实以前我们惯用的 Date时间类是可变类，这就意味着在多线程环境下对共享 Date变量进行操作时，必须由程序员自己来保证线程安全！否则极有可能翻车。

而自 Java8开始推出的 LocalDateTime却是线程安全的，开发人员不用再考虑并发问题，这点我们从 LocalDateTime的官方源码中即可看出：

不说别的，就光一句：

Thisclassis immutable and thread-safe. （不可变、线程安全！）

你就没有任何理由不用 LocalDateTime！

日期格式化的选择

大家除了惯用 Date来表示时间之外，还有一个用于和 Date连用的 SimpleDateFormat 时间格式化类大家可能也戒不掉了!

SimpleDateFormat最主要的致命问题也是在于它本身并不线程安全，这在它的源码注释里已然告知过了：

那取而代之，我们现在改用什么呢？其实在前文已经用到啦，那就是了 DateTimeFormatter了，他也是线程安全的：

小声BB

好了，说了这么多，如果你项目里还在使用 Date或者 SimpleDateFormat的话，答应我，二话别说，赶快全部偷偷去改掉，快！速度！跑步前进！