簡(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ù)開發(fā)更完整的業(yè)務(wù)系統(tǒng)打下基礎(chǔ)。1. Java銀行管理系統(tǒng)從學(xué)生項(xiàng)目到可落地的分層架構(gòu)做Java銀行管理系統(tǒng)的人多半繞不開一個(gè)尷尬代碼跑通了演示完了交差了但心里清楚這系統(tǒng)拿不出手。我在某次接手一個(gè)模擬項(xiàng)目X的銀行系統(tǒng)時(shí)就遇到過這種狀態(tài)——登錄、開戶、存取款都能跑一進(jìn)并發(fā)測(cè)試就翻車余額對(duì)不上連接池直接打滿。后來花了兩周重構(gòu)整個(gè)工程結(jié)構(gòu)才把常見學(xué)生項(xiàng)目的“單類打天下”改成真正能維護(hù)的分層架構(gòu)。這篇筆記就是用那次重構(gòu)的視角來拆解從工程骨架、數(shù)據(jù)庫(kù)設(shè)計(jì)到鑒權(quán)、事務(wù)和排錯(cuò)按落地順序走一遍。你可能是剛?cè)腴T的初學(xué)者也可能是準(zhǔn)備做課程設(shè)計(jì)的在校生這套思路能幫你把“能演示的項(xiàng)目”升級(jí)成“經(jīng)得起問的項(xiàng)目”。2. 工程骨架與數(shù)據(jù)庫(kù)設(shè)計(jì)先說清楚表和連接池怎么定2.1 三層架構(gòu)職責(zé)劃分dao、service、web各自管什么常見的翻車寫法是把JDBC代碼、業(yè)務(wù)判斷、Servlet請(qǐng)求處理全塞進(jìn)一個(gè)類看起來熱鬧后續(xù)每個(gè)功能都要改這一個(gè)類。我在某高校項(xiàng)目里見過一個(gè)核心類超過三千行的版本加個(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的增刪改查不寫if else邏輯這樣分層帶來的直接好處是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ì)先把三張核心表和字段寫下來這是整個(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)格式見下, 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è)地方要特別注意都是踩過坑才改出來的余額字段必須用DECIMAL不能用double或float。二進(jìn)制浮點(diǎn)數(shù)存金額會(huì)出現(xiàn)0.10.2不等于0.3的經(jīng)典問題銀行系統(tǒng)一旦出現(xiàn)分位對(duì)不上賬等于直接報(bào)廢。account_no直接用19位字符串而不是自增id。因?yàn)榭ㄌ?hào)可能以特定數(shù)字開頭比如銀行卡常見的62開頭自增id無法滿足這種業(yè)務(wù)前綴。同時(shí)它作為業(yè)務(wù)維度唯一標(biāo)識(shí)和數(shù)據(jù)庫(kù)主鍵解耦。transaction_log里必須保存balance_after這個(gè)字段是交易后余額的快照。后續(xù)排查問題時(shí)如果賬戶余額和流水對(duì)不上直接按時(shí)間順序重放流水就能定位是哪一筆出了問題。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ù)說明initialSize5啟動(dòng)時(shí)預(yù)建5個(gè)連接避免第一個(gè)請(qǐng)求來臨時(shí)建連讓首次訪問慢半拍maxActive30最大活躍連接數(shù)超過這個(gè)數(shù)會(huì)排隊(duì)等待。設(shè)太小容易打滿設(shè)太大數(shù)據(jù)庫(kù)本身扛不住30對(duì)中小項(xiàng)目夠用maxWait60000拿不到連接時(shí)的最大等待時(shí)間超過就拋異常避免線程無限掛死validationQuerySELECT 1每次從池里拿連接前先驗(yàn)證可用性防止拿到已經(jīng)被數(shù)據(jù)庫(kù)斷開的死連接連接池的獲取和歸還必須配套。我用一個(gè)工具類封裝DAO層拿完連接后必須關(guān)閉連接但關(guān)閉的是歸還連接池而不是真正斷開這是連接池的實(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與路徑問題第一次跑這個(gè)配置時(shí)最容易遇到的就是Properties.load()讀不到文件。常見原因是配置文件放在了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ò)信息里根本不說是文件找不到。排查方法是先判斷in是否為null打印當(dāng)前classpath路徑看一眼。我遇到過在某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)制字符串 } }這里說明一下設(shè)計(jì)取舍。靜態(tài)鹽SALT寫死在代碼里好處是用戶表里不需要單獨(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ì)話過期和權(quán)限失效登錄成功后把用戶信息放Session再寫一個(gè)攔截器對(duì)所有受保護(hù)頁(yè)面做過濾。我用的是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ù)的寫法是如果沒有session就新建一個(gè)配合攔截器邏輯判斷時(shí)會(huì)產(chǎn)生問題。二是過濾器的映射范圍。在web.xml里把需要登錄才能訪問的路徑全部包進(jìn)去比如/account/、/transaction/。千萬(wàn)別用/*全包否則login.jsp本身也會(huì)被攔截形成死循環(huán)。三是Session超時(shí)web.xml里配置session-config session-timeout30/session-timeout /session-config30分鐘沒操作自動(dòng)失效。調(diào)試時(shí)這個(gè)超時(shí)會(huì)經(jīng)常打斷流程可以先把時(shí)間調(diào)長(zhǎng)一點(diǎn)功能跑通后再改回來。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)限判斷最容易出問題的點(diǎn)在頁(yè)面按鈕顯隱上。前端隱藏一個(gè)按鈕不等于后端安全直接構(gòu)造請(qǐng)求URL就能繞過頁(yè)面調(diào)接口。后來我把權(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ù)邏輯看起來簡(jiǎn)單實(shí)際上有四個(gè)環(huán)節(jié)都要做對(duì)事務(wù)開啟、余額校驗(yàn)、更新賬戶、寫流水。缺一個(gè)系統(tǒng)都會(huì)在對(duì)賬時(shí)暴露問題。public void deposit(Long accountId, BigDecimal amount) { String sql UPDATE account SET balance balance ? WHERE id ? AND status 1; // 執(zhí)行更新返回受影響行數(shù) // 如果行數(shù)為0說明賬戶不存在或已凍結(jié) }這里有個(gè)細(xì)節(jié)把balance從庫(kù)里查出來然后在Java里加好再寫回存在并發(fā)覆蓋問題。兩條線程同時(shí)讀到100都加上50后提交的會(huì)把先提交的覆蓋。所以我用UPDATE的原子操作直接在SQL語(yǔ)句層面完成加減數(shù)據(jù)庫(kù)的行鎖會(huì)保證同一時(shí)間只有一筆操作能成功修改這個(gè)賬戶。存款流程結(jié)束后必須寫流水。流水表里存balance_after方便后續(xù)對(duì)賬。寫流水和更新余額這兩個(gè)動(dòng)作必須在同一個(gè)事務(wù)里否則會(huì)出現(xiàn)余額變了但流水沒記錄的臟數(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ù)什么時(shí)候真正提交。在Spring管理下方法執(zhí)行完才提交如果步驟2或3拋異常步驟1的扣減會(huì)回滾不會(huì)出現(xiàn)扣了錢對(duì)方?jīng)]收到的情況。但如果你用的是原生JDBC沒有事務(wù)控制步驟1執(zhí)行完提交了步驟2失敗資金憑空消失。另外accountDao.deductBalance的SQL里必須帶balance ?條件UPDATE account SET balance balance - ? WHERE id ? AND balance ? AND status 1這樣做的目的是讓余額判斷和扣減操作合在一個(gè)原子SQL里避免“查出來判斷夠了再更新”兩步之間的并發(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ù)可讀、盡量唯一方便排查問題。我用的方案是String transNo T System.currentTimeMillis() String.format(%04d, new Random().nextInt(10000));這個(gè)方案在單機(jī)低并發(fā)下夠用但注意Random生成的4位數(shù)在高并發(fā)下可能碰撞。后來我改成用數(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ù)過大會(huì)導(dǎo)致深度分頁(yè)性能下降。LIMIT 100000, 20這樣的寫法數(shù)據(jù)庫(kù)要先掃描前面十萬(wàn)條記錄再丟棄。當(dāng)數(shù)據(jù)量真的大起來時(shí)我一般會(huì)改成基于上次查詢的最后一筆流水id做游標(biāo)分頁(yè)也就是WHERE id ? ORDER BY id DESC LIMIT 20但課程設(shè)計(jì)階段用LIMIT offset的方式夠用。5. 常見問題與避坑連接泄漏、浮點(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塊里沒有調(diào)用con.close()或者寫成了con.close()后System.exit(0)。連接沒有歸還連接池池里的連接被耗盡。最典型的場(chǎng)景是異常路徑上沒有close比如SQLException拋出前忘記釋放。解決用try-with-resources語(yǔ)法連接相關(guān)的語(yǔ)句全包在里面不需要手動(dòng)finally。Java 7之后Connection實(shí)現(xiàn)了AutoCloseable接口這樣寫既美觀又不會(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è)賬戶存取款幾次后余額和流水表重算出來的金額不一樣差的金額是幾分錢。原因在Java代碼里用了double類型傳金額數(shù)據(jù)庫(kù)字段也建成了double。浮點(diǎn)數(shù)在二進(jìn)制里無法精確表示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ù)上把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í)無法分辨哪筆在前。原因數(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)來改。5.4 并發(fā)扣款覆蓋余額判斷和扣減分離導(dǎo)致超扣現(xiàn)象兩個(gè)線程同時(shí)讀取余額100各自判斷可以扣80同時(shí)提交后余額變成20而不是預(yù)期的正確值甚至變成負(fù)數(shù)。原因查詢余額和更新余額是兩個(gè)獨(dú)立步驟沒有放在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)里也沒有使用行鎖保護(hù)。兩個(gè)請(qǐng)求并發(fā)執(zhí)行時(shí)同時(shí)讀到舊值然后分別寫回先寫回的被后寫回覆蓋。解決用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ù)沒有在請(qǐng)求時(shí)重新校驗(yàn)session。瀏覽器后退時(shí)可能從本地cache加載頁(yè)面不發(fā)起請(qǐng)求。后端從session取用戶信息時(shí)沒有判斷null。解決在web.xml里給受保護(hù)頁(yè)面配置禁止瀏覽器緩存的響應(yīng)頭filter filter-nameNoCacheFilter/filter-name /filter !-- 對(duì)應(yīng)過濾器里設(shè)置 -- response.setHeader(Cache-Control, no-cache, no-store, must-revalidate);后端取Session屬性時(shí)統(tǒng)一用工具類如果取出來是null直接跳轉(zhuǎn)到登錄頁(yè)而不是讓NullPointerException冒泡到用戶界面。調(diào)試session問題時(shí)先在瀏覽器開發(fā)者工具的Network面板里看響應(yīng)頭有沒有清晰的緩存控制標(biāo)識(shí)。6. 收尾驗(yàn)證用單元測(cè)試和壓測(cè)腳本給項(xiàng)目兜底6.1 Service層單元測(cè)試用Mock數(shù)據(jù)驗(yàn)證事務(wù)回滾功能代碼寫完只代表邏輯存在不代表邏輯正確。我給轉(zhuǎn)賬寫了一個(gè)JUnit單元測(cè)試。沒有測(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)出賬戶余額沒變 BigDecimal fromBalance accountDao.getBalance(fromId); assertEquals(new BigDecimal(1000.00), fromBalance); } }這個(gè)測(cè)試驗(yàn)證的是最核心的邊界轉(zhuǎn)賬失敗時(shí)轉(zhuǎn)出賬戶余額不能有動(dòng)靜。如果斷言通過事務(wù)回滾是生效的。我每次改business邏輯都先跑一遍這些測(cè)試再手動(dòng)點(diǎn)頁(yè)面效率高很多。6.2 手工壓測(cè)驗(yàn)證并發(fā)安全關(guān)鍵的并發(fā)場(chǎng)景模擬可以用一個(gè)簡(jiǎn)單的腳本程序來驗(yàn)證前面提到的并發(fā)扣款問題。用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ù)說明原子更新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ù)走一遍開戶、存款、取款、轉(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ì)你有幫助把該繞的坑提前繞過去。本文還有配套的精品資源點(diǎn)擊獲取