简介：这是一份面向Java初学者与进阶开发者的网络聊天室项目源码，围绕Socket通信、多线程与数据库技术展开，适合用来练习网络编程、并发处理与用户信息管理的综合实践。压缩包共46个文件，约199KB，以20个class编译文件、7个java源码、10张jpg与2张gif界面素材为主，另含txt说明、db数据库文件及工程配置，源码与运行产物齐全，便于直接导入调试。已有193人学习浏览。项目覆盖服务端与客户端Socket连接、消息广播、多线程并发处理、用户注册登录验证及聊天记录存储等模块，读者可据此理解多对多消息传递与在线状态跟踪的实现思路，并参考异常捕获与错误处理方式完善程序健壮性，是巩固Java技术栈的实用练手素材。

1. 从一次课程设计答辩说起：为什么我建议你认真做一套 Java 网络聊天室

每年到了课程设计季，总有人拿着一个只能在本机跑起来的"聊天室"来答辩，界面能发消息，但换台电脑就连接失败，多开两个客户端就消息错乱，关掉窗口服务端直接崩。问题不在 Java，而在于大多数人对"网络通信"这四个字的理解停留在Socket会accept就行。真正能拿得出手的 Java 网络聊天室，核心是三件事的配合：Socket 通信负责把字节送对地方，多线程负责让服务端同时伺候几十个连接而不打架，数据库负责让消息和用户不随进程退出而蒸发。这套方案就是围绕这三根柱子搭的，适合正在做网络编程课设、Java 综合实训，或者想拿一个完整通信项目练手的同学。下面从需求、架构、实现一路讲到怎么验收，能照着改、照着交。

2. 需求与选型：先把边界划清楚再动手

2.1 功能需求拆成四层来看

做聊天室最容易犯的错是一上来就写ServerSocket，写到一半发现"私聊怎么实现""历史消息存哪""用户重名怎么办"全没想。我一般会把需求按四层拆：接入层管连接建立与断开，业务层管登录、群聊、私聊、在线列表，持久层管用户账号和消息记录，展示层管客户端界面刷新。接入层要解决的是同一时刻多个客户端连进来，服务端不能阻塞在某个read()上；业务层要解决的是消息该发给谁——群聊广播给所有人，私聊只投递给目标用户；持久层要解决的是用户注册信息、好友关系、离线消息的落库；展示层要解决的是收到消息后界面不卡死。这四层拆清楚，后面的类图和线程模型才有依据，否则代码写到三千行必然返工。

功能清单我通常收敛到这几项：用户注册与登录（账号密码校验）、在线用户列表实时刷新、群聊广播、一对一私聊、消息历史查询、异常断开后的资源回收。看起来不多，但每一项背后都有坑，比如在线列表刷新就涉及"用户上线/下线时如何通知所有客户端"，这直接决定了你用轮询还是服务端推送。

2.2 技术选型：为什么是原生 Socket 而不是框架

很多人会问，都什么年代了还用裸Socket，上 Netty 不好吗。这里要说清楚：课程设计和毕设考察的是你对 TCP 通信本质的理解，Netty 把Selector、缓冲区、编解码全封装了，你调通了也说不清accept和read的阻塞关系。原生Socket+ 多线程的方案，代码量可控，每一行你都能讲明白，答辩时被追问"为什么每个连接开一个线程"你能答上来，这才是这套方案的价值。数据库选 MySQL，用 JDBC 直连即可，不必上连接池框架，但连接管理要自己写对，后面会讲。客户端界面用 Swing，虽然老，但零依赖、能快速出效果，课设场景足够。通信协议用自定义的文本协议，一行一条消息，字段用分隔符隔开，简单直观，调试时telnet就能测。

提示：选型的原则是"每一层你都能解释清楚为什么"，而不是"哪个流行用哪个"。答辩老师问的往往不是你会不会用框架，而是你懂不懂底层。

2.3 通信协议设计：一行一条消息的约定

协议是整套系统的"普通话"，定不好后面全是方言。我一般用这样的格式：类型|发送者|接收者|内容|时间戳，字段之间用竖线分隔，一条消息以换行符结尾。类型字段区分LOGIN、LOGOUT、GROUP、PRIVATE、LIST、HISTORY等。为什么用换行符做消息边界？因为 TCP 是字节流，没有消息边界的概念，你不定边界，服务端read到的可能是半条消息，也可能是两条粘在一起，这就是经典的粘包问题。用换行符分隔，配合BufferedReader.readLine()，天然解决边界问题，代价是消息内容里不能出现换行，这个约束在聊天场景完全可接受。

// 协议常量定义，集中管理避免魔法字符串散落各处 public class Protocol { public static final String SEP = "\\|"; // 字段分隔符，正则转义 public static final String LOGIN = "LOGIN"; // 登录请求 public static final String GROUP = "GROUP"; // 群聊消息 public static final String PRIVATE = "PRIVATE";// 私聊消息 public static final String LIST = "LIST"; // 在线列表 public static final String HISTORY = "HISTORY";// 历史查询 // 组装一条协议消息：类型|发送者|接收者|内容|时间戳 public static String build(String type, String from, String to, String content) { return type + "|" + from + "|" + to + "|" + content + "|" + System.currentTimeMillis(); } }

这段代码的关键在于把协议格式收敛到一个类里，客户端和服务端都引用它，改协议只改一处。build方法里时间戳用毫秒，方便后续按时间排序查历史。注意SEP用了正则转义，因为String.split接收的是正则表达式，竖线在正则里是"或"的意思，不转义会切错，这是新手第一个翻车点。

3. 总体架构设计：C/S 结构与线程模型的职责划分

3.1 服务端三层结构：监听、会话、持久化

服务端我拆成三个职责明确的层。最外层是监听层，一个主线程死循环accept()，每接到一个连接就交给会话层；会话层为每个客户端连接维护一个ClientHandler对象，里面持有该连接的Socket、输入输出流、对应的用户名，并跑一个独立线程负责读这个连接的消息；持久化层封装所有 JDBC 操作，提供saveMessage、getHistory、verifyUser等方法，被会话层调用。三层之间通过共享的在线用户表（一个ConcurrentHashMap<String, ClientHandler>）通信，会话层上线时注册、下线时移除，广播时遍历这张表。

这个结构的好处是职责单一：监听层只管接客，会话层只管对话，持久层只管记账。出问题时定位很快——连不上看监听层，消息发不出看会话层，历史查不到看持久层。很多同学的代码把这三件事揉在一个类里，两千行下去自己都看不懂，改一个 bug 引出三个新 bug。

3.2 线程模型：一连接一线程的取舍

服务端为每个连接开一个读线程，这是最直观的模型。主线程accept后new Thread(new ClientHandler(socket)).start()，每个ClientHandler的run方法里while循环readLine，读到消息就分发处理。这个模型在几十到几百连接的量级完全够用，课设场景绰绰有余。它的代价是线程数随连接数线性增长，上万连接会撑爆内存，但那是 Netty 的 NIO 模型要解决的问题，不是这套方案的目标。答辩时如果被问"连接数上限怎么办"，你可以答：当前模型受限于线程栈内存，单机几百连接稳定，若要支撑更高并发需改用Selector多路复用，这是明确的演进方向，反而显得你想过。

写线程模型时有个细节必须处理：客户端异常断开时，readLine会抛IOException或返回null，此时必须finally里关闭流、移除在线表、通知其他人该用户下线。不写finally，用户直接关窗口，服务端线程就泄漏了，跑一天内存就满。

3.3 客户端结构：界面线程与通信线程分离

客户端最容易踩的坑是把网络读写放在 Swing 的事件线程（EDT）里，结果就是点一下发送，界面卡住直到服务端回消息。正确做法是通信线程独立：一个后台线程专门readLine收消息，收到后通过SwingUtilities.invokeLater把界面更新任务丢回 EDT。发送时直接往输出流写，写操作很快，不会明显阻塞。这样界面始终响应，收消息也不卡。

// 客户端接收线程：独立于界面线程，收到消息后切回 EDT 更新界面 new Thread(() -> { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8))) { String line; while ((line = in.readLine()) != null) { // 阻塞读，直到有消息或连接断开 final String msg = line; SwingUtilities.invokeLater(() -> appendToChatArea(msg)); // 切回界面线程 } } catch (IOException e) { SwingUtilities.invokeLater(() -> appendToChatArea("连接已断开")); } }).start();

这段代码有两个要点：一是readLine阻塞在后台线程，不影响界面；二是invokeLater保证界面组件只在 EDT 里被修改，Swing 不是线程安全的，跨线程直接改组件会出现玄学般的界面错乱。字符集显式指定 UTF-8，避免中文在不同系统默认编码下变乱码，这是血泪经验。

4. 核心模块实现：从连接建立到消息落库

4.1 服务端监听与会话分发

监听层的代码很短，但每一行都有讲究。ServerSocket绑定端口后进入accept循环，每接受一个连接就构造ClientHandler并启动线程。这里要注意accept本身是阻塞的，所以它必须跑在独立线程里，不能放在主线程，否则主线程被占住，后续任何逻辑都执行不了。

public class ChatServer { private static final int PORT = 8888; // 在线用户表，key 为用户名，value 为对应会话，ConcurrentHashMap 保证并发安全 public static final Map<String, ClientHandler> ONLINE = new ConcurrentHashMap<>(); public static void main(String[] args) throws IOException { ServerSocket server = new ServerSocket(PORT); System.out.println("服务端启动，监听端口 " + PORT); while (true) { Socket socket = server.accept(); // 阻塞等待新连接 ClientHandler handler = new ClientHandler(socket); new Thread(handler, "client-" + socket.getPort()).start(); // 一连接一线程 } } }

ONLINE用ConcurrentHashMap而不是HashMap，因为多个会话线程会同时读写这张表——用户 A 上线注册、用户 B 下线移除、广播时遍历，普通HashMap在并发下会抛ConcurrentModificationException甚至死循环。线程命名带上端口号，排查问题时日志里一眼能看出是哪个连接。

4.2 消息路由：群聊广播与私聊定向投递

消息分发是业务核心。ClientHandler读到一行后先按|切分，取第一个字段判断类型。群聊就遍历ONLINE给每个会话写消息，私聊就按接收者用户名从表里取出目标会话单独写。写操作要加锁或用同步的输出方法，因为同一个会话的输出流可能被多个线程同时写（比如 A 给 B 私聊的同时，C 在群里发消息也要写给 B），两个线程同时write会导致消息字节交错，接收端解析出乱码。

// 会话内统一的发送方法，synchronized 保证同一连接的消息不交错 public synchronized void send(String msg) { try { out.write(msg + "\n"); // 换行符作为消息边界 out.flush(); // 立即刷出，避免缓冲导致对方收不到 } catch (IOException e) { // 写失败说明连接已断，触发下线清理 ChatServer.ONLINE.remove(username); } } // 群聊广播：遍历在线表逐个发送 public static void broadcast(String msg) { for (ClientHandler h : ONLINE.values()) { h.send(msg); } }

synchronized加在send方法上，锁的是当前会话对象，保证同一连接上的写操作串行。flush不能省，BufferedWriter有缓冲区，不刷出消息会攒着，对方迟迟收不到，这是新手最常见的"消息发了但对方没反应"的原因。广播时如果某个会话写失败，顺手把它从在线表移除，避免死连接一直占着。

4.3 数据库持久化：用户表与消息表的设计

持久层用 JDBC 直连 MySQL，两张核心表。用户表存账号、密码（存哈希不存明文）、昵称、注册时间；消息表存消息类型、发送者、接收者、内容、发送时间。消息表加索引在(receiver, send_time)上，因为历史查询最常用的场景是"查我和某人的最近 N 条消息"。

CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, -- 用户名唯一，防重名 password VARCHAR(64) NOT NULL, -- 存 SHA-256 哈希，不存明文 nickname VARCHAR(32), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, msg_type VARCHAR(16) NOT NULL, -- GROUP / PRIVATE sender VARCHAR(32) NOT NULL, receiver VARCHAR(32), -- 群聊为 NULL content TEXT NOT NULL, send_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_receiver_time (receiver, send_time) -- 历史查询走索引 );

密码存哈希是底线，哪怕课设也别存明文，答辩时这是加分项。消息表的receiver群聊时留空，查询群聊历史就按msg_type='GROUP'过滤。JDBC 操作封装成一个MessageDao类，每个方法内部getConnection、PreparedStatement、close，用PreparedStatement而不是字符串拼接，防 SQL 注入的同时性能也更好。连接用完必须关，try-with-resources是最省心的写法。

4.4 登录校验与在线状态同步

登录流程是：客户端发LOGIN|用户名|密码，服务端查库校验，通过则把该会话注册进ONLINE，回一条成功消息，然后广播"某某上线"给所有人并推送最新在线列表；失败则回错误消息，客户端提示重试。这里有个并发细节：两个客户端同时用同一账号登录，ONLINE.put会覆盖前一个，导致前一个连接变成"幽灵"——它还在读消息，但已经不在表里，收不到广播。处理办法是注册前先containsKey判断，已在线则拒绝本次登录并提示"该账号已在别处登录"。

在线列表同步用服务端主动推送，而不是客户端定时轮询。用户上线、下线时，服务端组装当前ONLINE.keySet()拼成LIST|...消息广播给所有人，客户端收到就刷新列表控件。推送比轮询实时，也省流量，是这类系统的标准做法。

5. 避坑与排查：那些让课设返工的常见问题

5.1 中文乱码：编码不统一导致的消息变问号

现象是客户端发中文，对方收到一串问号或方块。原因几乎总是两端编码不一致：服务端用平台默认编码（Windows 下常是 GBK），客户端用 UTF-8，或者InputStreamReader没指定字符集。解决办法是两端所有流构造时显式传StandardCharsets.UTF_8，包括InputStreamReader、OutputStreamWriter、PrintWriter，一处不落。数据库连接串也要带characterEncoding=utf8。我一般会在项目启动时打印Charset.defaultCharset()确认环境，省得靠猜。

5.2 粘包与半包：消息被截断或两条粘一起

现象是偶尔收到半条消息，或者两条消息连成一条解析失败。原因是 TCP 是流式协议，没有消息边界，read一次拿到的字节数不确定。解决办法就是协议里定边界——这套方案用换行符，配合readLine天然按行切分。如果你自己用read(byte[])读，就必须自己处理缓冲区拼接，麻烦且易错。另一个容易忽略的点是消息内容里如果混入换行符会破坏边界，所以发送前要把内容里的\n替换掉。

5.3 线程泄漏：用户关窗口后服务端线程不释放

现象是跑一段时间后服务端内存持续上涨，jstack看到大量client-xxxx线程卡在readLine。原因是客户端异常断开时，服务端的读线程没有正确退出和清理。解决办法是在ClientHandler.run的finally块里做三件事：从ONLINE移除自己、关闭 socket 和流、广播下线通知。readLine返回null或抛异常都走这个finally，保证任何退出路径都清理干净。

5.4 界面卡死：网络操作跑在事件线程上

现象是点发送后界面无响应，或者收消息时窗口假死。原因是把readLine或数据库查询放在了 Swing 的 EDT 里。解决办法是网络读写全部放后台线程，界面更新统一用SwingUtilities.invokeLater切回 EDT。判断标准很简单：任何可能阻塞超过几十毫秒的操作，都不能出现在按钮回调里。

5.5 数据库连接耗尽：每次操作新建连接不关闭

现象是运行一段时间后报Too many connections。原因是每次 JDBC 操作都DriverManager.getConnection却忘了close，连接越积越多。解决办法是用try-with-resources确保Connection、PreparedStatement、ResultSet都被关闭，或者封装一个工具方法统一管理。课设量级不必上连接池，但关闭必须严格。

6. 验收与答辩：怎么证明这套聊天室真的能跑

验收不是演示一遍"能发消息"就完事，而是要证明它在异常场景下也稳。我一般按这张表逐项过，每项都有明确的通过标准，答辩时照着演示，老师问什么都有据可查。

演示顺序也有讲究：先演示正常流程建立信心，再主动制造异常——当着老师的面直接关掉一个客户端，然后展示服务端日志里该连接被清理、其他客户端收到下线提示，这一手比任何口头解释都有说服力。数据库那块，现场用命令行查一下t_message表，证明消息真的落库了，而不是只存在内存里。

答辩被追问的高频问题提前准备好答案：为什么一连接一线程（答：模型直观、课设量级够用，高并发需换 NIO）；粘包怎么解决（答：换行符定边界 + readLine）；密码怎么存（答：SHA-256 哈希）；线程安全怎么保证（答：ConcurrentHashMap + 发送方法加锁）。每个答案都能落到具体代码行，而不是背概念。

从那以后我每次带人做通信类项目，都强制要求先画协议表、再写服务端骨架、最后接界面，顺序颠倒一次就返工一次，这个习惯帮我省下的时间比任何技巧都多。希望这套结构能帮你把课设稳稳交出去。

本文还有配套的精品资源，点击获取