Spring 企業級開發實戰：深度解析事務併發的五大核心問題

前言

在企業級 Spring 應用開發中，事務管理是確保數據一致性的基石。然而，當多個事務並發執行時，若隔離級別配置不當，極易引發髒讀、不可重複讀、幻讀以及兩類丟失更新等經典併發異常。本文將系統剖析這五大問題的成因、場景與防範策略，助你構建健壯的數據訪問層。

一、髒讀：讀取未提交的「臟」數據

定義：事務 A 修改數據後未提交，事務 B 讀取了這筆未提交數據。若事務 A 隨後回滾，事務 B 讀到的即為不存在的「髒數據」。

典型場景：

• 事務 1：更新用戶餘額 -100（未提交）
• 事務 2：讀取用戶餘額，發現已扣款，據此發放優惠券
• 事務 1：因庫存不足回滾，餘額恢復原狀
• 結果：事務 2 基於錯誤數據發放優惠券，造成業務損失

防範：將事務隔離級別設為 READ_COMMITTED 或更高（如 Oracle 預設級別），確保只能讀取已提交數據。

二、不可重複讀：同一事務內多次查詢結果不一致

定義：事務 A 先後兩次讀取同一條數據，期間事務 B 修改並提交了該數據，導致事務 A 兩次讀取結果不同。

典型場景：

• 事務 1：查詢訂單狀態為「待付款」
• 事務 2：用戶完成支付，更新訂單狀態為「已付款」並提交
• 事務 1：再次查詢同一訂單，發現狀態變為「已付款」
• 結果：事務 1 邏輯判斷出現分歧，可能重複發貨或漏單

防範：使用 REPEATABLE_READ 隔離級別（MySQL InnoDB 預設），或在查詢時加上行級鎖 SELECT ... FOR UPDATE。

三、幻讀：數據行數莫名增減

定義：事務 A 按條件查詢某範圍數據，事務 B 在此範圍內插入/刪除數據並提交，事務 A 再次查詢發現行數變化，如見幻覺。

與不可重複讀的區別：前者針對「修改」，後者針對「新增/刪除」導致的行集合變化。

典型場景：

• 事務 1：統計某分類下商品數量為 100
• 事務 2：新增一件該分類商品並提交
• 事務 1：再次統計，數量變為 101，業務邏輯判斷失效

防範：需採用 SERIALIZABLE 序列化隔離級別，或在應用層面通過表級鎖、間隙鎖機制解決（InnoDB 的 Next-Key Lock 已在 REPEATABLE READ 下解決大部分幻讀）。

補充說明：Oracle 資料庫採用多版本併發控制（MVCC），預設不會出現髒讀。防止不可重複讀可用行級鎖，防止幻讀則需表級鎖，但這會嚴重影響併發性能，生產環境建議結合業務場景選擇樂觀鎖或悲觀鎖策略。

四、第一類丟失更新：回滾覆蓋了他人的修改

定義：事務 A、B 同時操作同一數據，A 先修改，B 後修改失敗回滾，導致 A 的修改也被一併回滾。

本質：事務撤銷導致的覆蓋丟失，屬於數據庫系統內部錯誤，現代主流資料庫（Oracle、MySQL、PostgreSQL）均在內核層面修復，開發者無需額外處理。

五、第二類丟失更新：提交覆蓋了他人的修改

定義：事務 A、B 同時讀取同一數據，A 先修改提交，B 後修改提交，導致 A 的更新被 B 覆蓋。

典型場景：

• 兩用戶同時編輯同一商品庫存，初始 100
• 用戶 A：讀取 100，扣減 10，提交更新為 90
• 用戶 B：讀取 100（舊值），扣減 5，提交更新為 95
• 結果：實際應為 85，卻變為 95，丟失 A 的更新

防範方案：

1. 悲觀鎖：SELECT ... FOR UPDATE 加排他鎖，串行化訪問
2. 樂觀鎖：引入版本號或時間戳，更新時 WHERE version = oldVersion，失敗則重試
3. 原子操作：UPDATE stock SET count = count - 5 WHERE id = 1 避免「讀-改-寫」非原子性

總結與最佳實踐建議

在 Spring 中，可通過 @Transactional(isolation = Isolation.REPEATABLE_READ) 聲明式指定隔離級別，結合 JPA/Hibernate 的 @Version 實現樂觀鎖，是企業級開發中最通用的組合策略。實際項目中，建議以「讀已提交 + 樂觀鎖」為基線，核心交易環節升級為「可重複讀 + 悲觀鎖」，在一致性與吞吐間取得平衡。