简介一套完整的银行排号系统项目资料面向Java Web开发学习者及课程设计、毕业设计人群聚焦取号、队列动态更新、预约服务等银行常见业务场景的完整实现。压缩包约1.69MB主要包含项目报告、答辩PPT、源代码和数据库文件数据库负责维护用户信息、预约记录与队列状态源代码按业务逻辑、数据访问、界面展示等层次划分报告详细记录需求分析、总体设计、编码实现、功能测试和问题解决过程答辩PPT可直接用于项目展示与汇报。系统采用模型-视图-控制器架构前端通过Swing或JavaFX构建操作界面服务端使用Servlet或Spring Boot处理请求并以关系型数据库完成数据持久化同时涉及权限控制、数据加密、异常处理、单元测试与集成测试等工程实践兼顾可靠性与安全性。项目报告中还整理了开发中遇到的问题与解决方案答辩PPT亦涵盖项目背景、功能演示和性能评估方便汇报前快速梳理思路。目前已有151人学习借助这份完整案例可以拆解一个可运行的Java项目掌握前后端协作、数据库建模、分层开发及答辩展示的实用方法也能为同类管理信息系统设计提供参考。1. 直接拆这份基于 Java 的银行排号系统为什么把它当第一份实战源码银行排号这题目看起来是个课程设计标配但真正把它拆开你能摸到 Java 后端一整条链路MVC 分层怎么划、DAO 层怎么访问数据库、Servlet 或 Spring Boot 怎么接收请求、数据库表怎么符合第三范式还附带了项目报告和答辩 PPT。这套资源解决的不只是“我有代码能交差”而是让你从源码里梳理出需求分析到部署验证的完整闭环。适合期末攒项目、准备 Java 面试、以及刚接手别人代码想快速理清主流程的人。不要一上来就盯源码先看目录再跑通项目最后再研究队列那套核心逻辑顺序对了阅读成本能少一半。2. 系统骨架MVC 分层和模块边界先立住2.1 拿到压缩包后我建议你先按这个顺序拆文件这个包的根目录一般分四块项目报告doc 或 pdf答辩 PPT源码目录数据库脚本。很多同学一解压就直奔 src然后看到十几个包名就头晕。实际上报告和 PPT 是理解设计意图最快的入口报告里的用例图和时序图已经把取号、叫号、窗口分配、预约这些流程画清楚了。先花半小时读报告比在代码里盲猜快得多。源码目录里通常按三层组织controller或servlet、service、dao再加一个entity或model存放实体类。这个分层对应的就是 MVC 里的 Controller、Model 和持久层。有人会问为什么没有明显的 View 层如果界面用的是 Swing那 View 就是独立的view包通过事件监听器调 Controller如果用的是 Servlet JSPJSP 本身就承担 View 的角色。先认准这一条线后面的代码阅读就不会迷路。提示解压后先检查有没有README或导入说明.txt。这类毕业设计包的数据库连接配置通常写死在jdbc.properties或application.yml里先改配置再启动能省掉一大堆环境问题。2.2 MVC 分离到底把职责切在哪个位置MVC 的核心不是让代码分层而是让修改某一层时不影响其他层。银行排号系统里你会看到这样的边界Controller 层只做三件事接收参数、调用 Service、返回结果。它不写 SQL也不拼接业务规则。以“取号”这个动作为例Controller 里的方法大概只做参数解析和响应分发。Service 层是业务逻辑的核心包括号码生成、窗口轮询、队列状态流转这些规则封装在 Service 里Controller 不感知具体策略。DAO 层负责和数据库对话它的职责非常窄一个方法对应一条 SQL。这种拆分带来的实际好处是如果你要把队列从“按序号排队”改成“按优先级排队”只需要改 Service 层的排序策略DAO 层的selectNextWaiting()可能根本不用动。界面从 Swing 换成 Web 端也只动 View 和 Controller 的交互方式业务规则完全复用。这不只是代码洁癖而是答辩时老师一定会追问的扩展性话题。2.3 一次完整请求的链路从按钮点击到数据落库以取号为例整套链路是这样的用户在界面点击“取号”按钮。View 捕获事件调用 Controller 的takeTicket(serviceType)方法。Controller 接受参数调用 Service 层的generateTicket()。Service 先查数据库获取当天最大号码计算新号码再写入 queue_record 表。DAO 层执行 SQL返回影响行数。Service 把生成的号码返回给 ControllerController 再响应给 View。这个链路里每一步的耦合都被接口隔开了。你在源码里会看到Service 依赖的是 DAO 接口而不是具体实现这就是面向接口编程。如果包里的实现是 Spring Boot MyBatis你会看到Service和Mapper注解如果是原生 Servlet JDBCService 里就得手动管理 Connection。两种写法逻辑一致但代码风格差异很大看的时候先确认框架别把两种思路混在一起读。3. 核心业务逻辑取号、叫号与队列状态流转3.1 号码生成规则格式、同一天重置、并发安全三个点银行的排号号牌通常有固定格式比如字母加日期加序号A202407120013含义是 A 类业务对私、2024 年 7 月 12 日、当天第 13 号。这种设计既方便用户阅读也方便系统按日期维度统计。对应到代码中Service 层生成号码的逻辑大致是这样的public synchronized String generateTicket(String serviceType) { // 1. 取当天的日期字符串如 20240712 String today new SimpleDateFormat(yyyyMMdd).format(new Date()); // 2. 查数据库获取当天该业务类型的最大号码 String maxNo queueMapper.selectMaxNoByDate(serviceType, today); int nextSeq 1; if (maxNo ! null maxNo.length() 4) { // 号码后四位是当日序号解析后加 1 nextSeq Integer.parseInt(maxNo.substring(maxNo.length() - 4)) 1; } // 3. 拼接新号码并写入队列表 String ticketNo serviceType today.substring(4) String.format(%04d, nextSeq); QueueRecord record new QueueRecord(); record.setTicketNo(ticketNo); record.setServiceType(serviceType); record.setStatus(WAITING); record.setCreateTime(new Date()); queueMapper.insert(record); return ticketNo; }这里有两个关键点。第一synchronized锁保证了在同一时刻只有一个线程能进入方法避免两个请求同时读到同一个最大号码、生成了重复号。第二查询和插入是分开的两步中间存在时间窗口synchronized只能挡得住单机应用如果未来部署成多实例就需要用数据库锁或 Redis 分布式锁来兜底。答辩时主动提这一层能加分不少。3.2 队列状态机WAITING 到 CALLED 再到 FINISHED队列记录不是一条静态数据它的状态会随着窗口叫号和业务完成而流转。最常见的状态转移是WAITING等待中取号成功进入排队队列。CALLED已叫号窗口叫号用户前往窗口。FINISHED已完成业务办理完毕。CANCELLED已取消用户离开或主动取消。状态流转的核心方法是叫号操作。窗口工作人员点击“下一位”系统会把当前最早的一条 WAITING 记录置为 CALLED并绑定到当前窗口public QueueRecord callNext(int windowId) { // 1. 找到当前队列里最久的 WAITING 记录 QueueRecord next queueMapper.selectNextWaiting(); if (next null) { return null; } // 2. 更新状态为已叫号绑定窗口 next.setStatus(CALLED); next.setWindowId(windowId); next.setCallTime(new Date()); queueMapper.updateStatus(next); return next; }selectNextWaiting这个 SQL 很关键。普通实现是SELECT * FROM queue_record WHERE statusWAITING ORDER BY create_time LIMIT 1这就实现了先到先得的公平队列。如果要支持优先客户则可在查询时增加priority字段并进行条件排序。源码包里的 DAO 层一般会留出这个接口改造优先级策略时不用动 Service 层逻辑。3.3 窗口分配轮询、空闲优先还是就近分配窗口分配是整个系统里最容易在答辩时被展开聊的点。最简实现是“空闲窗口抢单”即窗口主动叫号时系统返回当前等待最久的人。另一种是“轮询分配”系统按窗口编号轮询发送叫号通知适合每个窗口服务能力一致的场景。还有更细的按业务类型分配窗口A 类业务去 1-3 号窗B 类业务去 4-5 号窗。这个项目最可能采用的是“各窗口共用一条队列”的模式所有窗口的 Service 方法调用同一个callNext()。好处是实现了负载均衡坏处是队列排序规则单一。如果你想加“VIP 客户优先”就在selectNextWaiting里增加优先级字段排序如果你想让某个窗口只处理特定业务就得把callNext的参数改成带serviceType过滤条件。改动范围很小因为 DAO 层已经按状态和窗口 ID 做了条件封装。4. 数据库设计第三范式下的核心表与并发控制4.1 数据模型用户、排队记录、窗口、服务类型各司其职一套合格的银行排号系统至少需要四张核心表用户表、排队记录表、窗口信息表、服务类型表。用户表管理登录和权限窗口表记录窗口编号和当前状态服务类型表定义业务类别排队记录表则关联用户或匿名取号者、业务类型、窗口和状态。表名核心字段设计要点userid, username, password, role密码应存加密后的散列值role 区分管理员和柜员service_typeid, type_code, type_nametype_code 对应号码前缀如 A、B、Cwindow_infoid, window_no, statusstatus 标识空闲或忙碌queue_recordid, ticket_no, service_type, status, window_id, create_time, call_time, finish_timeticket_no 可设唯一索引status 加普通索引便于查询这里体现第三范式的地方在于queue_record 不直接存业务类型的中文名称而是存 service_type 的编码或外键。要显示中文名时通过关联查询 service_type 表获得。这样如果某天把“对私业务”改成“个人业务”只需要改 service_type 表排队记录完全不受影响。4.2 关键 SQL建表和查询脚本这样写数据库脚本里最值得读的是建表语句和排队记录的查询索引。源码包里的 SQL 脚本一般长这样CREATE TABLE queue_record ( id INT PRIMARY KEY AUTO_INCREMENT, ticket_no VARCHAR(20) NOT NULL, service_type VARCHAR(2) NOT NULL, status VARCHAR(10) DEFAULT WAITING, window_id INT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, call_time DATETIME, finish_time DATETIME, UNIQUE KEY uk_ticket_no (ticket_no), KEY idx_status_time (status, create_time) );uk_ticket_no唯一索引是整个系统防重复的最后一道防线即使应用层 synchronized 失效数据库也会拒绝重复号牌。idx_status_time是复合索引覆盖了selectNextWaiting查询中的status和create_time两个字段避免每次叫号时全表扫描。给表加数据时可以故意插入一条重复的 ticket_no 验证唯一索引是否生效这也是坑测试的一个锻炼机会。4.3 事务控制叫号操作里的两步写入叫号这个动作如果只更新了 queue_record 的状态却发现窗口绑定失败会造成记录了“已叫号”但窗口无法服务的数据不一致。所以源码里的实现通常会把状态更新和窗口绑定放在同一个事务里Transactional(rollbackFor Exception.class) public QueueRecord callNextTransactional(int windowId) { QueueRecord next queueMapper.selectNextWaiting(); if (next null) { return null; } next.setStatus(CALLED); next.setWindowId(windowId); queueMapper.updateStatus(next); return next; }Spring Boot 环境下Transactional注解会自动管理事务边界方法执行结束提交异常自动回滚。如果包里的实现是原生 JDBC事务控制就要手动做conn.setAutoCommit(false)成功后conn.commit()失败后conn.rollback()。看源码时注意区分这两种实现手写事务的和注解事务的排查思路完全不同。5. 避坑清单乱码、并发重复号和界面卡死的五个血泪问题5.1 数据库中文字段全部变成问号现象启动系统后窗口名称和服务类型显示成“???”界面一片乱码。原因数据库连接 URL 里没有带characterEncodingUTF-8或者数据库表本身是 latin1 字符集。Java 侧写入的 UTF-8 数据在入库时被强行转成了旧编码。解决在 JDBC 连接串后面追加参数jdbc:mysql://localhost:3306/bank_queue?useUnicodetruecharacterEncodingUTF-8如果是已经存了乱码的表先备份数据再用ALTER TABLE queue_record CONVERT TO CHARACTER SET utf8mb4;把整表字符集统一。从那以后我每建一个连接配置都会先写全编码参数不再指望数据库默认值。5.2 JDBC 驱动加载报 ClassNotFoundException现象启动时控制台抛出java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver。原因项目安装了数据库驱动 jar但没把它打入运行时的 classpath。在 Eclipse 或 IDEA 里jar 必须是 Build Path 的一部分而不是只丢在项目根目录。解决把mysql-connector-java-x.x.x.jar放到WEB-INF/lib或通过 Maven 添加依赖。如果用的是 Mavenpom.xml 里加上dependency groupIdcom.mysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency检查驱动是否生效最简单的方式是用Class.forName(com.mysql.cj.jdbc.Driver)写一个测试类单独跑不依赖任何框架。5.3 两个窗口同时叫号出现了重复的号码现象测试时并发点击两个窗口的“取号”按钮后台生成了两个一模一样的 ticket_no。原因generateTicket方法没有加锁两个线程同时读取数据库最大号码同时计算 nextSeq同时插入。这在单体应用里属于典型的并发访问问题。解决给生成号码的方法加synchronized或者在 SQL 层用SELECT ... FOR UPDATE锁行。如果你用的是 Spring Boot最简单是对方法加同步再在表上建唯一索引兜底。双保险的效果是即使锁失效数据库层也会拒绝重复插入。5.4 点击取号后界面卡死窗口无响应现象界面点击“取号”按钮后整个窗口变白几秒后才恢复。原因数据库查询是同步耗时操作却放在了 Swing 的事件线程EDT里执行。EDT 被数据库 IO 阻塞界面自然无法刷新。解决把耗时操作放进独立线程比如 SwingWorkernew SwingWorkerString, Void() { Override protected String doInBackground() throws Exception { return queueService.generateTicket(A); } Override protected void done() { try { label.setText(您的号码是 get()); } catch (Exception e) { e.printStackTrace(); } } }.execute();如果你的包里界面是 JSP 或 Vue 前端不存在这个 EDT 问题但页面请求也会有响应等待问题需要异步加载或加载提示。读代码时先判断 View 是桌面端还是 Web 端再对症下药。5.5 登录功能被注入绕过输入 or 11直接进系统现象登录页面输入特殊字符后未验证密码就进入了系统后台。原因DAO 层拼接 SQL 时直接拼字符串String sql SELECT * FROM user WHERE username username AND password password ;解决改用 PreparedStatement 参数化查询String sql SELECT * FROM user WHERE username? AND password?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password);用 MyBatis 的话就用#{}而非${}。答辩时老师只要看到登录查询用了PreparedStatement你就能反问回去你见过几条 SQL 注入案例这是毕业设计里最容易被抽查的安全考点。6. 答辩演示与进阶验证如何让系统“活”起来6.1 十分钟演示脚本按“取号—叫号—完成—查询”四步卡点答辩现场演示最忌讳边操作边想。我一般建议把十分钟分成四段前两分钟打开系统展示登录和权限控制中间三分钟走一遍完整的取号、叫号、窗口办理流程再用两分钟展示数据库里的数据变化证明操作是真的落库的剩下三分钟留给老师提问。演示时打开数据库管理工具把 queue_record 表放在屏幕上。取号后立刻执行一遍SELECT * FROM queue_record ORDER BY id DESC LIMIT 5让老师看到新增记录。这段操作直观说明了业务逻辑与数据库的联动比口头解释“我用了 JDBC”有力得多。6.2 预判两个追问并发场景和上线差距这类课题答辩时的两大高频追问一是“多窗口同时叫号是否会冲突”二是“这个系统距离真实银行落地还差什么”。第一个问题用你在测试里验证过的并发场景回答直接说“我用两个线程模拟同时取号数据库唯一索引保证了号码不重复。”第二个问题要坦诚地指出差距真实场景需要热备份、多级排队策略和大屏展示当前系统只完成了核心闭环。承认边界反而显得你对系统理解深刻。6.3 让系统更抗打的三个小改造如果是想把这套作品拿去面试或二开建议优先做三件事给 ticket_no 加上 UUID 前缀或日期时间的完整格式增强区间扩展的识别性在状态流转记录里增加操作日志表记录每次叫号的窗口和操作人把连接池从手动管理换成 HikariCP并配置最大连接数。这三个改动半小时内能完成却能明显拉升项目的工程完成度。这个项目给我最大的收获不是 Java 语法而是理解了“单一职责”在代码里的落点Controller 轻、Service 重、DAO 纯哪一层出了问题都能单点排查。从那以后我拿到任何一份源码包都会先定死这三层边界再动代码宁可多花半小时理结构也不在混乱的依赖里硬调 bug。希望这份拆解能帮你在自己的排号系统上少踩几个坑。本文还有配套的精品资源点击获取 Java银行排号系统源码拆解：MVC分层、队列状态机与数据库并发控制
简介一套完整的银行排号系统项目资料面向Java Web开发学习者及课程设计、毕业设计人群聚焦取号、队列动态更新、预约服务等银行常见业务场景的完整实现。压缩包约1.69MB主要包含项目报告、答辩PPT、源代码和数据库文件数据库负责维护用户信息、预约记录与队列状态源代码按业务逻辑、数据访问、界面展示等层次划分报告详细记录需求分析、总体设计、编码实现、功能测试和问题解决过程答辩PPT可直接用于项目展示与汇报。系统采用模型-视图-控制器架构前端通过Swing或JavaFX构建操作界面服务端使用Servlet或Spring Boot处理请求并以关系型数据库完成数据持久化同时涉及权限控制、数据加密、异常处理、单元测试与集成测试等工程实践兼顾可靠性与安全性。项目报告中还整理了开发中遇到的问题与解决方案答辩PPT亦涵盖项目背景、功能演示和性能评估方便汇报前快速梳理思路。目前已有151人学习借助这份完整案例可以拆解一个可运行的Java项目掌握前后端协作、数据库建模、分层开发及答辩展示的实用方法也能为同类管理信息系统设计提供参考。1. 直接拆这份基于 Java 的银行排号系统为什么把它当第一份实战源码银行排号这题目看起来是个课程设计标配但真正把它拆开你能摸到 Java 后端一整条链路MVC 分层怎么划、DAO 层怎么访问数据库、Servlet 或 Spring Boot 怎么接收请求、数据库表怎么符合第三范式还附带了项目报告和答辩 PPT。这套资源解决的不只是“我有代码能交差”而是让你从源码里梳理出需求分析到部署验证的完整闭环。适合期末攒项目、准备 Java 面试、以及刚接手别人代码想快速理清主流程的人。不要一上来就盯源码先看目录再跑通项目最后再研究队列那套核心逻辑顺序对了阅读成本能少一半。2. 系统骨架MVC 分层和模块边界先立住2.1 拿到压缩包后我建议你先按这个顺序拆文件这个包的根目录一般分四块项目报告doc 或 pdf答辩 PPT源码目录数据库脚本。很多同学一解压就直奔 src然后看到十几个包名就头晕。实际上报告和 PPT 是理解设计意图最快的入口报告里的用例图和时序图已经把取号、叫号、窗口分配、预约这些流程画清楚了。先花半小时读报告比在代码里盲猜快得多。源码目录里通常按三层组织controller或servlet、service、dao再加一个entity或model存放实体类。这个分层对应的就是 MVC 里的 Controller、Model 和持久层。有人会问为什么没有明显的 View 层如果界面用的是 Swing那 View 就是独立的view包通过事件监听器调 Controller如果用的是 Servlet JSPJSP 本身就承担 View 的角色。先认准这一条线后面的代码阅读就不会迷路。提示解压后先检查有没有README或导入说明.txt。这类毕业设计包的数据库连接配置通常写死在jdbc.properties或application.yml里先改配置再启动能省掉一大堆环境问题。2.2 MVC 分离到底把职责切在哪个位置MVC 的核心不是让代码分层而是让修改某一层时不影响其他层。银行排号系统里你会看到这样的边界Controller 层只做三件事接收参数、调用 Service、返回结果。它不写 SQL也不拼接业务规则。以“取号”这个动作为例Controller 里的方法大概只做参数解析和响应分发。Service 层是业务逻辑的核心包括号码生成、窗口轮询、队列状态流转这些规则封装在 Service 里Controller 不感知具体策略。DAO 层负责和数据库对话它的职责非常窄一个方法对应一条 SQL。这种拆分带来的实际好处是如果你要把队列从“按序号排队”改成“按优先级排队”只需要改 Service 层的排序策略DAO 层的selectNextWaiting()可能根本不用动。界面从 Swing 换成 Web 端也只动 View 和 Controller 的交互方式业务规则完全复用。这不只是代码洁癖而是答辩时老师一定会追问的扩展性话题。2.3 一次完整请求的链路从按钮点击到数据落库以取号为例整套链路是这样的用户在界面点击“取号”按钮。View 捕获事件调用 Controller 的takeTicket(serviceType)方法。Controller 接受参数调用 Service 层的generateTicket()。Service 先查数据库获取当天最大号码计算新号码再写入 queue_record 表。DAO 层执行 SQL返回影响行数。Service 把生成的号码返回给 ControllerController 再响应给 View。这个链路里每一步的耦合都被接口隔开了。你在源码里会看到Service 依赖的是 DAO 接口而不是具体实现这就是面向接口编程。如果包里的实现是 Spring Boot MyBatis你会看到Service和Mapper注解如果是原生 Servlet JDBCService 里就得手动管理 Connection。两种写法逻辑一致但代码风格差异很大看的时候先确认框架别把两种思路混在一起读。3. 核心业务逻辑取号、叫号与队列状态流转3.1 号码生成规则格式、同一天重置、并发安全三个点银行的排号号牌通常有固定格式比如字母加日期加序号A202407120013含义是 A 类业务对私、2024 年 7 月 12 日、当天第 13 号。这种设计既方便用户阅读也方便系统按日期维度统计。对应到代码中Service 层生成号码的逻辑大致是这样的public synchronized String generateTicket(String serviceType) { // 1. 取当天的日期字符串如 20240712 String today new SimpleDateFormat(yyyyMMdd).format(new Date()); // 2. 查数据库获取当天该业务类型的最大号码 String maxNo queueMapper.selectMaxNoByDate(serviceType, today); int nextSeq 1; if (maxNo ! null maxNo.length() 4) { // 号码后四位是当日序号解析后加 1 nextSeq Integer.parseInt(maxNo.substring(maxNo.length() - 4)) 1; } // 3. 拼接新号码并写入队列表 String ticketNo serviceType today.substring(4) String.format(%04d, nextSeq); QueueRecord record new QueueRecord(); record.setTicketNo(ticketNo); record.setServiceType(serviceType); record.setStatus(WAITING); record.setCreateTime(new Date()); queueMapper.insert(record); return ticketNo; }这里有两个关键点。第一synchronized锁保证了在同一时刻只有一个线程能进入方法避免两个请求同时读到同一个最大号码、生成了重复号。第二查询和插入是分开的两步中间存在时间窗口synchronized只能挡得住单机应用如果未来部署成多实例就需要用数据库锁或 Redis 分布式锁来兜底。答辩时主动提这一层能加分不少。3.2 队列状态机WAITING 到 CALLED 再到 FINISHED队列记录不是一条静态数据它的状态会随着窗口叫号和业务完成而流转。最常见的状态转移是WAITING等待中取号成功进入排队队列。CALLED已叫号窗口叫号用户前往窗口。FINISHED已完成业务办理完毕。CANCELLED已取消用户离开或主动取消。状态流转的核心方法是叫号操作。窗口工作人员点击“下一位”系统会把当前最早的一条 WAITING 记录置为 CALLED并绑定到当前窗口public QueueRecord callNext(int windowId) { // 1. 找到当前队列里最久的 WAITING 记录 QueueRecord next queueMapper.selectNextWaiting(); if (next null) { return null; } // 2. 更新状态为已叫号绑定窗口 next.setStatus(CALLED); next.setWindowId(windowId); next.setCallTime(new Date()); queueMapper.updateStatus(next); return next; }selectNextWaiting这个 SQL 很关键。普通实现是SELECT * FROM queue_record WHERE statusWAITING ORDER BY create_time LIMIT 1这就实现了先到先得的公平队列。如果要支持优先客户则可在查询时增加priority字段并进行条件排序。源码包里的 DAO 层一般会留出这个接口改造优先级策略时不用动 Service 层逻辑。3.3 窗口分配轮询、空闲优先还是就近分配窗口分配是整个系统里最容易在答辩时被展开聊的点。最简实现是“空闲窗口抢单”即窗口主动叫号时系统返回当前等待最久的人。另一种是“轮询分配”系统按窗口编号轮询发送叫号通知适合每个窗口服务能力一致的场景。还有更细的按业务类型分配窗口A 类业务去 1-3 号窗B 类业务去 4-5 号窗。这个项目最可能采用的是“各窗口共用一条队列”的模式所有窗口的 Service 方法调用同一个callNext()。好处是实现了负载均衡坏处是队列排序规则单一。如果你想加“VIP 客户优先”就在selectNextWaiting里增加优先级字段排序如果你想让某个窗口只处理特定业务就得把callNext的参数改成带serviceType过滤条件。改动范围很小因为 DAO 层已经按状态和窗口 ID 做了条件封装。4. 数据库设计第三范式下的核心表与并发控制4.1 数据模型用户、排队记录、窗口、服务类型各司其职一套合格的银行排号系统至少需要四张核心表用户表、排队记录表、窗口信息表、服务类型表。用户表管理登录和权限窗口表记录窗口编号和当前状态服务类型表定义业务类别排队记录表则关联用户或匿名取号者、业务类型、窗口和状态。表名核心字段设计要点userid, username, password, role密码应存加密后的散列值role 区分管理员和柜员service_typeid, type_code, type_nametype_code 对应号码前缀如 A、B、Cwindow_infoid, window_no, statusstatus 标识空闲或忙碌queue_recordid, ticket_no, service_type, status, window_id, create_time, call_time, finish_timeticket_no 可设唯一索引status 加普通索引便于查询这里体现第三范式的地方在于queue_record 不直接存业务类型的中文名称而是存 service_type 的编码或外键。要显示中文名时通过关联查询 service_type 表获得。这样如果某天把“对私业务”改成“个人业务”只需要改 service_type 表排队记录完全不受影响。4.2 关键 SQL建表和查询脚本这样写数据库脚本里最值得读的是建表语句和排队记录的查询索引。源码包里的 SQL 脚本一般长这样CREATE TABLE queue_record ( id INT PRIMARY KEY AUTO_INCREMENT, ticket_no VARCHAR(20) NOT NULL, service_type VARCHAR(2) NOT NULL, status VARCHAR(10) DEFAULT WAITING, window_id INT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, call_time DATETIME, finish_time DATETIME, UNIQUE KEY uk_ticket_no (ticket_no), KEY idx_status_time (status, create_time) );uk_ticket_no唯一索引是整个系统防重复的最后一道防线即使应用层 synchronized 失效数据库也会拒绝重复号牌。idx_status_time是复合索引覆盖了selectNextWaiting查询中的status和create_time两个字段避免每次叫号时全表扫描。给表加数据时可以故意插入一条重复的 ticket_no 验证唯一索引是否生效这也是坑测试的一个锻炼机会。4.3 事务控制叫号操作里的两步写入叫号这个动作如果只更新了 queue_record 的状态却发现窗口绑定失败会造成记录了“已叫号”但窗口无法服务的数据不一致。所以源码里的实现通常会把状态更新和窗口绑定放在同一个事务里Transactional(rollbackFor Exception.class) public QueueRecord callNextTransactional(int windowId) { QueueRecord next queueMapper.selectNextWaiting(); if (next null) { return null; } next.setStatus(CALLED); next.setWindowId(windowId); queueMapper.updateStatus(next); return next; }Spring Boot 环境下Transactional注解会自动管理事务边界方法执行结束提交异常自动回滚。如果包里的实现是原生 JDBC事务控制就要手动做conn.setAutoCommit(false)成功后conn.commit()失败后conn.rollback()。看源码时注意区分这两种实现手写事务的和注解事务的排查思路完全不同。5. 避坑清单乱码、并发重复号和界面卡死的五个血泪问题5.1 数据库中文字段全部变成问号现象启动系统后窗口名称和服务类型显示成“???”界面一片乱码。原因数据库连接 URL 里没有带characterEncodingUTF-8或者数据库表本身是 latin1 字符集。Java 侧写入的 UTF-8 数据在入库时被强行转成了旧编码。解决在 JDBC 连接串后面追加参数jdbc:mysql://localhost:3306/bank_queue?useUnicodetruecharacterEncodingUTF-8如果是已经存了乱码的表先备份数据再用ALTER TABLE queue_record CONVERT TO CHARACTER SET utf8mb4;把整表字符集统一。从那以后我每建一个连接配置都会先写全编码参数不再指望数据库默认值。5.2 JDBC 驱动加载报 ClassNotFoundException现象启动时控制台抛出java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver。原因项目安装了数据库驱动 jar但没把它打入运行时的 classpath。在 Eclipse 或 IDEA 里jar 必须是 Build Path 的一部分而不是只丢在项目根目录。解决把mysql-connector-java-x.x.x.jar放到WEB-INF/lib或通过 Maven 添加依赖。如果用的是 Mavenpom.xml 里加上dependency groupIdcom.mysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency检查驱动是否生效最简单的方式是用Class.forName(com.mysql.cj.jdbc.Driver)写一个测试类单独跑不依赖任何框架。5.3 两个窗口同时叫号出现了重复的号码现象测试时并发点击两个窗口的“取号”按钮后台生成了两个一模一样的 ticket_no。原因generateTicket方法没有加锁两个线程同时读取数据库最大号码同时计算 nextSeq同时插入。这在单体应用里属于典型的并发访问问题。解决给生成号码的方法加synchronized或者在 SQL 层用SELECT ... FOR UPDATE锁行。如果你用的是 Spring Boot最简单是对方法加同步再在表上建唯一索引兜底。双保险的效果是即使锁失效数据库层也会拒绝重复插入。5.4 点击取号后界面卡死窗口无响应现象界面点击“取号”按钮后整个窗口变白几秒后才恢复。原因数据库查询是同步耗时操作却放在了 Swing 的事件线程EDT里执行。EDT 被数据库 IO 阻塞界面自然无法刷新。解决把耗时操作放进独立线程比如 SwingWorkernew SwingWorkerString, Void() { Override protected String doInBackground() throws Exception { return queueService.generateTicket(A); } Override protected void done() { try { label.setText(您的号码是 get()); } catch (Exception e) { e.printStackTrace(); } } }.execute();如果你的包里界面是 JSP 或 Vue 前端不存在这个 EDT 问题但页面请求也会有响应等待问题需要异步加载或加载提示。读代码时先判断 View 是桌面端还是 Web 端再对症下药。5.5 登录功能被注入绕过输入 or 11直接进系统现象登录页面输入特殊字符后未验证密码就进入了系统后台。原因DAO 层拼接 SQL 时直接拼字符串String sql SELECT * FROM user WHERE username username AND password password ;解决改用 PreparedStatement 参数化查询String sql SELECT * FROM user WHERE username? AND password?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password);用 MyBatis 的话就用#{}而非${}。答辩时老师只要看到登录查询用了PreparedStatement你就能反问回去你见过几条 SQL 注入案例这是毕业设计里最容易被抽查的安全考点。6. 答辩演示与进阶验证如何让系统“活”起来6.1 十分钟演示脚本按“取号—叫号—完成—查询”四步卡点答辩现场演示最忌讳边操作边想。我一般建议把十分钟分成四段前两分钟打开系统展示登录和权限控制中间三分钟走一遍完整的取号、叫号、窗口办理流程再用两分钟展示数据库里的数据变化证明操作是真的落库的剩下三分钟留给老师提问。演示时打开数据库管理工具把 queue_record 表放在屏幕上。取号后立刻执行一遍SELECT * FROM queue_record ORDER BY id DESC LIMIT 5让老师看到新增记录。这段操作直观说明了业务逻辑与数据库的联动比口头解释“我用了 JDBC”有力得多。6.2 预判两个追问并发场景和上线差距这类课题答辩时的两大高频追问一是“多窗口同时叫号是否会冲突”二是“这个系统距离真实银行落地还差什么”。第一个问题用你在测试里验证过的并发场景回答直接说“我用两个线程模拟同时取号数据库唯一索引保证了号码不重复。”第二个问题要坦诚地指出差距真实场景需要热备份、多级排队策略和大屏展示当前系统只完成了核心闭环。承认边界反而显得你对系统理解深刻。6.3 让系统更抗打的三个小改造如果是想把这套作品拿去面试或二开建议优先做三件事给 ticket_no 加上 UUID 前缀或日期时间的完整格式增强区间扩展的识别性在状态流转记录里增加操作日志表记录每次叫号的窗口和操作人把连接池从手动管理换成 HikariCP并配置最大连接数。这三个改动半小时内能完成却能明显拉升项目的工程完成度。这个项目给我最大的收获不是 Java 语法而是理解了“单一职责”在代码里的落点Controller 轻、Service 重、DAO 纯哪一层出了问题都能单点排查。从那以后我拿到任何一份源码包都会先定死这三层边界再动代码宁可多花半小时理结构也不在混乱的依赖里硬调 bug。希望这份拆解能帮你在自己的排号系统上少踩几个坑。本文还有配套的精品资源点击获取