簡介面向 Java 初學者的銀行賬戶轉(zhuǎn)賬模擬系統(tǒng)以圖形界面與多線程機制實現(xiàn)適合正在學習 Swing 界面編程和線程并發(fā)的讀者幫助理解多線程共享賬戶余額時的讀寫與同步問題。程序設定 A、B 兩個初始余額均為 1000 元的賬戶由線程隨機向?qū)Ψ睫D(zhuǎn)賬轉(zhuǎn)賬金額不得大于當前余額余額為零即無法繼續(xù)交易界面下方設有「交易開始」「清屏」按鈕點擊開始后按鈕切換為「結束交易」結束時將全部記錄寫入 ab.txt。壓縮包共 2 個 java 源文件分別承載窗口界面的構建與轉(zhuǎn)賬線程邏輯整體僅約 2KB結構緊湊便于導入 IDE 直接運行和二次改造。已有 4171 人學習下載可作為課程實驗、并發(fā)練習或課程設計的參考范例幫助讀者掌握界面事件響應、線程調(diào)度與交易記錄持久化的完整實現(xiàn)思路。1. 銀行賬戶轉(zhuǎn)賬幾乎是每個做后端課程設計的人都寫過的題目兩個賬戶一扣一加包進事務跑通就算完事?？刹l(fā)一開到 50余額對不上、偶發(fā)死鎖、超時重試后錢被扣兩次問題會一起冒出來。這份模擬銀行賬戶轉(zhuǎn)賬系統(tǒng)的源碼包價值不在“能轉(zhuǎn)”而在它把賬戶表、流水表、事務邊界、冪等占位和對賬 SQL 都攤開擺在明面上能順著一條鏈路看清錢從 A 到 B 的每一步也能看清哪一步最容易漏。適合正在做課程設計的學生、要給業(yè)務系統(tǒng)補一段結算邏輯的后端以及想把“事務到底加在哪一層”弄明白的開發(fā)者。下面按拆包順序走數(shù)據(jù)模型、調(diào)用鏈路、冪等與對賬、踩坑現(xiàn)場最后是一套能自己跑的驗證方法。2. 數(shù)據(jù)模型先立住賬戶表、流水表、單據(jù)表怎么擺拿到包先別急著跑main把建表腳本翻出來看一遍基本能判斷這套代碼是“能演示”還是“能改”。模擬轉(zhuǎn)賬系統(tǒng)里最常見的偷懶做法是只建一張account表扣款balance balance - x入賬balance balance x跑通了日志也漂亮。問題是這套結構沒有任何回溯能力賬一旦對不上你只能看著兩個數(shù)字發(fā)呆不知道是哪一筆、哪個時刻、哪個方向出的錯。所以合格的做法一定是三張表起步——賬戶、單據(jù)、流水各管一件事。2.1 快照與事實分離為什么流水表不能省賬戶表存的是快照回答“現(xiàn)在有多少錢”流水表存的是事實回答“錢是怎么變成現(xiàn)在這樣的”。兩者的關系類似庫存與出入庫單快照可以重算事實不能重寫。只留快照的系統(tǒng)等于把賬本燒了只記住余額出了問題連后悔藥都沒得吃。一筆轉(zhuǎn)賬在流水表里應該落兩條記錄一條出賬DEBIT一條入賬CREDIT金額相等、方向相反。這樣就得到一個恒等式所有流水的出賬金額之和永遠等于入賬金額之和誤差為零。這條恒等式是對賬時最強的斷言比任何“我核對了一遍余額”都可靠。很多課程設計只落一條“轉(zhuǎn)賬流水”把 from/to 塞進同一行看著省事真出問題時你沒法用 SQL 直接驗證平衡性只能寫代碼繞。單據(jù)表則是另一層一次轉(zhuǎn)賬請求對應一行帶唯一單號它既是業(yè)務憑證也是冪等鍵。有了它“這筆請求到底成功沒有”這個問題才有地方回答。三張表的分工可以記成一句話單據(jù)管請求流水管變化賬戶管現(xiàn)狀。2.2 建表 SQL三個約束把臟數(shù)據(jù)擋在數(shù)據(jù)庫門外下面是我在這個包里看到的表結構我做了一點整理注釋補全了可以直接拿去跑。注意引擎必須是 InnoDBMyISAM 沒有事務也沒有行鎖這個場景下等于殘廢。-- 賬戶表只存當前狀態(tài)balance 是快照 CREATE TABLE account ( id BIGINT NOT NULL AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL COMMENT 賬號業(yè)務唯一鍵, owner_name VARCHAR(64) NOT NULL COMMENT 戶名演示用不存任何真實信息, balance DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 可用余額單位元, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0凍結, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_account_no (account_no), CONSTRAINT ck_balance_nonneg CHECK (balance 0) -- 最后一道防線 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 單據(jù)表一次轉(zhuǎn)賬請求一行order_no 同時是冪等鍵 CREATE TABLE transfer_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL COMMENT 冪等鍵客戶端生成或服務端雪花號, from_account VARCHAR(32) NOT NULL, to_account VARCHAR(32) NOT NULL, amount DECIMAL(18,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0處理中 1成功 2失敗, fail_reason VARCHAR(255) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), -- 冪等靠它不靠先查后插 KEY idx_from_created (from_account, created_at) -- 查某賬戶最近轉(zhuǎn)出用 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 流水表只追加不更新一筆轉(zhuǎn)賬兩條 CREATE TABLE account_flow ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL, account_no VARCHAR(32) NOT NULL, direction TINYINT NOT NULL COMMENT 1出賬 2入賬, amount DECIMAL(18,2) NOT NULL, balance_after DECIMAL(18,2) NOT NULL COMMENT 記賬后余額回溯時不用重算, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_acc_dir (order_no, account_no, direction), -- 防同一筆重復記賬 KEY idx_acc_id (account_no, id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;三個約束是這套表結構的核心。uk_order_no讓并發(fā)下只有一條單據(jù)能插進去重復請求在數(shù)據(jù)庫層面就被擋住uk_order_acc_dir保證同一筆單據(jù)對同一賬戶同一方向只能記一次賬重試邏輯寫錯了也不會雙記ck_balance_nonneg是余額的兜底任何繞過業(yè)務校驗的路徑都會被數(shù)據(jù)庫拒絕。提示MySQL 5.7 及更早版本會解析CHECK但不執(zhí)行寫上去只是注釋。上線前用SELECT VERSION();確認8.0.16 以上才真正生效。如果只能跑 5.7這個斷言必須由應用層和定時巡檢補上。索引也在為后面的查詢鋪路。idx_acc_id (account_no, id)是給“查某賬戶流水按時間倒序翻頁”準備的用自增 id 代替 created_at 排序可以避免同一秒內(nèi)多條流水順序不穩(wěn)。idx_from_created用來做“某賬戶當日轉(zhuǎn)出總額”這類風控口徑的統(tǒng)計。2.3 余額存字段還是實時匯總三種方案的成本賬新手最容易糾結的一點既然有流水表為什么還要在賬戶表冗余一個balance直接SUM不行嗎能行但要看規(guī)模。三種常見方案的實際差別如下。方案余額怎么得到讀性能寫性能一致性風險適用場景只存流水SUM(CASE WHEN direction2 THEN amount ELSE -amount END)差隨流水行數(shù)線性劣化好純追加低賬戶少、流水少的課堂演示余額字段 流水直接讀account.balance好主鍵或唯一索引命中中需行鎖保護中字段與流水可能不一致絕大多數(shù)業(yè)務系統(tǒng)余額字段 日終校準讀字段定時任務用流水重算比對好中低有對賬任務的正式系統(tǒng)這個包用的是第二種也是我一般會選的讀多寫少的場景下把計算成本壓到寫入時一次性付掉。代價是必須在轉(zhuǎn)賬鏈路里保證“改余額”和“寫流水”在同一個事務里否則就會出現(xiàn)賬戶扣了錢、流水沒落下的單邊賬。第三種是在第二種基礎上加定時校準屬于線上系統(tǒng)的標配課程設計里加一個每天凌晨跑的比對任務成本很低答辯時也是個加分項。有一點要提前說清余額字段是冗余冗余就意味著可能不一致。所以系統(tǒng)里必須存在一條能從流水重算出余額的路徑哪怕它平時不跑。這條路徑就是你的后悔藥沒有它任何“余額好像不對”的反饋你都只能靠猜。3. 轉(zhuǎn)賬鏈路拆解一次請求里的鎖、事務和回滾表建好了接下來看錢的路徑。一次轉(zhuǎn)賬從 HTTP 進來經(jīng)過參數(shù)校驗、冪等占位、加鎖、校驗、扣款、入賬、記流水、改單據(jù)狀態(tài)最后提交事務。這條鏈路上任何一步的位置放錯都會在并發(fā)下暴露出來。這一章拆三段事務邊界畫在哪、鎖按什么順序拿、隔離級別和超時怎么配。3.1 事務邊界為什么Transactional只能貼在 Service 的公有方法上事務邊界的原則很簡單一個事務只包住必須原子的一段數(shù)據(jù)庫操作越短越好。放在 Controller 上是錯的把參數(shù)解析、序列化都包進去了放在 Mapper 上也不對一次轉(zhuǎn)賬要動四張表跨 Mapper正確位置是 Service 的公有方法而且這個方法必須是通過 Spring 代理調(diào)用的。下面這幾件事千萬別塞進事務里調(diào)用外部接口、發(fā)消息、寫文件日志、睡幾毫秒做“防重”。事務持有數(shù)據(jù)庫連接和行鎖任何耗時操作都在放大鎖沖突窗口。我見過把一次 HTTP 回調(diào)寫在事務里的實現(xiàn)壓測時鎖等待直接打滿innodb_lock_wait_timeout一個接一個超時。常見做法是把外部調(diào)用挪到事務提交之后用事務同步回調(diào)或者本地消息表來保證最終一致。另一個容易忽略的點是rollbackFor。Spring 默認只在遇到RuntimeException和Error時回滾受檢異常直接提交。也就是說你throw new IOException()之后扣款已經(jīng)落庫了。// 錯誤寫法受檢異常不回滾扣款會留在庫里 Transactional public void transfer(TransferCmd cmd) throws Exception { ... } // 正確寫法顯式聲明回滾異常類型 Transactional(rollbackFor Exception.class) public void transfer(TransferCmd cmd) { ... }參數(shù)說明rollbackFor Exception.class覆蓋所有異常如果業(yè)務上確實有“部分失敗也要提交”的場景用noRollbackFor單獨排除別靠吞異常來實現(xiàn)吞異常是后面第 5 章要重點說的坑。3.2 加鎖順序與核心轉(zhuǎn)賬代碼并發(fā)轉(zhuǎn)賬出死鎖八成是鎖順序不一致。A 轉(zhuǎn) B 時先鎖 A 再鎖 BB 轉(zhuǎn) A 時先鎖 B 再鎖 A兩個事務各持一把等對方InnoDB 檢測到環(huán)路就干掉其中一個報Deadlock found when trying to get lock。解決辦法不復雜所有涉及雙賬戶的操作統(tǒng)一按賬號字典序升序加鎖。賬號是字符串用compareTo排排完再依次SELECT ... FOR UPDATE。Service public class TransferService { private final AccountMapper accountMapper; private final TransferOrderMapper orderMapper; private final AccountFlowMapper flowMapper; Transactional(rollbackFor Exception.class, isolation Isolation.READ_COMMITTED) public TransferResult transfer(TransferCmd cmd) { String orderNo cmd.getOrderNo(); // 1. 搶占冪等鍵并發(fā)下只有一個線程能插進 uk_order_no try { orderMapper.insertProcessing(orderNo, cmd.getFrom(), cmd.getTo(), cmd.getAmount()); } catch (DuplicateKeyException e) { // 重復請求不再轉(zhuǎn)賬直接返回上一次的結果 return orderMapper.queryResult(orderNo); } // 2. 統(tǒng)一加鎖順序賬號字典序小的先鎖 String first cmd.getFrom().compareTo(cmd.getTo()) 0 ? cmd.getFrom() : cmd.getTo(); String second first.equals(cmd.getFrom()) ? cmd.getTo() : cmd.getFrom(); Account a accountMapper.lockByNo(first); // SELECT ... FOR UPDATE Account b accountMapper.lockByNo(second); if (a null || b null) { throw new BizException(賬戶不存在); } if (a.getStatus() ! 1 || b.getStatus() ! 1) { throw new BizException(賬戶狀態(tài)異常); } // 3. 金額比較用 compareToBigDecimal 的 equals 會比較 scale if (a.getBalance().compareTo(cmd.getAmount()) 0) { throw new BizException(余額不足); } // 4. 帶條件的扣款即便上面的判斷失效這里也扣不成負數(shù) int updated accountMapper.debit(cmd.getFrom(), cmd.getAmount()); if (updated ! 1) { throw new BizException(扣款失敗余額不足); } accountMapper.credit(cmd.getTo(), cmd.getAmount()); // 5. 兩條流水出賬一條、入賬一條各帶記賬后余額 flowMapper.insert(orderNo, cmd.getFrom(), 1, cmd.getAmount(), accountMapper.selectBalance(cmd.getFrom())); flowMapper.insert(orderNo, cmd.getTo(), 2, cmd.getAmount(), accountMapper.selectBalance(cmd.getTo())); orderMapper.markSuccess(orderNo); return TransferResult.success(orderNo); } }對應的 Mapper 里扣款語句必須帶條件這是余額不為負的最終保障!-- 扣款把判斷和更新合成一條語句消除檢查與執(zhí)行之間的窗口 -- update iddebit UPDATE account SET balance balance - #{amount}, updated_at NOW() WHERE account_no #{accountNo} AND balance gt; #{amount} /update !-- 入賬不需要條件加錢永遠安全 -- update idcredit UPDATE account SET balance balance #{amount}, updated_at NOW() WHERE account_no #{accountNo} /update邏輯說明第 1 步的冪等占位放在事務內(nèi)、業(yè)務操作之前讓重復請求在最早的地方被擋掉第 2 步的排序是關鍵它把“兩個事務互相等”這件事從根上消除第 4 步的updated ! 1判斷不能省它是把數(shù)據(jù)庫返回的影響行數(shù)當作業(yè)務信號用——影響 0 行說明條件不成立直接拋異?；貪L別硬著頭皮往下走。參數(shù)說明isolation Isolation.READ_COMMITTED是可選項MySQL 默認的可重復讀在這個場景下也能工作因為FOR UPDATE是當前讀。但讀已提交能讓鎖的持有范圍更小一些配合短事務更穩(wěn)。如果你的包用的是默認隔離級別別為了這一行去改先跑通再說。注意SELECT ... FOR UPDATE必須命中索引否則會退化成鎖全表。確認account_no上有唯一索引且執(zhí)行計劃是typeeq_ref或ref。3.3 隔離級別、鎖等待和連接池的三個參數(shù)代碼寫對了參數(shù)配錯一樣出事。這個包里我調(diào)整過三個值都比較關鍵。第一個是innodb_lock_wait_timeout默認 50 秒。轉(zhuǎn)賬這種短事務等 50 秒毫無意義只會把 Tomcat 線程和連接池一起拖死。改成 3 到 5 秒超時立刻失敗讓上游重試比干等強。-- 會話級先驗證確認無副作用后再寫進配置文件 SET SESSION innodb_lock_wait_timeout 5; SHOW VARIABLES LIKE innodb_lock_wait_timeout;第二個是 Spring 事務的timeout屬性單位秒。它和數(shù)據(jù)庫側的鎖等待超時是兩個層次的東西前者管整個事務方法的執(zhí)行時長后者只管等鎖。兩個都要設Transactional(timeout 10)配合數(shù)據(jù)庫 5 秒能保證事務不會因為某條慢 SQL 無限掛起。第三個是連接池大小。轉(zhuǎn)賬事務在高峰期同時占用連接數(shù)的上限就是池子的上限。池子太小會排隊太大會把數(shù)據(jù)庫打滿。經(jīng)驗值是從 10 到 20 起壓測時看HikariPool的activeConnections和pendingThreads后者長期大于 0 就說明該加但別超過數(shù)據(jù)庫max_connections的七成。還有一個參數(shù)常被忽略spring.datasource.hikari.connection-timeout默認 30 秒。轉(zhuǎn)賬接口的 RT 通常是幾十毫秒連接等待 30 秒沒有意義調(diào)到 3 秒左右讓過載快速失敗比雪崩好。4. 冪等與對賬重復提交、超時重試之后賬還對得上嗎真實場景里轉(zhuǎn)賬請求不會只來一次。用戶手抖點兩下、網(wǎng)關超時自動重試、上游消息重復投遞都會讓你的接口收到同一個業(yè)務請求的多份副本。冪等不是加分項是底線。而對賬是冪等失效時的兜底兩者一套組合才能說這個系統(tǒng)“賬是對的”。4.1 冪等占位用唯一索引搶鎖別用先查后插先查后插在并發(fā)下必然翻車因為查詢和插入之間存在窗口兩個線程可以同時查到“不存在”。正確做法是把判斷交給數(shù)據(jù)庫order_no上加唯一索引插入成功的那一個線程繼續(xù)執(zhí)行失敗的直接走重復請求分支。這就是常說的“用唯一約束做分布式鎖”。但這里有個 Spring 層面的坑要提前避開。如果冪等占位和業(yè)務操作在同一個事務里插入拋出的DuplicateKeyException被catch住了事務本身可能已經(jīng)被標記為 rollback-only后續(xù)任何操作都會在提交時炸掉報Transaction rolled back because it has been marked as rollback-only。不同版本的代理行為有差異穩(wěn)妥的做法是把占位插入放到獨立事務里。// 獨立事務占位失敗不影響外層捕獲異常后事務仍是干凈的 Transactional(propagation Propagation.REQUIRES_NEW, rollbackFor Exception.class) public boolean tryOccupy(String orderNo, TransferCmd cmd) { try { orderMapper.insertProcessing(orderNo, cmd.getFrom(), cmd.getTo(), cmd.getAmount()); return true; // 搶到了繼續(xù)轉(zhuǎn)賬 } catch (DuplicateKeyException e) { return false; // 沒搶到說明是重復請求 } }邏輯說明REQUIRES_NEW會掛起外層事務、新開一個插入失敗只影響這個內(nèi)層事務外層不受污染。返回false時外層直接查單據(jù)狀態(tài)返回結果不再執(zhí)行扣款。代價是多占一個連接所以這個方法必須極短不能在里面做任何查詢以外的事。參數(shù)說明propagation選REQUIRES_NEW而不是NESTED因為NESTED依賴保存點某些連接池和驅(qū)動下行為不一致。業(yè)務上還有個細節(jié)如果占位成功了但后面的轉(zhuǎn)賬失敗了單據(jù)狀態(tài)會停在 0處理中。這時不能簡單刪掉重來得靠后面的狀態(tài)機和對賬處理。4.2 狀態(tài)機與失敗補償0/1/2 三個狀態(tài)夠不夠單據(jù)表里我用了三個狀態(tài)0 處理中、1 成功、2 失敗。夠用但有前提——必須有一套任務去清理長期停在 0 的單據(jù)。處理中的單據(jù)意味著“占位成功但結果未知”?？赡艿脑虬ㄟM程被 kill、數(shù)據(jù)庫連接斷開、事務超時。這類單據(jù)不能直接判成功也不能直接判失敗正確姿勢是查流水如果account_flow里已經(jīng)有這筆order_no的兩條記錄說明錢動過了把狀態(tài)補成 1如果沒有說明事務回滾了補成 2。這個判斷依據(jù)流水而不是依據(jù)余額因為流水是只追加的事實。-- 清理僵尸單據(jù)30 分鐘前還是處理中且沒有任何流水 SELECT o.order_no FROM transfer_order o LEFT JOIN account_flow f ON f.order_no o.order_no WHERE o.status 0 AND o.created_at NOW() - INTERVAL 30 MINUTE GROUP BY o.order_no HAVING COUNT(f.id) 0;查到之后統(tǒng)一置為失敗并記錄原因。注意這條 SQL 要跑在只讀副本或者低峰期LEFT JOIN GROUP BY在單據(jù)量大時并不便宜加個時間范圍限定比如只掃最近三天。補償邏輯一定要做成可重復執(zhí)行的。定時任務重復跑、人工手動觸發(fā)、服務重啟補跑都可能發(fā)生。判斷依據(jù)永遠是“當前狀態(tài) 流水是否存在”而不是“上次跑到哪了”。4.3 對賬 SQL三條查詢把不平的賬撈出來對賬不需要寫代碼三條 SQL 基本能覆蓋課程設計和中小系統(tǒng)。第一條查單邊賬——單據(jù)成功但流水條數(shù)不對。-- 成功的單據(jù)流水必須正好兩條不等于 2 的就是單邊賬 SELECT o.order_no, o.amount, COUNT(f.id) AS flow_cnt FROM transfer_order o LEFT JOIN account_flow f ON f.order_no o.order_no WHERE o.status 1 GROUP BY o.order_no, o.amount HAVING COUNT(f.id) 2;第二條查金額不平——出賬和入賬金額必須相等差值不為零就是臟數(shù)據(jù)。-- 同一單據(jù)內(nèi)出賬金額 - 入賬金額 必須為 0 SELECT order_no, SUM(CASE WHEN direction 1 THEN amount ELSE -amount END) AS diff FROM account_flow GROUP BY order_no HAVING diff 0;第三條查余額斷裂——每條流水的balance_after應該等于上一筆的balance_after加減本筆金額賬戶表當前余額應等于最后一筆流水的balance_after。第三條 SQL 稍長思路是用窗口函數(shù)取上一行。-- 8.0 以上用 LAG 取上一筆余額驗證流水鏈是否連續(xù) WITH f AS ( SELECT account_no, id, direction, amount, balance_after, LAG(balance_after) OVER (PARTITION BY account_no ORDER BY id) AS prev_balance FROM account_flow ) SELECT * FROM f WHERE prev_balance IS NOT NULL AND balance_after prev_balance (CASE WHEN direction 2 THEN amount ELSE -amount END);三條查詢都返回空集才算這批數(shù)據(jù)是干凈的。前兩條可以隨時跑第三條在流水量大時要限賬戶否則窗口函數(shù)會掃全表。5. 避坑排查死鎖、負余額和“事務沒回滾”的五個現(xiàn)場這一章是我自己在跑這套代碼時踩到的五個現(xiàn)場按出現(xiàn)頻率排。每條都按“現(xiàn)象 → 原因 → 解決”寫癥狀描述盡量貼近你會在日志里看到的那行字。5.1 現(xiàn)象并發(fā)壓測幾分鐘后開始報 Deadlock found現(xiàn)象50 并發(fā)雙向轉(zhuǎn)賬前 30 秒正常之后日志里零星出現(xiàn)Deadlock found when trying to get lock; try restarting transaction接口返回 500重試后又能成功。原因兩個方向的事務加鎖順序相反。A→B 先鎖 AB→A 先鎖 B交叉等待形成環(huán)路。InnoDB 檢測到環(huán)路會主動殺掉代價小的那個事務被殺的拋出這個異常。另一個可能來源是SELECT ... FOR UPDATE沒走到account_no索引退化成鎖一批記錄甚至全表鎖范圍一大任何交叉都可能死鎖。解決按賬號字典序統(tǒng)一加鎖這是根本解。同時確認執(zhí)行計劃EXPLAIN SELECT * FROM account WHERE account_no ? FOR UPDATE;應該顯示typeconst或eq_ref。如果業(yè)務層無法保證順序比如批量代發(fā)把批量拆成單筆或者用SELECT ... FOR UPDATE時一次性按IN排序取回讓數(shù)據(jù)庫按索引順序加鎖而不是按IN列表順序。5.2 現(xiàn)象A 賬戶扣了錢B 賬戶沒收到單據(jù)狀態(tài)是成功現(xiàn)象對賬 SQL 查出單邊賬transfer_order狀態(tài)為 1但account_flow只有一條出賬記錄B 的余額沒變。原因入賬和出賬被拆到了兩個事務里。常見寫法是扣款方法加Transactional入賬方法也加然后 Service 里順序調(diào)用。兩個方法各自提交中間任何失敗都會留下半成品。另一種是同一種病在try-catch里把入賬的異常吞了只打了日志事務照常提交。解決一筆轉(zhuǎn)賬的所有數(shù)據(jù)庫寫操作必須在同一個事務邊界內(nèi)debit、credit、兩條流水、單據(jù)狀態(tài)更新全部由最外層的Transactional覆蓋。捕獲異常的地方只允許兩種處理要么原樣拋出觸發(fā)回滾要么記錄后拋出。任何“catch 了只打日志”的代碼都是定時炸彈。5.3 現(xiàn)象余額出現(xiàn)負數(shù)但業(yè)務校驗沒報錯現(xiàn)象定時對賬發(fā)現(xiàn)某賬戶balance -0.01查流水最后幾筆扣款都成功但當時余額已經(jīng)不夠了。原因先SELECT查余額判斷夠不夠再UPDATE扣款。兩個動作之間有窗口另一個事務插進來把余額花掉了你的判斷基于舊值扣款照常執(zhí)行。這是最經(jīng)典的檢查與使用分離問題TOCTOU。還有一種情況是CHECK (balance 0)在 5.7 上不生效應用層又沒做條件更新直接扣穿。解決把判斷寫進UPDATE的WHERE里也就是AND balance #{amount}靠影響行數(shù)判斷成敗。這比任何鎖都輕。再加數(shù)據(jù)庫CHECK兜底確認版本 8.0.16以及一條每日巡檢 SQL查balance 0的賬戶哪怕理論上不可能也要讓它報警。5.4 現(xiàn)象Transactional明明加了拋異常后數(shù)據(jù)還是落庫了現(xiàn)象故意在轉(zhuǎn)賬后拋RuntimeException期望回滾結果余額被改了單據(jù)也變成成功了。原因五種常見失效場景——方法不是publicSpring 代理攔不到同一個類里this.method()自調(diào)用走不到代理異常被catch后沒重新拋拋的是受檢異常而沒配rollbackFor類沒有被 Spring 管理自己new出來的對象。這五種現(xiàn)象一樣、原因各異排查時按這個順序?qū)?。解決自調(diào)用場景把方法拆到另一個 Bean受檢異常統(tǒng)一配rollbackFor Exception.class類上加Service且確保包掃描覆蓋最省事的驗證方式是在事務方法里手動拋一次異?？磾?shù)據(jù)庫有沒有變化兩分鐘能排掉大部分疑慮。提示調(diào)試事務是否生效把日志級別開到logging.level.org.springframework.transactionDEBUG能看到Creating new transaction/Rolling back這類關鍵行比讀代碼快。5.5 現(xiàn)象對賬差一分錢反復對數(shù)都對不上現(xiàn)象總額守恒的校驗差 0.01逐個賬戶查又都能對上只有某些涉及手續(xù)費的記錄不平。原因double參與金額計算。0.1 0.2在二進制浮點里不等于0.3這個誤差會在多次累加后變成一分錢。另一種原因是在中間步驟就setScale四舍五入每步都舍一次誤差累積。還有一種BigDecimal.equals()比較時把scale也比了1.0和1.00判不相等導致校驗邏輯誤判。解決金額全程BigDecimal且只用字符串構造new BigDecimal(0.01)絕不用new BigDecimal(0.01)。比較用compareTo() 0。舍入只在最終落庫那一刻做一次setScale(2, RoundingMode.HALF_UP)。手續(xù)費在什么環(huán)節(jié)扣、按什么基數(shù)算寫進注釋別靠人記。6. 壓測驗證用 200 并發(fā)和三條斷言驗收賬平不平跑通單筆轉(zhuǎn)賬只能說明代碼能編譯驗證賬對不對還得靠并發(fā)。我一般會寫個最土的壓測腳本先制造混亂再用斷言收口比看一堆日志有說服力。#!/usr/bin/env bash # 200 個并發(fā)請求每個請求單號唯一同時故意發(fā) 50 個重復單號試冪等 BASEhttp://localhost:8080/api/transfer seq 1 200 | xargs -P 50 -I{} curl -s -o /dev/null -w %{http_code}\n \ -X POST $BASE \ -H Content-Type: application/json \ -d {\orderNo\:\T20240{}\,\from\:\ACC0001\,\to\:\ACC0002\,\amount\:\1.00\} # 冪等驗證同一個單號打 50 次最終只應有一條單據(jù)、兩條流水 seq 1 50 | xargs -P 50 -I{} curl -s -o /dev/null \ -X POST $BASE \ -H Content-Type: application/json \ -d {orderNo:IDEMPOTENT-001,from:ACC0003,to:ACC0004,amount:2.00}腳本里-P 50是并發(fā)度-w %{http_code}把狀態(tài)碼打出來方便統(tǒng)計失敗率。跑完先看接口層200 個請求里成功多少、超時多少、5xx 多少。低于 95% 成功率就先去查鎖等待和連接池別急著分析數(shù)據(jù)。數(shù)據(jù)層的驗收是三條斷言全過才算這套實現(xiàn)站得住。-- 斷言一總額守恒轉(zhuǎn)賬不創(chuàng)造也不銷毀錢 SELECT SUM(balance) AS total_after FROM account; -- 應等于壓測前記錄的初始總額 -- 斷言二成功單據(jù)的流水凈額必須為 0 SELECT order_no, SUM(CASE WHEN direction 1 THEN amount ELSE -amount END) AS diff FROM account_flow GROUP BY order_no HAVING diff 0; -- 斷言三冪等單號只被真正執(zhí)行一次 SELECT COUNT(*) AS flow_cnt FROM account_flow WHERE order_no IDEMPOTENT-001; -- 應為 2斷言一是最硬的那條。壓測前后各跑一次兩個數(shù)字必須完全相等差一分都說明有事務沒回滾干凈或者有寫入繞過了流水。斷言二驗證每筆單據(jù)內(nèi)部平衡斷言三驗證冪等占位是否真的擋住了 49 次重復請求。觀測指標建議同時盯住四個用一張表記下來比憑感覺判斷靠譜。指標從哪看健康區(qū)間異常時先查TPS壓測工具匯總穩(wěn)定不抖連接池、慢 SQLP99 響應時間壓測工具匯總小于鎖等待超時的一半innodb_lock_wait_timeout死鎖次數(shù)SHOW ENGINE INNODB STATUS\G的 LATEST DETECTED DEADLOCK0加鎖順序、索引命中活躍連接數(shù)Hikari 的activeConnections小于池上限的 80%事務是否過長這套流程我現(xiàn)在每次改完轉(zhuǎn)賬相關代碼都會完整走一遍哪怕只是把一個SELECT改成UPDATE。因為“看起來等價”的改動在并發(fā)下經(jīng)常不等價而賬目類的 bug 一旦上線損失的不是性能而是可信度。上面這些建表語句、Service 骨架和對賬 SQL 都來自這份模擬銀行賬戶轉(zhuǎn)賬系統(tǒng)的源碼包改一改就能塞進自己的課程設計或者業(yè)務模塊里跑起來先從單筆跑通再上并發(fā)腳本別跳步。希望幫到你。本文還有配套的精品資源點擊獲取