簡(jiǎn)介這套Java會(huì)議管理系統(tǒng)源碼面向Java初學(xué)者與畢業(yè)設(shè)計(jì)/課程設(shè)計(jì)人群聚焦會(huì)議全流程管理涵蓋會(huì)議增刪改查、參會(huì)人員維護(hù)、日程安排及權(quán)限控制等模塊可幫助讀者快速上手企業(yè)級(jí)Java項(xiàng)目結(jié)構(gòu)。資源包體積僅286KB共41個(gè)文件以25個(gè)Java源文件為主干另有11張PNG圖片展示系統(tǒng)ER圖和界面效果以及SQL腳本、XML配置Maven的pom.xml等和README說(shuō)明便于對(duì)照代碼理解數(shù)據(jù)庫(kù)設(shè)計(jì)與構(gòu)建流程。項(xiàng)目基于JDK12與MySQL8.0涉及Swing/JavaFX圖形界面構(gòu)建配合Maven管理依賴(lài)適合作為理解面向?qū)ο蠓謱印DBC數(shù)據(jù)操作和MVC模式的實(shí)戰(zhàn)范例。目前已有338人學(xué)習(xí)對(duì)于需要參考完整會(huì)議管理實(shí)現(xiàn)或搭建類(lèi)似系統(tǒng)的開(kāi)發(fā)者來(lái)說(shuō)這份源碼能直接提供可運(yùn)行的功能框架與模塊劃分思路。1. 一套能跑的 Java 會(huì)議管理系統(tǒng)源碼離“能用”還差三步把一套 Java 會(huì)議管理系統(tǒng)源碼放在你面前第一件事別急著打開(kāi) IDE先把“會(huì)議”這個(gè)詞拆成一條狀態(tài)流草稿、待審核、已發(fā)布、進(jìn)行中、已結(jié)束、已取消。市面上大量課程設(shè)計(jì)案例源碼翻車(chē)就翻在這里——前端點(diǎn)幾下能增刪改查真放進(jìn)辦公室用一個(gè)星期重復(fù)預(yù)訂沒(méi)人攔、會(huì)議沖突沒(méi)人管、簽到數(shù)據(jù)進(jìn)不了統(tǒng)計(jì)報(bào)表。這套源碼的價(jià)值不是“能跑”而是把會(huì)議管理從 Excel 表格變成帶權(quán)限、帶狀態(tài)、帶校驗(yàn)的業(yè)務(wù)流。它適合三類(lèi)人做畢設(shè)的學(xué)生、要給小組做內(nèi)部會(huì)議管理的開(kāi)發(fā)者以及想照著 Spring Boot 項(xiàng)目結(jié)構(gòu)補(bǔ) Java 基礎(chǔ)的學(xué)習(xí)者。源碼負(fù)責(zé)下限你要負(fù)責(zé)上限。2. 拿到源碼先別急著改技術(shù)棧、運(yùn)行路徑和數(shù)據(jù)庫(kù)初始化2.1 老套路和新套路先分清這套源碼是 SSM 還是 Spring BootJava 會(huì)議管理系統(tǒng)源碼在市面上流傳最廣的兩條技術(shù)線(xiàn)一條是 Servlet JSP JDBC 的老寫(xiě)法一條是 Spring Boot MyBatis 的新寫(xiě)法中間還有大量 SSMSpring Spring MVC MyBatis過(guò)渡形態(tài)。拿到源碼第一步不是看業(yè)務(wù)代碼而是看根目錄和 pom.xml判斷它屬于哪一代這決定了你本機(jī)要裝什么、怎么啟動(dòng)。技術(shù)棧組合JDK 版本典型啟動(dòng)方式適合場(chǎng)景Servlet JSP JDBCJDK 1.6~1.8直接扔進(jìn) Tomcat webapps課程設(shè)計(jì)、老系統(tǒng)維護(hù)SSMSpringSpringMVCMyBatisJDK 1.8Maven 打包成 War 部署 Tomcat多數(shù)畢設(shè)源碼Spring Boot MyBatis/MyBatis-PlusJDK 1.8java -jar 或 War 部署新項(xiàng)目、小團(tuán)隊(duì)內(nèi)部系統(tǒng)判斷方法很簡(jiǎn)單有webapp/WEB-INF/web.xml和spring-mvc.xml的是 SSM只有src/main/java/com/xxx/Application.java的是 Spring Boot。我見(jiàn)過(guò)不少人把 SSM 源碼當(dāng) Spring Boot 改改到一半發(fā)現(xiàn)SpringBootApplication啟動(dòng)類(lèi)根本不在白折騰兩天。源碼里如果帶mapper.xml手寫(xiě) SQL想快速上手就先別看 MyBatis 源碼級(jí)原理把映射文件的 namespace 和 resultMap 對(duì)齊就夠了想深入再回頭補(bǔ)那是后話(huà)。選型上我的建議是能跑通就先別換框架。畢設(shè)場(chǎng)景里 SSM 和 Spring Boot 都能交差但你要是把 SSM 遷移到 Spring Boot等于重構(gòu)一遍時(shí)間成本夠你再寫(xiě)兩個(gè)模塊。反過(guò)來(lái)如果源碼本身就是 Spring Boot部署會(huì)省很多事。2.2 最小運(yùn)行環(huán)境JDK、Maven、Tomcat、MySQL 四件套怎么對(duì)齊運(yùn)行環(huán)境是最容易翻車(chē)的環(huán)節(jié)而且翻車(chē)原因往往不是軟件裝沒(méi)裝而是版本不匹配。老源碼用 JDK 8 Tomcat 8新源碼用 JDK 17 Tomcat 10混著用會(huì)出現(xiàn)詭異的ClassNotFoundException或NoClassDefFoundError這類(lèi)問(wèn)題排查起來(lái)很費(fèi)時(shí)間因?yàn)閳?bào)錯(cuò)信息基本不指向真實(shí)原因。我一般按這個(gè)順序?qū)R環(huán)境每一步都用命令驗(yàn)證不靠 IDE 提示java -version mvn -version echo $CATALINA_HOME mysql --versionjava -version確認(rèn) JDK 主版本。Spring Boot 2.x 要求 JDK 8 以上Spring Boot 3.x 要求 JDK 17先看 pom.xml 里的java.version。mvn -version確認(rèn) Maven 版本和它使用的 JDK。Maven 3.6 配合 JDK 8 是主流組合。echo $CATALINA_HOME確認(rèn) Tomcat 環(huán)境變量。如果沒(méi)有輸出說(shuō)明 Tomcat 是免安裝版直接解壓用的后面啟動(dòng)時(shí)直接進(jìn) bin 目錄。mysql --version確認(rèn) MySQL 版本。MySQL 5.7 和 8.0 的 JDBC 驅(qū)動(dòng)類(lèi)名不一樣這個(gè)坑放到 2.3 說(shuō)。Java 環(huán)境變量配置是老生常談但新手總在PATH上出錯(cuò)JAVA_HOME配好了PATH里沒(méi)有%JAVA_HOME%\bin命令行還是找不到 java。配置完記得新開(kāi)終端再驗(yàn)證別在舊窗口里反復(fù)折騰。Tomcat 如果解壓后端口被占改conf/server.xml里的 8080 即可這個(gè)后面部署章還會(huì)再提到。2.3 初始化數(shù)據(jù)庫(kù)與改連接參數(shù)三個(gè)必改點(diǎn)大多數(shù)會(huì)議管理系統(tǒng)源碼會(huì)附帶 SQL 腳本通常在sql/meeting.sql或doc/db.sql。拿到腳本先不要直接 source打開(kāi)看一眼建庫(kù)語(yǔ)句的字符集和表名。我遇到不止一次腳本里建庫(kù)用latin1表結(jié)構(gòu)又是utf8中文字段寫(xiě)入后全是問(wèn)號(hào)。建議手動(dòng)建一個(gè)庫(kù)統(tǒng)一用 utf8mb4CREATE DATABASE IF NOT EXISTS meeting_sys DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE meeting_sys; SOURCE /path/to/meeting.sql;建庫(kù)和執(zhí)行腳本分開(kāi)做好處是如果腳本里的建庫(kù)語(yǔ)句有問(wèn)題不會(huì)污染你手動(dòng)建好的庫(kù)。SOURCE的路徑最好用絕對(duì)路徑避免相對(duì)路徑在當(dāng)前目錄不對(duì)時(shí)報(bào)錯(cuò)。數(shù)據(jù)庫(kù)連接配置是第二個(gè)必改點(diǎn)。Spring Boot 項(xiàng)目改src/main/resources/application.ymlSSM 改jdbc.propertiesspring: datasource: url: jdbc:mysql://localhost:3306/meeting_sys?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 你的密碼 driver-class-name: com.mysql.cj.jdbc.Driver三個(gè)必改參數(shù)說(shuō)清楚serverTimezoneAsia/Shanghai不寫(xiě)MySQL 8 默認(rèn)按 UTC 連接存入的時(shí)間比北京時(shí)間少 8 小時(shí)。這個(gè)坑在簽到和會(huì)議時(shí)間上特別致命。driver-class-nameMySQL 5.7 用com.mysql.jdbc.DriverMySQL 8.0 用com.mysql.cj.jdbc.Driver寫(xiě)錯(cuò)啟動(dòng)時(shí)直接ClassNotFoundException。allowPublicKeyRetrievaltrueMySQL 8 使用 caching_sha2_password 認(rèn)證時(shí)JDBC 連接會(huì)報(bào)Public Key Retrieval is not allowed加上這個(gè)參數(shù)解決。第三個(gè)必改點(diǎn)是文件上傳路徑。會(huì)議系統(tǒng)通常有導(dǎo)入?yún)?huì)人、上傳附件功能源碼里默認(rèn)路徑寫(xiě)死成D:/upload或/home/upload這在你機(jī)器上不存在啟動(dòng)時(shí)不報(bào)錯(cuò)一上傳就報(bào)錯(cuò)。去application.yml或常量類(lèi)里搜upload或file.path改成自己的絕對(duì)路徑。這三項(xiàng)改完項(xiàng)目才能算真正“落到你的機(jī)器上”接下來(lái)才能談業(yè)務(wù)邏輯。3. 會(huì)議狀態(tài)機(jī)與數(shù)據(jù)一致性怎么保證同一間會(huì)議室不被搶3.1 會(huì)議的狀態(tài)是什么六個(gè)狀態(tài)和兩條流轉(zhuǎn)邊界會(huì)議管理系統(tǒng)看起來(lái)是一堆增刪改查但核心不在 CRUD而在狀態(tài)流轉(zhuǎn)。會(huì)議從創(chuàng)建到結(jié)束本質(zhì)上是一條不允許亂跳的線(xiàn)草稿0→ 待審核1→ 已發(fā)布2→ 進(jìn)行中3→ 已結(jié)束4任意狀態(tài)下可以走取消5。很多源碼把狀態(tài)設(shè)計(jì)成隨意改的 int 字段前端下拉框一選就提交這是數(shù)據(jù)混亂的根源。我建議先確認(rèn)源碼里是否有狀態(tài)常量類(lèi)或枚舉沒(méi)有就自己補(bǔ)一個(gè)public enum MeetingStatus { DRAFT(0, 草稿), PENDING(1, 待審核), PUBLISHED(2, 已發(fā)布), RUNNING(3, 進(jìn)行中), FINISHED(4, 已結(jié)束), CANCELED(5, 已取消); private final int code; private final String desc; MeetingStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }兩條邊界必須鎖死一是只有“已發(fā)布”狀態(tài)才能被預(yù)訂、簽到和通知草稿和待審核狀態(tài)不允許占用會(huì)議室資源二是“已結(jié)束”和“已取消”是終態(tài)不允許再流轉(zhuǎn)回任何可進(jìn)行狀態(tài)。源碼里如果存在直接UPDATE meeting SET status 某個(gè)值的寫(xiě)法后面并發(fā)場(chǎng)景一定會(huì)出問(wèn)題。狀態(tài)機(jī)做對(duì)了權(quán)限也跟著清晰普通用戶(hù)只能操作自己創(chuàng)建的草稿和待審核會(huì)議管理員才能審核和取消已發(fā)布會(huì)議。這套規(guī)則寫(xiě)在 Service 層統(tǒng)一校驗(yàn)不要散落在 Controller 里。3.2 會(huì)議室沖突檢測(cè)一條 SQL 和一把鎖會(huì)議系統(tǒng)最核心的數(shù)據(jù)一致性問(wèn)題是會(huì)議室沖突。兩個(gè)會(huì)議在同一間會(huì)議室、時(shí)間有重疊必須只能有一個(gè)成功。先看源碼里有沒(méi)有沖突檢測(cè)很多源碼只在頁(yè)面 JS 里校驗(yàn)這等于沒(méi)做。后端必須再查一次而且查法和插入要在同一個(gè)事務(wù)里。時(shí)間段重疊的判斷邏輯是新會(huì)議開(kāi)始時(shí)間小于已有會(huì)議結(jié)束時(shí)間且新會(huì)議結(jié)束時(shí)間大于已有會(huì)議開(kāi)始時(shí)間。寫(xiě)成 SQL 就是SELECT id FROM meeting WHERE room_id #{roomId} AND status IN (2, 3) AND start_time #{endTime} AND end_time #{startTime} FOR UPDATE;注意最后那句FOR UPDATE。它的作用是把命中的會(huì)議行鎖住防止兩個(gè)請(qǐng)求同時(shí)查到“沒(méi)有沖突”然后同時(shí)插入造成實(shí)際沖突。這個(gè)查詢(xún)必須放在事務(wù)里才有鎖效果單獨(dú)執(zhí)行是沒(méi)用的。對(duì)應(yīng)到代碼上Transactional(rollbackFor Exception.class) public void createMeeting(Meeting meeting) { ListMeeting conflicts meetingMapper.selectConflict(meeting.getRoomId(), meeting.getStartTime(), meeting.getEndTime()); if (!conflicts.isEmpty()) { throw new BusinessException(該會(huì)議室在此時(shí)間段已被預(yù)訂); } meetingMapper.insert(meeting); }為什么不建議用唯一索引或樂(lè)觀(guān)鎖來(lái)防沖突因?yàn)闀?huì)議室沖突的判斷依賴(lài)時(shí)間區(qū)間重疊不是簡(jiǎn)單的唯一字段MySQL 沒(méi)法為“區(qū)間不重疊”建唯一索引。FOR UPDATE是常見(jiàn)做法里最直接可靠的一種代價(jià)是并發(fā)低一點(diǎn)但對(duì)會(huì)議管理系統(tǒng)這種低并發(fā)場(chǎng)景完全夠用。你要是把這段邏輯寫(xiě)對(duì)面試時(shí)被問(wèn)“Java 怎么保證數(shù)據(jù)一致性”就能拿這個(gè)真實(shí)場(chǎng)景舉例比背八股文強(qiáng)。3.3 狀態(tài)流轉(zhuǎn)落庫(kù)用樂(lè)觀(guān)鎖防止按鈕被點(diǎn)兩次會(huì)議狀態(tài)流轉(zhuǎn)還有一個(gè)高頻問(wèn)題用戶(hù)雙擊“通過(guò)審核”按鈕或者兩個(gè)管理員同時(shí)操作同一場(chǎng)會(huì)議狀態(tài)被覆蓋。常見(jiàn)的錯(cuò)誤寫(xiě)法是UPDATE meeting SET status 2 WHERE id #{id}這條 SQL 執(zhí)行兩次第一次草稿變待審核第二次待審核還是變待審核看起來(lái)沒(méi)毛病。但如果是從“待審核”到“已發(fā)布”和從“待審核”到“已取消”兩個(gè)操作同時(shí)提交后提交的會(huì)覆蓋先提交的最終狀態(tài)取決于誰(shuí)最后執(zhí)行而不是誰(shuí)先合法。我給源碼改造時(shí)習(xí)慣加一個(gè)version字段每次更新攜帶版本號(hào)UPDATE meeting SET status #{newStatus}, version version 1 WHERE id #{id} AND status #{expectStatus} AND version #{version}執(zhí)行后判斷影響行數(shù)如果為 0說(shuō)明狀態(tài)已經(jīng)被別人改過(guò)直接拋異常提示“會(huì)議狀態(tài)已變化請(qǐng)刷新后重試”。這里有兩個(gè)參數(shù)容易寫(xiě)錯(cuò)expectStatus是從當(dāng)前狀態(tài)遷出的那個(gè)狀態(tài)比如草稿(0)只能遷到待審核(1)或已取消(5)那么expectStatus就傳 0version必須用查詢(xún)時(shí)帶出來(lái)的舊值不能用數(shù)據(jù)庫(kù)函數(shù)。這兩個(gè)條件同時(shí)滿(mǎn)足才更新才是真正的樂(lè)觀(guān)鎖。事務(wù)上要配合Transactional保證“校驗(yàn)狀態(tài) 更新?tīng)顟B(tài)”要么都成功要么都失敗。有些源碼把校驗(yàn)寫(xiě)在 Service 里、更新寫(xiě)在 Mapper XML 里中間忘了加事務(wù)注解結(jié)果校驗(yàn)過(guò)了但更新失敗狀態(tài)沒(méi)變還不報(bào)錯(cuò)這種隱性 bug 比直接報(bào)錯(cuò)難查得多。改完這段建議順手寫(xiě)一條單元測(cè)試模擬兩次并發(fā)更新斷言只有一次成功。4. 從本地跑通到部署打包、配置和故障排查順序4.1 把項(xiàng)目打包成 War 扔進(jìn) Tomcat一條命令和兩個(gè)注意點(diǎn)源碼在你本地能跑之后下一步是打包部署。SSM 和多數(shù)畢設(shè)源碼都是以 War 包形式部署到 Tomcat 的打包命令只有一條mvn clean package -DskipTestsclean清理 target 目錄避免舊產(chǎn)物殘留導(dǎo)致“改了代碼不生效”的假象。-DskipTests跳過(guò)測(cè)試因?yàn)楫呍O(shè)項(xiàng)目里經(jīng)常有跑不通的測(cè)試類(lèi)影響打包。打包完成后War 包在target/目錄下文件名通常是項(xiàng)目名-0.0.1-SNAPSHOT.war。復(fù)制到 Tomcat 的 webapps 目錄然后啟動(dòng)cp target/meeting.war $CATALINA_HOME/webapps/ $CATALINA_HOME/bin/startup.sh兩個(gè)注意點(diǎn)。第一War 包解壓后的訪(fǎng)問(wèn)路徑默認(rèn)是包名比如meeting.war對(duì)應(yīng)http://localhost:8080/meeting/。如果你的頁(yè)面資源引用的是根路徑/css/style.css部署后這些資源全部 404需要在pom.xml里把finalName改成ROOT或者在 Tomcat 里配置虛擬目錄。第二舊 Tomcat 目錄下如果已經(jīng)有同名文件夾先停 Tomcat 再刪舊包直接覆蓋容易出現(xiàn)“部分文件還是舊的”這種玄學(xué)問(wèn)題頁(yè)面改了不生效最后發(fā)現(xiàn)是舊 class 沒(méi)清干凈。4.2 三個(gè)必改配置數(shù)據(jù)庫(kù)密碼、上傳路徑、通知開(kāi)關(guān)部署到別人的機(jī)器或服務(wù)器有三個(gè)配置必須改漏一個(gè)都算沒(méi)部署完。spring: datasource: password: 生產(chǎn)環(huán)境密碼 servlet: multipart: max-file-size: 20MB max-request-size: 50MB mail: host: smtp.example.com port: 465 username: notifyexample.com password: 郵箱授權(quán)碼 properties: mail: debug: false file: upload-dir: /data/meeting/upload數(shù)據(jù)庫(kù)密碼不用解釋但注意不要把密碼明文提交到 Git 倉(cāng)庫(kù)。如果源碼配套的是application-dev.yml和application-prod.yml分環(huán)境配置部署時(shí)用--spring.profiles.activeprod指定別改錯(cuò)文件。上傳路徑我前面 2.3 提過(guò)一次這里再?gòu)?qiáng)調(diào)不要用相對(duì)路徑。相對(duì)路徑依賴(lài)你啟動(dòng) Tomcat 時(shí)的工作目錄用startup.sh啟動(dòng)和用 IDE 啟動(dòng)工作目錄不一樣上傳的文件會(huì)散落在不同地方定期備份時(shí)找不到文件到時(shí)候想后悔都來(lái)不及。第三個(gè)是通知開(kāi)關(guān)。會(huì)議系統(tǒng)通常帶郵件或短信通知源碼里默認(rèn)可能是關(guān)閉的也可能是寫(xiě)死的假發(fā)送。部署前確認(rèn)mail.enabled這類(lèi)開(kāi)關(guān)的值不需要通知就關(guān)掉避免每次開(kāi)會(huì)都往日志里刷異常堆棧。需要通知就把mail.username配成真實(shí)郵箱注意很多郵箱要用授權(quán)碼而不是登錄密碼用登錄密碼會(huì)一直報(bào)認(rèn)證失敗。4.3 404、500、亂碼、連不上庫(kù)按這個(gè)順序排查部署后出問(wèn)題按順序排查不要東一下西一下。我的固定順序是日志 → 數(shù)據(jù)庫(kù) → 訪(fǎng)問(wèn)路徑 → 編碼。第一步看日志。Tomcat 的logs/catalina.out和應(yīng)用自己的日志文件基本能定位 80% 的問(wèn)題。Spring Boot 項(xiàng)目還可以用java -jar meeting.war --debug臨時(shí)打開(kāi)調(diào)試日志但生產(chǎn)環(huán)境不建議。tail -n 200 $CATALINA_HOME/logs/catalina.out第二步看數(shù)據(jù)庫(kù)連接。連不上庫(kù)的報(bào)錯(cuò)特征很明顯Communications link failure或Access denied。前者查 MySQL 是否啟動(dòng)、端口是否 3306、服務(wù)器防火墻是否放行后者查 2.3 里說(shuō)的驅(qū)動(dòng)類(lèi)名和密碼。第三步看訪(fǎng)問(wèn)路徑。部署后首頁(yè) 404先確認(rèn)訪(fǎng)問(wèn)的路徑和解壓后的目錄名是否一致再確認(rèn)是否加了項(xiàng)目上下文路徑。頁(yè)面能打開(kāi)但接口報(bào) 404看 Controller 的RequestMapping和前端請(qǐng)求路徑是否對(duì)得上最常見(jiàn)的是前端多寫(xiě)或少寫(xiě)了一個(gè)/。第四步看編碼。頁(yè)面亂碼先改 Tomcat 連接器的編碼Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8/URIEncodingUTF-8只解決 URL 參數(shù)亂碼POST 表單亂碼要看代碼里有沒(méi)有設(shè)置request.setCharacterEncoding(UTF-8)Spring Boot 項(xiàng)目一般靠CharacterEncodingFilter自動(dòng)處理。這四步走完本地部署的絕大多數(shù)故障都能落地。5. 避坑Java 會(huì)議管理系統(tǒng)源碼最常見(jiàn)的五個(gè)翻車(chē)點(diǎn)5.1 會(huì)議時(shí)間整整少了 8 小時(shí)現(xiàn)象頁(yè)面上選的 14:00 開(kāi)會(huì)數(shù)據(jù)庫(kù)里存的是 06:00簽到時(shí)間也跟著錯(cuò)。 原因JDBC 連接串沒(méi)寫(xiě)serverTimezoneMySQL 8 默認(rèn)按服務(wù)器時(shí)區(qū)很多是 UTC處理北京時(shí)間比 UTC 早 8 小時(shí)。 解決在數(shù)據(jù)庫(kù)連接 URL 里加上serverTimezoneAsia/Shanghai。注意別寫(xiě)成serverTimezoneGMT%2B8格式不對(duì)會(huì)啟動(dòng)失敗。改完重啟應(yīng)用插入一條測(cè)試數(shù)據(jù)驗(yàn)證時(shí)間。5.2 會(huì)議室沖突校驗(yàn)只在頁(yè)面上做現(xiàn)象用 Postman 繞過(guò)頁(yè)面直接調(diào)接口同一間會(huì)議室同一時(shí)間段能創(chuàng)建兩個(gè)會(huì)議。 原因沖突檢測(cè)寫(xiě)在 JavaScript 里后端接口沒(méi)做二次校驗(yàn)或者后端校驗(yàn)和插入不在同一個(gè)事務(wù)。 解決按 3.2 的方式把沖突檢測(cè) SQL 放到 Service 層Transactional包住查詢(xún)和插入查詢(xún)加FOR UPDATE。記住一句話(huà)前端校驗(yàn)是體驗(yàn)后端校驗(yàn)是安全缺一不可。5.3 雙擊“審核通過(guò)”按鈕狀態(tài)被覆蓋現(xiàn)象管理員快速雙擊按鈕或者兩個(gè)管理員同時(shí)操作最終狀態(tài)和預(yù)期不符。 原因更新語(yǔ)句沒(méi)有狀態(tài)條件UPDATE meeting SET status2 WHERE id?執(zhí)行兩次第二次把別人的操作覆蓋了。 解決加version樂(lè)觀(guān)鎖更新時(shí)帶expectStatus和舊version影響行數(shù)為 0 就拋異常。這條規(guī)則適用于所有含工作流的系統(tǒng)不止會(huì)議管理。5.4 定時(shí)任務(wù)把未開(kāi)始的會(huì)議掃成“已結(jié)束”現(xiàn)象每天早上 9 點(diǎn)的定時(shí)任務(wù)跑完當(dāng)天下午的會(huì)議狀態(tài)全變成“已結(jié)束”。 原因掃描條件寫(xiě)成end_time now。如果 SQL 里用的是end_time now()而會(huì)議結(jié)束時(shí)間和 now 之間的小時(shí)差沒(méi)算對(duì)或者數(shù)據(jù)庫(kù)時(shí)間和應(yīng)用服務(wù)器時(shí)間不一致就會(huì)誤判。更隱蔽的是定時(shí)任務(wù)方法和狀態(tài)更新方法不在同一個(gè)事務(wù)掃描查到舊數(shù)據(jù)。 解決掃描條件統(tǒng)一用start_time NOW() AND end_time NOW()判斷進(jìn)行中用end_time NOW() AND status 3判斷轉(zhuǎn)已結(jié)束。時(shí)間一律以數(shù)據(jù)庫(kù)時(shí)間為準(zhǔn)應(yīng)用服務(wù)器時(shí)間只做人眼展示。5.5 導(dǎo)出 Excel 導(dǎo)出到一半內(nèi)存溢出現(xiàn)象導(dǎo)出參會(huì)人列表幾千條數(shù)據(jù)沒(méi)問(wèn)題上萬(wàn)條就卡死或 OOM。 原因用XSSFWorkbook把所有行一次性加載進(jìn)內(nèi)存數(shù)據(jù)量大直接撐爆堆內(nèi)存。 解決數(shù)據(jù)量超過(guò)一萬(wàn)行改用SXSSFWorkbook流式寫(xiě)入。順帶說(shuō)一句很多人問(wèn) Java POI Word 能生成圖表嗎Excel 圖表的 POI 支持還算完整Word 里的復(fù)雜圖表 POI 支持有限別指望一個(gè)工具包全搞定導(dǎo)出前先評(píng)估數(shù)據(jù)規(guī)模再選方案。SXSSFWorkbook workbook new SXSSFWorkbook(1000); Sheet sheet workbook.createSheet(參會(huì)人); // 逐行寫(xiě)入不要一次性全 load 進(jìn)內(nèi)存 workbook.dispose(); // 用完后釋放臨時(shí)文件SXSSFWorkbook(1000)里的 1000 表示內(nèi)存中保留的行數(shù)超過(guò)的部分寫(xiě)到臨時(shí)文件。用完必須調(diào)dispose()否則臨時(shí)文件不會(huì)被清理這是很多人的血淚教訓(xùn)。6. 把源碼改出“可交付”的樣子驗(yàn)證清單和一個(gè)值得深挖的方向6.1 上手先跑這 6 條驗(yàn)證源碼改完用一張表做驗(yàn)收比漫無(wú)目的地點(diǎn)點(diǎn)點(diǎn)效率高。我每次拿到這類(lèi)系統(tǒng)都會(huì)先跑這幾條驗(yàn)證點(diǎn)操作預(yù)期結(jié)果會(huì)議創(chuàng)建與沖突創(chuàng)建兩個(gè)同會(huì)議室重疊時(shí)間的會(huì)議第二個(gè)被攔截提示已占用狀態(tài)流轉(zhuǎn)草稿提交審核、審核通過(guò)狀態(tài)依次變?yōu)榇龑徍恕⒁寻l(fā)布越權(quán)操作普通用戶(hù)嘗試取消已發(fā)布會(huì)議接口拒絕返回?zé)o權(quán)限時(shí)間與時(shí)區(qū)創(chuàng)建明天 14:00 的會(huì)議并查看列表列表顯示 14:00不是 06:00并發(fā)重復(fù)提交雙擊審核按鈕或并發(fā)調(diào)用接口僅一次成功不影響行數(shù)為 0導(dǎo)出報(bào)表導(dǎo)出 2000 條參會(huì)人數(shù)據(jù)正常生成 Excel內(nèi)存無(wú)明顯波動(dòng)這 6 條過(guò)完系統(tǒng)的核心邏輯才算基本可信。很多源碼本地能跑驗(yàn)收一上就露餡問(wèn)題全在狀態(tài)機(jī)和并發(fā)校驗(yàn)上。6.2 一個(gè)值得深挖的方向把會(huì)議通知改成異步重試會(huì)議系統(tǒng)的通知功能源碼里多半是同步發(fā)送郵件用戶(hù)點(diǎn)保存要等郵件發(fā)完頁(yè)面才響應(yīng)體驗(yàn)很差而且郵件服務(wù)器一抖整個(gè)創(chuàng)建會(huì)議就失敗。我一般會(huì)把通知改成線(xiàn)程池異步執(zhí)行private final ThreadPoolExecutor notifyExecutor new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(500)); public void sendMeetingNotify(Meeting meeting) { notifyExecutor.execute(() - { try { mailService.send(meeting); } catch (Exception e) { log.error(會(huì)議通知發(fā)送失敗會(huì)議ID{}, meeting.getId(), e); } }); }核心參數(shù)是兩個(gè)核心線(xiàn)程數(shù) 2、最大線(xiàn)程數(shù) 4對(duì)會(huì)議系統(tǒng)這種低頻通知完全夠用隊(duì)列容量 500防止郵件服務(wù)器臨時(shí)故障時(shí)任務(wù)無(wú)限堆積。失敗不重試的話(huà)至少要打印日志留痕。再進(jìn)一步可以建一張notify_record表發(fā)送失敗記錄狀態(tài)定時(shí)任務(wù)掃表重試這就是可靠通知的雛形。我自己接手這類(lèi)源碼時(shí)最后悔的一件事是沒(méi)有先梳理狀態(tài)機(jī)就往會(huì)議表里加字段結(jié)果統(tǒng)計(jì)報(bào)表里的“已結(jié)束”和“已取消”混在一起數(shù)據(jù)全亂回頭補(bǔ)了一整天才掰回來(lái)。后來(lái)每改一個(gè)狀態(tài)流轉(zhuǎn)就補(bǔ)一條對(duì)應(yīng)的驗(yàn)證用例再把沖突檢測(cè) SQL 和樂(lè)觀(guān)鎖寫(xiě)進(jìn) Service 層這套系統(tǒng)才真正從“能跑”變成“敢給別人用”。希望你拿到源碼時(shí)先走一遍這條改造路徑能少踩幾個(gè)我踩過(guò)的坑。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取