在Java 8之前，處理日期時(shí)間我們常用Date、Calendar和SimpleDateFormat。這些API雖然功能完備，但設(shè)計(jì)上存在諸多痛點(diǎn)：可讀性差、API混亂、線程不安全、時(shí)區(qū)處理困難，稍有不慎就會(huì)掉進(jìn)各種“時(shí)間錯(cuò)亂”的坑里。

Java 8推出了全新的日期時(shí)間API（java.time包），每個(gè)類職責(zé)清晰、操作簡(jiǎn)潔、線程安全，并且完美支持時(shí)區(qū)處理。遺憾的是，由于早期第三方庫(kù)對(duì)新類型支持不足，許多項(xiàng)目仍在使用老API。如今幾乎所有主流框架都已適配，是時(shí)候全面擁抱Java 8日期時(shí)間類了。

本文將通過實(shí)際案例，剖析老API的典型陷阱，并展示如何使用新API優(yōu)雅避坑。同時(shí)，我們用Mermaid圖直觀呈現(xiàn)核心概念，幫助你徹底掌握正確的日期時(shí)間處理方式。

1. 日期時(shí)間初始化：從“穿越”到“精準(zhǔn)”

先看一個(gè)新手常犯的錯(cuò)誤——用Date構(gòu)造函數(shù)初始化時(shí)間：

Date date = new Date(2019, 12, 31, 11, 12, 13);
System.out.println(date);

輸出結(jié)果令人大跌眼鏡：

Sat Jan 31 11:12:13 CST 3920

原來Date的年份參數(shù)需要減去1900，月份從0開始（0代表1月）。正確的寫法是：

Date date = new Date(2019 - 1900, 11, 31, 11, 12, 13);

但這還不夠，當(dāng)涉及國(guó)際化時(shí)，必須使用Calendar并指定時(shí)區(qū)：

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

為什么紐約時(shí)區(qū)初始化后，輸出變成了2020年1月1日？這正是時(shí)區(qū)在背后起作用。我們接著深入時(shí)區(qū)問題。

2. 時(shí)區(qū)問題：UTC才是真正的“世界時(shí)間”

2.1 Date的本質(zhì)：UTC時(shí)間戳

Date內(nèi)部保存的是一個(gè)long型時(shí)間戳，即從1970-01-01 00:00:00 UTC到現(xiàn)在的毫秒數(shù)。因此，無論你在世界哪個(gè)角落執(zhí)行new Date()，得到的時(shí)間戳都是一樣的。調(diào)用toString()時(shí)會(huì)根據(jù)當(dāng)前JVM默認(rèn)時(shí)區(qū)轉(zhuǎn)換為本地時(shí)間顯示，但Date本身不包含任何時(shí)區(qū)信息。

2.2 正確保存與展示時(shí)間

為了正確國(guó)際化，保存時(shí)間應(yīng)當(dāng)使用UTC（時(shí)間戳），展示時(shí)再根據(jù)用戶時(shí)區(qū)轉(zhuǎn)換為本地時(shí)間。老API中通常使用Calendar攜帶時(shí)區(qū)，但操作繁瑣且易錯(cuò)。

Java 8引入了ZonedDateTime = LocalDateTime + ZoneId，徹底分離了“本地日期時(shí)間表示”和“帶時(shí)區(qū)的時(shí)間點(diǎn)”。下面是一個(gè)完整的解析和展示示例：

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

可以看到，同一個(gè)UTC時(shí)間點(diǎn)（東京時(shí)區(qū)22:00）在不同時(shí)區(qū)下展示為不同的本地時(shí)間。這正是時(shí)區(qū)的正確作用，而非“時(shí)間錯(cuò)亂”。

2.3 時(shí)區(qū)轉(zhuǎn)換流程

下面的Mermaid圖清晰地展示了從本地時(shí)間表示到UTC存儲(chǔ)，再到展示的過程：

3. 格式化和解析：三個(gè)深坑與解決方案

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年的第一周（取決于區(qū)域設(shè)置）。下圖展示了week year的計(jì)算規(guī)則：

解決方案：無特殊需求，一律使用小寫y表示年份。

3.2 坑二：SimpleDateFormat線程不安全

將SimpleDateFormat定義為static并在多線程中復(fù)用，會(huì)導(dǎo)致解析結(jié)果混亂甚至異常：

private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

// 線程池中并發(fā)調(diào)用sdf.parse()

問題根源在于SimpleDateFormat內(nèi)部共享Calendar實(shí)例，且操作未加鎖：

public class SimpleDateFormat extends DateFormat {
    protected Calendar calendar;  // 共享變量！
    // parse方法會(huì)清空并重建calendar
}

并發(fā)時(shí)序可能導(dǎo)致一個(gè)線程清空Calendar后，另一個(gè)線程接著使用，產(chǎn)生錯(cuò)誤結(jié)果。

解決方案：

• 使用ThreadLocal為每個(gè)線程保存一份SimpleDateFormat實(shí)例；
• 更佳方案：直接使用Java 8的DateTimeFormatter，它是線程安全的。

3.3 坑三：寬松解析導(dǎo)致數(shù)據(jù)錯(cuò)誤

String dateString = "20160901";
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM");
System.out.println(sdf.parse(dateString)); // Mon Jan 01 00:00:00 CST 2091

本意是解析年月，卻因?yàn)樽址?，被錯(cuò)誤解析為第75個(gè)月（0901個(gè)月），得到2091年1月。

而DateTimeFormatter默認(rèn)嚴(yán)格解析，遇到不匹配直接拋出異常：

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyyMM");
dtf.parse("20160901"); // 拋出DateTimeParseException

4. 日期時(shí)間計(jì)算：告別溢出與繁瑣

4.1 時(shí)間戳計(jì)算的溢出問題

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范圍內(nèi)溢出，結(jié)果為負(fù)值。改為30L即可。

手動(dòng)計(jì)算時(shí)間戳容易出錯(cuò)，推薦使用Calendar或Java 8 API。

4.2 Java 8計(jì)算API的強(qiáng)大

LocalDateTime now = LocalDateTime.now();
LocalDateTime later = now.plusDays(30);  // 簡(jiǎn)潔明了

除了簡(jiǎn)單的加減，TemporalAdjusters提供了豐富的調(diào)整器：

// 本月第一天
LocalDate.now().with(TemporalAdjusters.firstDayOfMonth());

// 下一個(gè)周六
LocalDate.now().with(TemporalAdjusters.next(DayOfWeek.SATURDAY));

// 自定義：增加隨機(jī)天數(shù)
LocalDate.now().with(temporal -> temporal.plus(ThreadLocalRandom.current().nextInt(100), ChronoUnit.DAYS));

4.3 Period與ChronoUnit的陷阱

計(jì)算兩個(gè)日期差時(shí)，Period返回的是“幾年幾月幾日”，而不是總天數(shù)：

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（只輸出剩余天數(shù)）
System.out.println(period);             // P2M11D
System.out.println(ChronoUnit.DAYS.between(start, end)); // 72（總天數(shù)）

如果需要總天數(shù)，請(qǐng)使用ChronoUnit.DAYS.between()。

5. 新老API轉(zhuǎn)換：必須明確時(shí)區(qū)

老項(xiàng)目升級(jí)時(shí)難免需要互轉(zhuǎn)。轉(zhuǎn)換時(shí)務(wù)必提供時(shí)區(qū)，否則可能丟失信息。

// 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());

下圖總結(jié)了Java 8時(shí)間類與遺留類的對(duì)應(yīng)關(guān)系：

6. 總結(jié)：全面擁抱Java 8日期時(shí)間API

通過以上對(duì)比，我們可以看到Java 8的java.time包在各個(gè)方面都優(yōu)于舊API：

• 清晰：類名職責(zé)明確，如LocalDateTime、ZonedDateTime、Instant。
• 安全：不可變對(duì)象，線程安全，無需額外同步。
• 功能豐富：內(nèi)置大量時(shí)間調(diào)整器、計(jì)算方法。
• 時(shí)區(qū)友好：顯式處理時(shí)區(qū)，避免隱式轉(zhuǎn)換錯(cuò)誤。

如果你還在使用Date和Calendar，是時(shí)候重構(gòu)了。遷移到Java 8日期時(shí)間API，不僅能消除潛在bug，還能讓代碼更簡(jiǎn)潔易讀。

思考與討論：

• Date本質(zhì)是UTC時(shí)間戳，但toString()卻輸出帶時(shí)區(qū)（如CST）的字符串，你知道這是為什么嗎？
• MySQL中datetime和timestamp類型有什么區(qū)別？它們是否包含時(shí)區(qū)信息？

到此這篇關(guān)于Java8中日期時(shí)間API的避坑指南與最佳實(shí)踐指南的文章就介紹到這了,更多相關(guān)Java8日期時(shí)間API使用內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論