尧图网页设计 
简介这份资源是面向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 MapString, 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) { IteratorMap.EntryString, PrintWriter it ONLINE.entrySet().iterator(); while (it.hasNext()) { Map.EntryString, 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 默认 GBKLinux 默认 UTF-8两边不一致就乱码。解决所有流包装都显式传StandardCharsets.UTF_8包括服务端和客户端一处都不能漏。如果客户端用System.out.println打印控制台编码也要设成 UTF-8IDEA 里在 VM options 加-Dfile.encodingUTF-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(); // 阻塞直到有事件就绪 SetSelectionKey keys selector.selectedKeys(); IteratorSelectionKey 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 断了还是按钮没绑定事件”的纠结时间。希望帮到你。本文还有配套的精品资源点击获取 Java TCP聊天室实战：从Socket连接到消息广播完整链路
简介这份资源是面向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 MapString, 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) { IteratorMap.EntryString, PrintWriter it ONLINE.entrySet().iterator(); while (it.hasNext()) { Map.EntryString, 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 默认 GBKLinux 默认 UTF-8两边不一致就乱码。解决所有流包装都显式传StandardCharsets.UTF_8包括服务端和客户端一处都不能漏。如果客户端用System.out.println打印控制台编码也要设成 UTF-8IDEA 里在 VM options 加-Dfile.encodingUTF-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(); // 阻塞直到有事件就绪 SetSelectionKey keys selector.selectedKeys(); IteratorSelectionKey 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 断了还是按钮没绑定事件”的纠结时间。希望帮到你。本文还有配套的精品资源点击获取