简介：这份资源是面向Java初学者与网络编程进阶者的TCP网络通信聊天室完整项目包，围绕客户端与服务器端实时交互场景，帮助读者理解面向连接、可靠传输的TCP协议原理及Java网络编程API的实际运用。包内共15个文件，以java源码、class编译文件、properties配置、prefs与classpath工程文件为主，另附mp4演示视频和doc报告论文，压缩包约7.19MB，结构清晰便于按模块查阅。源码中服务器端通过ServerSocket监听端口，借助多线程处理多个客户端连接并广播消息，客户端使用Socket建立连接、以输入输出流收发数据，涵盖多线程编程、异常处理与消息队列等关键点。演示视频展示编译运行与实时聊天流程，6000字论文则深入讨论设计目标、技术选型、功能特点与性能分析。目前已有1187人学习，适合希望动手实践并系统掌握多人在线聊天系统设计的读者。
1. Java TCP 网络通信聊天室：从三次握手到消息广播，一套能跑通的完整链路
很多人第一次接触 Socket 编程，都是从一个聊天室开始的。但真正动手写的时候才发现，问题不在“能不能连上”，而在“连上之后消息怎么发、发给谁、断了怎么办”。Java 的 TCP 网络通信聊天室，本质上是用ServerSocket和Socket搭一条可靠的字节通道，再在这条通道上定义自己的“消息协议”——谁发的、发给谁、是文本还是系统通知。它解决的是多客户端实时消息同步的问题，适合想搞懂 TCP 连接生命周期、线程模型和 I/O 读写边界的开发者。标题里提到的源码、演示视频和报告论文，核心都绕不开这条链路：服务端监听端口、客户端发起三次握手、连接建立后双方通过输入输出流交换数据。把这套东西跑通，比背十遍 TCP 协议栈都有用。
2. 先想清楚：为什么聊天室是理解 TCP 的最佳练手项目
2.1 TCP 连接在聊天室里的真实生命周期
TCP 不是“连上就完事”的协议。在聊天室场景里，一条连接从建立到销毁，要经历几个明确阶段：客户端调用new Socket(host, port)触发三次握手；服务端accept()返回一个新的Socket实例，这个实例专门对应这个客户端；双方通过getInputStream()和getOutputStream()读写字节；任何一方调用close()或异常退出，触发四次挥手。很多新手写的聊天室“只能一个人说话”，根因就是没理解accept()返回的是每个客户端独立的 Socket，而不是共享同一个。
服务端必须为每个连接维护一个独立的处理线程或通道。如果用单线程循环去read()，第一个客户端不发消息，第二个客户端就连accept()都进不来。这是 TCP 全双工特性带来的必然结果：连接是双向的，但你的代码如果只在一个方向上阻塞，另一个方向就废了。
提示：
accept()阻塞等待新连接，read()阻塞等待数据到达。两个阻塞点必须在不同线程里，否则聊天室永远只能服务一个人。
2.2 选 BIO 还是 NIO：聊天室规模决定技术路线
Java 里实现 TCP 服务端有两套主流方案：BIO（阻塞 I/O）和 NIO（非阻塞 I/O）。聊天室如果只是课程设计或小团队内部使用，BIO 完全够用，代码直观，调试方便。一个客户端一个线程，线程数等于在线人数，几十个人以内毫无压力。NIO 用Selector多路复用，单线程或少量线程就能管理上千连接，但代码复杂度陡增，缓冲区管理、半包粘包处理都得自己来。
我一般会这样选：如果目标是“跑通原理、交报告、演示功能”，BIO 是首选；如果标题里明确要求“高并发”或“支持大量客户端”，再考虑 NIO。常见做法是用ExecutorService线程池来管理客户端线程，避免new Thread()无限创建导致资源耗尽。线程池核心参数建议：核心线程数设为 10，最大线程数设为 200，队列用LinkedBlockingQueue，空闲线程存活时间 60 秒。这样既能应对突发连接，又不会让服务器被线程拖垮。
2.3 消息协议设计：别让“纯文本”变成黑匣子
TCP 是字节流协议，它不关心你发的是“你好”还是“USER:张三:你好”。如果不定义消息边界，接收方read()到的可能是一半消息，也可能是两条消息粘在一起。聊天室最常见的做法是行协议：每条消息以换行符\n结尾，接收方用BufferedReader.readLine()按行读取。这样天然解决了粘包问题，因为readLine()会一直读到换行符才返回。
消息格式建议用简单的分隔符协议，比如类型|发送者|内容。类型可以是MSG（普通消息）、SYS（系统通知）、LIST（在线列表）。服务端收到后解析，再根据类型决定广播给所有人还是只回给发送者。这种设计的好处是扩展性强，后面加私聊、加文件传输，只需要新增类型字段，不用推翻重来。
// 消息协议常量定义 public class Protocol { public static final String SEPARATOR = "|"; public static final String TYPE_MSG = "MSG"; // 普通聊天消息 public static final String TYPE_SYS = "SYS"; // 系统通知 public static final String TYPE_LIST = "LIST"; // 在线用户列表 // 封装消息：类型|发送者|内容 public static String encode(String type, String sender, String content) { return type + SEPARATOR + sender + SEPARATOR + content; } // 解析消息，返回长度为3的数组 public static String[] decode(String line) { return line.split("\\" + SEPARATOR, 3); } }这段代码定义了聊天室最基础的消息编解码规则。encode把类型、发送者、内容拼成一行，decode按分隔符拆开。注意split的第二个参数传 3，表示最多拆成三段，这样消息内容里如果包含|也不会被错误切分。参数SEPARATOR选竖线是因为它比逗号、冒号更少出现在日常聊天文本里，降低解析冲突概率。
3. 服务端实现：从 ServerSocket 到消息广播的完整代码
3.1 启动监听与客户端接入线程模型
服务端入口非常固定：创建ServerSocket绑定端口，然后死循环accept()。每接到一个客户端，就把这个 Socket 交给线程池处理。这里有一个血泪经验：accept()返回后，一定要先给客户端发送欢迎消息或要求输入昵称，否则客户端连上来之后一片空白，用户不知道下一步干什么。
public class ChatServer { private static final int PORT = 8888; // 线程池：核心10，最大200，空闲60秒回收 private static final ExecutorService POOL = new ThreadPoolExecutor( 10, 200, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(500), new ThreadPoolExecutor.CallerRunsPolicy()); // 保存在线客户端：昵称 -> 输出流 private static final Map<String, PrintWriter> ONLINE = new ConcurrentHashMap<>(); public static void main(String[] args) throws IOException { ServerSocket server = new ServerSocket(PORT); System.out.println("聊天室服务端已启动，端口：" + PORT); while (true) { Socket client = server.accept(); // 阻塞等待新连接 POOL.execute(new ClientHandler(client)); // 交给线程池 } } }ServerSocket的accept()是阻塞方法，没有新连接时线程停在这里。POOL.execute()把每个客户端封装成ClientHandler任务提交给线程池。ONLINE用ConcurrentHashMap是因为多个线程会同时读写这个 Map，普通HashMap在并发下会丢数据甚至死循环。CallerRunsPolicy是拒绝策略：当队列满且线程数达到上限时，由调用者线程自己执行任务，保证消息不丢，但会短暂阻塞accept()，适合聊天室这种不能丢消息的场景。
3.2 单个客户端的读写循环与昵称注册
每个ClientHandler要干三件事：读取客户端发来的第一行作为昵称、把昵称和输出流注册到ONLINE、进入循环不断读取消息并广播。读取用BufferedReader包装InputStreamReader，指定 UTF-8 编码，否则中文会变乱码。
class ClientHandler implements Runnable { private final Socket socket; private String nickname; private PrintWriter out; public ClientHandler(Socket socket) { this.socket = socket; } @Override public void run() { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8))) { out = new PrintWriter(new OutputStreamWriter( socket.getOutputStream(), StandardCharsets.UTF_8), true); out.println("请输入昵称："); nickname = in.readLine(); // 第一行作为昵称 if (nickname == null || nickname.trim().isEmpty()) return; ONLINE.put(nickname, out); broadcast(Protocol.encode(Protocol.TYPE_SYS, "系统", nickname + " 加入了聊天室")); String line; while ((line = in.readLine()) != null) { // 阻塞读，直到客户端断开 String[] parts = Protocol.decode(line); if (parts.length == 3 && Protocol.TYPE_MSG.equals(parts[0])) { broadcast(Protocol.encode(Protocol.TYPE_MSG, nickname, parts[2])); } } } catch (IOException e) { System.out.println(nickname + " 连接异常：" + e.getMessage()); } finally { if (nickname != null) { ONLINE.remove(nickname); broadcast(Protocol.encode(Protocol.TYPE_SYS, "系统", nickname + " 离开了聊天室")); } } } // 广播给所有在线客户端 private void broadcast(String msg) { for (PrintWriter writer : ONLINE.values()) { writer.println(msg); } } }PrintWriter的第二个参数true表示自动刷新，每次println后立即把数据推出去，不用手动flush()。in.readLine()在循环里阻塞，客户端一断开就返回null，循环结束，进入finally清理在线列表并广播离开通知。broadcast遍历ONLINE的所有输出流逐个写入，这就是聊天室“群发”的本质。注意ONLINE的 value 是PrintWriter，不是Socket，因为写消息只需要输出流，存 Socket 反而增加耦合。
3.3 广播时的并发修改与异常剔除
broadcast方法在遍历ONLINE.values()时，如果有客户端刚好断开并从 Map 中移除，ConcurrentHashMap的弱一致性迭代器不会抛ConcurrentModificationException，但可能读到已经关闭的流。这时writer.println()不会抛异常，而是设置内部错误标志，后续写入全部静默失败。所以更稳妥的做法是在广播时检查writer.checkError()，如果为true就主动从ONLINE移除该条目。
private void broadcast(String msg) { Iterator<Map.Entry<String, PrintWriter>> it = ONLINE.entrySet().iterator(); while (it.hasNext()) { Map.Entry<String, PrintWriter> entry = it.next(); PrintWriter writer = entry.getValue(); writer.println(msg); if (writer.checkError()) { // 写入失败，说明客户端已断开 it.remove(); // 从在线列表剔除 } } }checkError()返回true表示流在之前的写入中发生过错误，通常是客户端 Socket 已关闭。用Iterator显式遍历可以在检测到失效连接时安全移除，避免无效广播。这个细节很多教程不讲，但实际跑起来，客户端强制关闭后服务端还在傻傻地往一个死连接写数据，日志里全是无意义的异常，加上这段逻辑就干净了。
4. 客户端实现：连接、收发消息与界面线程的配合
4.1 建立连接与后台接收线程
客户端要做两件互不干扰的事：等待用户输入并发送、随时接收服务端推来的消息。如果用单线程，readLine()一阻塞，用户就没法输入了。所以必须开两个线程：主线程负责读键盘输入并发送，后台线程负责从 Socket 读消息并打印。
public class ChatClient { public static void main(String[] args) throws IOException { Socket socket = new Socket("127.0.0.1", 8888); BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); PrintWriter out = new PrintWriter(new OutputStreamWriter( socket.getOutputStream(), StandardCharsets.UTF_8), true); BufferedReader keyboard = new BufferedReader(new InputStreamReader(System.in)); // 后台线程：持续接收服务端消息 new Thread(() -> { try { String msg; while ((msg = in.readLine()) != null) { System.out.println(msg); // 直接打印到控制台 } } catch (IOException e) { System.out.println("与服务端断开连接"); } }).start(); // 主线程：读键盘输入并发送 String input; while ((input = keyboard.readLine()) != null) { out.println(Protocol.encode(Protocol.TYPE_MSG, "我", input)); } } }new Socket("127.0.0.1", 8888)触发三次握手，连接失败会抛ConnectException。后台线程用 lambda 创建，循环readLine()直到服务端关闭连接。主线程读键盘，每读一行就按协议编码发送。注意这里发送者写的是“我”，实际服务端会用注册的昵称覆盖，所以客户端发送时其实只需要传内容，发送者字段由服务端填充更合理。这个细节在写报告论文时可以作为一个“协议优化点”来讨论。
4.2 用 Swing 做界面时的 EDT 陷阱
如果聊天室带图形界面，最大的坑是在非 EDT 线程里更新 UI 组件。Swing 不是线程安全的，后台接收线程直接调用textArea.append(msg)可能导致界面错乱甚至死锁。正确做法是用SwingUtilities.invokeLater()把 UI 更新操作丢回事件调度线程。
// 后台接收线程中更新 UI 的正确方式 while ((msg = in.readLine()) != null) { final String finalMsg = msg; SwingUtilities.invokeLater(() -> { chatArea.append(finalMsg + "\n"); chatArea.setCaretPosition(chatArea.getDocument().getLength()); }); }invokeLater把 Runnable 放到 EDT 的事件队列末尾，等当前事件处理完再执行。setCaretPosition让滚动条自动跟到最新消息，否则用户要手动往下拉。这个写法比直接append多一层包装，但避免了玄学崩溃。很多课程设计里的聊天室界面偶尔卡死，根因就在这里。
4.3 客户端断线重连的简单策略
网络抖动或服务端重启时，客户端readLine()会返回null或抛IOException。如果不做处理，用户只能重启客户端。一个简单的重连策略是：在后台接收线程的catch块里，循环尝试new Socket()，每次间隔 3 秒，最多重试 5 次。重连成功后重新注册昵称，并提示用户“已重新连接”。
private static Socket connectWithRetry(String host, int port) { int retries = 5; while (retries-- > 0) { try { return new Socket(host, port); } catch (IOException e) { System.out.println("连接失败，3秒后重试...剩余次数：" + retries); try { Thread.sleep(3000); } catch (InterruptedException ignored) {} } } throw new RuntimeException("无法连接到聊天室服务端"); }这段代码把重连逻辑封装成独立方法，主线程和后台线程都可以调用。Thread.sleep(3000)让重试间隔固定，避免疯狂重连打爆服务端。实际项目中可以把重试次数和间隔做成配置项，但课程设计里写死 5 次 3 秒足够演示容错思路。
5. 避坑与排查：聊天室跑不起来时先看这 5 条
5.1 现象：客户端连不上，报 Connection refused
原因通常是服务端没启动，或者端口被占用后ServerSocket创建失败但没打印异常。解决：先确认服务端main方法已经跑起来，控制台有“聊天室服务端已启动”输出。如果端口被占用，换一个端口，比如从 8888 改成 9999。Windows 下可以用netstat -ano | findstr 8888查看端口占用进程。
5.2 现象：中文消息显示为问号或乱码
原因是InputStreamReader和OutputStreamWriter没有指定字符集，用了平台默认编码。Windows 默认 GBK，Linux 默认 UTF-8，两边不一致就乱码。解决：所有流包装都显式传StandardCharsets.UTF_8，包括服务端和客户端，一处都不能漏。如果客户端用System.out.println打印，控制台编码也要设成 UTF-8，IDEA 里在 VM options 加-Dfile.encoding=UTF-8。
5.3 现象：一个人说话，其他人收不到
检查broadcast方法是否真的遍历了所有在线输出流。常见错误是把消息只写回给发送者自己的out，或者ONLINEMap 在注册时 key 用了socket.getPort()但广播时遍历的是空集合。解决：在broadcast入口打印ONLINE.size()，确认在线人数正确。如果 size 是 0，说明昵称注册那一步没执行成功，检查in.readLine()是否返回了 null。
5.4 现象：客户端关闭后，服务端线程不退出
readLine()在客户端正常close()时会返回null，循环结束，线程自然退出。但如果客户端是强制杀进程，TCP 连接没有正常挥手，服务端readLine()可能阻塞很久才抛异常。解决：在服务端设置socket.setSoTimeout(30000)，30 秒没收到数据就抛SocketTimeoutException，在 catch 里清理资源。这样即使客户端异常掉线，服务端也能在 30 秒内回收线程。
5.5 现象：消息发送顺序错乱或丢失
TCP 保证字节流有序可靠，但如果你在PrintWriter外面又包了BufferedWriter且没有正确 flush，消息就会卡在缓冲区。解决：统一用PrintWriter自动刷新，或者每次write后手动flush()。另外，多线程同时往同一个PrintWriter写数据会导致消息交错，比如两个线程同时println，输出可能变成MSG|张MSG|李|你好|你好。解决：对PrintWriter的写入操作加synchronized，或者每个客户端只用一个线程负责写。
6. 进阶技巧：用 NIO 重写聊天室核心，把线程数压到个位数
BIO 聊天室跑通之后，如果想在报告论文里体现深度，可以进一步用 NIO 的Selector重写服务端。核心思路是：所有客户端连接注册到同一个Selector上，一个或少数几个线程轮询就绪事件，可读就读、可写就写。这样 1000 个在线用户也只需要 1 到 4 个线程，资源占用大幅下降。
关键代码结构如下：
Selector selector = Selector.open(); ServerSocketChannel serverChannel = ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8888)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { selector.select(); // 阻塞直到有事件就绪 Set<SelectionKey> keys = selector.selectedKeys(); Iterator<SelectionKey> it = keys.iterator(); while (it.hasNext()) { SelectionKey key = it.next(); it.remove(); // 必须手动移除，否则下次还会处理 if (key.isAcceptable()) { SocketChannel client = serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ, new ClientState()); } else if (key.isReadable()) { SocketChannel client = (SocketChannel) key.channel(); ByteBuffer buffer = ByteBuffer.allocate(1024); int len = client.read(buffer); if (len == -1) { client.close(); continue; } buffer.flip(); // 处理半包：把 buffer 中数据追加到 ClientState 的累积缓冲区 // 按换行符切分完整消息，再广播 } } }selector.select()是 NIO 的核心阻塞点，有事件才返回。it.remove()必须调用，否则已处理的事件下次循环还会出现。ClientState是自定义附件对象，用来保存每个客户端的累积缓冲区，解决 TCP 半包问题：一次read可能只读到半条消息，需要把数据攒起来，直到遇到换行符才认为是一条完整消息。这个累积缓冲区的实现是 NIO 聊天室最容易翻车的地方，血泪经验是：缓冲区要用ByteArrayOutputStream动态扩展，不要用固定大小数组，否则长消息会被截断。
验证 NIO 版本是否正确的办法很简单：开 200 个客户端同时连接，用jconsole或jstack观察服务端线程数。BIO 版本线程数会飙到 200 以上，NIO 版本应该稳定在个位数。如果 NIO 版本线程数也暴涨，说明Selector没起作用，检查configureBlocking(false)是否漏调。
最后说一个我自己的习惯：每次写完聊天室，先不急着加界面，用telnet 127.0.0.1 8888手动连上去发几行文本，确认服务端协议解析和广播逻辑没问题，再写客户端。这样能把网络层和界面层的问题分开排查，省下大量“到底是 Socket 断了还是按钮没绑定事件”的纠结时间。希望帮到你。
本文还有配套的精品资源，点击获取
