住在公司附近的壞處就是，夜里可能被領(lǐng)導(dǎo)一通電話叫去公司看問(wèn)題。服務(wù)總是報(bào)錯(cuò)，重啟也沒(méi)用。到公司打開(kāi)電腦，日志好多這個(gè)錯(cuò)誤：

Exception in thread "pool-1-thread-4" java.lang.NumberFormatException: For input string: ""

順著堆棧找過(guò)去，發(fā)現(xiàn)是SimpleDateFormat在多線程環(huán)境下出了幺蛾子。一個(gè)用了3年的工具類(lèi)，在并發(fā)量上來(lái)之后，直接讓服務(wù)跪了。

今天就把這次踩坑換來(lái)的經(jīng)驗(yàn)分享給你。全文3000字，看完至少讓你少踩3個(gè)生產(chǎn)級(jí)別的坑。

一、故事要從那個(gè)凌晨說(shuō)起：老套路的致命問(wèn)題

那天晚上修復(fù)完bug，我翻了翻項(xiàng)目代碼，發(fā)現(xiàn)一個(gè)扎心的事實(shí)：

• 數(shù)據(jù)庫(kù)里存的是DateTime；
• 業(yè)務(wù)代碼里混用Date，方法調(diào)用復(fù)雜，易出錯(cuò)；
• 時(shí)間比較全靠getTime()獲取毫秒值，可讀性極差；
• 日期格式化用SimpleDateFormat，封裝好的工具類(lèi)，埋下線程安全隱患。

其實(shí)早在Java 8發(fā)布時(shí)，官方就已經(jīng)給我們提供了一套完整、安全、高效的日期處理解決方案，只是很多人（包括之前的我）一直固守老套路，從未認(rèn)真了解過(guò)這套“新玩具”。

先給大家梳理一下這套新方案的核心成員，記住它們的分工，就能避開(kāi)80%的坑：

這里先給大家拋一個(gè)核心原則，后面所有內(nèi)容都圍繞這個(gè)原則展開(kāi)：數(shù)據(jù)庫(kù)存儲(chǔ)用bigint，java中用Instant和LocalDateTime，展示用DateTimeFormatter。

二、數(shù)據(jù)庫(kù)存儲(chǔ)：用BIGINT存時(shí)間戳，真香

聊完核心工具類(lèi)，我們先解決第一個(gè)基礎(chǔ)問(wèn)題：日期數(shù)據(jù)到底該怎么存？這也是我這次踩坑的間接原因之一。

我當(dāng)時(shí)的第一版數(shù)據(jù)庫(kù)設(shè)計(jì)，用的是MySQL的DATETIME類(lèi)型，Java代碼中對(duì)應(yīng)java.util.Dat e。乍一看邏輯通順，日期類(lèi)型存日期，直觀又方便，但實(shí) 際運(yùn)行后，接連踩了3個(gè)坑：

• 時(shí)區(qū)錯(cuò)亂：不同環(huán)境（開(kāi)發(fā)、測(cè)試、生產(chǎn)）的MySQL時(shí)區(qū)配置不一致，導(dǎo)致存進(jìn)去的時(shí)間和實(shí)際時(shí)間偏差幾小時(shí)，排查起來(lái)極其費(fèi)力；
• 性能瓶頸：當(dāng)數(shù)據(jù)量達(dá)到百萬(wàn)級(jí)后，日期字段的排序、篩選操作速度急劇下降，索引優(yōu)化效果甚微；
• 分庫(kù)分表麻煩：按時(shí)間分片時(shí)，DATETIME類(lèi)型需要額外處理時(shí)區(qū)和格式，容易出現(xiàn)分片偏差，而整數(shù)類(lèi)型的時(shí)間戳則能完美規(guī)避這個(gè)問(wèn)題。

后來(lái)將數(shù)據(jù)庫(kù)字段全部改成BIGINT存時(shí)間戳（毫秒級(jí)），所有問(wèn)題瞬間迎刃而解，感覺(jué)整個(gè)世界都清凈了。

推薦的實(shí)體類(lèi)設(shè)計(jì)如下，兼顧數(shù)據(jù)庫(kù)性能和業(yè)務(wù)語(yǔ)義：

@Entity
@Table(name = "orders")
public class Order {
   
    // 數(shù)據(jù)庫(kù)存BIGINT，追求極致的查詢性能
    @Column(name = "create_time", nullable = false)
    private Long createTimeStamp;
   
    // 業(yè)務(wù)代碼里用Instant操作，兩全其美（語(yǔ)義準(zhǔn)確+操作便捷）
    public Instant getCreateTime() {
        return Instant.ofEpochMilli(createTimeStamp);
    }
   
    public void setCreateTime(Instant instant) {
        this.createTimeStamp = instant.toEpochMilli();
    }
}

這樣設(shè)計(jì)的優(yōu)勢(shì)非常明顯，主要有3點(diǎn)：

• 性能炸裂：整數(shù)的比較、索引查詢速度，遠(yuǎn)超DATETIME等日期類(lèi)型，尤其適合大數(shù)據(jù)量場(chǎng)景；
• 時(shí)區(qū)無(wú)關(guān)：時(shí)間戳本身是絕對(duì)時(shí)間點(diǎn)，不依賴(lài)任何時(shí)區(qū)配置，不存在跨環(huán)境時(shí)區(qū)轉(zhuǎn)換錯(cuò)誤；
• 兼容性好：無(wú)論使用MySQL、PostgreSQL還是Oracle，BIGINT類(lèi)型都是通用支持的，無(wú)需額外適配。

有同學(xué)可能會(huì)問(wèn)：“用BIGINT存數(shù)字，我想在數(shù)據(jù)庫(kù)里直接查看具體時(shí)間，豈不是很麻煩？” 其實(shí)一點(diǎn)都不復(fù)雜，寫(xiě)SQL時(shí)簡(jiǎn)單轉(zhuǎn)換一下即可：

SELECT from_unixtime(create_time/1000) FROM orders;

這里除以1000，是因?yàn)槲覀兇娴氖呛撩爰?jí)時(shí)間戳，而MySQL的from_unixtime函數(shù)接收的是秒級(jí)時(shí)間戳，根據(jù)自己的存儲(chǔ)精度調(diào)整即可。

三、Java中的使用：優(yōu)先選Instant，按需轉(zhuǎn)LocalDateTime

解決了數(shù)據(jù)庫(kù)存儲(chǔ)（BIGINT時(shí)間戳）的問(wèn)題，接下來(lái)重點(diǎn)聊核心疑問(wèn)：數(shù)據(jù)庫(kù)存的是BIGINT時(shí)間戳，Java代碼里為什么不直接用long類(lèi)型操作？反而要先映射成Instant？

總結(jié)來(lái)說(shuō)，不直接用long時(shí)間戳、優(yōu)先將BIGINT映射到Instant，核心有3點(diǎn)原因，每一點(diǎn)都能幫我們避開(kāi)生產(chǎn)坑：

• 語(yǔ)義更清晰，避免歧義：long類(lèi)型只是一個(gè)單純的數(shù)字，你無(wú)法直接判斷它是毫秒級(jí)、秒級(jí)時(shí)間戳，還是普通的計(jì)數(shù)；而Instant明確表示“絕對(duì)時(shí)間點(diǎn)”，與數(shù)據(jù)庫(kù)的BIGINT時(shí)間戳語(yǔ)義完全對(duì)應(yīng)，一看就知道是“某個(gè)具體的瞬間”，無(wú)需額外注釋。
• 操作更便捷，減少計(jì)算錯(cuò)誤：long類(lèi)型計(jì)算時(shí)間差（如“7天前”），需要手動(dòng)換算毫秒數(shù)（72460601000L），極易漏算、錯(cuò)算；而Instant自帶豐富的API（如minus、plus），可以直接按天、小時(shí)、分鐘操作，無(wú)需手動(dòng)換算，從根源上避免錯(cuò)誤。
• 可擴(kuò)展性更強(qiáng)，適配復(fù)雜場(chǎng)景：long類(lèi)型只能做簡(jiǎn)單的大小比較和差值計(jì)算，無(wú)法直接轉(zhuǎn)換時(shí)區(qū)、格式化展示；而Instant可以輕松轉(zhuǎn)為L(zhǎng)ocalDateTime、ZonedDateTime，適配業(yè)務(wù)邏輯處理、前端展示等多種復(fù)雜場(chǎng)景，無(wú)需額外封裝工具類(lèi)。

而Instant，正是為解決long時(shí)間戳的痛點(diǎn)而生，它與BIGINT時(shí)間戳是“天生一對(duì)”，也是我們將數(shù)據(jù)庫(kù)BIGINT映射到Java實(shí)體類(lèi)的首選。

延伸疑問(wèn)：為什么還要把Instant轉(zhuǎn)成LocalDateTime

有同學(xué)會(huì)問(wèn)：“既然Instant這么好，為什么不全程用Instant？還要轉(zhuǎn)成LocalDateTime，多此一舉？”

答案很簡(jiǎn)單：Instant適合“機(jī)器處理”，LocalDateTime適合“人類(lèi)交互”。兩者的定位不同，各司其職——我們將數(shù)據(jù)庫(kù)BIGINT映射為Instant，是為了保證數(shù)據(jù)語(yǔ)義準(zhǔn)確、操作便捷；而將Instant轉(zhuǎn)為L(zhǎng)ocalDateTime，是為了適配“與人相關(guān)”的業(yè)務(wù)場(chǎng)景，讓代碼更易讀、更貼合實(shí)際需求。

哪些情況用Instant直接處理？哪些情況要轉(zhuǎn)LocalDateTime

結(jié)合實(shí)際項(xiàng)目經(jīng)驗(yàn)，我整理了清晰的場(chǎng)景劃分，一看就懂：

可直接用Instant處理的場(chǎng)景（無(wú)需轉(zhuǎn)LocalDateTime）

Instant的核心優(yōu)勢(shì)是“絕對(duì)時(shí)間點(diǎn)”，無(wú)需考慮時(shí)區(qū)，適合所有“機(jī)器層面”的時(shí)間操作，主要有3類(lèi)場(chǎng)景：

• 時(shí)間比較操作：比如判斷訂單創(chuàng)建時(shí)間是否在30分鐘內(nèi)、用戶注冊(cè)時(shí)間是否超過(guò)7天，直接用Instant的isBefore、isAfter方法，語(yǔ)義清晰、操作便捷，無(wú)需轉(zhuǎn)換。
• 時(shí)間差值計(jì)算（無(wú)需展示）：比如計(jì)算兩個(gè)操作之間的時(shí)間間隔（如接口調(diào)用耗時(shí)），用Instant的until方法，可直接獲取天、小時(shí)、分鐘等差值，無(wú)需轉(zhuǎn)為L(zhǎng)ocalDateTime。
• 數(shù)據(jù)存儲(chǔ)與傳輸（中間過(guò)程）：實(shí)體類(lèi)中映射數(shù)據(jù)庫(kù)BIGINT、服務(wù)間傳輸時(shí)間信息，直接用Instant，無(wú)需轉(zhuǎn)換——它語(yǔ)義準(zhǔn)確、體積小，還能避免時(shí)區(qū)錯(cuò)亂。

舉個(gè)直接用Instant處理的示例（時(shí)間比較）：

// 訂單創(chuàng)建時(shí)間（Instant），判斷是否在30分鐘內(nèi)
Instant orderCreateTime = order.getCreateTime();
Instant now = Instant.now();
// 直接用Instant API判斷，無(wú)需轉(zhuǎn)LocalDateTime
if (orderCreateTime.isAfter(now.minus(30, ChronoUnit.MINUTES))) {
    System.out.println("訂單創(chuàng)建時(shí)間在30分鐘內(nèi)");
}

需要將Instant轉(zhuǎn)為L(zhǎng)ocalDateTime的場(chǎng)景

當(dāng)時(shí)間需要“被人閱讀”“與人交互”時(shí)，就需要將Instant轉(zhuǎn)為L(zhǎng)ocalDateTime，主要有4類(lèi)場(chǎng)景，每一類(lèi)都貼合實(shí)際業(yè)務(wù)：

• 前端展示時(shí)間：將后端的時(shí)間數(shù)據(jù)返回給前端，需要展示為“yyyy-MM-dd HH:mm:ss”格式（如訂單創(chuàng)建時(shí)間、用戶注冊(cè)時(shí)間），需先將Instant轉(zhuǎn)為L(zhǎng)ocalDateTime，再用DateTimeFormatter格式化。
• 與人相關(guān)的業(yè)務(wù)計(jì)算：比如用戶生日、店鋪營(yíng)業(yè)時(shí)間、本地定時(shí)任務(wù)（每天8點(diǎn)執(zhí)行），這些場(chǎng)景關(guān)注的是“本地時(shí)間”，與人的生活習(xí)慣相關(guān)，適合用LocalDateTime。
• 接收前端傳入的時(shí)間參數(shù)：前端傳遞的日期字符串（如“2025-05-08 10:10:10”），通常對(duì)應(yīng)本地時(shí)間，先解析為L(zhǎng)ocalDateTime，再根據(jù)需求轉(zhuǎn)為Instant存儲(chǔ)。
• 日志打印與調(diào)試：開(kāi)發(fā)調(diào)試時(shí)，打印時(shí)間信息，用LocalDateTime能直觀看到具體的日期時(shí)間，方便排查問(wèn)題；若打印Instant，還需要手動(dòng)轉(zhuǎn)換才能看懂。

舉個(gè)Instant轉(zhuǎn)LocalDateTime的示例（前端展示）：

// 實(shí)體類(lèi)中的Instant（映射數(shù)據(jù)庫(kù)BIGINT）
Instant orderCreateTime = order.getCreateTime();
// 轉(zhuǎn)為L(zhǎng)ocalDateTime（指定時(shí)區(qū)，避免錯(cuò)亂）
LocalDateTime localDateTime = orderCreateTime.atZone(ZoneId.of("Asia/Shanghai")).toLocalDateTime();
// 格式化后返回給前端
String formatTime = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss").format(localDateTime);

這里補(bǔ)充一個(gè)關(guān)鍵注意點(diǎn)：Instant轉(zhuǎn)LocalDateTime時(shí)，必須指定時(shí)區(qū)（如Asia/Shanghai），因?yàn)镮nstant本身無(wú)時(shí)區(qū)，不指定時(shí)區(qū)會(huì)默認(rèn)使用系統(tǒng)時(shí)區(qū)，可能導(dǎo)致時(shí)間錯(cuò)亂。

四、格式化：徹底告別SimpleDateFormat

回到文章開(kāi)頭的報(bào)警事件，罪魁禍?zhǔn)拙褪?strong>SimpleDateFormat的線程不安全問(wèn)題。這也是很多老項(xiàng)目的通病，我們先看看常見(jiàn)的錯(cuò)誤用法，再講正確的姿勢(shì)。

先看兩個(gè)錯(cuò)誤示范，尤其是第二個(gè)，幾乎是“踩坑重災(zāi)區(qū)”：

// 錯(cuò)誤示范1：每個(gè)請(qǐng)求都new一個(gè)，浪費(fèi)資源
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String dateStr = formatter.format(new Date());
// 錯(cuò)誤示范2：定義成static共享，線程不安全?。ǜ卟l(fā)下必出問(wèn)題）
private static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

SimpleDateFormat之所以線程不安全，是因?yàn)樗鼉?nèi)部有可修改的成員變量，多線程并發(fā)調(diào)用時(shí)，會(huì)出現(xiàn)資源競(jìng)爭(zhēng)，導(dǎo)致格式化結(jié)果錯(cuò)亂、拋出異常（就像我這次遇到的一樣）。

而Java 8提供的DateTimeFormatter，完美解決了這個(gè)問(wèn)題——它是不可變的、線程安全的，可以放心地定義成靜態(tài)常量，全局復(fù)用。

推薦的工具類(lèi)寫(xiě)法如下，兼顧通用性和安全性：

public class DateUtils {
    // 定義為靜態(tài)常量，全局復(fù)用，線程安全
    private static final DateTimeFormatter FORMATTER =
        DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
   
    /**
     * 格式化Instant（需要指定時(shí)區(qū)，因?yàn)镮nstant無(wú)時(shí)區(qū)）
     */
    public static String format(Instant instant) {
        // 這里用系統(tǒng)默認(rèn)時(shí)區(qū)，也可根據(jù)業(yè)務(wù)指定（如ZoneId.of("Asia/Shanghai")）
        ZonedDateTime dateTime = instant.atZone(ZoneId.systemDefault());
        return dateTime.format(FORMATTER);
    }
   
    /**
     * 格式化LocalDateTime（自帶本地時(shí)區(qū)含義，可直接格式化）
     */
    public static String format(LocalDateTime dateTime) {
        return dateTime.format(FORMATTER);
    }
   
    /**
     * 將字符串解析為Instant（反向操作）
     */
    public static Instant parse(String dateStr) {
        // 先解析成LocalDateTime，再轉(zhuǎn)Instant（指定時(shí)區(qū)）
        LocalDateTime dateTime = LocalDateTime.parse(dateStr, FORMATTER);
        return dateTime.atZone(ZoneId.systemDefault()).toInstant();
    }
}

這里有一個(gè)關(guān)鍵注意點(diǎn)，一定要記牢：格式化Instant時(shí)，必須指定時(shí)區(qū)——因?yàn)镮nstant本身不包含時(shí)區(qū)信息，直接格式化會(huì)報(bào)錯(cuò)；而LocalDateTime自帶“本地”時(shí)區(qū)含義，無(wú)需額外指定時(shí)區(qū)，可直接格式化。

五、Spring Boot中的實(shí)戰(zhàn)技巧：入?yún)?、返回、?shù)據(jù)庫(kù)交互全適配

在實(shí)際的Spring Boot項(xiàng)目中，我們通常需要和前端交互（接收前端日期字符串、返回格式化后的日期），還要和數(shù)據(jù)庫(kù)交互（自動(dòng)轉(zhuǎn)換時(shí)間戳和Instant）。這里分享3個(gè)實(shí)用技巧，幫你簡(jiǎn)化開(kāi)發(fā)，避免重復(fù)編碼。

1. 接收前端數(shù)據(jù)：@DateTimeFormat

前端傳遞的日期通常是字符串（如“2025-05-08 10:10:10”），我們無(wú)需手動(dòng)解析，用@DateTimeFormat注解即可自動(dòng)將字符串轉(zhuǎn)換為L(zhǎng)ocalDateTime/ZonedDateTime：

public class UserDTO {
   
    // 前端傳"2025-05-08 10:10:10"，自動(dòng)轉(zhuǎn)換為L(zhǎng)ocalDateTime
    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime birthday;
   
    // getter/setter省略
}

注意：@DateTimeFormat主要用于接收前端的請(qǐng)求參數(shù)（如GET請(qǐng)求的參數(shù)、POST請(qǐng)求的表單參數(shù)），如果是JSON格式的請(qǐng)求體，需要用下面的@JsonFormat注解。

2. 返回給前端：@JsonFormat

我們需要將Java中的日期類(lèi)型（LocalDateTime/Instant），格式化后以字符串形式返回給前端，用@JsonFormat注解即可實(shí)現(xiàn)，還能指定時(shí)區(qū)：

public class UserVO {
   
    // 返回給前端時(shí)，格式化為"yyyy/MM/dd HH:mm:ss"，指定時(shí)區(qū)為GMT+8（北京時(shí)間）
    @JsonFormat(pattern = "yyyy/MM/dd HH:mm:ss", timezone = "GMT+8")
    private LocalDateTime createTime;
   
    // getter/setter省略
}

這里建議明確指定timezone為“GMT+8”，避免因服務(wù)器時(shí)區(qū)配置不同，導(dǎo)致返回給前端的時(shí)間錯(cuò)亂。

3. 數(shù)據(jù)庫(kù)交互（MyBatis）：自定義TypeHandler自動(dòng)轉(zhuǎn)換

之前我們說(shuō)過(guò)，數(shù)據(jù)庫(kù)存BIGINT時(shí)間戳，實(shí)體類(lèi)用Instant——如果每次查詢、插入都手動(dòng)轉(zhuǎn)換，會(huì)非常繁瑣。這時(shí)可以自定義MyBatis的TypeHandler，讓框架自動(dòng)幫我們完成轉(zhuǎn)換。

自定義InstantTypeHandler的代碼如下：

public class InstantTypeHandler extends BaseTypeHandler<Instant> {
   
    @Override
    public void setNonNullParameter(PreparedStatement ps, int i,
                                     Instant parameter, JdbcType jdbcType) throws SQLException {
        // 插入/更新時(shí)，將Instant轉(zhuǎn)為BIGINT（毫秒級(jí)）
        ps.setLong(i, parameter.toEpochMilli());
    }
   
    @Override
    public Instant getNullableResult(ResultSet rs, String columnName) throws SQLException {
        // 查詢時(shí)，將BIGINT轉(zhuǎn)為Instant
        long timestamp = rs.getLong(columnName);
        return Instant.ofEpochMilli(timestamp);
    }
   
    // 其他兩個(gè)方法（getNullableResult的另外兩種重載）省略，實(shí)現(xiàn)邏輯類(lèi)似
}

定義好TypeHandler后，在MyBatis的配置文件中注冊(cè)，或者在實(shí)體類(lèi)的字段上直接指定，MyBatis就會(huì)自動(dòng)幫你完成BIGINT和Instant的轉(zhuǎn)換，無(wú)需手動(dòng)處理，極大提升開(kāi)發(fā)效率。

六、總結(jié)所有最佳實(shí)踐

5條黃金法則，記牢這5條，就能避開(kāi)絕大多數(shù)日期處理坑：

• 存儲(chǔ)用時(shí)間戳：數(shù)據(jù)庫(kù)字段一律用BIGINT存毫秒值，兼顧性能和兼容性；
• 映射用Instant：實(shí)體類(lèi)里用Instant對(duì)應(yīng)BIGINT，語(yǔ)義準(zhǔn)確，避免時(shí)區(qū)歧義；
• 業(yè)務(wù)用LocalDateTime：給人看的時(shí)間、日期計(jì)算，用LocalDateTime，代碼更易讀；
• 比較用Instant API：時(shí)間比較用isBefore()、isAfter()，清晰表達(dá)業(yè)務(wù)意圖，避免計(jì)算錯(cuò)誤；
• 格式化用DateTimeFormatter：定義成static final常量，全局復(fù)用，線程安全。

到此這篇關(guān)于SpringBoot項(xiàng)目中日期處理的最佳實(shí)踐的文章就介紹到這了,更多相關(guān)SpringBoot日期處理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論