简介这份Java网络聊天室项目源码面向学习Java网络编程、Socket通信、多线程与数据库应用的初中级开发者可作为课程设计、毕业设计或综合实训的参考案例。压缩包共46个文件约199KB包含7个java源文件、20个class编译文件及jpg界面截图、txt说明、db数据库等便于读者对照源码、运行结果和说明理解整体实现。已有195人学习下载说明该案例具备一定的参考价值。内容围绕客户端与服务器端通信展开涵盖Socket连接与消息广播、多线程处理并发连接、用户注册登录与数据库校验、聊天记录存储以及多人聊天在线状态管理等关键环节并保留调试与异常处理思路。读者可据此梳理聊天室从连接建立到消息分发的完整流程学习网络通信、并发控制和数据持久化的组织方式适合作为动手实践与查漏补缺的素材。1. 需求先立住为什么一个 Java 网络聊天室值得认真做很多人做 Java 网络聊天室的第一反应是打开教程抄一段ServerSocketaccept()的代码跑通「服务端收一行、客户端显示一行」就交差。真到答辩现场被问一句「两个客户端同时发消息会怎么样」程序当场卡死——这就是单线程阻塞模型的宿命。网络通信、多线程、数据库这三件事凑在一起才构成一个能拿得出手的方案Socket 决定消息怎么在网络里跑多线程决定成百上千的连接怎么互不拖累数据库决定聊天记录、用户账号、离线消息这些「有状态」的东西存在哪。这套方案适合三类人正在做 Java 课程设计需要一套完整结构的学生、准备毕设想找一个可扩展题目的同学以及想把 BIO/NIO 模型吃透的初级后端。下面按需求、设计、实现、避坑、验收的顺序把整套东西拆开讲。2. 总体架构设计三层职责划分与消息流转模型2.1 从「一个 accept 循环」升级到三层结构单文件版的聊天室最典型的结构是main方法里一个while(true)不断accept()拿到 Socket 后直接在当前线程读数据。它只能服务一个人第二个人连上后必须等第一个人断开。合格的方案要做的第一件事是把「接入」「连接管理」「业务处理」三件事拆开。我一般把服务端切成三层接入层负责监听端口、接受连接、把 Socket 交给连接管理器。这一层只做搬运不做业务。连接管理层维护一个在线客户端集合线程安全负责连接的上线与下线、心跳检测、消息广播的遍历。业务层负责登录鉴权、私聊路由、群聊分发、消息落库、离线消息补发。这样分层以后每个类的职责足够窄。接入层改端口不影响业务业务层换存储不影响通信。客户端那边同理拆成「网络收发」「界面刷新」「本地缓存」三块UI 线程绝对不能直接读 Socket否则界面会跟着堵塞。2.2 消息协议设计一条消息到底长什么样裸 Socket 传的是字节流TCP 只保证字节顺序不保证「一次 read 就是一条完整消息」。如果客户端发hello服务端read到的可能是hel下一次才是lo。这是新手最容易翻车的地方之一也是必须自己定协议的原因。我采用的方案是「长度前缀 JSON 载荷」即每条消息先写 4 个字节的 int表示 body 长度再写 body 的 UTF-8 字节。body 用 JSON字段固定{ type: PRIVATE, from: 1001, to: 1002, content: 在吗, timestamp: 1710000000000, token: 登录后下发的会话凭证 }type枚举我通常定这几个LOGIN、LOGOUT、PUBLIC群聊、PRIVATE私聊、HEARTBEAT心跳、HISTORY_REQ拉历史记录、HISTORY_RESP、ERROR。字段token只在登录后携带用于服务端校验身份避免客户端伪造from。为什么不用 Java 原生序列化因为它把类结构绑死在两端客户端换个版本就InvalidClassException而且体积大、不可读、有安全风险。JSON 加长度前缀实现简单、跨语言、抓包可读调试成本低得多。2.3 线程模型选型BIO 线程池还是 NIO Selector这是整个方案里最需要想清楚的一次选型。三种常见做法模型实现复杂度单机承载连接适用场景单线程 BIO极低1教学演示不能交付BIO 线程池低数百到一千左右课程设计、毕设首选NIO Selector高数千以上想拿高分或做进阶课程设计和毕设我建议直接上BIO 线程池。理由是逻辑直观每个连接一个线程调试时断点打得明白线程池控制住线程总数不至于一千个连接就一千个线程把内存吃穿代码量在可控范围内答辩时讲得清楚。NIO 的Selector加ByteBuffer的写法OP_READ半包处理这些细节没有足够时间打磨反而容易出隐性 bug。线程池用两个一个负责处理新连接或者主线程 accept 后直接 submit一个负责处理已连接客户端的数据读写。核心参数按「连接数上限 × 1.2」估队列用有界队列拒绝策略用CallerRunsPolicy压力大时让 accept 线程自己跑任务天然形成反压比直接抛异常把连接丢掉要好。提示线程数量不是越多越好。一个连接一个线程时每个线程默认栈约 1MB几百个连接就是几百 MB 虚拟内存。线程池的核心数要按实际压力测别照抄网上「200 个线程」的参数。2.4 数据库设计账号、消息、在线状态三张核心表聊天室一旦要记录历史消息和用户账号就必须有库。我用 MySQL三张主表加一张关系表-- 用户表 CREATE TABLE t_user ( user_id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT SHA-256 加盐后的密文, nickname VARCHAR(32) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 消息表群聊 to_id 为 0私聊存接收方 id CREATE TABLE t_message ( msg_id BIGINT PRIMARY KEY AUTO_INCREMENT, from_id BIGINT NOT NULL, to_id BIGINT NOT NULL DEFAULT 0, msg_type TINYINT NOT NULL COMMENT 1群聊 2私聊, content VARCHAR(1000) NOT NULL, send_time DATETIME(3) NOT NULL, INDEX idx_to_time (to_id, send_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 离线消息表用户不在线时先落库上线后拉取 CREATE TABLE t_offline ( id BIGINT PRIMARY KEY AUTO_INCREMENT, to_id BIGINT NOT NULL, msg_id BIGINT NOT NULL, delivered TINYINT DEFAULT 0, INDEX idx_to_delivered (to_id, delivered) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;t_message上的idx_to_time联合索引是为「拉取某人和某人的最近 N 条聊天记录」这个查询准备的走to_id过滤再按send_time倒序避免全表扫。离线消息单独建表而不是在消息表加标记位原因是离线消息的读写频率远高于普通历史消息单独拆表可以让热点表和冷数据表互不干扰清理也更方便——投递成功后直接按id批量物理删除不会让主消息表膨胀。3. 服务端核心实现连接管理、消息路由与线程安全3.1 连接注册中心用一个并发容器管住所有 Socket所有在线连接必须有一个统一的注册中心。我的写法是维护一个ConcurrentHashMapLong, ClientSessionkey 是用户 idvalue 封装了 Socket、输入输出流、最后心跳时间和用户基本信息。public class SessionManager { // 用户 id - 会话线程安全 private static final ConcurrentHashMapLong, ClientSession SESSIONS new ConcurrentHashMap(); public static void online(ClientSession session) { ClientSession old SESSIONS.put(session.getUserId(), session); if (old ! null) { // 同一账号重复登录踢掉旧连接避免一个账号两处在线导致消息错乱 old.close(); } } public static void offline(Long userId) { SESSIONS.remove(userId); } public static void broadcast(String json) { for (ClientSession s : SESSIONS.values()) { s.send(json); // send 内部加锁见下文 } } }这里三个设计点值得说明。第一用ConcurrentHashMap而不是HashMap因为广播时遍历和对新连接的写入是并发发生的普通HashMap遍历中被打断会抛ConcurrentModificationException。第二put的返回值处理重复登录这是实际项目里一定会遇到的问题用户手机和电脑同时登录必须明确规则我选择「后登录踢前一个」。第三broadcast遍历时如果某个连接写失败不能中断整个广播send方法内部要 catch 掉异常并触发该连接下线否则一个人掉线全场收不到消息。ClientSession.send()必须加锁因为群聊广播和多线程私聊转发可能同时对同一个 Socket 的OutputStream写入。两个线程同时写字节流会交错客户端解出来的 JSON 直接坏掉。解决办法是给每个 session 一个synchronized或ReentrantLock把「写长度 写 body flush」作为一个原子块。3.2 消息分发器一个 switch 撑起全部业务分支连接读线程收到一条完整消息后交给分发器按type路由。它是一个典型的分发结构代码不复杂但每个分支的边界条件必须写全。public void dispatch(ClientSession session, Message msg) { switch (msg.getType()) { case LOGIN: // 校验用户名密码成功则注册会话并补发离线消息 if (userService.auth(msg.getUsername(), msg.getPassword())) { session.bindUser(userService.findByName(msg.getUsername())); SessionManager.online(session); offlineService.pushOffline(session); } else { session.send(Message.error(账号或密码错误)); } break; case PUBLIC: // 群聊先落库再广播保证历史记录不丢 long msgId messageService.save(session.getUserId(), 0L, 1, msg.getContent()); SessionManager.broadcast(Message.publicMsg(session.getUserId(), msg.getContent(), msgId)); break; case PRIVATE: // 私聊在线直接转发离线落离线表 long pid messageService.save(session.getUserId(), msg.getToId(), 2, msg.getContent()); ClientSession target SessionManager.get(msg.getToId()); if (target ! null) { target.send(Message.privateMsg(session.getUserId(), msg.getContent(), pid)); } else { offlineService.save(msg.getToId(), pid); } break; case HEARTBEAT: session.touch(); // 刷新最后活跃时间 break; case HISTORY_REQ: session.send(messageService.queryHistory(session.getUserId(), msg.getToId(), msg.getLimit())); break; default: session.send(Message.error(不支持的消息类型)); } }顺序上有个关键取舍先落库再转发而不是先转发再异步落库。前者在服务端崩溃时会丢最新几条消息但不会出现「对方收到了、历史记录里没有」的不一致后者吞吐略高却可能让两个人看到的记录不一样。聊天室的场景里一致性优先我选前者。如果将来量大了再改成先写消息队列、由消费端落库并广播那是另一种架构了。HISTORY_REQ的limit参数必须在服务端做上限校验比如最多 100 条不能让客户端传 100000 把数据库拖死。3.3 心跳与断线检测怎么知道对面已经悄悄走了TCP 连接的「断开」有两类一类是客户端正常调close()服务端read返回 -1能感知另一类是客户端断电、拔网线、进程被杀服务端完全不知道线程会一直阻塞在read上连接泄漏。这就是聊天室必须做心跳的原因。我的做法是客户端每 30 秒发一条HEARTBEAT服务端touch()更新lastActiveTime服务端起一个单线程的定时任务每 60 秒扫一遍SESSIONS把now - lastActiveTime 90s的会话强制关闭并从注册中心移除。ScheduledExecutorService cleaner Executors.newSingleThreadScheduledExecutor(); cleaner.scheduleAtFixedRate(() - { long now System.currentTimeMillis(); for (ClientSession s : SessionManager.all()) { if (now - s.getLastActive() 90_000L) { s.close(); // close 内部会触发注销 SessionManager.offline(s.getUserId()); } } }, 60, 60, TimeUnit.SECONDS);三个阈值的关系要理清心跳间隔 30 秒 扫描周期 60 秒 超时阈值 90 秒。如果超时阈值比扫描周期还小会出现「刚判超时下一条心跳就到了」的误杀如果心跳间隔接近超时阈值网络稍抖就掉线。建议心跳间隔取超时阈值的 1/3。注意close()里要同时关闭 Socket 和从注册中心移除并且要幂等。定时任务和读线程可能同时调用它重复关闭不能抛异常。3.4 离线消息投递上线那一刻补齐所有欠账离线消息的处理分写入和投递两段。写入发生在私聊时对方不在线投递发生在用户登录成功后由offlineService.pushOffline(session)完成。实现上要注意两点。一是投递顺序必须按id升序否则用户看到的消息时间线是乱的。二是投递完成后要标记delivered 1或者直接删除不能重复推。我倾向「先查询未投递列表 → 逐条发送 → 发送成功后批量更新或删除」中间某条发送失败就停下下次登录重试保证至少一次送达。客户端那边要做消息去重用msg_id判重防止重试导致的重复显示。4. 客户端与通信可靠性UI 与 Socket 的边界怎么划4.1 收发分离UI 线程永远不碰 Socket客户端如果用 Swing 或 JavaFX最大的坑是「在按钮点击事件里直接read()」。网络一卡整个界面白屏无响应用户以为程序死了。正确做法是两条线程或两个线程池发送线程池界面触发发送后把消息丢进队列由后台线程真正写 Socket。接收线程一个独立的while循环持续阻塞读读满一条完整消息就通过SwingUtilities.invokeLater()或Platform.runLater()交回 UI 线程刷新。// 接收线程只负责读和派发不直接改界面 public void receiveLoop() { try (DataInputStream in new DataInputStream(socket.getInputStream())) { while (running) { int len in.readInt(); // 先读 4 字节长度 if (len 0 || len 1024 * 1024) { throw new IOException(非法长度: len); } byte[] body new byte[len]; in.readFully(body); // 必须 readFully一次 read 可能读不全 Message msg JSON.parseObject(new String(body, StandardCharsets.UTF_8), Message.class); SwingUtilities.invokeLater(() - ui.onMessage(msg)); // 切回 UI 线程 } } catch (IOException e) { SwingUtilities.invokeLater(() - ui.onDisconnected(e.getMessage())); } }readFully和read的区别值得单独说read(byte[])返回值可能小于数组长度只读了一半就返回剩下的字节还在内核缓冲区。用readFully才会阻塞到读满为止。这个细节不做对消息内容稍微长一点就会解析失败而且报错位置很随机极难复现。长度上限校验也是必须的防止对端发一个Integer.MAX_VALUE让你new byte[]直接OutOfMemoryError。4.2 断线重连一个带退避的重连状态机真实网络会断。客户端要有重连机制但不能「一断就死循环重连」那会把服务端打挂。我一般用指数退避首次 1 秒之后 2、4、8 秒上限 30 秒重连成功后重置。private void reconnectLoop() { int delay 1; while (!connected retry MAX_RETRY) { try { Thread.sleep(delay * 1000L); connect(); // 内部重新建 Socket、发 LOGIN delay 1; // 成功则重置退避 } catch (Exception e) { retry; delay Math.min(delay * 2, 30); // 指数退避封顶 30 秒 } } }重连成功后要重新发LOGIN并且主动拉一次离线消息和历史记录把断线期间的消息补齐。如果服务端会话是按 token 维持的重连时带上原 token 可以避免重复登录被踢。4.3 消息顺序与去重客户端也要有兜底服务端保证了写入顺序但网络传输、重连补发都可能让客户端收到重复消息或乱序消息。客户端的做法是维护一个最近收到的msg_id集合可以用LinkedHashSet保留最近 500 个收到消息先判重再展示同时按send_time和msg_id做一次稳定排序后再渲染消息列表。这套兜底在演示时往往看不出来但真实网络环境下能避免大量「同一条消息出现两次」的提问。5. 常见问题排查这个项目最容易翻车的五个点5.1 广播时抛 ConcurrentModificationException现象群聊消息一发服务端日志里偶尔冒ConcurrentModificationException部分人收不到消息。原因广播用普通HashMap遍历遍历过程中有新用户上线执行了put或者有人掉线执行了remove集合结构被修改。解决换成ConcurrentHashMap遍历时用它的弱一致性迭代器或者在广播前把values()复制成一个ArrayList再遍历代价是一次小内存分配但绝对安全。5.2 客户端收到的 JSON 解析失败且时好时坏现象短消息正常稍长的中文消息偶尔报 JSON 解析异常重启后又能跑。原因两个问题叠加。一是用了read(byte[])而不是readFully半包被当成完整消息二是中文 UTF-8 占 3 字节长度按字符算而不是按字节算长度前缀和实际 body 对不上。解决长度前缀统一按byte[]的字节数计算body.getBytes(StandardCharsets.UTF_8).length读取用DataInputStream.readFully。写完这两条这类问题基本绝迹。5.3 关闭窗口后服务端线程不释放连接数越测越多现象反复开关客户端服务端线程数只增不减最后OutOfMemoryError: unable to create new native thread。原因客户端直接关窗口没调socket.close()服务端读线程一直阻塞在read上服务端也没有心跳超时清理。解决客户端加窗口关闭监听close()前先发LOGOUT服务端心跳清理任务必须实现别嫌麻烦跳过。压测时用jstack看线程栈阻塞在socketRead0的就是没释放的。5.4 数据库连接在并发下被打满现象几个人同时发消息服务端报Too many connections或者响应突然变慢几秒。原因每次发消息都DriverManager.getConnection()新建连接用完不关或关得慢没有连接池。解决引入连接池HikariCP 或 Druid最大连接数按「并发写消息的线程数 余量」配比如 1020。所有 DAO 用 try-with-resources 保证释放。另外消息落库不要放在持有 session 锁的代码块里否则一次慢 SQL 会卡住整个广播。5.5 同一账号两处登录导致消息错乱现象A 在两端登录B 发私聊给 A只有一端收到或者两端都收到但历史记录只有一条。原因注册中心 key 是用户 id后登录的put覆盖了前一个但前一个连接的读线程还在跑仍会往旧 Socket 写。解决put时检查旧值旧连接主动close()并置一个kicked标记让旧连接的读循环检测到标记后退出。同时在协议层明确规则后登录踢前一个并在被踢端弹一个提示。6. 验收与答辩怎么证明这套聊天室真的能用功能验收不要只演示「两个窗口互发一句你好」那只能证明最理想路径通了。我通常准备一张验收清单逐条跑验收项操作方式通过标准多客户端并发同时开 20 个客户端登录全部在线群聊消息无丢失、无重复私聊在线转发A 私聊 BB 在线B 实时收到双方历史记录一致私聊离线补发B 离线时 A 私聊B 再登录登录后自动收到顺序正确断线重连手动断网 10 秒再恢复自动重连补齐断线期间消息心跳清理强杀一个客户端进程90 秒内服务端移除该会话重复登录同账号两端登录旧端被踢新端正常压力粗测用脚本模拟 100 连接持续发消息服务端线程数稳定无 OOM答辩时最容易被追问的三个问题提前准备好答案为什么选 BIO 不选 NIO回答连接规模在千级以内BIO 加线程池代码可维护性更高NIO 的复杂度在这个规模下是负收益消息为什么先落库再转发回答一致性优先避免两端记录不一致心跳为什么是 30 秒回答取超时阈值的 1/3兼顾及时性和误判率。把这三条讲清楚基本就能说明你做过取舍、不是抄的。还有个演示技巧提前用脚本灌 500 条历史消息和一个离线用户现场演示「登录即补发」的效果比空库演示有说服力得多。压测数据也提前跑好截图存着现场只跑小规模避免网络抖动翻车。这套东西我从第一次写聊天室把服务端写成单线程、答辩时被问得哑口无言之后就形成了一个习惯任何网络程序先把「连接生命周期」画出来——怎么建、怎么判活、怎么断、断了怎么补——这四个问题答不上来代码写得再漂亮也是纸糊的。希望这套结构能帮到你少走我当年那段弯路。本文还有配套的精品资源点击获取