Java网络聊天室实战：Socket通信、多线程与消息持久化-北京尧图网络

简介这是一份面向Java初学者与课程设计者的网络聊天室项目源码围绕Socket通信、多线程并发和数据库管理三条主线提供从客户端界面到服务端消息广播的完整实现适合用于网络编程实验、期末项目参考或技术栈串联练习。压缩包共46个文件、约199KB包含7个java源文件、20个class编译文件、10张jpg与2张gif界面素材以及txt说明、db数据库和工程配置文件源码、资源与可运行产物相对齐全便于直接导入IDE后对照阅读。现有194人学习下载说明其在同类教学项目中具备一定参考热度。读者可从中梳理用户注册登录验证、在线状态跟踪、多对多消息广播、聊天记录入库及异常捕获等关键流程也能观察服务端为每个连接分配线程、客户端监听并刷新界面的具体写法为后续调试与功能扩展提供可复用的代码骨架。1. 需求不是「能聊天就行」一个局域网聊天室真正要解决的四个问题「三个人同时登录就翻车」——这是 java 网络聊天室项目里最常见的第一次事故。两个人一对一聊得好好的第三个人进来消息开始串台、中文变成问号、有人掉线却一个报错都没有。多数人第一反应是 Socket 通信写错了其实读写就那么几十行真正难的是两件事一条消息到哪里算结束一个连接从建立到断开之间经历了哪些状态。多线程技术和数据库技术在这类项目里不是加分项而是被这两个问题硬逼出来的必需品——多条连接同时跑就必须有并发模型消息要能离线补发、要能查历史就必须有持久化。这套方案交付的是一个支持私聊、群聊、在线列表、离线补发和心跳检测的完整网络聊天室适合正在做课程设计或毕业设计的同学照着搭也适合需要一份能真正跑起来的局域网通信方案的人直接改。2. 总体架构与通信协议三层结构与 8 字节帧头的分工我一般不会一上来就写new ServerSocket(8888)。动手之前先定两件事谁负责搬字节谁负责决定消息发给谁。这两个职责一旦混在一个类里后期加群聊、加离线消息、加已读回执每改一个功能都要动核心循环改到第三次基本就要重写。分层不是为了好看是为了让「新增一个消息类型」变成只加一个分支而不是重排整条链路。2.1 三层结构接入层、业务层、存储层的职责边界接入层只认字节和连接它手里有一个ClientSession管着 socket、输入输出流、最近活跃时间、是否已登录这几样东西。业务层只认消息对象和用户 ID它负责「这条消息该投给哪些 session」。存储层只认 SQL负责用户、消息、群成员的增删改查。给这三层划边界我用一条很土但有效的规则接入层不允许出现User、Message这种业务对象只允许出现sessionId和byte[]业务层不允许出现InputStream、OutputStream只允许调用 session 的send(Frame)存储层不允许System.out.println所有异常往上抛由业务层决定是记日志还是回错误码。层核心类只做绝不做接入层ChatServer、ClientSession、FrameCodec接受连接、拆帧、心跳、关闭清理查库、判断业务权限业务层MessageRouter、OnlineRegistry、HeartbeatGuard路由、在线状态、群成员展开直接读写流、拼 SQL 字符串存储层UserDao、MessageDao、GroupDao参数化 SQL、事务、批量更新持有 socket 引用、做线程调度这样切完一次私聊消息的路径就很清楚了客户端 A 写出一帧 → A 对应的ClientSession读线程拆出CHAT_PRIVATE→ 交给MessageRouter→ 路由查OnlineRegistry拿到 B 的 session → 调session.send()写出 → 同时MessageDao.save()落库并把delivered置 0等 B 回 ACK 再置 1。全链路没有一处需要知道对方是本地还是远端也没有一处需要知道消息存在哪张表。2.2 帧格式设计TCP 是字节流不是消息流这是整个项目里最容易翻车、也最值得先写的一层。TCP 只保证字节有序到达不保证一次read正好读到一条完整消息。发得快的时候两条消息会粘在一起粘包发得大或者网络抖动的时候一条消息会被拆成两次到达半包。如果直接readUTF()或按行读本地测试永远正常一上多人并发就开始出现「A 的消息里带着 B 的内容」这种玄学现象。解决办法是给每条消息加一个固定长度的帧头帧头里写明载荷有多长接收方先读满帧头再按长度读满载荷读不满就继续等下一次read。字段长度说明magic2 字节固定魔数 0xCAFE用于丢弃脏数据、快速判定协议错位version1 字节协议版本从 1 开始便于后续字段扩展type1 字节消息类型见 2.3length4 字节载荷字节数不含 8 字节帧头payload变长UTF-8 编码的 JSON 字节数组public final class FrameCodec { public static final short MAGIC (short) 0xCAFE; public static final int HEADER_LEN 8; // 2 1 1 4 public static final int MAX_PAYLOAD 64 * 1024; // 单帧上限 64KB防恶意长度撑爆内存 /** 组装一帧返回的 ByteBuffer 已 flip可直接 write 到通道 */ public static ByteBuffer encode(byte type, byte[] payload) { if (payload.length MAX_PAYLOAD) { throw new IllegalArgumentException(payload too large: payload.length); } ByteBuffer buf ByteBuffer.allocate(HEADER_LEN payload.length); buf.putShort(MAGIC); buf.put((byte) 1); // version buf.put(type); buf.putInt(payload.length); // 只写载荷长度不含帧头本身 buf.put(payload); buf.flip(); return buf; } /** * 从累积缓冲区里尝试取出完整一帧。 * 返回 null 表示数据还不够调用方应继续 read 后再调一次。 */ public static Frame tryDecode(ByteBuffer in) { if (in.remaining() HEADER_LEN) return null; in.mark(); // 数据不足时要能回退到帧头起点 short magic in.getShort(); if (magic ! MAGIC) throw new ProtocolException(bad magic: magic); byte version in.get(); byte type in.get(); int len in.getInt(); if (len 0 || len MAX_PAYLOAD) throw new ProtocolException(bad length: len); if (in.remaining() len) { in.reset(); return null; } // 半包等下次 byte[] payload new byte[len]; in.get(payload); return new Frame(version, type, payload); } }几个参数值得单独解释。MAX_PAYLOAD一定要有没有它的话对端只要发一个声明长度为 2GB 的帧头服务端就会new byte[2G]直接 OOM这是最典型的入门级安全问题。mark()/reset()是半包处理的关键读帧头之前先打标记发现载荷不够就退回去等下一批字节到了从头再解析否则帧头会被吃掉一半后面全乱。version字段现在用不上但协议一旦发布就很难改留一个字节的成本远低于将来加字段时要兼容旧客户端的成本。提示接收端不要一次read一次解析。正确做法是每个连接维护一个ByteBuffer累积缓冲区循环tryDecode直到返回 null再回到read。2.3 消息类型与载荷约定用 JSON 换取可调试性类型码只用一字节所以够用很久。载荷统一用 JSON不用 Java 原生序列化。原因很实际原生序列化把类名和字段签名写进字节流客户端和服务端稍微不同步就抛InvalidClassException而且抓包看到的是一堆乱码联调时完全没有排查余地。JSON 抓包直接能读加字段也不会让老客户端崩。类型码名称方向载荷关键字段0x01LOGIN_REQC→Susername, passwordHash0x02LOGIN_RESPS→Ccode, userId, nickname, token0x03CHAT_PRIVATEC→S / S→CmsgId, from, to, content, ts0x04CHAT_GROUPC→S / S→CmsgId, from, groupId, content, ts0x05HEARTBEAT双向ts0x06ACK双向msgId, status0x07ONLINE_LISTS→Cusers[]0x08OFFLINE_PULLC→SsinceId, limit{msgId:9f2c1a7b4e8d4c31,from:1001,to:1002,content:在吗,ts:1710000000000}msgId是客户端生成的 16 字节随机串作用有两个一是幂等客户端超时重发时服务端靠它去重二是回执关联服务端投递成功后客户端回一个带同样msgId的 ACK服务端才知道这条可以标成已送达。没有这个字段离线消息就永远分不清「发出去了」和「对方收到了」后面 4.3 的补发逻辑根本没法写。3. Socket 通信与多线程并发连接生命周期与线程池模型协议定完接入层就可以动手了。这一层的关键不是accept()而是想清楚一个连接的完整生命周期建立 → 注册 → 认证 → 活跃 → 超时或异常 → 清理。这六个状态里任何一步没处理干净表现出来的都是「服务端跑一晚上就卡死」或者「在线列表里挂着一堆早就不在的人」。3.1 服务端接入与连接注册主线程只做一件事不停accept把拿到的 socket 包装成ClientSession丢给线程池自己立刻回去等下一个连接。绝不能在主线程里处理业务否则一个慢查询就能让整个服务停止接受新连接。public void start() throws IOException { try (ServerSocket server new ServerSocket()) { server.setReuseAddress(true); // 重启时不必等 TIME_WAIT 释放端口 server.bind(new InetSocketAddress(8888), 128); // backlog128等待队列长度 while (running) { Socket socket server.accept(); socket.setTcpNoDelay(true); // 聊天是小包高频关掉 Nagle 降低延迟 socket.setKeepAlive(true); socket.setSoTimeout(90_000); // 90 秒内没收到任何字节即判定超时 pool.execute(new ClientSession(socket, router, registry)); } } }setReuseAddress(true)是血泪经验不加这一行调试期间反复重启服务端会频繁遇到Address already in use明明进程已经退了端口还占着只能干等或换端口。setTcpNoDelay(true)影响的是延迟聊天场景下消息体很小默认的 Nagle 算法会攒包再发主观感受就是「点了发送要愣一下才到」。setSoTimeout是心跳机制的最后一道防线它保证即使应用层心跳逻辑写错了阻塞的read也会在 90 秒后抛SocketTimeoutException让这个连接有机会被回收而不是永远挂在那里。连接进来之后立刻注册到一个全局在线表key 用自增的sessionId而不是用户名因为登录前也要能发消息比如登录失败要回错误码。3.2 并发模型为什么不能给每个连接开一个裸线程教科书上的写法是每个连接new Thread(...)。几十个连接确实没问题但这个模型有两个隐患线程栈默认 1MB几百个连接就是几百 MB 的地址空间更麻烦的是线程创建和销毁完全不受控一旦有人用脚本疯狂重连服务端会被线程创建拖垮。这个项目我用固定线程池核心 16、最大 64、有界队列 1000。为什么是这组数几十到几百人在线的局域网场景单条消息的业务处理耗时基本在毫秒级16 个核心线程足够最大 64 是给登录高峰、群发这种瞬时峰值留的余量队列必须有界无界队列在压力下只会把 OOM 推迟几秒。ThreadPoolExecutor pool new ThreadPoolExecutor( 16, 64, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1000), r - { Thread t new Thread(r, chat-worker- SEQ.getAndIncrement()); t.setDaemon(true); // 不阻止 JVM 退出 return t; }, new ThreadPoolExecutor.AbortPolicy() // 拒绝时不静默丢弃抛出去让上层记日志 );线程名统一加chat-worker-前缀这个细节在做故障排查时价值极高jstack打出来一眼就能看出是业务线程卡住了还是 GC 线程在跑不用靠线程编号猜。拒绝策略选AbortPolicy而不是DiscardPolicy因为静默丢弃会让「为什么有些消息没到」变成悬案抛异常至少日志里有痕迹。注意这里刻意没有上 NIO。NIO 在几千连接的场景下才有明显收益代价是选择器、半包状态机、写缓冲区管理全部要自己维护代码量翻三倍。几百连接的课程设计或毕设阻塞 IO 线程池是性价比最高的选择把复杂度留给真正需要的项目。3.3 心跳与断线检测read返回 -1 远远不够很多人以为连接断了read会返回 -1。这只在对方正常关闭发 FIN时成立。如果对方是拔网线、断电、WiFi 切换服务端这一侧的 socket 完全无感知read会一直阻塞下去在线列表里就会挂着一个永远不说话的幽灵用户发给他的消息全部石沉大海。这就是典型的半开连接。解决办法是应用层心跳。客户端每 15 秒发一帧HEARTBEAT服务端每收到任意一帧就更新lastActiveAt另起一个调度线程每 15 秒扫一遍超过 90 秒没动静就强制关闭。// ClientSession 内部 private volatile long lastActiveAt System.currentTimeMillis(); public void touch() { this.lastActiveAt System.currentTimeMillis(); } // 独立的调度线程与业务线程池隔离避免被慢业务拖住 scheduler.scheduleAtFixedRate(() - { long now System.currentTimeMillis(); for (ClientSession s : registry.snapshot()) { if (now - s.lastActiveAt() 90_000L) { s.close(CloseReason.HEARTBEAT_TIMEOUT); // 内部统一走注销落库广播下线 } } }, 15, 15, TimeUnit.SECONDS);lastActiveAt用volatile修饰因为写它的是 IO 线程、读它的是调度线程不加的话调度线程可能一直读到旧值。超时时间设成心跳间隔的 6 倍是为了容忍网络抖动和客户端 GC 停顿设得太紧会误杀正常连接表现出来就是「用户抱怨偶尔无故掉线」。关闭逻辑必须收敛到close()一个方法里所有路径超时、异常、用户主动退出都调它用AtomicBoolean保证只执行一次否则注销逻辑跑两遍会把刚重连上来的新 session 从在线表里删掉。3.4 客户端收发分离与界面线程安全客户端这边最常见的错误是「点发送按钮就直接往输出流写」。Swing 的事件线程只有一个任何阻塞写都会让界面假死更严重的是如果同时在跑的还有心跳线程两个线程往同一个OutputStream写字节会交错对端收到的就是一帧长度对不上内容的坏数据。正确做法是两个线程各司其职读线程死循环阻塞读帧写线程从BlockingQueue里取帧串行写出。所有想发消息的地方都只是往队列里offer不碰流。// 写线程唯一持有 OutputStream 的线程天然串行不会出现帧交错 new Thread(() - { try { while (running) { Frame f sendQueue.take(); // 队列空时阻塞不空转 out.write(FrameCodec.encode(f.type(), f.payload())); out.flush(); } } catch (Exception e) { /* 通知界面重连 */ } }, chat-writer).start(); // 读线程收到消息后必须切回 EDT 才能动 UI new Thread(() - { while (running) { Frame f FrameCodec.readFrom(in); // 阻塞直到读满一帧 FrameHandler.handle(f); // 内部用 invokeLater 切线程 } }, chat-reader).start();sendQueue用LinkedBlockingQueue并且要设上限比如 500。不设上限的话网络卡住时用户连点发送队列会无限增长直到内存爆掉设了上限之后offer返回 false界面就能提示「网络繁忙」这才是可用的交互。界面更新一律走SwingUtilities.invokeLaterSwing 组件不是线程安全的从读线程直接append到文本域轻则显示错乱重则抛NullPointerException而且堆栈完全看不出原因。4. 数据库设计与消息持久化三张核心表撑起离线补发到了这一步聊天已经能跑通了但用户一关客户端刚才的对话就消失了离线期间别人发的消息也永远收不到。持久化要解决的就是这两件事同时还得保证在高并发写入下不出重复、不漏消息。4.1 表结构把索引建在查询路径上表设计我遵循一条原则先写出最频繁的那条查询再倒推索引。这个项目最频繁的两条是「按用户名查密码」和「按收件人拉未投递消息」索引就围绕它们建。CREATE TABLE t_user ( id BIGINT NOT NULL AUTO_INCREMENT, username VARCHAR(32) NOT NULL, password_hash CHAR(64) NOT NULL COMMENT SHA-256(明文密码 salt), salt CHAR(16) NOT NULL, nickname VARCHAR(32) NOT NULL, online TINYINT NOT NULL DEFAULT 0 COMMENT 0离线 1在线仅作展示真实状态以内存为准, last_login DATETIME NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_message ( id BIGINT NOT NULL AUTO_INCREMENT, msg_id CHAR(16) NOT NULL COMMENT 客户端生成用于幂等去重, from_id BIGINT NOT NULL, to_id BIGINT NOT NULL COMMENT 私聊为对方用户ID群聊为群ID, chat_type TINYINT NOT NULL COMMENT 1私聊 2群聊, content VARCHAR(2000) NOT NULL, send_time DATETIME(3) NOT NULL, delivered TINYINT NOT NULL DEFAULT 0 COMMENT 0未投递 1已投递, PRIMARY KEY (id), UNIQUE KEY uk_msg_id (msg_id), KEY idx_pull (to_id, delivered, id) -- 直接服务离线拉取顺序与 WHERE/ORDER BY 一致 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_group_member ( group_id BIGINT NOT NULL, user_id BIGINT NOT NULL, join_time DATETIME NOT NULL, PRIMARY KEY (group_id, user_id), KEY idx_user (user_id) -- 反查我加入了哪些群 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;idx_pull (to_id, delivered, id)这个联合索引是整张表的性能关键。离线拉取的 SQL 是WHERE to_id? AND delivered0 ORDER BY id ASC LIMIT 200字段顺序、等值条件、排序方向三者完全对齐走的是覆盖索引扫描不需要回表也不需要额外排序。索引顺序写反成(delivered, to_id, id)就会退化成扫描全表未投递消息。utf8mb4而不是utf8因为utf8在 MySQL 里其实是三字节的阉割版存不了四字节字符比如某些表情聊天内容里出现就会直接报错或截断。4.2 DAO 层幂等插入、批量更新与事务边界写入消息最怕重复。客户端因为超时重发同一条消息可能到达两次如果直接INSERT收件人就会看到两遍。用唯一索引 ON DUPLICATE KEY UPDATE来处理既保证幂等又不用先查后插先查后插在并发下有竞态两个线程同时查不到就会都插进去。public class MessageDao { private final DataSource ds; // HikariCPmaximumPoolSize20 /** 幂等落库msg_id 冲突时什么都不做不抛异常也不产生重复行 */ public void save(Message m) throws SQLException { String sql INSERT INTO t_message(msg_id,from_id,to_id,chat_type,content,send_time,delivered) VALUES(?,?,?,?,?,?,0) ON DUPLICATE KEY UPDATE msg_id msg_id; // 空更新仅吞掉重复 try (Connection c ds.getConnection(); PreparedStatement ps c.prepareStatement(sql)) { ps.setString(1, m.getMsgId()); ps.setLong(2, m.getFromId()); ps.setLong(3, m.getToId()); ps.setInt(4, m.getChatType()); ps.setString(5, m.getContent()); ps.setTimestamp(6, Timestamp.valueOf(m.getSendTime())); ps.executeUpdate(); } } /** 上线时拉未投递消息limit 必须带否则老账号一次性拉几万条会把内存打满 */ public ListMessage pullUndelivered(long userId, int limit) throws SQLException { String sql SELECT id,msg_id,from_id,chat_type,content,send_time FROM t_message WHERE to_id? AND delivered0 ORDER BY id ASC LIMIT ?; ListMessage list new ArrayList(); try (Connection c ds.getConnection(); PreparedStatement ps c.prepareStatement(sql)) { ps.setLong(1, userId); ps.setInt(2, limit); try (ResultSet rs ps.executeQuery()) { while (rs.next()) list.add(map(rs)); } } return list; } }ON DUPLICATE KEY UPDATE msg_id msg_id这个写法看着别扭但它是 MySQL 里成本最低的空更新不修改任何值只让语句合法返回同时把重复键异常吞掉。也有人用INSERT IGNORE区别是IGNORE会顺带吞掉其他类型的错误比如字段超长被截断把真正的问题掩盖掉不建议。连接池大小设 20 而不是更大因为数据库端连接数是有限的池子开太大反而会增加上下文切换和锁争用。DAO 里所有方法都是短连接模式用完立刻归还绝不在业务逻辑里持有Connection做多次往返。4.3 离线消息投递拉取、回执、清理三段式登录成功后的流程要严格按顺序走先鉴权拿到 userId再查未投递消息批量推送给该用户的 session等客户端回 ACK 之后再批量标记已投递。这里有个容易被忽略的点——不能推一条就UPDATE一条几十条消息就是几十次往返登录会明显卡顿。批量更新一次搞定。public int markDelivered(ListLong ids) throws SQLException { if (ids null || ids.isEmpty()) return 0; String placeholders String.join(,, Collections.nCopies(ids.size(), ?)); String sql UPDATE t_message SET delivered1 WHERE id IN ( placeholders ); try (Connection c ds.getConnection(); PreparedStatement ps c.prepareStatement(sql)) { for (int i 0; i ids.size(); i) ps.setLong(i 1, ids.get(i)); return ps.executeUpdate(); } }按主键id更新而不是按msg_id因为主键更新直接定位行msg_id虽然是唯一索引但还要多一次索引查找。占位符用String.join动态拼值仍然走setLong不存在注入风险——这一点必须区分清楚拼的是占位符数量不是用户数据。清理策略也要提前想好否则表会无限涨。我的做法是保留 30 天每天凌晨跑一次分批删除每批 500 行加LIMIT避免一条DELETE锁住太多行导致其他写入排队。注意数据库操作千万不要在 socket 的读线程里同步执行。一条慢 SQL 就能让这个连接彻底停止收发表现出来就是「这个人卡住了但别人都正常」。我的做法是给持久化单独一个小线程池4~8 个线程路由线程只负责投递落库异步提交。5. 避坑与排查五个最容易翻车的点从现象倒推原因这一章是我带项目时踩过的坑里挑出来的。它们的共同特征是本地单人测试 100% 正常多人一上就出问题而且报错信息完全没有指向性。5.1 连接与并发类问题现象一第三个人登录后前两个人互相收不到消息了服务端没有任何异常。原因基本可以锁定在线表。很多人用HashMapLong, ClientSession存 session多个 IO 线程同时put、removeHashMap在扩容时会形成链表环之后get直接死循环或者返回 null。更隐蔽的是遍历时remove抛ConcurrentModificationException如果这个异常被catch吞掉表现就是「消息随机丢失」。解决是把在线表换成ConcurrentHashMapkey 用 sessionId另外维护一个userId → sessionId的映射用于消息路由。遍历统一用snapshot()拿快照再操作不要在迭代过程中直接改表。如果确实需要原子性的「检查并加入」用computeIfAbsent而不是先get再put。现象二服务端跑一晚上 CPU 跑到 100%日志里刷屏Connection reset。原因是异常处理写成了不跳出循环。典型代码是catch (IOException e) { e.printStackTrace(); }然后继续下一轮while。对端已经断开下一次read立刻又抛同样的异常几万次每秒的空转就把一个核吃满了。解决是异常分支必须break并且统一走finally里的关闭逻辑。我的写法是读循环只有三种出口正常读到帧、读返回 -1、抛异常后两种都break出去在finally里从在线表注销、把未投递消息标记回未送达、广播下线通知。printStackTrace在 100% CPU 场景下本身也是负担改用带上下文的日志并且加限流。现象三A 收到本该发给 B 的消息内容或者收到的 JSON 解析失败。这是帧交错多个线程同时往同一个OutputStream写导致的。write(byte[])不是原子操作两个线程各写半帧字节就混在一起了对端按长度解析出来自然是别人的内容。解决是每个 session 只允许一个线程写。最轻量的做法是给 session 加一把写锁synchronized (writeLock) { out.write(...); out.flush(); }更彻底的做法是像 3.4 那样给每个连接配一个写队列加单写线程。我个人倾向前者锁的粒度小、代码少几百连接完全够用。顺带提醒flush()一定要在锁内否则数据还留在缓冲区里锁就白加了。5.2 数据与编码类问题现象四中文在服务端日志里正常到客户端变成问号或者方块。编码问题几乎百分百是「一端用了平台默认编码」。new String(bytes)和getBytes()无参版本都依赖file.encodingWindows 默认 GBK、Linux 默认 UTF-8本地跑没问题换个环境就乱码。解决是所有字符串和字节的转换都必须显式指定字符集new String(payload, StandardCharsets.UTF_8)、content.getBytes(StandardCharsets.UTF_8)。数据库连接串里也要带characterEncodingutf8mb4表本身也必须是utf8mb4。三层里只要有一层漏了前面的努力全部白费所以这个规范值得写成团队约定。现象五对方明明只发了一条消息收件人看到了两条重复内容完全一样。原因是客户端超时重发而服务端没有做幂等。客户端发出去之后等 ACK超过 3 秒没收到就重发但第一条其实已经到达并落库了。解决靠msg_id唯一索引加ON DUPLICATE KEY UPDATE也就是 4.2 里那个写法。另外 ACK 也要带msgId客户端收到之后按msgId从待确认队列里移除不能只靠超时判断。这个坑的隐蔽之处在于测试时网络好从来不超时一上真实环境就开始偶发重复。5.3 出问题先看哪三样东西排查这类项目我一般按固定顺序看三样比漫无目的地加日志快得多。jstack pid看线程都在干什么如果大量线程卡在socketRead0说明对端不发数据、连接空转检查心跳如果卡在getConnection说明数据库连接池被打满了去查谁没还连接。netstat -ano | grep 8888看连接状态大量CLOSE_WAIT说明服务端没关 socket是finally里漏了close()大量SYN_RECV说明有人疯狂重连或者 accept 队列满了。服务端日志按 sessionId 打前缀。这一点在并发场景下是决定性的——没有 sessionId 的日志混在一起根本分不清哪行属于哪个用户等于没有日志。6. 验收与答辩八条测试用例和三个必答问题功能跑通不等于项目做完了。答辩现场最容易被问倒的不是「你怎么实现的」而是「你怎么证明它是对的」。我的建议是提前准备一张测试清单每一条都能当场演示比讲十分钟架构有说服力。编号用例操作通过标准T1单聊基本通路A 发给 BB 200ms 内收到内容与编码正确T2群聊广播A 在 5 人群内发消息其余 4 人全部收到发送者不回显重复T3在线列表同步C 登录后 A、B 观察双方列表 1s 内出现 CT4离线补发关闭 BA 发 3 条B 登录B 登录后按序收到 3 条顺序不乱T5幂等用脚本对同一 msgId 连发 5 次库中只有 1 行B 只收到 1 条T6心跳超时杀掉客户端进程不发 FIN90s 内服务端判定下线并广播T7并发压力60 个模拟连接同时发心跳 10 分钟内存平稳无异常日志CPU 低于 30%T8断线重连拔网线 10s 后恢复自动重连重连期间消息不丢T7 用一段脚本就能做不需要专业压测工具。开 60 个 socket 持续发心跳观察服务端线程数和内存曲线这一条最能证明线程池模型是站得住的。import socket, threading, time, struct MAGIC, VERSION, HEARTBEAT 0xCAFE, 1, 0x05 def frame(payloadb{}): return struct.pack(HBBi, MAGIC, VERSION, HEARTBEAT, len(payload)) payload def worker(n): s socket.create_connection((127.0.0.1, 8888)) try: while True: s.sendall(frame()) # 每 15 秒一次心跳与客户端行为一致 time.sleep(15) finally: s.close() for i in range(60): threading.Thread(targetworker, args(i,), daemonTrue).start() time.sleep(600) # 持续 10 分钟期间用 jstack 观察线程数是否稳定在 16~64这段脚本的价值在于它绕过了图形界面直接构造原始帧能顺带验证 2.2 的帧格式是否真的按字节对齐——如果 Java 端的ByteBuffer字节序写成了小端这里发过去服务端会直接报 bad magic比在界面上盲猜快得多。答辩的提问基本集中在三个点上提前把答案压成一两句话比背稿子管用。第一个是「你怎么处理粘包半包」。答8 字节定长帧头长度字段只算载荷接收端累积缓冲 mark/reset读不满就退回等下次read。第二个是「多线程怎么保证安全」。答在线表用ConcurrentHashMap每个连接一把写锁保证帧不交错lastActiveAt用volatile关闭逻辑用AtomicBoolean保证只执行一次。第三个是「消息会不会重复或丢失」。答msg_id唯一索引保证不重复delivered标记加 ACK 保证不丢登录时按sinceId拉取补偿。我自己的习惯是每接一个新项目都强制先手写一遍帧编解码的单测再写业务。第一次做这个聊天室时我是反过来的先写界面先连 socket结果合并代码那天发现两个人的长度字段一个含帧头一个不含联调了整整一个下午抓包看了几百帧才定位。从那以后协议这层不写测试就不往下走已经成为硬规矩。希望帮到你。本文还有配套的精品资源点击获取

Java网络聊天室实战：Socket通信、多线程与消息持久化

相关推荐

Windows驱动安装全解析：x86/x64判断、签名校验与pnputil排错

Typora写作效率优化：自动化工具链与快捷键定制

Raft算法解析：分布式系统共识机制与工程实践

更多资讯

办公软件实战教学：以真实任务驱动的Word+Excel+PPT协同学习框架

大型汽车4S店维修管理系统：从需求到落地的全流程设计

Kraken简正波仿真：传播损耗与阵元波形从原理到Matlab实现

零基础入门Unity AI Demo：从跑通到改参数的新手避坑指南

VoiceStudio：基于Electron+k2-fsa的离线语音分析工作台

LETKF算法编译指南：从环境配置到性能优化

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？