简介这是一套基于 Java Web 的网络聊天室完整项目面向正在学习 Java 全栈开发、想通过真实案例掌握实时通信技术的开发者。项目中综合运用了前端页面构建、样式美化、脚本交互等界面技术以及后端框架、业务处理、会话保持、数据库读写、异步请求和双向通信等核心知识点可作为课程设计、毕业设计或求职作品集的直接参考。压缩包内共包含二百八十四个文件压缩后约二十三兆字节涵盖演示图片、程序库、页面脚本、配置说明等多种类型文件按功能模块组织便于逐层研读。目前已有二百一十八人学习浏览说明此项目具有一定人气。通过解压研读可以理清用户注册、登录校验、好友管理、消息实时收发等完整链路还能借鉴作者的分层设计思路与安全处理细节对提升动手能力很有帮助适合想通过实战巩固技术基础的学习者。1. 这个基于Javaweb的网络聊天室考你的不是聊天是对会话的理解一个基于Javaweb的网络聊天室zip包拿到手最常见的翻车点其实不在聊天逻辑而在先跑起来这一步。你很可能在课设、实训或转行自学的节点上选了它它能一次性串起Servlet、JSP、Filter、Session、JDBC和MySQL几乎把Javaweb的核心考点全占上。它适合两类人——急着交课程设计的学生和想把黑马Javaweb笔记里那些零散知识点拼成一个完整案例的人。别急着改代码先把它当黑匣子解剖一遍登录态怎么存、消息怎么广播、在线用户怎么维护这三件事弄透你才算真正拥有了这个项目而不是只会点运行按钮。2. 让 zip 里的项目跑起来IDEA 运行 Javaweb 项目的完整配置顺序2.1 解压后先分清这项目是 Maven 结构还是纯 lib 结构拿到zip先别双击导入。第一件事是打开解压目录看有没有pom.xml。这个判断决定了你在IDEA里的整个操作路径有pom.xml这是Maven工程IDEA用Open选中pom.xml或根目录等右下角进度条走完依赖会按pom里的坐标从中央仓库拉。没有pom.xml只有src目录和WebRoot或web、WebContent这是传统的裸Javaweb项目lib是打进WEB-INF下的jar包。导入时要手动Add as Library否则全屏飘红。我一般会优先选Maven结构的版本因为它解决了jar包管理问题。纯lib结构的坑是Tomcat运行时从WEB-INF/lib加载jar而IDEA默认用module的classpath编译两边jar不一致就会出现编译过了启动后ClassNotFoundException这种玄学报错。如果你手里是纯lib版本记得在IDEA里把WEB-INF/lib下的jar全部右键Add as Library并且在Project Structure的Artifacts里确认Output Layout包含了这些jar。这一步别急着启动Tomcat。先顺手看一眼web.xml或有没有WebServlet注解判断项目用的Servlet版本。Tomcat 8.5对应Servlet 3.1Tomcat 9对应4.0如果你用Tomcat 10传统javax包会被改成jakarta很多老项目直接起不来。建议直接用Tomcat 8.5或9别在版本上挑战自己。2.2 数据库脚本与连接配置三个最容易改错的地方聊天室项目一定依赖MySQL不可能用文件模拟在线和高频读写。先在MySQL里把库和表建好。常见的表结构分两张用户表和消息表。CREATE DATABASE chat_db DEFAULT CHARACTER SET utf8mb4; USE chat_db; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_message ( id INT PRIMARY KEY AUTO_INCREMENT, from_user VARCHAR(50) NOT NULL, to_user VARCHAR(50) DEFAULT all, content VARCHAR(1000) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明to_user用all表示群聊私聊时写对方用户名这比拆两张表简单idx_create_time是给历史消息分页查询用的索引没有它数据量到几千条后查询会明显变慢。表字符集一定要用utf8mb4只写utf8的话用户输入emoji时会被截断报错这是聊天场景的高频事故。建完表改JDBC配置。常见做法是放在src/jdbc.properties内容如下jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/chat_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password123456参数说明useUnicode和characterEncodingutf8是保证中文进出数据库不乱码的标配serverTimezoneAsia/Shanghai是因为MySQL 8的驱动强制要求时区不写会报Cannot create PoolableConnectionFactory。密码改成你自己本机的数据库名别改和SQL脚本保持一致。改完这三处字符集、时区、密码数据库这关就过了。如果你在导入项目后启动报错提到Access denied for user基本就是jdbc.properties里的用户名密码和你本机MySQL不一致和代码逻辑无关不用怀疑人生。2.3 在 IDEA 里配置 TomcatContext 路径、输出目录和 Artifact数据库通了剩最后一段路把Tomcat配置对。IDEA里Run - Edit Configurations - - Tomcat Server - Local然后按下面这张表核对缺哪个补哪个别一上来就Debug。配置项推荐值踩坑备注Application server指向你的Tomcat解压目录不是bin目录是Tomcat根目录Open browserAfter launch http://localhost:8080/chat/设一个固定入口省得每次手敲Deployment选中Artifact: 你的项目:war explodedwar exploded 比 war 好改代码不用反复打war包Application context/chat和浏览器访问路径严格一致JRE项目JDK版本项目编译用JDK 8就选8别选17硬跑老框架配置完点启动浏览器能打开登录页就算过了第一关。如果报Artifact is being deployed, please check logs去看Tomcat本地日志的catalina.out别只看IDEA控制台最后的几行真正的错误在堆栈中部。常见的有两种一是ClassNotFoundException: com.mysql.cj.jdbc.Driver说明mysql-connector.jar没打到Artifact里回2.1检查jar包是否进了Output Layout二是Unable to compile class for JSP说明JDK版本和项目不匹配按表格第四行调整。到这儿项目跑起来了才有资格谈聊天室的实现逻辑。注意如果你在正式写任何业务代码前就连启动都过不去九成是上面2.1和2.2的结构判断出错回头重看一遍不要急着找代码里的bug。3. 消息怎么走登录拦截、在线用户与两种消息推送方式的实现3.1 登录会话怎么管Session 绑定 Filter 拦截的最小实现聊天室和静态网页的区别在于它得知道谁在说话。Javaweb里这个谁就是HttpSession。登录验证通过后把查出来的User对象放进Session后续每个请求都能从Session里取回当前用户。WebServlet(/login) public class LoginServlet extends HttpServlet { Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 先解决POST乱码再取参数 req.setCharacterEncoding(UTF-8); String username req.getParameter(username); String password req.getParameter(password); // 参数绑定查询别自己拼SQL字符串 User user UserDao.findByUsernameAndPassword(username, password); if (user null) { req.setAttribute(error, 用户名或密码不对); req.getRequestDispatcher(/login.jsp).forward(req, resp); return; } // 登录成功的标志把用户挂进Session HttpSession session req.getSession(); session.setAttribute(loginUser, user); resp.sendRedirect(req.getContextPath() /chat.jsp); } }逻辑说明第一行setCharacterEncoding(UTF-8)只对POST请求体生效必须写在读取第一个参数之前否则中文用户名直接乱码。findByUsernameAndPassword用PreparedStatement做参数绑定不是为了炫技而是防SQL注入——用户名里带个 or 11能直接绕过登录这是聊天室这类公开项目最常被攻击的点。最后sendRedirect用重定向而不是forward是为了让浏览器地址栏变成chat.jsp用户刷新聊天页不会重复提交登录表单这是个很小的体验细节。Session有了还差一层拦截。不然用户直接在地址栏敲/chat.jsp也能进聊天室登录验证就白做了。用一个Filter统一拦截WebFilter(/*) public class LoginFilter implements Filter { Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; String uri request.getRequestURI(); // 白名单登录页、登录接口、静态资源放行 if (uri.endsWith(/login.jsp) || uri.endsWith(/login) || uri.contains(/static/)) { chain.doFilter(req, resp); return; } // 核心判断Session里没有loginUser就回登录页 HttpSession session request.getSession(false); if (session null || session.getAttribute(loginUser) null) { response.sendRedirect(request.getContextPath() /login.jsp); return; } chain.doFilter(req, resp); } }参数说明request.getSession(false)很关键带false表示没有Session时返回null而不是新建一个——否则每次被拦截的请求都会自动创建一个无用Session内存白白被吃。白名单里的/static/要看你项目静态资源放哪如果CSS、JS在webapp根目录下没做子目录就得换成放行.css、.js、.png等后缀判断。这个Filter过滤的是所有请求聊天消息的轮询接口和WebSocket握手地址也要放进白名单不然用户聊着聊着突然被302踢回登录页。3.2 消息广播的两条路线轮询的性价比和 WebSocket 的直连聊天室最核心的问题是消息怎么从A到B。Javaweb里有两条路你要根据手里项目的技术栈选不要照抄。第一条路是HTTP轮询也是很多zip里默认的做法。前端用一个setInterval每2秒调一次Servlet接口拉取最新消息并渲染到页面上。后端接口长这样WebServlet(/loadMessages) public class LoadMessagesServlet extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { req.setCharacterEncoding(UTF-8); // lastId是前端记住的最后一条消息ID做增量拉取 int lastId Integer.parseInt(req.getParameter(lastId)); ListMessage messages MessageDao.findNewerThan(lastId, 50); resp.setContentType(application/json;charsetUTF-8); StringBuilder json new StringBuilder([); for (int i 0; i messages.size(); i) { Message m messages.get(i); if (i 0) json.append(,); json.append(String.format( {\id\:%d,\fromUser\:\%s\,\content\:\%s\}, m.getId(), m.getFromUser(), m.getContent())); } json.append(]); resp.getWriter().write(json.toString()); } }逻辑说明增量拉取的核心是lastId参数。前端保存上次拉到的最大消息ID每次只取比它新的消息避免每次返回全表数据。limit 50是保护就算某次lastId丢失最多拉回50条不会把整个表压到响应里。这个接口是高频接口——每2秒一次在聊天室这种场景下它比WebSocket轻得多实现也不依赖Tomcat的WebSocket容器部署到任何Javaweb服务器都能跑。第二条路是WebSocket适合追求实时性的项目。不同点在于HTTP轮询每次都要建立请求、服务器压数据库查消息、返回、断开2秒的延迟肉眼可见WebSocket建立一次连接后服务器可以直接把消息推给所有客户端。这也是Javaweb完整案例里显得更高级的做法ServerEndpoint(/chatSocket) public class ChatWebSocket { // 在线客户端表key是用户名value是WebSocket会话 private static ConcurrentHashMapString, Session clients new ConcurrentHashMap(); OnOpen public void onOpen(Session session) { // 握手URL带上登录用户名解决WebSocket拿不到HttpSession的问题 String query session.getQueryString(); String username query.split()[1]; clients.put(username, session); } OnMessage public void onMessage(String message, Session session) throws IOException { // 服务器收到后广播给所有在线客户端 for (Session s : clients.values()) { if (s.isOpen()) { s.getBasicRemote().sendText(message); } } } OnClose public void onClose(Session session) { clients.values().remove(session); } }逻辑说明ServerEndpoint是javax.websocket的注解Tomcat 8.5原生支持。WebSocket的Session和HttpSession不是一回事直接在OnOpen里拿HttpSession是不行的所以常见做法是前端连接时把用户名拼在URL上服务端从query string解析。广播用了ConcurrentHashMap遍历每次遍历前不用加锁这个类内部按段加了锁并发安全。发消息前判isOpen()防止向已经关闭的会话写数据抛IOException——这条血泪经验来自线上翻车不判的话用户关浏览器瞬间下一轮广播就会炸出一屏幕异常。选型建议如果zip里是轮询实现别急着改成WebSocket轮询在几十人课设规模下完全够用。改成WebSocket反而会引入断连重连心跳保活一堆新问题详见下一章避坑。如果你是为了答辩吹项目亮点保留轮询作为降级方案主推WebSocket才是正确姿势。3.3 在线用户表为什么会崩ConcurrentHashMap 的正确用法聊天室的聊天框旁边通常有在线用户列表这个列表在并发下是最容易出bug的地方。很多zip里的写法是public static HashMapString, HttpSession onlineUsers new HashMap();这个写法在单线程测试时没问题但Javaweb的Servlet是多线程的两个用户同时上线各自线程同时往HashMap里写轻则覆盖重则在扩容时形成环形链表CPU直接打满100%。正确做法是换ConcurrentHashMappublic class OnlineUserManager { // key: 用户名value: 该用户的所有会话集合 private static ConcurrentHashMapString, CopyOnWriteArrayListHttpSession online new ConcurrentHashMap(); public static void add(String username, HttpSession session) { CopyOnWriteArrayListHttpSession sessions online.computeIfAbsent(username, k - new CopyOnWriteArrayList()); sessions.add(session); } public static void remove(String username) { online.remove(username); } public static ListString allNames() { return Collections.list(online.keys()); } }参数说明computeIfAbsent保证同一个用户名第一次加入时原子地创建列表不会出现两个线程同时put同一个key一个覆盖另一个的情况。value用CopyOnWriteArrayList是因为在线列表的读操作别人看谁在线远多于写操作这个集合读不加锁、写在语义上隔离正好贴合场景。HttpSession存进去的用途是后续做管理员踢人下线——调session.invalidate()就可以远程把某个用户踢掉回答辩时这是个加分项。这段代码放在application作用域还是静态类里都行常见做法是被一个WebListener的ServletContextListener持有这样整个应用只有一份实例线程安全由容器保证。别把在线列表放数据库那会让在线失去实时语义每次查询还要扛硬盘延迟没有任何必要。4. 聊天室避坑记录乱码、掉线、同账号互踢与连接泄漏4.1 中文全变问号请求、响应、JDBC 四处编码要一起改现象登录时输入中文昵称数据库里显示???聊天框发中文别人看到的是乱码页面正常但消息却先乱码再入库。原因聊天项目的中文要过四道门——请求编码、响应编码、JDBC连接编码、数据库表编码。任何一道门是默认ISO-8859-1中文到这就被截断成问号。最常见的是省略了MySQL连接参数的characterEncodingutf8或者建表用了默认latin1。解决按4个位置逐一检查。请求用Filter统一做编码转换响应统一显式声明charsetJDBC连接串加characterEncodingutf8建表语句显式DEFAULT CHARSETutf8mb4。改完重启Tomcat再发一条中文测试消息如果库里正常、页面正常才算关干净。如果数据库里还是乱码查连接串和表结构别再看Java代码——这两处最隐蔽。4.2 WebSocket 说断就断闲置两分钟后浏览器掉线现象用WebSocket版聊天室打开页面挂机两分钟回来发消息完全没反应。控制台看WebSocket连接已经是CLOSED状态日志里出现The remote endpoint was in state [TEXT_PARTIAL_WRITING]或类似报错。原因Tomcat 8.5默认的WebSocket会话空闲超时是120秒。在这期间没有消息交互容器会主动关闭连接。这是很多WebSocket项目稳定掉线的头号原因不是你的业务代码写错了。解决在OnOpen里把最大空闲时间设大或置0OnOpen public void onOpen(Session session) { session.setMaxIdleTimeout(0); // 0表示不限制 String username session.getQueryString().split()[1]; clients.put(username, session); }参数说明setMaxIdleTimeout(0)会让服务器不主动关空闲连接但网络设备可能仍然在意闲连接所以前端再补一个保活逻辑每30秒发送一个心跳包服务端收到心跳只更新时间不广播避免打扰别人。心跳用JSON包裹比如{type:ping}服务端在OnMessage里判断type是ping就return不进入广播流程。这两件事一起做掉线问题才算根治。4.3 同账号多窗口一个窗口登录把另一个窗口踢下线现象同一账号在Chrome普通窗口和隐身窗口各开一个聊天室后开的窗口刚连上先开的窗口就被踢回登录页。或者反过来先开的窗口一刷新后开的窗口不能发消息。原因在线用户表用ConcurrentHashMapString, HttpSession只存了一个Session新登录的同名用户put进去就把旧Session覆盖了。旧窗口的下一个请求从Session里取不到loginUserFilter判断未登录302回登录页。这是把用户名和单会话强绑定的典型后果。解决两种情况二选一。如果项目定位是游戏大厅式单端登录那你需要在LoginServlet里记录旧Session并invalidate()新登录直接顶掉旧的业务逻辑简单明了。如果是要允许多人同时登录就把在线表改成我在3.3节推荐的ConcurrentHashMapString, CopyOnWriteArrayListHttpSession同一个用户名存多个Session。发消息时遍历这个用户的所有Session这样一个窗口说话该账号的所有窗口都能收到自己发的内容体验更接近微信网页版。4.4 Too many connections连接池没配跑了半天数据库崩了现象项目早上启动正常午饭后开始报Too many connections重启Tomcat能好一阵过几小时又复发。数据库重启后短暂恢复正常User表才几百行不至于有性能问题。原因代码里用DriverManager.getConnection()拿连接用完没finally close()。每个请求都新建物理连接消息轮询每2秒一次积累半天就把MySQL默认的151个连接数打满了。这是Javaweb项目最常见也最低级的血泪坑——不一定是这段代码写的但每一个打开连接没关的地方都是嫌疑人。解决立刻检查所有Dao类凡是getConnection和close跨了方法边界的都有泄漏风险。最小改动是改成try-with-resourcestry (Connection conn getConn(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { // 查询逻辑 } catch (SQLException e) { log.error(查询失败, e); }逻辑说明try-with-resources会在代码块结束后按逆序自动关闭rs、ps、conn比手写finally里一层层判空close要可靠得多。更进一步的方案是引入Druid或HikariCP连接池把连接数上限固定比如配置initialSize5, maxActive20让多个请求复用一组物理连接。连接池对聊天室这种高频率短连接场景收益明显消息轮询的连接开销会从每次新建物理连接降为从池里借一次。如果你来不及改连接池至少把所有Dao的close逻辑统一排查一遍能挡住90%的泄漏。5. 验收前加两个小改造敏感词入库前过滤与双开多账号验证5.1 敏感词过滤在消息写入前统一做聊天室项目答辩时老师大概率会问如果有人发不当内容怎么办。与其当场编不如在消息Dao写入前加一寸过滤public class SensitiveFilter { private static ListString words Arrays.asList(词1, 词2, 词3); public static String filter(String content) { String result content; for (String word : words) { result result.replace(word, **); } return result; } }调用时在MessageDao.insert前一行执行content SensitiveFilter.filter(content)保证库里和页面上都是过滤后的内容。词表先放List之后拆到数据库或文件都行。这个小过滤逻辑不复杂但在方案里体现了内容安全设计是Databases之外的加分项。词表放内存意味着改动要重启量大了可以换Trie树算法现阶段不必上。5.2 用两个浏览器三个账号按清单跑满一小时验收不能只自己对着一个窗口点。打开Chrome普通窗口、隐身窗口和Edge窗口注册user1、user2、user3按下面顺序跑一遍三个账号互发群聊消息确认每个窗口都能看到顺序不乱。用user1给user2发私聊确认user3看不到。把user3的窗口关闭30秒后看在线列表是否移除该用户重新登录确认能加回。挂着user1窗口离开5分钟回来发一条消息确认WebSocket没掉线或者轮询正常拉取。刷新任意聊天窗口确认历史消息能加载出最近20条且lastId逻辑没有重复加载。去MySQL执行SELECT * FROM t_message ORDER BY id DESC LIMIT 5;确认每条消息都有正确的from_user、to_user和content。这套清单跑完功能性验收基本闭环。我自己的习惯是最后再检查一遍Tomcat日志里是否有红色异常哪怕功能正常也不放过——很多线上问题都藏在这些被忽略的堆栈里。这一步做完再提交你能比同组人多一份底气。希望帮到你。本文还有配套的精品资源点击获取
基于JavaWeb的网络聊天室：从运行配置到会话与消息推送全解析
简介这是一套基于 Java Web 的网络聊天室完整项目面向正在学习 Java 全栈开发、想通过真实案例掌握实时通信技术的开发者。项目中综合运用了前端页面构建、样式美化、脚本交互等界面技术以及后端框架、业务处理、会话保持、数据库读写、异步请求和双向通信等核心知识点可作为课程设计、毕业设计或求职作品集的直接参考。压缩包内共包含二百八十四个文件压缩后约二十三兆字节涵盖演示图片、程序库、页面脚本、配置说明等多种类型文件按功能模块组织便于逐层研读。目前已有二百一十八人学习浏览说明此项目具有一定人气。通过解压研读可以理清用户注册、登录校验、好友管理、消息实时收发等完整链路还能借鉴作者的分层设计思路与安全处理细节对提升动手能力很有帮助适合想通过实战巩固技术基础的学习者。1. 这个基于Javaweb的网络聊天室考你的不是聊天是对会话的理解一个基于Javaweb的网络聊天室zip包拿到手最常见的翻车点其实不在聊天逻辑而在先跑起来这一步。你很可能在课设、实训或转行自学的节点上选了它它能一次性串起Servlet、JSP、Filter、Session、JDBC和MySQL几乎把Javaweb的核心考点全占上。它适合两类人——急着交课程设计的学生和想把黑马Javaweb笔记里那些零散知识点拼成一个完整案例的人。别急着改代码先把它当黑匣子解剖一遍登录态怎么存、消息怎么广播、在线用户怎么维护这三件事弄透你才算真正拥有了这个项目而不是只会点运行按钮。2. 让 zip 里的项目跑起来IDEA 运行 Javaweb 项目的完整配置顺序2.1 解压后先分清这项目是 Maven 结构还是纯 lib 结构拿到zip先别双击导入。第一件事是打开解压目录看有没有pom.xml。这个判断决定了你在IDEA里的整个操作路径有pom.xml这是Maven工程IDEA用Open选中pom.xml或根目录等右下角进度条走完依赖会按pom里的坐标从中央仓库拉。没有pom.xml只有src目录和WebRoot或web、WebContent这是传统的裸Javaweb项目lib是打进WEB-INF下的jar包。导入时要手动Add as Library否则全屏飘红。我一般会优先选Maven结构的版本因为它解决了jar包管理问题。纯lib结构的坑是Tomcat运行时从WEB-INF/lib加载jar而IDEA默认用module的classpath编译两边jar不一致就会出现编译过了启动后ClassNotFoundException这种玄学报错。如果你手里是纯lib版本记得在IDEA里把WEB-INF/lib下的jar全部右键Add as Library并且在Project Structure的Artifacts里确认Output Layout包含了这些jar。这一步别急着启动Tomcat。先顺手看一眼web.xml或有没有WebServlet注解判断项目用的Servlet版本。Tomcat 8.5对应Servlet 3.1Tomcat 9对应4.0如果你用Tomcat 10传统javax包会被改成jakarta很多老项目直接起不来。建议直接用Tomcat 8.5或9别在版本上挑战自己。2.2 数据库脚本与连接配置三个最容易改错的地方聊天室项目一定依赖MySQL不可能用文件模拟在线和高频读写。先在MySQL里把库和表建好。常见的表结构分两张用户表和消息表。CREATE DATABASE chat_db DEFAULT CHARACTER SET utf8mb4; USE chat_db; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_message ( id INT PRIMARY KEY AUTO_INCREMENT, from_user VARCHAR(50) NOT NULL, to_user VARCHAR(50) DEFAULT all, content VARCHAR(1000) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明to_user用all表示群聊私聊时写对方用户名这比拆两张表简单idx_create_time是给历史消息分页查询用的索引没有它数据量到几千条后查询会明显变慢。表字符集一定要用utf8mb4只写utf8的话用户输入emoji时会被截断报错这是聊天场景的高频事故。建完表改JDBC配置。常见做法是放在src/jdbc.properties内容如下jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/chat_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password123456参数说明useUnicode和characterEncodingutf8是保证中文进出数据库不乱码的标配serverTimezoneAsia/Shanghai是因为MySQL 8的驱动强制要求时区不写会报Cannot create PoolableConnectionFactory。密码改成你自己本机的数据库名别改和SQL脚本保持一致。改完这三处字符集、时区、密码数据库这关就过了。如果你在导入项目后启动报错提到Access denied for user基本就是jdbc.properties里的用户名密码和你本机MySQL不一致和代码逻辑无关不用怀疑人生。2.3 在 IDEA 里配置 TomcatContext 路径、输出目录和 Artifact数据库通了剩最后一段路把Tomcat配置对。IDEA里Run - Edit Configurations - - Tomcat Server - Local然后按下面这张表核对缺哪个补哪个别一上来就Debug。配置项推荐值踩坑备注Application server指向你的Tomcat解压目录不是bin目录是Tomcat根目录Open browserAfter launch http://localhost:8080/chat/设一个固定入口省得每次手敲Deployment选中Artifact: 你的项目:war explodedwar exploded 比 war 好改代码不用反复打war包Application context/chat和浏览器访问路径严格一致JRE项目JDK版本项目编译用JDK 8就选8别选17硬跑老框架配置完点启动浏览器能打开登录页就算过了第一关。如果报Artifact is being deployed, please check logs去看Tomcat本地日志的catalina.out别只看IDEA控制台最后的几行真正的错误在堆栈中部。常见的有两种一是ClassNotFoundException: com.mysql.cj.jdbc.Driver说明mysql-connector.jar没打到Artifact里回2.1检查jar包是否进了Output Layout二是Unable to compile class for JSP说明JDK版本和项目不匹配按表格第四行调整。到这儿项目跑起来了才有资格谈聊天室的实现逻辑。注意如果你在正式写任何业务代码前就连启动都过不去九成是上面2.1和2.2的结构判断出错回头重看一遍不要急着找代码里的bug。3. 消息怎么走登录拦截、在线用户与两种消息推送方式的实现3.1 登录会话怎么管Session 绑定 Filter 拦截的最小实现聊天室和静态网页的区别在于它得知道谁在说话。Javaweb里这个谁就是HttpSession。登录验证通过后把查出来的User对象放进Session后续每个请求都能从Session里取回当前用户。WebServlet(/login) public class LoginServlet extends HttpServlet { Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 先解决POST乱码再取参数 req.setCharacterEncoding(UTF-8); String username req.getParameter(username); String password req.getParameter(password); // 参数绑定查询别自己拼SQL字符串 User user UserDao.findByUsernameAndPassword(username, password); if (user null) { req.setAttribute(error, 用户名或密码不对); req.getRequestDispatcher(/login.jsp).forward(req, resp); return; } // 登录成功的标志把用户挂进Session HttpSession session req.getSession(); session.setAttribute(loginUser, user); resp.sendRedirect(req.getContextPath() /chat.jsp); } }逻辑说明第一行setCharacterEncoding(UTF-8)只对POST请求体生效必须写在读取第一个参数之前否则中文用户名直接乱码。findByUsernameAndPassword用PreparedStatement做参数绑定不是为了炫技而是防SQL注入——用户名里带个 or 11能直接绕过登录这是聊天室这类公开项目最常被攻击的点。最后sendRedirect用重定向而不是forward是为了让浏览器地址栏变成chat.jsp用户刷新聊天页不会重复提交登录表单这是个很小的体验细节。Session有了还差一层拦截。不然用户直接在地址栏敲/chat.jsp也能进聊天室登录验证就白做了。用一个Filter统一拦截WebFilter(/*) public class LoginFilter implements Filter { Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; String uri request.getRequestURI(); // 白名单登录页、登录接口、静态资源放行 if (uri.endsWith(/login.jsp) || uri.endsWith(/login) || uri.contains(/static/)) { chain.doFilter(req, resp); return; } // 核心判断Session里没有loginUser就回登录页 HttpSession session request.getSession(false); if (session null || session.getAttribute(loginUser) null) { response.sendRedirect(request.getContextPath() /login.jsp); return; } chain.doFilter(req, resp); } }参数说明request.getSession(false)很关键带false表示没有Session时返回null而不是新建一个——否则每次被拦截的请求都会自动创建一个无用Session内存白白被吃。白名单里的/static/要看你项目静态资源放哪如果CSS、JS在webapp根目录下没做子目录就得换成放行.css、.js、.png等后缀判断。这个Filter过滤的是所有请求聊天消息的轮询接口和WebSocket握手地址也要放进白名单不然用户聊着聊着突然被302踢回登录页。3.2 消息广播的两条路线轮询的性价比和 WebSocket 的直连聊天室最核心的问题是消息怎么从A到B。Javaweb里有两条路你要根据手里项目的技术栈选不要照抄。第一条路是HTTP轮询也是很多zip里默认的做法。前端用一个setInterval每2秒调一次Servlet接口拉取最新消息并渲染到页面上。后端接口长这样WebServlet(/loadMessages) public class LoadMessagesServlet extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { req.setCharacterEncoding(UTF-8); // lastId是前端记住的最后一条消息ID做增量拉取 int lastId Integer.parseInt(req.getParameter(lastId)); ListMessage messages MessageDao.findNewerThan(lastId, 50); resp.setContentType(application/json;charsetUTF-8); StringBuilder json new StringBuilder([); for (int i 0; i messages.size(); i) { Message m messages.get(i); if (i 0) json.append(,); json.append(String.format( {\id\:%d,\fromUser\:\%s\,\content\:\%s\}, m.getId(), m.getFromUser(), m.getContent())); } json.append(]); resp.getWriter().write(json.toString()); } }逻辑说明增量拉取的核心是lastId参数。前端保存上次拉到的最大消息ID每次只取比它新的消息避免每次返回全表数据。limit 50是保护就算某次lastId丢失最多拉回50条不会把整个表压到响应里。这个接口是高频接口——每2秒一次在聊天室这种场景下它比WebSocket轻得多实现也不依赖Tomcat的WebSocket容器部署到任何Javaweb服务器都能跑。第二条路是WebSocket适合追求实时性的项目。不同点在于HTTP轮询每次都要建立请求、服务器压数据库查消息、返回、断开2秒的延迟肉眼可见WebSocket建立一次连接后服务器可以直接把消息推给所有客户端。这也是Javaweb完整案例里显得更高级的做法ServerEndpoint(/chatSocket) public class ChatWebSocket { // 在线客户端表key是用户名value是WebSocket会话 private static ConcurrentHashMapString, Session clients new ConcurrentHashMap(); OnOpen public void onOpen(Session session) { // 握手URL带上登录用户名解决WebSocket拿不到HttpSession的问题 String query session.getQueryString(); String username query.split()[1]; clients.put(username, session); } OnMessage public void onMessage(String message, Session session) throws IOException { // 服务器收到后广播给所有在线客户端 for (Session s : clients.values()) { if (s.isOpen()) { s.getBasicRemote().sendText(message); } } } OnClose public void onClose(Session session) { clients.values().remove(session); } }逻辑说明ServerEndpoint是javax.websocket的注解Tomcat 8.5原生支持。WebSocket的Session和HttpSession不是一回事直接在OnOpen里拿HttpSession是不行的所以常见做法是前端连接时把用户名拼在URL上服务端从query string解析。广播用了ConcurrentHashMap遍历每次遍历前不用加锁这个类内部按段加了锁并发安全。发消息前判isOpen()防止向已经关闭的会话写数据抛IOException——这条血泪经验来自线上翻车不判的话用户关浏览器瞬间下一轮广播就会炸出一屏幕异常。选型建议如果zip里是轮询实现别急着改成WebSocket轮询在几十人课设规模下完全够用。改成WebSocket反而会引入断连重连心跳保活一堆新问题详见下一章避坑。如果你是为了答辩吹项目亮点保留轮询作为降级方案主推WebSocket才是正确姿势。3.3 在线用户表为什么会崩ConcurrentHashMap 的正确用法聊天室的聊天框旁边通常有在线用户列表这个列表在并发下是最容易出bug的地方。很多zip里的写法是public static HashMapString, HttpSession onlineUsers new HashMap();这个写法在单线程测试时没问题但Javaweb的Servlet是多线程的两个用户同时上线各自线程同时往HashMap里写轻则覆盖重则在扩容时形成环形链表CPU直接打满100%。正确做法是换ConcurrentHashMappublic class OnlineUserManager { // key: 用户名value: 该用户的所有会话集合 private static ConcurrentHashMapString, CopyOnWriteArrayListHttpSession online new ConcurrentHashMap(); public static void add(String username, HttpSession session) { CopyOnWriteArrayListHttpSession sessions online.computeIfAbsent(username, k - new CopyOnWriteArrayList()); sessions.add(session); } public static void remove(String username) { online.remove(username); } public static ListString allNames() { return Collections.list(online.keys()); } }参数说明computeIfAbsent保证同一个用户名第一次加入时原子地创建列表不会出现两个线程同时put同一个key一个覆盖另一个的情况。value用CopyOnWriteArrayList是因为在线列表的读操作别人看谁在线远多于写操作这个集合读不加锁、写在语义上隔离正好贴合场景。HttpSession存进去的用途是后续做管理员踢人下线——调session.invalidate()就可以远程把某个用户踢掉回答辩时这是个加分项。这段代码放在application作用域还是静态类里都行常见做法是被一个WebListener的ServletContextListener持有这样整个应用只有一份实例线程安全由容器保证。别把在线列表放数据库那会让在线失去实时语义每次查询还要扛硬盘延迟没有任何必要。4. 聊天室避坑记录乱码、掉线、同账号互踢与连接泄漏4.1 中文全变问号请求、响应、JDBC 四处编码要一起改现象登录时输入中文昵称数据库里显示???聊天框发中文别人看到的是乱码页面正常但消息却先乱码再入库。原因聊天项目的中文要过四道门——请求编码、响应编码、JDBC连接编码、数据库表编码。任何一道门是默认ISO-8859-1中文到这就被截断成问号。最常见的是省略了MySQL连接参数的characterEncodingutf8或者建表用了默认latin1。解决按4个位置逐一检查。请求用Filter统一做编码转换响应统一显式声明charsetJDBC连接串加characterEncodingutf8建表语句显式DEFAULT CHARSETutf8mb4。改完重启Tomcat再发一条中文测试消息如果库里正常、页面正常才算关干净。如果数据库里还是乱码查连接串和表结构别再看Java代码——这两处最隐蔽。4.2 WebSocket 说断就断闲置两分钟后浏览器掉线现象用WebSocket版聊天室打开页面挂机两分钟回来发消息完全没反应。控制台看WebSocket连接已经是CLOSED状态日志里出现The remote endpoint was in state [TEXT_PARTIAL_WRITING]或类似报错。原因Tomcat 8.5默认的WebSocket会话空闲超时是120秒。在这期间没有消息交互容器会主动关闭连接。这是很多WebSocket项目稳定掉线的头号原因不是你的业务代码写错了。解决在OnOpen里把最大空闲时间设大或置0OnOpen public void onOpen(Session session) { session.setMaxIdleTimeout(0); // 0表示不限制 String username session.getQueryString().split()[1]; clients.put(username, session); }参数说明setMaxIdleTimeout(0)会让服务器不主动关空闲连接但网络设备可能仍然在意闲连接所以前端再补一个保活逻辑每30秒发送一个心跳包服务端收到心跳只更新时间不广播避免打扰别人。心跳用JSON包裹比如{type:ping}服务端在OnMessage里判断type是ping就return不进入广播流程。这两件事一起做掉线问题才算根治。4.3 同账号多窗口一个窗口登录把另一个窗口踢下线现象同一账号在Chrome普通窗口和隐身窗口各开一个聊天室后开的窗口刚连上先开的窗口就被踢回登录页。或者反过来先开的窗口一刷新后开的窗口不能发消息。原因在线用户表用ConcurrentHashMapString, HttpSession只存了一个Session新登录的同名用户put进去就把旧Session覆盖了。旧窗口的下一个请求从Session里取不到loginUserFilter判断未登录302回登录页。这是把用户名和单会话强绑定的典型后果。解决两种情况二选一。如果项目定位是游戏大厅式单端登录那你需要在LoginServlet里记录旧Session并invalidate()新登录直接顶掉旧的业务逻辑简单明了。如果是要允许多人同时登录就把在线表改成我在3.3节推荐的ConcurrentHashMapString, CopyOnWriteArrayListHttpSession同一个用户名存多个Session。发消息时遍历这个用户的所有Session这样一个窗口说话该账号的所有窗口都能收到自己发的内容体验更接近微信网页版。4.4 Too many connections连接池没配跑了半天数据库崩了现象项目早上启动正常午饭后开始报Too many connections重启Tomcat能好一阵过几小时又复发。数据库重启后短暂恢复正常User表才几百行不至于有性能问题。原因代码里用DriverManager.getConnection()拿连接用完没finally close()。每个请求都新建物理连接消息轮询每2秒一次积累半天就把MySQL默认的151个连接数打满了。这是Javaweb项目最常见也最低级的血泪坑——不一定是这段代码写的但每一个打开连接没关的地方都是嫌疑人。解决立刻检查所有Dao类凡是getConnection和close跨了方法边界的都有泄漏风险。最小改动是改成try-with-resourcestry (Connection conn getConn(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { // 查询逻辑 } catch (SQLException e) { log.error(查询失败, e); }逻辑说明try-with-resources会在代码块结束后按逆序自动关闭rs、ps、conn比手写finally里一层层判空close要可靠得多。更进一步的方案是引入Druid或HikariCP连接池把连接数上限固定比如配置initialSize5, maxActive20让多个请求复用一组物理连接。连接池对聊天室这种高频率短连接场景收益明显消息轮询的连接开销会从每次新建物理连接降为从池里借一次。如果你来不及改连接池至少把所有Dao的close逻辑统一排查一遍能挡住90%的泄漏。5. 验收前加两个小改造敏感词入库前过滤与双开多账号验证5.1 敏感词过滤在消息写入前统一做聊天室项目答辩时老师大概率会问如果有人发不当内容怎么办。与其当场编不如在消息Dao写入前加一寸过滤public class SensitiveFilter { private static ListString words Arrays.asList(词1, 词2, 词3); public static String filter(String content) { String result content; for (String word : words) { result result.replace(word, **); } return result; } }调用时在MessageDao.insert前一行执行content SensitiveFilter.filter(content)保证库里和页面上都是过滤后的内容。词表先放List之后拆到数据库或文件都行。这个小过滤逻辑不复杂但在方案里体现了内容安全设计是Databases之外的加分项。词表放内存意味着改动要重启量大了可以换Trie树算法现阶段不必上。5.2 用两个浏览器三个账号按清单跑满一小时验收不能只自己对着一个窗口点。打开Chrome普通窗口、隐身窗口和Edge窗口注册user1、user2、user3按下面顺序跑一遍三个账号互发群聊消息确认每个窗口都能看到顺序不乱。用user1给user2发私聊确认user3看不到。把user3的窗口关闭30秒后看在线列表是否移除该用户重新登录确认能加回。挂着user1窗口离开5分钟回来发一条消息确认WebSocket没掉线或者轮询正常拉取。刷新任意聊天窗口确认历史消息能加载出最近20条且lastId逻辑没有重复加载。去MySQL执行SELECT * FROM t_message ORDER BY id DESC LIMIT 5;确认每条消息都有正确的from_user、to_user和content。这套清单跑完功能性验收基本闭环。我自己的习惯是最后再检查一遍Tomcat日志里是否有红色异常哪怕功能正常也不放过——很多线上问题都藏在这些被忽略的堆栈里。这一步做完再提交你能比同组人多一份底气。希望帮到你。本文还有配套的精品资源点击获取
