尧图网站建设 
简介这是一套面向Java Web初学者与课程设计需求的银行排队叫号系统完整项目采用SSM框架搭配JSP技术实现运行于JDK1.8与Tomcat7环境数据库使用MySQL5.7。项目涵盖取号、叫号、窗口管理与业务统计等典型银行场景模块适合作为毕业设计、课程实训或SSM框架练手参考。压缩包共856个文件约29.65MB其中87个Java源文件承载核心业务逻辑49个JSP页面与25个HTML构成前端交互另有217个JS、97个CSS及大量PNG、GIF、JPG图片资源用于界面美化并附带SQL脚本、配置文件与演示视频目录结构清晰、层次分明。目前已有465人学习下载。读者可获得可直接导入Eclipse或IDEA运行的源码工程、数据库建表脚本以及完整操作录屏便于快速理解SSM整合流程、JSP页面跳转与排队算法实现对照视频排查环境配置与依赖问题高效完成二次开发与答辩准备。1. 银行排队叫号系统到底解决什么问题从 JSPM 选型说起去银行办业务最烦的不是排队本身而是不知道要等多久。大厅里坐满了人广播偶尔响一声谁也不知道下一个是不是自己。银行柜员也难受——客户全挤在窗口前秩序乱、效率低、体验差。排队叫号系统就是来解决这个信息不对称问题的取号、等待、叫号、办理每个环节都有明确的状态和反馈。这个 Java 项目基于 JSPM 架构实现了一套完整的银行排队叫号系统包含源码和演示视频。JSPM 是 JSP Model 的简称本质上是 JSP Servlet JavaBean 的经典 MVC 分层模式在银行、医院、政务大厅这类传统行业的内部管理系统中至今仍有大量存量项目在用。它不像 Spring Boot 那样开箱即用但胜在结构清晰、依赖少、部署简单适合课程设计、小型生产环境和二次开发学习。这套系统适合谁一是 Java Web 课程设计需要完整案例的学生二是想理解传统 MVC 分层架构如何落地业务场景的初中级开发者三是需要快速搭建叫号系统原型的技术团队。源码结构完整配合演示视频能快速理解业务流程和技术实现。2. 系统架构与核心模块拆解JSPM 分层怎么落地2.1 为什么选 JSPM 而不是 Spring Boot很多人第一反应是都什么年代了还用 JSP但放到银行网点这个场景里JSPM 有几个实际优势。第一银行内网环境往往不允许随意引入外部依赖JSP Servlet 只需要一个 Tomcat 容器就能跑不需要 Maven 拉一堆 jar 包。第二JSPM 的请求流转路径短从浏览器到 Servlet 到 DAO 再到数据库排查问题直观不需要理解 Spring 的自动装配和 AOP 代理链。第三对于课程设计来说JSPM 能让你真正理解 HTTP 请求、Session 管理、MVC 分层的底层逻辑而不是被框架封装成“只会写 Controller”。当然JSPM 也有明显短板JSP 页面里容易混入大量 Java 代码维护性差没有依赖注入对象创建全靠手动 new事务管理需要自己写。所以这套系统的价值不在于“技术多先进”而在于“结构清晰、能跑通、能改”。2.2 核心模块与数据流系统按业务拆成四个核心模块模块职责关键类取号模块客户取号、生成排队号、选择业务类型TicketServlet、TicketDAO队列管理维护等待队列、优先级排序、队列状态QueueManager、QueueDAO叫号模块柜员叫号、过号处理、重新入队CallServlet、CallService统计模块业务量统计、等待时长分析StatServlet、StatDAO数据流是这样的客户在取号机页面选择业务类型 → TicketServlet 生成排队号并写入数据库 → QueueManager 将号码加入对应业务队列 → 柜员点击叫号 → CallServlet 从队列头部取出号码 → 更新状态为“已叫号” → 大屏页面轮询获取当前叫号信息。2.3 数据库表设计要点-- 排队号表记录每一条取号记录 CREATE TABLE ticket ( id INT PRIMARY KEY AUTO_INCREMENT, ticket_no VARCHAR(10) NOT NULL, -- 排队号如 A001 business_type VARCHAR(20) NOT NULL, -- 业务类型个人/对公/VIP status TINYINT DEFAULT 0, -- 0等待 1已叫号 2已办理 3过号 create_time DATETIME DEFAULT NOW(), -- 取号时间 call_time DATETIME, -- 叫号时间 finish_time DATETIME, -- 办理完成时间 counter_id INT, -- 窗口编号 INDEX idx_status_type (status, business_type) );ticket_no用字母前缀区分业务类型A 开头是个人业务B 是对公V 是 VIP。status字段驱动整个状态机所有查询都围绕它做过滤。idx_status_type联合索引是关键——叫号时查询“某业务类型下 status0 的最小 ticket_no”没有这个索引在数据量上来后会全表扫描。3. 从零跑通叫号系统环境搭建与核心代码实现3.1 环境准备与项目导入先确认本地环境JDK 1.8 或以上、Tomcat 8.5 或以上、MySQL 5.7 或以上。这三点缺一不可版本不匹配是新手翻车最多的地方。# 检查 JDK 版本 java -version # 检查 MySQL 是否运行 mysql -u root -p -e SELECT VERSION(); # 检查 Tomcat 目录 ls $CATALINA_HOME/bin/startup.shJDK 建议用 1.8因为 JSPM 项目里可能用到一些较老的 APIJDK 17 以上会有模块化限制导致反射失败。MySQL 字符集设为 utf8mb4否则中文业务类型名称会乱码。Tomcat 的conf/server.xml里确认端口没被占用默认 8080。导入项目后先改数据库连接配置。通常在src/db.properties或src/com/bank/util/DBUtil.java里jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/bank_queue?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.passwordyour_passwordserverTimezone必须设否则 MySQL 8 会报时区错误。characterEncoding用 utf8mb4 而不是 utf8因为 utf8 在 MySQL 里只有 3 字节存不了 emoji 和部分生僻字。3.2 取号功能的 Servlet 实现// TicketServlet.java - 处理取号请求 public class TicketServlet extends HttpServlet { private TicketDAO ticketDAO new TicketDAO(); protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String businessType req.getParameter(businessType); // 生成排队号业务前缀 当日序号 String prefix getPrefix(businessType); int todayCount ticketDAO.countTodayByType(businessType); String ticketNo prefix String.format(%03d, todayCount 1); Ticket ticket new Ticket(); ticket.setTicketNo(ticketNo); ticket.setBusinessType(businessType); ticket.setStatus(0); ticketDAO.insert(ticket); // 返回 JSON 给前端展示 resp.setContentType(application/json;charsetUTF-8); resp.getWriter().write({\ticketNo\:\ ticketNo \}); } private String getPrefix(String type) { if (VIP.equals(type)) return V; if (对公.equals(type)) return B; return A; } }这段代码的核心逻辑是根据业务类型确定前缀查询当天该类型已取号数量加一后格式化成三位数。countTodayByType的 SQL 要加日期条件否则第二天号码会接着前一天继续增长。并发场景下这个“查再插”有竞态问题两个请求可能拿到同一个序号。生产环境需要用数据库唯一索引兜底或者用SELECT ... FOR UPDATE锁行。3.3 叫号逻辑与队列管理// CallService.java - 柜员叫号核心逻辑 public class CallService { private TicketDAO ticketDAO new TicketDAO(); public Ticket callNext(String businessType, int counterId) { // 查询该业务类型下等待中最小号码 Ticket next ticketDAO.findFirstWaiting(businessType); if (next null) return null; // 更新状态为已叫号 next.setStatus(1); next.setCallTime(new Date()); next.setCounterId(counterId); ticketDAO.updateStatus(next); return next; } // 过号处理将超时未到窗口的号码标记为过号 public void handleTimeout(int minutes) { ListTicket timeoutList ticketDAO.findTimeoutWaiting(minutes); for (Ticket t : timeoutList) { t.setStatus(3); ticketDAO.updateStatus(t); } } }findFirstWaiting对应的 SQL 是SELECT * FROM ticket WHERE status0 AND business_type? ORDER BY ticket_no ASC LIMIT 1。这里有个细节ticket_no是字符串排序A001 到 A999 没问题但超过 999 变成 A1000 后字符串排序会出错。解决办法是存一个自增的seq_no整数字段专门用来排序ticket_no只做展示。handleTimeout需要配合定时任务可以用ScheduledExecutorService每 30 秒扫一次也可以配 Quartz。过号后客户需要重新取号还是直接插入队首取决于业务规则代码里留了扩展点。3.4 大屏叫号展示的轮询方案大屏页面用 AJAX 轮询获取当前叫号信息间隔 2 到 3 秒// display.js - 大屏轮询逻辑 function pollCallInfo() { fetch(/bank/callInfo?counterId counterId) .then(res res.json()) .then(data { if (data.ticketNo) { document.getElementById(currentNo).textContent data.ticketNo; document.getElementById(counterNo).textContent data.counterId; // 语音播报 speak(请 data.ticketNo 号到 data.counterId 号窗口); } }) .catch(err console.error(轮询失败, err)); } setInterval(pollCallInfo, 2500);轮询间隔太短会给服务器压力太长客户感知延迟明显。2 到 3 秒是经验值。语音播报用浏览器自带的SpeechSynthesisAPI 就行不需要额外依赖。如果网点大屏是 Android 盒子可能需要用原生 TTS这个在 Web 端跑不了。4. 避坑指南部署和运行中最容易翻车的 5 个点4.1 中文乱码现象是页面显示问号原因是字符集不统一现象取号页面选择“对公业务”提交后数据库里存的是乱码大屏显示问号。原因JSP 页面、Servlet 响应、数据库连接、MySQL 表字符集四个环节只要有一个不是 UTF-8 就会乱码。常见的是 JSP 页面忘了写% page contentTypetext/html;charsetUTF-8 %或者数据库连接 URL 里没加characterEncodingutf8mb4。解决逐层检查。JSP 页面头部加pageEncodingUTF-8Servlet 里resp.setContentType(text/html;charsetUTF-8)JDBC URL 加useUnicodetruecharacterEncodingutf8mb4建表时指定DEFAULT CHARSETutf8mb4。四个地方全对齐乱码问题基本绝迹。4.2 数据库连接池耗尽现象是系统越用越慢原因是 Connection 没关闭现象系统刚启动正常跑半天后越来越慢最后报Cannot get a connection。原因JSPM 项目里很多新手直接在 Servlet 里DriverManager.getConnection()用完忘了close()。每次请求创建一个连接数据库最大连接数很快被打满。解决用连接池Druid 或 C3P0 都行。如果不想引入额外依赖至少把Connection、Statement、ResultSet的关闭放到finally块里。更好的做法是写一个DBUtil.close()静态方法统一处理DAO 层每个方法结束都调一次。4.3 叫号顺序错乱现象是号码跳着叫原因是排序字段类型不对现象柜员叫号时A010 还没叫A011 先出来了。原因ticket_no是 VARCHAR 类型ORDER BY ticket_no按字符串排序。当号码超过 999 变成四位数时A1000 会排在 A999 前面因为字符串比较是逐字符比的。解决加一个seq_no INT AUTO_INCREMENT字段查询时ORDER BY seq_no ASC。ticket_no只用于展示不参与排序。如果不想改表结构至少把号码位数固定成 4 位A0001 到 A9999这样字符串排序和数字排序结果一致。4.4 Tomcat 启动报 ClassNotFound现象是 404 或 500原因是 jar 包没放对位置现象项目在 IDE 里跑得好好的部署到 Tomcat 就报ClassNotFoundException。原因IDE 会自动把依赖 jar 加到 classpath但手动部署到 Tomcat 时jar 包必须放在WEB-INF/lib目录下。MySQL 驱动、JSON 库、连接池这些第三方 jar 一个都不能少。解决在项目根目录执行mvn dependency:copy-dependencies如果有 Maven或者手动把所有依赖 jar 复制到web/WEB-INF/lib。部署后检查 Tomcat 的logs/catalina.out缺哪个类就补哪个 jar。4.5 大屏轮询导致服务器卡顿现象是取号变慢原因是轮询频率太高现象大屏接上后取号页面响应明显变慢服务器 CPU 升高。原因每个大屏每 2 秒发一次请求10 个大屏就是每秒 5 次请求。如果每次请求都查数据库数据库压力成倍增加。解决在服务端加缓存叫号信息变化频率低可以用ConcurrentHashMap缓存每个窗口的当前叫号设置 3 秒过期。或者改用 WebSocket 推送只在叫号变化时推一次彻底消除轮询开销。如果不想大改至少把轮询间隔从 2 秒调到 5 秒并在 Servlet 里加Cache-Control响应头。5. 进阶技巧用状态机重构叫号逻辑与压测验证5.1 把散落的状态判断收进状态机原始代码里status字段的 0/1/2/3 散落在各个 Servlet 和 DAO 里改一个状态要翻好几个文件。我一般会抽一个TicketStateMachine类把状态流转规则集中管理public enum TicketState { WAITING(0), CALLED(1), FINISHED(2), TIMEOUT(3); private final int code; TicketState(int code) { this.code code; } public static TicketState fromCode(int code) { for (TicketState s : values()) { if (s.code code) return s; } throw new IllegalArgumentException(未知状态: code); } // 定义合法流转等待→已叫号→已办理等待→过号 public boolean canTransitionTo(TicketState target) { if (this WAITING target CALLED) return true; if (this CALLED target FINISHED) return true; if (this WAITING target TIMEOUT) return true; return false; } }这样每次更新状态前先调canTransitionTo非法流转直接抛异常。好处是业务规则显式化新人接手时看枚举就知道状态怎么走不用去翻 SQL 猜。5.2 用 JMeter 验证叫号并发叫号系统最怕的是并发取号时号码重复。用 JMeter 模拟 50 个线程同时取号测试项配置预期结果线程数5050 个不同号码Ramp-up1 秒1 秒内全部发出循环次数1每个线程取一次监听器聚合报告 结果树无重复 ticket_no如果出现重复号码说明countTodayByType加一那步有竞态。解决办法是在ticket表的ticket_no上加唯一索引插入冲突时捕获DuplicateKeyException并重试。重试次数设 3 次超过就返回“系统繁忙”。5.3 一个容易被忽略的细节过号后重新入队的位置过号客户重新取号时是排在队尾还是插到队首我见过有的系统直接插队首结果正常等待的客户投诉。合理的做法是给过号客户一个“优先但不等同于插队”的标记比如在队列里单独维护一个过号队列叫号时先叫过号队列再叫正常队列。这样既照顾了过号客户又不影响正常排队秩序。这个逻辑在QueueManager里加一个PriorityQueue就能实现关键是业务规则要和网点确认清楚代码只是执行。写这套系统最大的教训是别在状态字段上省设计。我一开始觉得 0/1/2/3 够用了后来加“暂停服务”“窗口关闭”这些状态时发现到处都要改 if-else。如果重来一次我会先把状态机画清楚再写代码。希望帮到你。本文还有配套的精品资源点击获取 Java JSPM银行排队叫号系统：源码解析与核心实现
简介这是一套面向Java Web初学者与课程设计需求的银行排队叫号系统完整项目采用SSM框架搭配JSP技术实现运行于JDK1.8与Tomcat7环境数据库使用MySQL5.7。项目涵盖取号、叫号、窗口管理与业务统计等典型银行场景模块适合作为毕业设计、课程实训或SSM框架练手参考。压缩包共856个文件约29.65MB其中87个Java源文件承载核心业务逻辑49个JSP页面与25个HTML构成前端交互另有217个JS、97个CSS及大量PNG、GIF、JPG图片资源用于界面美化并附带SQL脚本、配置文件与演示视频目录结构清晰、层次分明。目前已有465人学习下载。读者可获得可直接导入Eclipse或IDEA运行的源码工程、数据库建表脚本以及完整操作录屏便于快速理解SSM整合流程、JSP页面跳转与排队算法实现对照视频排查环境配置与依赖问题高效完成二次开发与答辩准备。1. 银行排队叫号系统到底解决什么问题从 JSPM 选型说起去银行办业务最烦的不是排队本身而是不知道要等多久。大厅里坐满了人广播偶尔响一声谁也不知道下一个是不是自己。银行柜员也难受——客户全挤在窗口前秩序乱、效率低、体验差。排队叫号系统就是来解决这个信息不对称问题的取号、等待、叫号、办理每个环节都有明确的状态和反馈。这个 Java 项目基于 JSPM 架构实现了一套完整的银行排队叫号系统包含源码和演示视频。JSPM 是 JSP Model 的简称本质上是 JSP Servlet JavaBean 的经典 MVC 分层模式在银行、医院、政务大厅这类传统行业的内部管理系统中至今仍有大量存量项目在用。它不像 Spring Boot 那样开箱即用但胜在结构清晰、依赖少、部署简单适合课程设计、小型生产环境和二次开发学习。这套系统适合谁一是 Java Web 课程设计需要完整案例的学生二是想理解传统 MVC 分层架构如何落地业务场景的初中级开发者三是需要快速搭建叫号系统原型的技术团队。源码结构完整配合演示视频能快速理解业务流程和技术实现。2. 系统架构与核心模块拆解JSPM 分层怎么落地2.1 为什么选 JSPM 而不是 Spring Boot很多人第一反应是都什么年代了还用 JSP但放到银行网点这个场景里JSPM 有几个实际优势。第一银行内网环境往往不允许随意引入外部依赖JSP Servlet 只需要一个 Tomcat 容器就能跑不需要 Maven 拉一堆 jar 包。第二JSPM 的请求流转路径短从浏览器到 Servlet 到 DAO 再到数据库排查问题直观不需要理解 Spring 的自动装配和 AOP 代理链。第三对于课程设计来说JSPM 能让你真正理解 HTTP 请求、Session 管理、MVC 分层的底层逻辑而不是被框架封装成“只会写 Controller”。当然JSPM 也有明显短板JSP 页面里容易混入大量 Java 代码维护性差没有依赖注入对象创建全靠手动 new事务管理需要自己写。所以这套系统的价值不在于“技术多先进”而在于“结构清晰、能跑通、能改”。2.2 核心模块与数据流系统按业务拆成四个核心模块模块职责关键类取号模块客户取号、生成排队号、选择业务类型TicketServlet、TicketDAO队列管理维护等待队列、优先级排序、队列状态QueueManager、QueueDAO叫号模块柜员叫号、过号处理、重新入队CallServlet、CallService统计模块业务量统计、等待时长分析StatServlet、StatDAO数据流是这样的客户在取号机页面选择业务类型 → TicketServlet 生成排队号并写入数据库 → QueueManager 将号码加入对应业务队列 → 柜员点击叫号 → CallServlet 从队列头部取出号码 → 更新状态为“已叫号” → 大屏页面轮询获取当前叫号信息。2.3 数据库表设计要点-- 排队号表记录每一条取号记录 CREATE TABLE ticket ( id INT PRIMARY KEY AUTO_INCREMENT, ticket_no VARCHAR(10) NOT NULL, -- 排队号如 A001 business_type VARCHAR(20) NOT NULL, -- 业务类型个人/对公/VIP status TINYINT DEFAULT 0, -- 0等待 1已叫号 2已办理 3过号 create_time DATETIME DEFAULT NOW(), -- 取号时间 call_time DATETIME, -- 叫号时间 finish_time DATETIME, -- 办理完成时间 counter_id INT, -- 窗口编号 INDEX idx_status_type (status, business_type) );ticket_no用字母前缀区分业务类型A 开头是个人业务B 是对公V 是 VIP。status字段驱动整个状态机所有查询都围绕它做过滤。idx_status_type联合索引是关键——叫号时查询“某业务类型下 status0 的最小 ticket_no”没有这个索引在数据量上来后会全表扫描。3. 从零跑通叫号系统环境搭建与核心代码实现3.1 环境准备与项目导入先确认本地环境JDK 1.8 或以上、Tomcat 8.5 或以上、MySQL 5.7 或以上。这三点缺一不可版本不匹配是新手翻车最多的地方。# 检查 JDK 版本 java -version # 检查 MySQL 是否运行 mysql -u root -p -e SELECT VERSION(); # 检查 Tomcat 目录 ls $CATALINA_HOME/bin/startup.shJDK 建议用 1.8因为 JSPM 项目里可能用到一些较老的 APIJDK 17 以上会有模块化限制导致反射失败。MySQL 字符集设为 utf8mb4否则中文业务类型名称会乱码。Tomcat 的conf/server.xml里确认端口没被占用默认 8080。导入项目后先改数据库连接配置。通常在src/db.properties或src/com/bank/util/DBUtil.java里jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/bank_queue?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.passwordyour_passwordserverTimezone必须设否则 MySQL 8 会报时区错误。characterEncoding用 utf8mb4 而不是 utf8因为 utf8 在 MySQL 里只有 3 字节存不了 emoji 和部分生僻字。3.2 取号功能的 Servlet 实现// TicketServlet.java - 处理取号请求 public class TicketServlet extends HttpServlet { private TicketDAO ticketDAO new TicketDAO(); protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String businessType req.getParameter(businessType); // 生成排队号业务前缀 当日序号 String prefix getPrefix(businessType); int todayCount ticketDAO.countTodayByType(businessType); String ticketNo prefix String.format(%03d, todayCount 1); Ticket ticket new Ticket(); ticket.setTicketNo(ticketNo); ticket.setBusinessType(businessType); ticket.setStatus(0); ticketDAO.insert(ticket); // 返回 JSON 给前端展示 resp.setContentType(application/json;charsetUTF-8); resp.getWriter().write({\ticketNo\:\ ticketNo \}); } private String getPrefix(String type) { if (VIP.equals(type)) return V; if (对公.equals(type)) return B; return A; } }这段代码的核心逻辑是根据业务类型确定前缀查询当天该类型已取号数量加一后格式化成三位数。countTodayByType的 SQL 要加日期条件否则第二天号码会接着前一天继续增长。并发场景下这个“查再插”有竞态问题两个请求可能拿到同一个序号。生产环境需要用数据库唯一索引兜底或者用SELECT ... FOR UPDATE锁行。3.3 叫号逻辑与队列管理// CallService.java - 柜员叫号核心逻辑 public class CallService { private TicketDAO ticketDAO new TicketDAO(); public Ticket callNext(String businessType, int counterId) { // 查询该业务类型下等待中最小号码 Ticket next ticketDAO.findFirstWaiting(businessType); if (next null) return null; // 更新状态为已叫号 next.setStatus(1); next.setCallTime(new Date()); next.setCounterId(counterId); ticketDAO.updateStatus(next); return next; } // 过号处理将超时未到窗口的号码标记为过号 public void handleTimeout(int minutes) { ListTicket timeoutList ticketDAO.findTimeoutWaiting(minutes); for (Ticket t : timeoutList) { t.setStatus(3); ticketDAO.updateStatus(t); } } }findFirstWaiting对应的 SQL 是SELECT * FROM ticket WHERE status0 AND business_type? ORDER BY ticket_no ASC LIMIT 1。这里有个细节ticket_no是字符串排序A001 到 A999 没问题但超过 999 变成 A1000 后字符串排序会出错。解决办法是存一个自增的seq_no整数字段专门用来排序ticket_no只做展示。handleTimeout需要配合定时任务可以用ScheduledExecutorService每 30 秒扫一次也可以配 Quartz。过号后客户需要重新取号还是直接插入队首取决于业务规则代码里留了扩展点。3.4 大屏叫号展示的轮询方案大屏页面用 AJAX 轮询获取当前叫号信息间隔 2 到 3 秒// display.js - 大屏轮询逻辑 function pollCallInfo() { fetch(/bank/callInfo?counterId counterId) .then(res res.json()) .then(data { if (data.ticketNo) { document.getElementById(currentNo).textContent data.ticketNo; document.getElementById(counterNo).textContent data.counterId; // 语音播报 speak(请 data.ticketNo 号到 data.counterId 号窗口); } }) .catch(err console.error(轮询失败, err)); } setInterval(pollCallInfo, 2500);轮询间隔太短会给服务器压力太长客户感知延迟明显。2 到 3 秒是经验值。语音播报用浏览器自带的SpeechSynthesisAPI 就行不需要额外依赖。如果网点大屏是 Android 盒子可能需要用原生 TTS这个在 Web 端跑不了。4. 避坑指南部署和运行中最容易翻车的 5 个点4.1 中文乱码现象是页面显示问号原因是字符集不统一现象取号页面选择“对公业务”提交后数据库里存的是乱码大屏显示问号。原因JSP 页面、Servlet 响应、数据库连接、MySQL 表字符集四个环节只要有一个不是 UTF-8 就会乱码。常见的是 JSP 页面忘了写% page contentTypetext/html;charsetUTF-8 %或者数据库连接 URL 里没加characterEncodingutf8mb4。解决逐层检查。JSP 页面头部加pageEncodingUTF-8Servlet 里resp.setContentType(text/html;charsetUTF-8)JDBC URL 加useUnicodetruecharacterEncodingutf8mb4建表时指定DEFAULT CHARSETutf8mb4。四个地方全对齐乱码问题基本绝迹。4.2 数据库连接池耗尽现象是系统越用越慢原因是 Connection 没关闭现象系统刚启动正常跑半天后越来越慢最后报Cannot get a connection。原因JSPM 项目里很多新手直接在 Servlet 里DriverManager.getConnection()用完忘了close()。每次请求创建一个连接数据库最大连接数很快被打满。解决用连接池Druid 或 C3P0 都行。如果不想引入额外依赖至少把Connection、Statement、ResultSet的关闭放到finally块里。更好的做法是写一个DBUtil.close()静态方法统一处理DAO 层每个方法结束都调一次。4.3 叫号顺序错乱现象是号码跳着叫原因是排序字段类型不对现象柜员叫号时A010 还没叫A011 先出来了。原因ticket_no是 VARCHAR 类型ORDER BY ticket_no按字符串排序。当号码超过 999 变成四位数时A1000 会排在 A999 前面因为字符串比较是逐字符比的。解决加一个seq_no INT AUTO_INCREMENT字段查询时ORDER BY seq_no ASC。ticket_no只用于展示不参与排序。如果不想改表结构至少把号码位数固定成 4 位A0001 到 A9999这样字符串排序和数字排序结果一致。4.4 Tomcat 启动报 ClassNotFound现象是 404 或 500原因是 jar 包没放对位置现象项目在 IDE 里跑得好好的部署到 Tomcat 就报ClassNotFoundException。原因IDE 会自动把依赖 jar 加到 classpath但手动部署到 Tomcat 时jar 包必须放在WEB-INF/lib目录下。MySQL 驱动、JSON 库、连接池这些第三方 jar 一个都不能少。解决在项目根目录执行mvn dependency:copy-dependencies如果有 Maven或者手动把所有依赖 jar 复制到web/WEB-INF/lib。部署后检查 Tomcat 的logs/catalina.out缺哪个类就补哪个 jar。4.5 大屏轮询导致服务器卡顿现象是取号变慢原因是轮询频率太高现象大屏接上后取号页面响应明显变慢服务器 CPU 升高。原因每个大屏每 2 秒发一次请求10 个大屏就是每秒 5 次请求。如果每次请求都查数据库数据库压力成倍增加。解决在服务端加缓存叫号信息变化频率低可以用ConcurrentHashMap缓存每个窗口的当前叫号设置 3 秒过期。或者改用 WebSocket 推送只在叫号变化时推一次彻底消除轮询开销。如果不想大改至少把轮询间隔从 2 秒调到 5 秒并在 Servlet 里加Cache-Control响应头。5. 进阶技巧用状态机重构叫号逻辑与压测验证5.1 把散落的状态判断收进状态机原始代码里status字段的 0/1/2/3 散落在各个 Servlet 和 DAO 里改一个状态要翻好几个文件。我一般会抽一个TicketStateMachine类把状态流转规则集中管理public enum TicketState { WAITING(0), CALLED(1), FINISHED(2), TIMEOUT(3); private final int code; TicketState(int code) { this.code code; } public static TicketState fromCode(int code) { for (TicketState s : values()) { if (s.code code) return s; } throw new IllegalArgumentException(未知状态: code); } // 定义合法流转等待→已叫号→已办理等待→过号 public boolean canTransitionTo(TicketState target) { if (this WAITING target CALLED) return true; if (this CALLED target FINISHED) return true; if (this WAITING target TIMEOUT) return true; return false; } }这样每次更新状态前先调canTransitionTo非法流转直接抛异常。好处是业务规则显式化新人接手时看枚举就知道状态怎么走不用去翻 SQL 猜。5.2 用 JMeter 验证叫号并发叫号系统最怕的是并发取号时号码重复。用 JMeter 模拟 50 个线程同时取号测试项配置预期结果线程数5050 个不同号码Ramp-up1 秒1 秒内全部发出循环次数1每个线程取一次监听器聚合报告 结果树无重复 ticket_no如果出现重复号码说明countTodayByType加一那步有竞态。解决办法是在ticket表的ticket_no上加唯一索引插入冲突时捕获DuplicateKeyException并重试。重试次数设 3 次超过就返回“系统繁忙”。5.3 一个容易被忽略的细节过号后重新入队的位置过号客户重新取号时是排在队尾还是插到队首我见过有的系统直接插队首结果正常等待的客户投诉。合理的做法是给过号客户一个“优先但不等同于插队”的标记比如在队列里单独维护一个过号队列叫号时先叫过号队列再叫正常队列。这样既照顾了过号客户又不影响正常排队秩序。这个逻辑在QueueManager里加一个PriorityQueue就能实现关键是业务规则要和网点确认清楚代码只是执行。写这套系统最大的教训是别在状态字段上省设计。我一开始觉得 0/1/2/3 够用了后来加“暂停服务”“窗口关闭”这些状态时发现到处都要改 if-else。如果重来一次我会先把状态机画清楚再写代码。希望帮到你。本文还有配套的精品资源点击获取