简介：这是一份面向Java初学者与网络编程入门者的综合性实践项目源码，围绕网络聊天室这一典型场景，串联起Socket通信、多线程并发处理与数据库管理等核心知识点，适合用于课程设计、毕业设计参考或自学练手。压缩包共46个文件，约199KB，以20个class编译文件、7个java源码、10张jpg界面截图及txt说明文档为主，另含数据库文件与工程配置文件，源码与运行产物齐全，便于直接导入IDE对照阅读。已有193人学习下载，具备一定的参考基础。项目覆盖用户注册登录验证、消息广播与在线状态跟踪、聊天记录持久化等模块，读者可从中理解服务端为每个连接开辟线程、客户端监听消息并刷新界面的完整链路，也能借鉴密码加密、异常捕获与调试排错思路，是深化Java技术理解、提升实际开发能力的一份实用素材。

1. 从一次“消息发出去对方没反应”说起

很多人第一次接触 Java 网络编程，都是从写一个聊天室开始的。想法很朴素：客户端连上服务端，输入一句话，服务端转发给所有人，屏幕上就能看到别人说的话。真动手写的时候，第一个翻车点往往不是界面，而是“消息发出去了，对方没反应”——控制台不报错，连接也没断，就是收不到。这类问题背后通常藏着 Socket 流的读写方式、线程阻塞、消息边界处理这几件事。这个 Java 网络聊天室项目，就是围绕 Socket 通信、多线程并发处理和数据库持久化三块搭起来的一个完整可跑的小系统，适合刚学完 Java 基础、想找一个能真正跑起来的多客户端网络程序来练手的开发者，也适合拿它当课程设计或二次开发的骨架。它不追求花哨，重点是把“多个客户端同时在线、消息实时转发、聊天记录落库”这条链路走通。

2. 项目定位与技术选型：为什么是 Socket + 多线程 + JDBC

2.1 这个聊天室到底解决什么问题

从功能上看，它要解决的是“多个人同时连到一个服务端，互相发消息，并且消息能被保存下来”这件事。拆开就是三个能力：第一，服务端要能同时接住多个客户端连接，不能来一个就把主线程卡死；第二，任意一个客户端发的消息，要能广播给其他在线的人；第三，聊天内容要能写进数据库，下次登录还能翻到历史记录。这三件事分别对应 Socket 通信、多线程并发、JDBC 数据库操作，也是这个项目标题里点名的三个技术点。

它适合的场景很明确：单机或局域网内的小规模聊天，客户端数量在几十个量级，不需要考虑分布式、消息队列、长连接保活这些重型方案。换句话说，它是一个“教学级但结构完整”的项目，拿来理解网络编程的基本盘非常合适。如果你一上来就想找 Netty 或者 WebSocket 的工程，那这个项目不是那个方向；但如果你想把“一个连接对应一个线程”这种最朴素的模型吃透，它正好。

2.2 技术栈拆解：每一层用了什么

项目的技术栈不复杂，但每一层都有明确职责，常见做法是这样组织的：

网络层用原生java.net.Socket和ServerSocket，没有引入第三方通信框架。这样做的好处是依赖少、代码透明，坏处是要自己处理粘包、线程安全、异常断开这些细节。并发层用多线程，一个客户端连上来就开一个线程专门读它的输入，主线程继续accept下一个连接。数据库层用 JDBC，通过DriverManager拿连接，用PreparedStatement执行插入和查询。客户端如果是图形界面，一般用 Swing 做窗口，如果是控制台版本，就用BufferedReader读键盘输入。

提示：数据库选型上，MySQL 是最常见的搭配，但项目本身不绑定具体数据库，只要 JDBC 驱动和连接串对得上，换成其他关系型数据库也能跑。连接串、用户名、密码通常集中在一个配置类或配置文件里，改的时候只动一处。

2.3 目录结构长什么样

一个结构清晰的版本，目录大致是这样组织的：

chatroom/ ├── src/ │ ├── server/ │ │ ├── ChatServer.java # 服务端入口，负责 accept 连接 │ │ ├── ClientHandler.java # 单个客户端的读写线程 │ │ └── MessageBroadcaster.java# 在线客户端集合与广播逻辑 │ ├── client/ │ │ ├── ChatClient.java # 客户端入口 │ │ └── ChatWindow.java # 图形界面（控制台版可省略） │ ├── dao/ │ │ ├── UserDao.java # 用户注册、登录校验 │ │ └── MessageDao.java # 聊天记录写入与查询 │ ├── model/ │ │ ├── User.java │ │ └── Message.java │ └── util/ │ └── DBUtil.java # 数据库连接获取与关闭 ├── lib/ │ └── mysql-connector-java.jar # 数据库驱动 └── sql/ └── init.sql # 建库建表脚本

这个划分的核心思路是“服务端、客户端、数据访问、模型、工具”五块分开。server包只关心连接和转发，dao包只关心 SQL，model包是纯数据对象，util放公共的连接管理。二次开发时想加功能，基本能一眼看出该往哪个包里塞代码。

2.4 数据库表设计：两张表撑起整个持久化

持久化部分不需要太复杂，两张表就够用。用户表存账号密码，消息表存聊天内容，常见建表语句如下：

-- 用户表：登录校验和昵称展示都靠它 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(32) ); -- 消息表：每条聊天记录一行，sender 存用户名 CREATE TABLE t_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sender VARCHAR(32) NOT NULL, content TEXT NOT NULL, send_time DATETIME DEFAULT CURRENT_TIMESTAMP );

t_user的username加了唯一约束，注册时重复插入会直接报错，省得在代码里再查一遍。t_message的send_time用数据库默认值，插入时不用手动传时间，少一个出错点。消息内容用TEXT而不是VARCHAR，是因为聊天内容长度不可控，用定长字段容易截断。这两张表的设计很朴素，但覆盖了“谁发的、发了什么、什么时候发的”三个关键信息，后面做历史记录查询直接按send_time倒序取就行。

3. 服务端核心链路：一个连接从 accept 到广播的完整过程

3.1 启动入口：ServerSocket 如何接住并发连接

服务端的起点是ServerSocket，它绑定一个端口，然后在一个循环里不断调用accept()等待客户端连进来。关键点是：accept()返回一个新的Socket之后，必须把这个连接交给独立线程去处理，主线程立刻回到accept()继续等下一个。如果直接在循环里读这个连接的数据，第二个客户端就连不进来了。

public class ChatServer { // 端口号集中定义，客户端要和服务端保持一致 private static final int PORT = 8888; public static void main(String[] args) throws IOException { ServerSocket serverSocket = new ServerSocket(PORT); System.out.println("聊天服务端已启动，监听端口：" + PORT); while (true) { // 阻塞等待客户端连接，每来一个就返回一个 Socket Socket socket = serverSocket.accept(); System.out.println("新客户端接入：" + socket.getInetAddress()); // 把连接交给独立线程处理，主线程继续 accept ClientHandler handler = new ClientHandler(socket); new Thread(handler).start(); } } }

这段代码里，PORT是服务端监听的端口，客户端连接时必须用同一个值。accept()是阻塞方法，没有连接进来时线程停在这里，这是正常的。new Thread(handler).start()是并发的关键——每个连接一个线程，互不阻塞。实际项目里如果连接数可能上百，我一般会把new Thread换成固定大小的线程池，避免线程数失控，但教学版本用裸线程更直观。

3.2 单客户端处理线程：读一行、转一行

ClientHandler是真正干活的地方，它实现Runnable，在run()里循环读取客户端发来的消息，读到之后交给广播器转发。这里有个血泪经验：读的时候要用BufferedReader.readLine()按行读，而不是直接读字节数组，否则消息边界很难判断。

public class ClientHandler implements Runnable { private final Socket socket; private BufferedReader reader; private PrintWriter writer; private String username; public ClientHandler(Socket socket) { this.socket = socket; } @Override public void run() { try { // 统一用 UTF-8，避免中文乱码 reader = new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); writer = new PrintWriter( new OutputStreamWriter(socket.getOutputStream(), StandardCharsets.UTF_8), true); // 第一行约定为用户名，用于标识身份 username = reader.readLine(); MessageBroadcaster.add(this); String line; // readLine 阻塞等待，客户端断开时返回 null while ((line = reader.readLine()) != null) { Message msg = new Message(username, line); MessageBroadcaster.broadcast(msg); // 转发给所有在线客户端 MessageDao.save(msg); // 落库保存 } } catch (IOException e) { System.out.println("客户端异常断开：" + username); } finally { MessageBroadcaster.remove(this); closeQuietly(); } } // 向该客户端发送一条消息 public void send(String text) { writer.println(text); } private void closeQuietly() { try { if (socket != null) socket.close(); } catch (IOException ignored) {} } }

几个参数和细节值得说清楚。InputStreamReader和OutputStreamWriter都显式指定了UTF-8，这是中文聊天室最容易翻车的地方，不指定就跟着系统默认编码走，跨机器一跑就乱码。PrintWriter的第二个参数true表示自动 flush，不设的话消息可能卡在缓冲区里发不出去，表现就是“对方半天收不到”。readLine()返回null代表客户端正常关闭了连接，这时候要跳出循环并把自己从在线列表里移除，否则广播时会往一个死连接写数据。

3.3 广播器：在线集合与线程安全

广播逻辑本身不复杂，难的是线程安全。多个ClientHandler线程会同时往在线集合里加人、删人、遍历发消息，如果用一个普通ArrayList，并发修改就会抛ConcurrentModificationException。常见做法是用CopyOnWriteArrayList，它在遍历时不会因为增删而崩。

public class MessageBroadcaster { // 写少读多的场景，CopyOnWriteArrayList 遍历安全 private static final List<ClientHandler> CLIENTS = new CopyOnWriteArrayList<>(); public static void add(ClientHandler handler) { CLIENTS.add(handler); } public static void remove(ClientHandler handler) { CLIENTS.remove(handler); } public static void broadcast(Message msg) { String text = msg.getSender() + "：" + msg.getContent(); for (ClientHandler client : CLIENTS) { client.send(text); // 逐个推送，某个连接异常不影响其他人 } } }

CopyOnWriteArrayList的代价是每次写操作都会复制整个数组，但聊天室的在线列表规模很小，增删也不频繁，这个开销完全可以接受。broadcast里逐个调用send，如果某个客户端已经断开但还没被移除，PrintWriter写失败一般不会抛异常（它会把错误吞掉），所以不会影响其他客户端的正常接收。这也是为什么finally里一定要remove，让在线列表尽量保持准确。

3.4 消息落库：JDBC 写入与异常兜底

消息转发的同时要写数据库，这一步放在MessageDao.save里。用PreparedStatement而不是拼接 SQL，既防注入又省得处理引号转义。

public class MessageDao { public static void save(Message msg) { String sql = "INSERT INTO t_message(sender, content) VALUES(?, ?)"; // try-with-resources 自动关闭连接和语句 try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, msg.getSender()); ps.setString(2, msg.getContent()); ps.executeUpdate(); } catch (SQLException e) { // 落库失败不能影响聊天主流程，只记录日志 System.err.println("消息保存失败：" + e.getMessage()); } } }

这里有个设计取舍：数据库写入失败时，只打印错误，不向上抛异常。原因是聊天室的核心功能是实时通信，数据库只是附加能力，如果因为数据库短暂不可用就让整个消息转发中断，体验会很差。DBUtil.getConnection()负责从连接池或DriverManager拿连接，具体实现放在工具类里，DAO 层不关心连接怎么来的。这种分层在二次开发时很省事——以后想换连接池，只改DBUtil一个文件。

4. 客户端与通信协议：约定比代码更重要

4.1 客户端连接与收发线程分离

客户端要做两件事：一是读键盘输入发给服务端，二是随时接收服务端推来的消息。这两件事必须分开，否则读键盘的时候收不到消息，收消息的时候没法输入。常见做法是主线程负责读键盘，另开一个线程专门收消息。

public class ChatClient { public static void main(String[] args) throws IOException { Socket socket = new Socket("127.0.0.1", 8888); BufferedReader reader = new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); PrintWriter writer = new PrintWriter( new OutputStreamWriter(socket.getOutputStream(), StandardCharsets.UTF_8), true); BufferedReader keyboard = new BufferedReader(new InputStreamReader(System.in)); // 先发用户名，服务端第一行按用户名处理 System.out.print("请输入昵称："); writer.println(keyboard.readLine()); // 收消息线程：持续读取服务端推送 new Thread(() -> { try { String line; while ((line = reader.readLine()) != null) { System.out.println(line); } } catch (IOException e) { System.out.println("与服务端断开连接"); } }).start(); // 主线程：读键盘输入并发送 String input; while ((input = keyboard.readLine()) != null) { writer.println(input); } } }

new Socket("127.0.0.1", 8888)里的地址和端口要和服务端一致，局域网内测试时把127.0.0.1换成服务端的实际地址。收消息线程用 lambda 起了一个匿名线程，里面循环readLine，读到就打印。主线程读System.in，每读一行就writer.println发出去。两个线程一个读一个写，互不干扰，这是客户端不卡顿的关键。

4.2 自定义消息格式：用分隔符区分类型

纯文本聊天够用，但一旦要加“登录”“私聊”“退出”这些指令，就得约定消息格式。最简单的做法是用一个分隔符把“类型”和“内容”分开，比如用|：

LOGIN|张三 MSG|大家好 PRIVATE|李四|晚上开会 QUIT|

服务端收到一行后先split("\\|")，看第一个字段是什么类型，再走不同分支。这种格式的优点是实现简单、调试直观，缺点是内容里不能出现分隔符。如果聊天内容可能包含|，就要么换一个更冷门的分隔符，要么对内容做转义。教学项目里一般约定“内容不包含分隔符”就够了，真要做严谨，可以换成 JSON，但那就需要引入序列化库，复杂度会上一个台阶。

注意：消息格式一旦定下来，服务端和客户端必须同步改。只改一边，表现就是“消息发出去了但对方没反应”或者“收到一堆乱码字段”。改协议的时候，我一般会先在纸上把几种消息类型列全，再动手写代码。

4.3 图形界面版本怎么接

如果客户端用 Swing，网络部分不用重写，只需要把“打印到控制台”换成“追加到文本区域”。收消息线程里调用chatArea.append(line + "\n")，发送按钮的监听器里调用writer.println(inputField.getText())。要注意 Swing 的界面更新必须在事件调度线程里做，跨线程直接改组件可能出问题，常见做法是用SwingUtilities.invokeLater包一层。

// 收消息线程中更新界面，必须切回事件调度线程 SwingUtilities.invokeLater(() -> chatArea.append(line + "\n"));

这行代码看着不起眼，但少了它，界面偶尔会卡住或者不刷新，排查起来很费时间。控制台版本没有这个问题，所以如果只是想验证通信逻辑，先用控制台跑通，再接界面，能省掉一半的调试成本。

5. 避坑与排查：那些跑起来才会暴露的问题

5.1 中文乱码：编码不统一

现象是客户端发中文，对方收到问号或者乱码。原因通常是服务端和客户端的InputStreamReader/OutputStreamWriter没有显式指定字符集，各自跟着系统默认编码走，两边不一致就乱。解决办法是在所有流包装的地方统一写StandardCharsets.UTF_8，包括服务端读、服务端写、客户端读、客户端写四处，一处漏了都可能出问题。数据库连接串里也建议带上characterEncoding=utf8，避免入库时再乱一次。

5.2 消息发不出去：忘了 flush

现象是代码逻辑看着没问题，但消息就是延迟很久才到，或者干脆不到。原因是PrintWriter默认带缓冲，不调用flush()数据就留在缓冲区里。解决办法是构造PrintWriter时把自动刷新参数设为true，或者每次println之后手动flush()。这个坑很隐蔽，因为不报错，只是“慢半拍”，新手容易怀疑是网络问题。

5.3 第二个客户端连不上：accept 被阻塞

现象是第一个客户端能正常聊天，第二个客户端一连就卡住。原因多半是在accept()之后直接在当前线程里读这个连接的数据，主线程被占住，回不到accept()。解决办法是把每个连接交给独立线程或线程池处理，主线程只负责接收连接。检查的时候看while循环里accept()后面是不是紧跟着readLine()，是的话就是这个问题。

5.4 广播时抛并发修改异常

现象是聊天人数一多，服务端偶尔抛ConcurrentModificationException，然后某个客户端就收不到消息了。原因是在线列表用了普通ArrayList，一个线程在遍历发消息，另一个线程同时在增删。解决办法是换成CopyOnWriteArrayList，或者对遍历加锁。前者更简单，适合在线列表规模不大的场景。

5.5 客户端断开后服务端还在写

现象是某个客户端关掉之后，服务端日志里还在往它发消息，甚至报错。原因是客户端断开时readLine()返回null，但ClientHandler没有在finally里把自己从在线列表移除。解决办法是确保finally块里一定执行remove和close，让在线列表和真实连接状态保持一致。这个坑在测试时不容易发现，因为断开一两个客户端影响不大，但积累多了广播就会变慢。

6. 二次开发：从能跑到好用，我一般改这几处

拿到这个项目跑通之后，真正有意思的是往上加东西。我的习惯是先不动核心通信链路，从外围功能切入，这样即使改坏了也容易回退。第一个改动点是私聊：在消息格式里加一个PRIVATE|目标用户|内容类型，服务端收到后不再广播，而是遍历在线列表找到目标用户的ClientHandler，单独send。这里要注意目标用户可能不在线，得给发送方回一条提示，否则用户会以为消息丢了。

第二个改动点是历史记录查询。MessageDao里加一个按时间倒序取最近 N 条的方法，客户端登录成功后先拉一次历史，再进入实时聊天。SQL 很简单：

// 取最近 50 条历史消息，按时间正序展示 String sql = "SELECT sender, content, send_time FROM t_message " + "ORDER BY send_time DESC LIMIT 50";

查出来是倒序的，展示前在内存里反转一下，或者用子查询再排一次序，看个人习惯。分页的话把LIMIT 50换成LIMIT ?, ?，传偏移量和条数就行。

第三个改动点是线程模型。教学版本一个连接一个线程，连接数一多线程就爆。我一般会换成固定大小的线程池，核心线程数按预期在线人数设，比如 50。改的时候只动ChatServer里new Thread(handler).start()那一行，换成executor.execute(handler)，其他代码不用动。这个改动风险低、收益明显，适合作为第一个性能优化点。

验证改动是否生效，我一般用“三客户端法”：开三个客户端，A 发广播看 B、C 是否都收到，A 发私聊给 B 看 C 是否收不到，关掉 B 再看 A 发消息是否正常。这套流程走一遍，基本能覆盖连接、广播、私聊、断开四个关键路径。从那以后我每次改通信相关的代码，都强制走一遍这个三客户端流程，哪怕只改了一行flush，也不敢省——网络程序的坑往往就藏在这种“看起来不会影响”的改动里。希望帮到你。

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