簡(jiǎn)介Java銀行管理系統(tǒng)是一份基于Java的綜合性課程實(shí)驗(yàn)項(xiàng)目資源面向Java初學(xué)者及正在學(xué)習(xí)面向?qū)ο缶幊?、軟件工程的學(xué)生用于理解賬戶管理、存取款、轉(zhuǎn)賬、利息計(jì)算等銀行核心業(yè)務(wù)的實(shí)現(xiàn)方式。壓縮包共7個(gè)文件包含源碼java文件、編譯后的class文件以及Eclipse工程配置.project、.classpath、.prefs整體僅8KB適合作為小型教學(xué)案例快速導(dǎo)入IDE運(yùn)行學(xué)習(xí)。目前已有763人學(xué)習(xí)下載。項(xiàng)目雖小但覆蓋了Account類的設(shè)計(jì)、存款取款、轉(zhuǎn)賬、余額查詢等典型模塊可幫助讀者掌握類結(jié)構(gòu)、方法封裝、異常處理及基礎(chǔ)數(shù)據(jù)持久化思路若進(jìn)一步擴(kuò)展還可涉及并發(fā)控制、SQL注入防范等安全性議題。整體上是一份麻雀雖小五臟俱全的Java入門實(shí)踐參考既能鞏固課堂理論也能為后續(xù)開(kāi)發(fā)更完整的業(yè)務(wù)系統(tǒng)打下基礎(chǔ)。1. Java銀行管理系統(tǒng)從學(xué)生項(xiàng)目到可落地的分層架構(gòu)做Java銀行管理系統(tǒng)的人多半繞不開(kāi)一個(gè)尷尬代碼跑通了演示完了交差了但心里清楚這系統(tǒng)拿不出手。我在某次接手一個(gè)模擬項(xiàng)目X的銀行系統(tǒng)時(shí)就遇到過(guò)這種狀態(tài)——登錄、開(kāi)戶、存取款都能跑一進(jìn)并發(fā)測(cè)試就翻車余額對(duì)不上連接池直接打滿。后來(lái)花了兩周重構(gòu)整個(gè)工程結(jié)構(gòu)才把常見(jiàn)學(xué)生項(xiàng)目的“單類打天下”改成真正能維護(hù)的分層架構(gòu)。這篇筆記就是用那次重構(gòu)的視角來(lái)拆解從工程骨架、數(shù)據(jù)庫(kù)設(shè)計(jì)到鑒權(quán)、事務(wù)和排錯(cuò)按落地順序走一遍。你可能是剛?cè)腴T的初學(xué)者也可能是準(zhǔn)備做課程設(shè)計(jì)的在校生這套思路能幫你把“能演示的項(xiàng)目”升級(jí)成“經(jīng)得起問(wèn)的項(xiàng)目”。2. 工程骨架與數(shù)據(jù)庫(kù)設(shè)計(jì)先說(shuō)清楚表和連接池怎么定2.1 三層架構(gòu)職責(zé)劃分dao、service、web各自管什么常見(jiàn)的翻車寫(xiě)法是把JDBC代碼、業(yè)務(wù)判斷、Servlet請(qǐng)求處理全塞進(jìn)一個(gè)類看起來(lái)熱鬧后續(xù)每個(gè)功能都要改這一個(gè)類。我在某高校項(xiàng)目里見(jiàn)過(guò)一個(gè)核心類超過(guò)三千行的版本加個(gè)字段要滾動(dòng)半天。做這個(gè)銀行管理系統(tǒng)時(shí)我用的標(biāo)準(zhǔn)三層web層只做參數(shù)接收、封裝請(qǐng)求對(duì)象、調(diào)用service、響應(yīng)結(jié)果service層負(fù)責(zé)業(yè)務(wù)規(guī)則比如余額是否充足、賬戶是否凍結(jié)、轉(zhuǎn)賬是否在同一個(gè)事務(wù)dao層只做SQL的增刪改查不寫(xiě)if else邏輯這樣分層帶來(lái)的直接好處是session校驗(yàn)、數(shù)據(jù)庫(kù)操作、業(yè)務(wù)判斷可以分別測(cè)試后面換數(shù)據(jù)庫(kù)或者改頁(yè)面時(shí)不用動(dòng)業(yè)務(wù)代碼。Controller里出現(xiàn)的SQL語(yǔ)句本身就是個(gè)設(shè)計(jì)味道很重的信號(hào)。2.2 建表SQL與字段陷阱賬戶表、客戶表、流水表怎么設(shè)計(jì)先把三張核心表和字段寫(xiě)下來(lái)這是整個(gè)系統(tǒng)里最需要先想清楚的部分后續(xù)的查詢性能、對(duì)賬邏輯都在這一步?jīng)Q定。-- 客戶表 CREATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, id_card VARCHAR(18) NOT NULL UNIQUE COMMENT 身份證號(hào)邏輯唯一, name VARCHAR(32) NOT NULL, phone VARCHAR(11) DEFAULT NULL, address VARCHAR(128) DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 賬戶表 CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_no VARCHAR(19) NOT NULL UNIQUE COMMENT 卡號(hào)長(zhǎng)度要預(yù)留, customer_id BIGINT NOT NULL, balance DECIMAL(14,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-正常 0-凍結(jié), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_account_customer FOREIGN KEY (customer_id) REFERENCES customer(id), KEY idx_customer_id (customer_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 交易流水表 CREATE TABLE transaction_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, trans_no VARCHAR(32) NOT NULL UNIQUE COMMENT 流水號(hào)格式見(jiàn)下, account_id BIGINT NOT NULL, trans_type TINYINT NOT NULL COMMENT 1-存款 2-取款 3-轉(zhuǎn)賬, amount DECIMAL(14,2) NOT NULL, balance_after DECIMAL(14,2) NOT NULL COMMENT 交易后余額對(duì)賬用, target_account_id BIGINT DEFAULT NULL COMMENT 轉(zhuǎn)賬目標(biāo)賬戶, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_account_created (account_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段設(shè)計(jì)上有幾個(gè)地方要特別注意都是踩過(guò)坑才改出來(lái)的余額字段必須用DECIMAL不能用double或float。二進(jìn)制浮點(diǎn)數(shù)存金額會(huì)出現(xiàn)0.10.2不等于0.3的經(jīng)典問(wèn)題銀行系統(tǒng)一旦出現(xiàn)分位對(duì)不上賬等于直接報(bào)廢。account_no直接用19位字符串而不是自增id。因?yàn)榭ㄌ?hào)可能以特定數(shù)字開(kāi)頭比如銀行卡常見(jiàn)的62開(kāi)頭自增id無(wú)法滿足這種業(yè)務(wù)前綴。同時(shí)它作為業(yè)務(wù)維度唯一標(biāo)識(shí)和數(shù)據(jù)庫(kù)主鍵解耦。transaction_log里必須保存balance_after這個(gè)字段是交易后余額的快照。后續(xù)排查問(wèn)題時(shí)如果賬戶余額和流水對(duì)不上直接按時(shí)間順序重放流水就能定位是哪一筆出了問(wèn)題。2.3 JDBC連接池與配置參數(shù)Druid連接池參數(shù)怎么設(shè)很多初學(xué)者用DriverManager.getConnection()每次請(qǐng)求都新建連接幾百個(gè)并發(fā)就能把數(shù)據(jù)庫(kù)連接打滿。我用的是阿里的Druid連接池配置如下# druid.properties driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/bank_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai usernamebank_user passwordbank_pass_123 initialSize5 maxActive30 minIdle5 maxWait60000 validationQuerySELECT 1 testWhileIdletrue timeBetweenEvictionRunsMillis60000關(guān)鍵參數(shù)說(shuō)明initialSize5啟動(dòng)時(shí)預(yù)建5個(gè)連接避免第一個(gè)請(qǐng)求來(lái)臨時(shí)建連讓首次訪問(wèn)慢半拍maxActive30最大活躍連接數(shù)超過(guò)這個(gè)數(shù)會(huì)排隊(duì)等待。設(shè)太小容易打滿設(shè)太大數(shù)據(jù)庫(kù)本身扛不住30對(duì)中小項(xiàng)目夠用maxWait60000拿不到連接時(shí)的最大等待時(shí)間超過(guò)就拋異常避免線程無(wú)限掛死validationQuerySELECT 1每次從池里拿連接前先驗(yàn)證可用性防止拿到已經(jīng)被數(shù)據(jù)庫(kù)斷開(kāi)的死連接連接池的獲取和歸還必須配套。我用一個(gè)工具類封裝DAO層拿完連接后必須關(guān)閉連接但關(guān)閉的是歸還連接池而不是真正斷開(kāi)這是連接池的實(shí)現(xiàn)機(jī)制。有的同學(xué)在finally塊里忘記調(diào)用close方法跑一個(gè)晚上連接池就爆了。數(shù)據(jù)源的初始化位置我一般放在ServletContextListener里做應(yīng)用啟動(dòng)時(shí)初始化一次比每次請(qǐng)求時(shí)new DataSource()要合理得多。2.4 配置文件加載失敗調(diào)試classpath與路徑問(wèn)題第一次跑這個(gè)配置時(shí)最容易遇到的就是Properties.load()讀不到文件。常見(jiàn)原因是配置文件放在了src/main/java目錄下和Java源碼混在一起編譯后文件在target/classes里能找到但在IDE里看到的是源碼目錄。正確做法是放在src/main/resources目錄下然后用如下方式加載InputStream in DruidUtil.class.getClassLoader().getResourceAsStream(druid.properties);這里有個(gè)細(xì)節(jié)getResourceAsStream返回null時(shí)Properties.load會(huì)直接拋NullPointerException而且報(bào)錯(cuò)信息里根本不說(shuō)是文件找不到。排查方法是先判斷in是否為null打印當(dāng)前classpath路徑看一眼。我遇到過(guò)在某IDE里運(yùn)行正常、打成war包后就報(bào)錯(cuò)的情況多半是打包時(shí)漏了配置文件。3. 登錄鑒權(quán)與角色權(quán)限Session怎么管、密碼怎么存3.1 MD5加鹽與迭代哈希密碼不能明文存很多初學(xué)者在數(shù)據(jù)庫(kù)里直接存明文密碼登錄時(shí)拿輸入值和數(shù)據(jù)庫(kù)比對(duì)。這在學(xué)習(xí)項(xiàng)目里能用一旦被拖庫(kù)所有賬號(hào)全暴露。我在重構(gòu)時(shí)用加鹽MD5SHA-256在密碼存儲(chǔ)和哈希速度上的表現(xiàn)差異較小MD5加鹽配合多次迭代足夠應(yīng)付課程設(shè)計(jì)和中低安全需求的場(chǎng)景。public class PasswordUtil { private static final String SALT bank_sys_static_salt; public static String hashPassword(String rawPassword) { String saltPassword rawPassword SALT; // 迭代3次降低暴力破解速度 String hashed saltPassword; for (int i 0; i 3; i) { hashed md5(hashed); } return hashed; } private static String md5(String input) { // 標(biāo)準(zhǔn)MessageDigest實(shí)現(xiàn)返回32位十六進(jìn)制字符串 } }這里說(shuō)明一下設(shè)計(jì)取舍。靜態(tài)鹽SALT寫(xiě)死在代碼里好處是用戶表里不需要單獨(dú)存鹽字段查詢簡(jiǎn)單壞處是如果源碼泄漏所有用戶的哈希值都可以被預(yù)先計(jì)算。真實(shí)生產(chǎn)環(huán)境會(huì)給每個(gè)用戶生成隨機(jī)鹽存在庫(kù)里。對(duì)于課程設(shè)計(jì)和中小系統(tǒng)靜態(tài)鹽加多次迭代能在易用性和安全性之間取平衡。3.2 Session管理與登錄攔截器會(huì)話過(guò)期和權(quán)限失效登錄成功后把用戶信息放Session再寫(xiě)一個(gè)攔截器對(duì)所有受保護(hù)頁(yè)面做過(guò)濾。我用的是Servlet Filter不需要額外引入框架也能達(dá)到目標(biāo)public class LoginFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; HttpSession session req.getSession(false); if (session null || session.getAttribute(currentUser) null) { resp.sendRedirect(req.getContextPath() /login.jsp); return; } chain.doFilter(request, response); } }注意點(diǎn)有三個(gè)一是req.getSession(false)和req.getSession()的區(qū)別。帶false表示拿不到就不創(chuàng)建避免惡意請(qǐng)求大量觸發(fā)session創(chuàng)建。不帶參數(shù)的寫(xiě)法是如果沒(méi)有session就新建一個(gè)配合攔截器邏輯判斷時(shí)會(huì)產(chǎn)生問(wèn)題。二是過(guò)濾器的映射范圍。在web.xml里把需要登錄才能訪問(wèn)的路徑全部包進(jìn)去比如/account/、/transaction/。千萬(wàn)別用/*全包否則login.jsp本身也會(huì)被攔截形成死循環(huán)。三是Session超時(shí)web.xml里配置session-config session-timeout30/session-timeout /session-config30分鐘沒(méi)操作自動(dòng)失效。調(diào)試時(shí)這個(gè)超時(shí)會(huì)經(jīng)常打斷流程可以先把時(shí)間調(diào)長(zhǎng)一點(diǎn)功能跑通后再改回來(lái)。3.3 角色權(quán)限柜員與管理員的操作邊界銀行系統(tǒng)里角色通常分兩種柜員處理日常業(yè)務(wù)管理員查流水、凍結(jié)賬戶。實(shí)現(xiàn)方式是登錄后在Session里存role字段在業(yè)務(wù)方法里用權(quán)限校驗(yàn)工具類判斷public class PermissionUtil { public static void checkAdmin(HttpSession session) throws PermissionDeniedException { Integer role (Integer) session.getAttribute(currentRole); if (role null || role ! Roles.ADMIN) { throw new PermissionDeniedException(需要管理員權(quán)限); } } }以前權(quán)限判斷最容易出問(wèn)題的點(diǎn)在頁(yè)面按鈕顯隱上。前端隱藏一個(gè)按鈕不等于后端安全直接構(gòu)造請(qǐng)求URL就能繞過(guò)頁(yè)面調(diào)接口。后來(lái)我把權(quán)限校驗(yàn)下沉到Service層每個(gè)關(guān)鍵操作先校驗(yàn)再執(zhí)行頁(yè)面上的隱藏只是體驗(yàn)優(yōu)化不是安全控制。這是從學(xué)生思維到工程思維的一個(gè)關(guān)鍵轉(zhuǎn)變。4. 存款取款與轉(zhuǎn)賬的業(yè)務(wù)閉環(huán)事務(wù)邊界和并發(fā)扣款4.1 存款業(yè)務(wù)事務(wù)邊界和余額校驗(yàn)存取款的業(yè)務(wù)邏輯看起來(lái)簡(jiǎn)單實(shí)際上有四個(gè)環(huán)節(jié)都要做對(duì)事務(wù)開(kāi)啟、余額校驗(yàn)、更新賬戶、寫(xiě)流水。缺一個(gè)系統(tǒng)都會(huì)在對(duì)賬時(shí)暴露問(wèn)題。public void deposit(Long accountId, BigDecimal amount) { String sql UPDATE account SET balance balance ? WHERE id ? AND status 1; // 執(zhí)行更新返回受影響行數(shù) // 如果行數(shù)為0說(shuō)明賬戶不存在或已凍結(jié) }這里有個(gè)細(xì)節(jié)把balance從庫(kù)里查出來(lái)然后在Java里加好再寫(xiě)回存在并發(fā)覆蓋問(wèn)題。兩條線程同時(shí)讀到100都加上50后提交的會(huì)把先提交的覆蓋。所以我用UPDATE的原子操作直接在SQL語(yǔ)句層面完成加減數(shù)據(jù)庫(kù)的行鎖會(huì)保證同一時(shí)間只有一筆操作能成功修改這個(gè)賬戶。存款流程結(jié)束后必須寫(xiě)流水。流水表里存balance_after方便后續(xù)對(duì)賬。寫(xiě)流水和更新余額這兩個(gè)動(dòng)作必須在同一個(gè)事務(wù)里否則會(huì)出現(xiàn)余額變了但流水沒(méi)記錄的臟數(shù)據(jù)。4.2 轉(zhuǎn)賬跨賬戶事務(wù)和并發(fā)控制轉(zhuǎn)賬比存款復(fù)雜在涉及兩個(gè)賬戶事務(wù)跨度更大。經(jīng)典轉(zhuǎn)賬代碼長(zhǎng)這樣Transactional(rollbackFor Exception.class) public void transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) { // 1. 扣減轉(zhuǎn)出賬戶 int fromResult accountDao.deductBalance(fromAccountId, amount); if (fromResult 0) { throw new BusinessException(余額不足或賬戶異常); } // 2. 增加轉(zhuǎn)入賬戶 accountDao.increaseBalance(toAccountId, amount); // 3. 記錄轉(zhuǎn)出流水 accountDao.insertTransLog(fromAccountId, 3, amount.negate(), fromAccountId); // 4. 記錄轉(zhuǎn)入流水 accountDao.insertTransLog(toAccountId, 3, amount, fromAccountId); }最隱蔽的問(wèn)題是事務(wù)什么時(shí)候真正提交。在Spring管理下方法執(zhí)行完才提交如果步驟2或3拋異常步驟1的扣減會(huì)回滾不會(huì)出現(xiàn)扣了錢對(duì)方?jīng)]收到的情況。但如果你用的是原生JDBC沒(méi)有事務(wù)控制步驟1執(zhí)行完提交了步驟2失敗資金憑空消失。另外accountDao.deductBalance的SQL里必須帶balance ?條件UPDATE account SET balance balance - ? WHERE id ? AND balance ? AND status 1這樣做的目的是讓余額判斷和扣減操作合在一個(gè)原子SQL里避免“查出來(lái)判斷夠了再更新”兩步之間的并發(fā)窗口。數(shù)據(jù)庫(kù)層面行鎖同時(shí)只能一個(gè)事務(wù)更新這條記錄后面的更新發(fā)現(xiàn)余額不夠會(huì)直接返回0行代碼里據(jù)此拋出異常。4.3 流水號(hào)生成時(shí)間戳隨機(jī)數(shù)的實(shí)現(xiàn)方案流水號(hào)需要業(yè)務(wù)可讀、盡量唯一方便排查問(wèn)題。我用的方案是String transNo T System.currentTimeMillis() String.format(%04d, new Random().nextInt(10000));這個(gè)方案在單機(jī)低并發(fā)下夠用但注意Random生成的4位數(shù)在高并發(fā)下可能碰撞。后來(lái)我改成用數(shù)據(jù)庫(kù)自增id做前綴拼接// 插入流水記錄拿到自增id Long id transLogDao.insertAndReturnId(...); String transNo T id System.currentTimeMillis();這樣流水號(hào)一定唯一因?yàn)閿?shù)據(jù)庫(kù)自增id不會(huì)重復(fù)。這個(gè)方案的好處還在于如果業(yè)務(wù)上要做冪等控制可以直接用這個(gè)流水號(hào)作為去重鍵。4.4 查詢優(yōu)化交易流水分頁(yè)與索引使用交易流水表數(shù)據(jù)量增長(zhǎng)很快如果不在account_id和created_at上建索引按用戶查歷史流水會(huì)全表掃描。前面建表SQL里已經(jīng)加了idx_account_created組合索引查詢時(shí)用SELECT * FROM transaction_log WHERE account_id ? ORDER BY created_at DESC LIMIT ?, ?這里有一件容易忽視的事分頁(yè)頁(yè)數(shù)過(guò)大會(huì)導(dǎo)致深度分頁(yè)性能下降。LIMIT 100000, 20這樣的寫(xiě)法數(shù)據(jù)庫(kù)要先掃描前面十萬(wàn)條記錄再丟棄。當(dāng)數(shù)據(jù)量真的大起來(lái)時(shí)我一般會(huì)改成基于上次查詢的最后一筆流水id做游標(biāo)分頁(yè)也就是WHERE id ? ORDER BY id DESC LIMIT 20但課程設(shè)計(jì)階段用LIMIT offset的方式夠用。5. 常見(jiàn)問(wèn)題與避坑連接泄漏、浮點(diǎn)精度和并發(fā)覆蓋5.1 連接池連接被耗盡getConnection后忘了關(guān)閉現(xiàn)象系統(tǒng)運(yùn)行一段時(shí)間后所有請(qǐng)求都卡在拿連接上日志報(bào)Connection is not available, request timed out。原因DA0層代碼里使用了Connection con JDBCUtil.getConnection()但finally塊里沒(méi)有調(diào)用con.close()或者寫(xiě)成了con.close()后System.exit(0)。連接沒(méi)有歸還連接池池里的連接被耗盡。最典型的場(chǎng)景是異常路徑上沒(méi)有close比如SQLException拋出前忘記釋放。解決用try-with-resources語(yǔ)法連接相關(guān)的語(yǔ)句全包在里面不需要手動(dòng)finally。Java 7之后Connection實(shí)現(xiàn)了AutoCloseable接口這樣寫(xiě)既美觀又不會(huì)漏try (Connection con JDBCUtil.getConnection(); PreparedStatement ps con.prepareStatement(sql)) { ps.setLong(1, id); ResultSet rs ps.executeQuery(); } catch (SQLException e) { log.error(query failed, e); }注意ResultSet不能放try里因?yàn)樗蕾嘢tatementStatement關(guān)了它就不能用了。只在try內(nèi)部使用不手動(dòng)關(guān)閉。5.2 余額對(duì)不上賬用了浮點(diǎn)類型或事務(wù)缺commit現(xiàn)象某個(gè)賬戶存取款幾次后余額和流水表重算出來(lái)的金額不一樣差的金額是幾分錢。原因在Java代碼里用了double類型傳金額數(shù)據(jù)庫(kù)字段也建成了double。浮點(diǎn)數(shù)在二進(jìn)制里無(wú)法精確表示0.1、0.2這樣的十進(jìn)制小數(shù)導(dǎo)致計(jì)算結(jié)果出現(xiàn)0.30000000000000004。另一個(gè)原因是手動(dòng)事務(wù)里執(zhí)行了connection.commit()只在成功路徑上異常路徑?jīng)]有回滾。解決Java側(cè)所有金額相關(guān)變量用BigDecimal數(shù)據(jù)庫(kù)字段在首次建表時(shí)就固定為DECIMAL(14,2)。BigDecimal構(gòu)造時(shí)用字符串構(gòu)造器new BigDecimal(19.99)不要用new BigDecimal(19.99)后者依然有精度問(wèn)題。事務(wù)上把commit和rollback統(tǒng)一放finally塊里做判斷try { // 業(yè)務(wù)操作 con.commit(); } catch (SQLException e) { con.rollback(); } finally { con.close(); }5.3 時(shí)間精度丟失created_at默認(rèn)值忽略毫秒現(xiàn)象同一秒內(nèi)多筆交易流水表里created_at完全一樣導(dǎo)致查不出先后順序?qū)~時(shí)無(wú)法分辨哪筆在前。原因數(shù)據(jù)庫(kù)字段默認(rèn)值是CURRENT_TIMESTAMP但它默認(rèn)精度到秒毫秒被舍掉。在高頻交易場(chǎng)景下同一秒內(nèi)會(huì)有多筆記錄。解決建表時(shí)把時(shí)間字段定義為DATETIME(3)配合DEFAULT CURRENT_TIMESTAMP(3)。Java側(cè)用LocalDateTime.now()傳入時(shí)注意類型匹配。如果已經(jīng)建好了表用ALTER TABLE transaction_log MODIFY created_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3)來(lái)改。5.4 并發(fā)扣款覆蓋余額判斷和扣減分離導(dǎo)致超扣現(xiàn)象兩個(gè)線程同時(shí)讀取余額100各自判斷可以扣80同時(shí)提交后余額變成20而不是預(yù)期的正確值甚至變成負(fù)數(shù)。原因查詢余額和更新余額是兩個(gè)獨(dú)立步驟沒(méi)有放在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)里也沒(méi)有使用行鎖保護(hù)。兩個(gè)請(qǐng)求并發(fā)執(zhí)行時(shí)同時(shí)讀到舊值然后分別寫(xiě)回先寫(xiě)回的被后寫(xiě)回覆蓋。解決用UPDATE ... WHERE balance ?原子操作替代兩步邏輯。數(shù)據(jù)庫(kù)行級(jí)鎖會(huì)讓第二個(gè)UPDATE等待第一個(gè)事務(wù)提交后執(zhí)行此時(shí)余額已不滿足條件返回0行業(yè)務(wù)代碼拋異常。這是并發(fā)扣款場(chǎng)景的標(biāo)準(zhǔn)做法。5.5 Session失效但頁(yè)面還顯示登錄態(tài)現(xiàn)象用戶明明已經(jīng)退出登錄按瀏覽器后退按鈕還能看到之前頁(yè)面數(shù)據(jù)或者session超時(shí)后直接操作某個(gè)功能按鈕報(bào)NullPointerException。原因前端頁(yè)面緩存了動(dòng)態(tài)數(shù)據(jù)沒(méi)有在請(qǐng)求時(shí)重新校驗(yàn)session。瀏覽器后退時(shí)可能從本地cache加載頁(yè)面不發(fā)起請(qǐng)求。后端從session取用戶信息時(shí)沒(méi)有判斷null。解決在web.xml里給受保護(hù)頁(yè)面配置禁止瀏覽器緩存的響應(yīng)頭filter filter-nameNoCacheFilter/filter-name /filter !-- 對(duì)應(yīng)過(guò)濾器里設(shè)置 -- response.setHeader(Cache-Control, no-cache, no-store, must-revalidate);后端取Session屬性時(shí)統(tǒng)一用工具類如果取出來(lái)是null直接跳轉(zhuǎn)到登錄頁(yè)而不是讓NullPointerException冒泡到用戶界面。調(diào)試session問(wèn)題時(shí)先在瀏覽器開(kāi)發(fā)者工具的Network面板里看響應(yīng)頭有沒(méi)有清晰的緩存控制標(biāo)識(shí)。6. 收尾驗(yàn)證用單元測(cè)試和壓測(cè)腳本給項(xiàng)目兜底6.1 Service層單元測(cè)試用Mock數(shù)據(jù)驗(yàn)證事務(wù)回滾功能代碼寫(xiě)完只代表邏輯存在不代表邏輯正確。我給轉(zhuǎn)賬寫(xiě)了一個(gè)JUnit單元測(cè)試。沒(méi)有測(cè)試框架的可以用一個(gè)main方法調(diào)Service邏輯測(cè)試建議用JUnit加H2內(nèi)存庫(kù)做集成驗(yàn)證。public class TransferServiceTest { private TransferService transferService new TransferService(); Test public void testTransfer_InsufficientBalance() { Long fromId 1L; Long toId 2L; BigDecimal amount new BigDecimal(9999999.00); // 斷言拋出余額不足異常 assertThrows(BusinessException.class, () - { transferService.transfer(fromId, toId, amount); }); // 斷言轉(zhuǎn)出賬戶余額沒(méi)變 BigDecimal fromBalance accountDao.getBalance(fromId); assertEquals(new BigDecimal(1000.00), fromBalance); } }這個(gè)測(cè)試驗(yàn)證的是最核心的邊界轉(zhuǎn)賬失敗時(shí)轉(zhuǎn)出賬戶余額不能有動(dòng)靜。如果斷言通過(guò)事務(wù)回滾是生效的。我每次改business邏輯都先跑一遍這些測(cè)試再手動(dòng)點(diǎn)頁(yè)面效率高很多。6.2 手工壓測(cè)驗(yàn)證并發(fā)安全關(guān)鍵的并發(fā)場(chǎng)景模擬可以用一個(gè)簡(jiǎn)單的腳本程序來(lái)驗(yàn)證前面提到的并發(fā)扣款問(wèn)題。用Java的線程池模擬多用戶同時(shí)取款public class ConcurrentWithdrawTest { public static void main(String[] args) throws Exception { int threadCount 10; ExecutorService pool Executors.newFixedThreadPool(threadCount); CountDownLatch start new CountDownLatch(1); AccountDao accountDao new AccountDao(); for (int i 0; i threadCount; i) { pool.submit(() - { try { start.await(); accountDao.withdraw(1L, new BigDecimal(50.00)); } catch (Exception e) { System.out.println(失敗: e.getMessage()); } }); } start.countDown(); pool.shutdown(); } }如果賬戶初始余額10010個(gè)線程各取50正確結(jié)果應(yīng)該是最多2個(gè)成功其余全部失敗。跑完后查詢數(shù)據(jù)庫(kù)余額確認(rèn)是0而不是負(fù)數(shù)說(shuō)明原子更新SQL生效了。我通常會(huì)把并發(fā)數(shù)調(diào)到線程池峰值再調(diào)大一倍看數(shù)據(jù)庫(kù)連接池是否會(huì)撐爆。跑一次這個(gè)測(cè)試比自己改半天代碼防并發(fā)更直觀。6.3 收尾的驗(yàn)證清單最后我有一套固定流程先把數(shù)據(jù)庫(kù)重置成初始數(shù)據(jù)啟動(dòng)服務(wù)走一遍開(kāi)戶、存款、取款、轉(zhuǎn)賬、查詢流水全流程然后把并發(fā)線程調(diào)大再跑一遍確認(rèn)余額不出負(fù)數(shù)、流水不丟不重最后把連接池的maxActive調(diào)到2模擬資源緊張環(huán)境看系統(tǒng)是否會(huì)拋出可讀的異常而不是長(zhǎng)時(shí)間掛死。這套流程走完我才有底氣把項(xiàng)目交付出去。之前的項(xiàng)目在一次演示時(shí)當(dāng)場(chǎng)翻車——轉(zhuǎn)賬后余額憑空少了50塊錢現(xiàn)場(chǎng)改代碼的狼狽樣子現(xiàn)在還記得。從那以后每次做銀行類項(xiàng)目我都強(qiáng)制走一遍并發(fā)測(cè)試和事務(wù)回滾驗(yàn)證別指望手動(dòng)點(diǎn)多幾個(gè)按鈕就能覆蓋邊界條件。希望這次拆解對(duì)你有幫助把該繞的坑提前繞過(guò)去。本文還有配套的精品資源點(diǎn)擊獲取