我要评论在java 8之前，处理日期时间我们常用date、calendar和simpledateformat。这些api虽然功能完备，但设计上存在诸多痛点：可读性差、api混乱、线程不安全、时区处理困难，稍有不慎就会掉进各种“时间错乱”的坑里。
java 8推出了全新的日期时间api（java.time包），每个类职责清晰、操作简洁、线程安全，并且完美支持时区处理。遗憾的是，由于早期第三方库对新类型支持不足，许多项目仍在使用老api。如今几乎所有主流框架都已适配，是时候全面拥抱java 8日期时间类了。
本文将通过实际案例，剖析老api的典型陷阱，并展示如何使用新api优雅避坑。同时，我们用mermaid图直观呈现核心概念，帮助你彻底掌握正确的日期时间处理方式。
1. 日期时间初始化：从“穿越”到“精准”
先看一个新手常犯的错误——用date构造函数初始化时间：
date date = new date(2019, 12, 31, 11, 12, 13); system.out.println(date);
输出结果令人大跌眼镜：
sat jan 31 11:12:13 cst 3920
原来date的年份参数需要减去1900，月份从0开始（0代表1月）。正确的写法是：
date date = new date(2019 - 1900, 11, 31, 11, 12, 13);
但这还不够，当涉及国际化时，必须使用calendar并指定时区：
calendar calendar = calendar.getinstance();
calendar.set(2019, calendar.december, 31, 11, 12, 13);
system.out.println(calendar.gettime()); // tue dec 31 11:12:13 cst 2019
calendar calendarny = calendar.getinstance(timezone.gettimezone("america/new_york"));
calendarny.set(2019, calendar.december, 31, 11, 12, 13);
system.out.println(calendarny.gettime()); // wed jan 01 00:12:13 cst 2020
为什么纽约时区初始化后，输出变成了2020年1月1日？这正是时区在背后起作用。我们接着深入时区问题。
2. 时区问题：utc才是真正的“世界时间”
2.1 date的本质：utc时间戳
date内部保存的是一个long型时间戳，即从1970-01-01 00:00:00 utc到现在的毫秒数。因此，无论你在世界哪个角落执行new date()，得到的时间戳都是一样的。调用tostring()时会根据当前jvm默认时区转换为本地时间显示，但date本身不包含任何时区信息。
2.2 正确保存与展示时间
为了正确国际化，保存时间应当使用utc（时间戳），展示时再根据用户时区转换为本地时间。老api中通常使用calendar携带时区，但操作繁琐且易错。
java 8引入了zoneddatetime = localdatetime + zoneid，彻底分离了“本地日期时间表示”和“带时区的时间点”。下面是一个完整的解析和展示示例：
string stringdate = "2020-01-02 22:00:00";
zoneid zonesh = zoneid.of("asia/shanghai");
zoneid zoneny = zoneid.of("america/new_york");
zoneid zonejst = zoneoffset.ofhours(9);
datetimeformatter formatter = datetimeformatter.ofpattern("yyyy-mm-dd hh:mm:ss");
zoneddatetime date = zoneddatetime.of(localdatetime.parse(stringdate, formatter), zonejst);
datetimeformatter outputformatter = datetimeformatter.ofpattern("yyyy-mm-dd hh:mm:ss z");
system.out.println(zonesh.getid() + outputformatter.withzone(zonesh).format(date));
system.out.println(zoneny.getid() + outputformatter.withzone(zoneny).format(date));
system.out.println(zonejst.getid() + outputformatter.withzone(zonejst).format(date));
输出：
asia/shanghai2020-01-02 21:00:00 +0800
america/new_york2020-01-02 08:00:00 -0500
+09:002020-01-02 22:00:00 +0900
可以看到，同一个utc时间点（东京时区22:00）在不同时区下展示为不同的本地时间。这正是时区的正确作用，而非“时间错乱”。
2.3 时区转换流程
下面的mermaid图清晰地展示了从本地时间表示到utc存储，再到展示的过程：
3. 格式化和解析：三个深坑与解决方案
3.1 坑一：yyyy与yyyy傻傻分不清
calendar cal = calendar.getinstance();
cal.set(2019, calendar.december, 29);
simpledateformat sdf = new simpledateformat("yyyy-mm-dd");
system.out.println(sdf.format(cal.gettime())); // 2020-12-29
输出居然是2020年！原因是大写y表示“week year”（周所在的年份），而2019年12月29日属于2020年的第一周（取决于区域设置）。下图展示了week year的计算规则：
解决方案：无特殊需求，一律使用小写y表示年份。
3.2 坑二：simpledateformat线程不安全
将simpledateformat定义为static并在多线程中复用，会导致解析结果混乱甚至异常：
private static simpledateformat sdf = new simpledateformat("yyyy-mm-dd hh:mm:ss");
// 线程池中并发调用sdf.parse()
问题根源在于simpledateformat内部共享calendar实例，且操作未加锁：
public class simpledateformat extends dateformat {
protected calendar calendar; // 共享变量！
// parse方法会清空并重建calendar
}
并发时序可能导致一个线程清空calendar后，另一个线程接着使用，产生错误结果。
解决方案：
- 使用
threadlocal为每个线程保存一份simpledateformat实例； - 更佳方案：直接使用java 8的
datetimeformatter，它是线程安全的。
3.3 坑三：宽松解析导致数据错误
string datestring = "20160901";
simpledateformat sdf = new simpledateformat("yyyymm");
system.out.println(sdf.parse(datestring)); // mon jan 01 00:00:00 cst 2091
本意是解析年月，却因为字符串包含日，被错误解析为第75个月（0901个月），得到2091年1月。
而datetimeformatter默认严格解析，遇到不匹配直接抛出异常：
datetimeformatter dtf = datetimeformatter.ofpattern("yyyymm");
dtf.parse("20160901"); // 抛出datetimeparseexception
4. 日期时间计算：告别溢出与繁琐
4.1 时间戳计算的溢出问题
date today = new date(); date nextmonth = new date(today.gettime() + 30 * 1000 * 60 * 60 * 24); system.out.println(nextmonth); // 比今天还早！
原因：30 * 1000 * 60 * 60 * 24 在int范围内溢出，结果为负值。改为30l即可。
手动计算时间戳容易出错，推荐使用calendar或java 8 api。
4.2 java 8计算api的强大
localdatetime now = localdatetime.now(); localdatetime later = now.plusdays(30); // 简洁明了
除了简单的加减，temporaladjusters提供了丰富的调整器：
// 本月第一天 localdate.now().with(temporaladjusters.firstdayofmonth()); // 下一个周六 localdate.now().with(temporaladjusters.next(dayofweek.saturday)); // 自定义：增加随机天数 localdate.now().with(temporal -> temporal.plus(threadlocalrandom.current().nextint(100), chronounit.days));
4.3 period与chronounit的陷阱
计算两个日期差时，period返回的是“几年几月几日”，而不是总天数：
localdate start = localdate.of(2019, 10, 1); localdate end = localdate.of(2019, 12, 12); period period = period.between(start, end); system.out.println(period.getdays()); // 11（只输出剩余天数） system.out.println(period); // p2m11d system.out.println(chronounit.days.between(start, end)); // 72（总天数）
如果需要总天数，请使用chronounit.days.between()。
5. 新老api转换：必须明确时区
老项目升级时难免需要互转。转换时务必提供时区，否则可能丢失信息。
// date -> localdatetime date date = new date(); localdatetime ldt = localdatetime.ofinstant(date.toinstant(), zoneid.systemdefault()); // localdatetime -> date localdatetime now = localdatetime.now(); date out = date.from(now.atzone(zoneid.systemdefault()).toinstant());
下图总结了java 8时间类与遗留类的对应关系：
6. 总结：全面拥抱java 8日期时间api
通过以上对比，我们可以看到java 8的java.time包在各个方面都优于旧api：
- 清晰：类名职责明确，如
localdatetime、zoneddatetime、instant。 - 安全：不可变对象，线程安全，无需额外同步。
- 功能丰富：内置大量时间调整器、计算方法。
- 时区友好：显式处理时区，避免隐式转换错误。
如果你还在使用date和calendar，是时候重构了。迁移到java 8日期时间api，不仅能消除潜在bug，还能让代码更简洁易读。
思考与讨论：
date本质是utc时间戳，但tostring()却输出带时区（如cst）的字符串，你知道这是为什么吗？- mysql中
datetime和timestamp类型有什么区别？它们是否包含时区信息？
到此这篇关于java8中日期时间api的避坑指南与最佳实践指南的文章就介绍到这了,更多相关java8日期时间api使用内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论