简介一款基于Java的实时聊天室项目界面完整提供群聊、私聊与在线用户列表功能适合正在学习Java网络编程、多线程及GUI开发的初学者也可作为课程设计与毕业设计的参考原型。压缩包内含42个文件其中14个java源码与15个class编译文件构成主体另配project、classpath、txt等工程配置文件压缩后仅46KB轻量且结构清晰。已有7431人浏览学习属于同类项目中热度较高的实战案例。项目通过ServerSocket与Socket建立客户端-服务器通信利用多线程并行处理用户收发消息使用Swing组件绘制聊天窗口、输入框与用户列表并在交互中处理事件监听与状态更新。此外还涉及消息序列化传输、集合框架维护在线用户、异常处理等知识点能帮助学习者在真实场景中理解Socket通信与多线程协作快速搭建并扩展自己的聊天室应用。1. 为什么你的Java聊天室总差口气群聊、私聊和用户列表才是完整的分水岭我第一次写完Java聊天室最得意的不是能发消息而是用户列表真的“会动”——有人进来自动多一行有人退出自动消失双击任意一个名字就能弹出私聊窗口。翻过不少同类源码后会发现能跑通群聊的示例很多但界面完整、私聊路由和用户列表同步全都到位的反而是少数大多数人卡在消息协议那一层后面的功能全堆在一串if里越写越乱。这篇把一个整理过很多次的落地方案拆开讲消息协议怎么定服务端和客户端各负责什么群聊、私聊、用户列表三条主线怎么串起来以及那些最容易翻车的边界问题。适合拿它做课程设计、毕业设计或者想弄懂Socket多线程和Swing协作关系的入门者。2. 先画清楚三条主线群聊广播、私聊路由与用户列表同步2.1 为什么用“一个客户端一条线程”的模型而不上NIO聊天室是一个典型的C/S模型服务端负责维护所有客户端的连接客户端只跟服务端通信。标题里的三个功能——群聊、私聊、用户列表——在服务端分别对应三种操作群聊是一次广播私聊是一次定向转发用户列表是一次状态同步。它们都依赖服务端维护的一份“当前在线用户”名单所以数据结构和消息协议是必须先想清楚的两件事。线程模型的选择上常见做法是一个客户端对应一条线程配合固定大小的线程池也就是BIO。理由很简单聊天室这种场景一个服务端同时撑几十个客户端是常态但让它去扛几百上千个长连接那是正经IM产品要考虑的事课程设计和内部工具没必要用NIO/AIO把代码复杂度拉高。我用Executors.newFixedThreadPool(50)连接数超过50时多余的客户端会在Accept队列里排队日志里能看到拒绝策略触发至少能提前知道服务端的瓶颈在哪。很多入门者在这里会犯第一个错每accept一个连接就直接new Thread去跑线程数没有上限。单个连接看不出问题一旦客户端反复断开重连JVM里会堆出大量僵尸线程和TIME_WAIT连接服务端莫名其妙变慢重启也没用。线程池加有界队列是更稳的组合开发期可以把线程数设小一点比如10方便用日志观察每个连接的建立和释放。服务端的启动流程很固定创建ServerSocket、绑定端口、循环accept每拿到一个Socket就封装成任务丢进线程池。端口选择上开发期用8888这类好记的端口部署到服务器时换到1024以上的其他端口避免和系统服务冲突。2.2 消息协议用JSON统一格式type字段决定路由消息协议是聊天室的骨架也是最多人偷懒的地方。直接拿“昵称:内容”这种字符串拼消息群聊还能凑合私聊一加就露馅——你得在内容里区分昵称、目标和正文还得约定分隔符万一用户输的内容里恰好包含分隔符整条消息解析就崩了。我一般直接用JSON解析虽然比手工切字符串慢一点但字段清晰、扩展方便。后面加心跳、加离线消息、加消息ID都只需要在JSON里加字段不用改传输逻辑。把消息统一成四个核心字段。type表示消息类型服务端按它分发from是发送者昵称to是私聊目标昵称群聊时留空content是正文。另外加一个time字段用于界面展示。下面这张表列出常用的消息类型type方向作用login客户端到服务端登录携带昵称logout客户端到服务端主动下线group客户端到服务端服务端广播群聊消息private客户端到服务端服务端转发私聊消息user_list服务端到客户端同步在线用户列表system服务端到客户端系统通知如用户上下线、目标不在线下面是一条登录消息、一条私聊消息和一条群聊消息的示例字段顺序无所谓但键名必须全局统一{type:login,from:A同学,time:2025-01-01 12:00:00} {type:private,from:A同学,to:B同学,content:在吗,time:2025-01-01 12:01:00} {type:group,from:A同学,content:大家好,time:2025-01-01 12:02:00}为什么不直接用Java对象序列化两个原因一是聊天室客户端未必只有Java一种实现JSON跨语言、可读性强服务端打印日志排查问题时一行JSON能直接看出是哪条消息出了问题序列化对象则是一堆不可读的字节二是流式传输上JSON字符串天然按行分隔配合BufferedWriter写一行、BufferedReader读一行应用层协议就是“一行一条消息”粘包问题基本不会出现。这里有个细节值得强调用readLine接收消息意味着消息内容里不能出现换行。聊天正文里如果允许用户输入换行发送前要替换成转义字符或统一去掉私聊窗口的多行输入框同理。这个问题不处理用户粘贴一段带换行的文字服务端会一次读到两行第一行解析失败第二行甚至会被当成伪消息处理属于典型的界面完整度杀手。2.3 用户列表同步全量拉取加增量广播用户列表是界面里最容易做烂的模块。它有两种同步方式全量和增量实际项目要把两者配合使用而不是只选一种。全量拉取的场景是登录。新客户端连上服务端后服务端要把当前所有在线用户一次性发给它否则新用户打开界面就只能看到自己其他人的状态全靠后续消息去猜。增量广播的场景是上下线。任何一个用户登录或离线服务端都要向所有在线用户广播一条user_list消息界面收到后对列表做一次全量刷新。这里用全量刷新实现是因为在线人数少时重绘一次列表的开销远小于维护增删状态的复杂度。很多半成品聊天室只做了群聊和私聊用户列表要么写死要么登录时拉一次就再也不更新。后果是有人下线了他还在列表里双击名字打开私聊窗口发出去的消息石沉大海。这类问题不影响编译和运行但演示时被问一句“这个人已经下线了为什么还显示”基本就露馅了。第4章会给客户端刷新用户列表的具体代码这里先把协议层的设计对齐登录时先全量后增量上下线时广播增量客户端无脑全量刷新。3. 服务端落地在线用户表、线程池与消息分发3.1 服务端骨架ServerSocket 线程池 在线用户表服务端核心是一张“在线用户表”。我用ConcurrentHashMapString, PrintWriterkey是昵称value是发送消息用的PrintWriter。选ConcurrentHashMap而不是HashMap是因为多线程同时登录、离线时普通HashMap在并发扩容场景下会出并发问题轻则丢数据重则导致CPU飙升属于那种不压测发现不了、压测才发现的黑匣子。这个类的读写非常频繁几乎每条消息都要查一遍所以还要避免在遍历时做耗时操作比如把广播逻辑放在锁外处理。服务端主框架代码public class ChatServer { // 在线用户表昵称 - 发送消息的出口 private static final ConcurrentHashMapString, PrintWriter onlineUsers new ConcurrentHashMap(); private static final ExecutorService pool Executors.newFixedThreadPool(50); public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(8888); System.out.println(聊天室服务端已启动端口 8888); while (true) { Socket socket serverSocket.accept(); pool.execute(new ClientHandler(socket)); } } }逻辑说明accept阻塞等待新连接每来一个客户端就创建一个ClientHandler任务提交到线程池每个任务对应一个Socket连接的生命周期。onlineUsers保存昵称到PrintWriter的映射PrintWriter是服务端向这个客户端发送消息的唯一出口后面群聊广播和私聊转发都靠它。参数说明端口8888是本地开发常用值部署到服务器时要换端口并注意防火墙线程池固定50超过上限的新连接会停留在Accept队列排队极端情况下客户端会感觉“连上了但没人理”这个行为要靠日志观察不能靠猜。ClientHandler内部的关键是初始化流程。把socket包装成BufferedReader和PrintWriterPrintWriter开启autoFlush然后进入读消息循环。这里把读循环和消息分发分开读循环只负责取出一行JSON分发方法负责解析并处理public class ClientHandler implements Runnable { private Socket socket; private PrintWriter out; private BufferedReader in; private String nickname; public ClientHandler(Socket socket) { this.socket socket; } public void run() { try { in new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF-8)); out new PrintWriter(new OutputStreamWriter(socket.getOutputStream(), UTF-8), true); String line; while ((line in.readLine()) ! null) { handleMessage(line); } } catch (IOException e) { e.printStackTrace(); } finally { // 离线清理 if (nickname ! null) { onlineUsers.remove(nickname); broadcastUserList(); } closeQuietly(socket); } } }逻辑说明run的finally块是保证用户列表不残留脏数据的关键。无论正常下线还是连接异常断开finally都会把昵称从在线用户表移除并向所有在线用户广播一次用户列表刷新。nickname是在登录成功后才赋值的用来判断这个连接是否已经完成登录。这里有个小陷阱如果客户端连上后不发login就断开nickname为nullremove就不会执行避免把别人同名用户的记录误删。3.2 登录处理先全量同步再增量广播当收到type为login的消息时服务端要做三件事把昵称和out写入onlineUsers给这个新用户单独发送一份全量在线列表向所有在线用户广播一份新的在线列表。注意顺序前两步有先后关系必须先put再给新用户发全量列表否则新用户收到的列表里不包含自己。登录处理代码private void handleLogin(String json) { nickname parseNickname(json); // 重名检查 if (onlineUsers.containsKey(nickname)) { out.println(buildSystemMsg(昵称已被占用)); return; } onlineUsers.put(nickname, out); sendFullUserList(nickname); // 只发给新用户 broadcastUserList(); // 广播给所有人 }逻辑说明重名检查放在put之前通过out直接回一条system消息客户端收到后提示“昵称已被占用”。这个检查和第5章会提到的重名坑相互呼应。sendFullUserList和broadcastUserList内部都会构建一条user_list消息消息体是当前在线昵称的集合两者的区别只是发送目标不同一个是单发一个是群发。user_list消息的内容就是在线用户表的所有key。这里要注意序列化顺序ConcurrentHashMap的遍历不保证顺序一致如果客户端每次刷新列表都乱序体验会很差。我一般会在发user_list前把昵称收集到一个ArrayList里做一次排序再放进JSON。排序字段用昵称的字符串自然序就行主要目的是让列表在多次刷新之间保持稳定。3.3 群聊广播与私聊路由一对多与一对一的两种分发群聊和私聊的处理都在消息分发方法里。分发方法先解析type字段再按类型走到不同分支。群聊是遍历onlineUsers把消息转发给所有人但通常不转发给发送者本人——客户端的聊天区已经在本地把自己发送的内容显示出来了再收一遍会重复显示。私聊是根据to字段去onlineUsers里找目标昵称找到就只发给目标。群聊与私聊的分发代码private void handleMessage(String json) { String type parseType(json); switch (type) { case login: handleLogin(json); break; case group: broadcastGroupMessage(json); break; case private: handlePrivateMessage(json); break; case logout: // 触发 finally 清理即可 break; default: System.out.println(未知消息类型: json); } } private void broadcastGroupMessage(String json) { String from parseNickname(json); for (Map.EntryString, PrintWriter entry : onlineUsers.entrySet()) { if (!entry.getKey().equals(from)) { entry.getValue().println(json); } } } private void handlePrivateMessage(String json) { String from parseNickname(json); String to parseTarget(json); PrintWriter target onlineUsers.get(to); if (target ! null) { target.println(json); // 回显给发送者自己私聊窗口才能看到 onlineUsers.get(from).println(json); } else { onlineUsers.get(from).println(buildSystemMsg(用户 to 不在线)); } }逻辑说明群聊广播过滤掉发送者是因为客户端已经自己显示了发出的群聊消息私聊转发给目标后还要把这条消息也发给发送者一份这样发送者的私聊窗口才能看到完整的会话记录。很多人漏掉这一步表现为“私聊发出去了目标收到了自己窗口没反应”。私聊目标不在线时回一条system消息而不是静默丢弃用户体验上是“有反馈”和“进黑洞”的区别。参数说明parseType、parseNickname、parseTarget这几个解析方法基于同一个JSON解析工具。有两点要注意一是解析失败的兜底JSON格式不对时不要抛异常中断连接而是打印日志并忽略这条消息因为一条坏消息不该把整个连接搞崩二是聊天正文里出现JSON特殊字符的问题发送端要把双引号和反斜杠做转义否则解析出的字段会错位这个问题和第5章的乱码一样属于高频坑。3.4 离线清理与用户列表广播放在finally更稳离线清理的逻辑放在ClientHandler的finally块里而不是放在logout消息的处理分支里。原因是客户端正常退出时会发logout但强制关窗口、断网、进程被杀这些情况服务端可能根本收不到logout只会发现readLine返回null或抛IOException。如果清理逻辑只在logout分支里做异常退出的用户就会永远留在在线用户表里直到服务端重启。所以我在run方法里把清理统一放在finally从onlineUsers移除当前昵称广播用户列表最后关闭socket。这也是第5.3节“用户下线后列表不更新”的根治方案。logout消息仍然保留它存在的意义是让客户端主动告知“我要下线了”服务端可以提前做一些资源清理但不依赖它来维持用户列表的正确性。4. 客户端界面落地主窗口、私聊窗口与用户列表刷新4.1 主窗口布局左侧用户列表右侧聊天区界面完整度首先看布局。主窗口我的做法是BorderLayout左侧放一个JScrollPane包裹的JList宽度150负责在线用户展示右侧用垂直分割上面是聊天区JTextPane下面是输入区输入区由JTextField和JButton组成。聊天区用JTextPane而不是JTextArea是因为私聊、群聊、系统消息可以用不同颜色展示这对区分信息来源很有帮助。初始化代码JFrame frame new JFrame(Java聊天室); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(600, 450); frame.setLayout(new BorderLayout()); JListString userList new JList(); DefaultListModelString userModel new DefaultListModel(); userList.setModel(userModel); userList.setPreferredSize(new Dimension(150, 400)); JTextPane chatPane new JTextPane(); chatPane.setEditable(false); JScrollPane chatScroll new JScrollPane(chatPane); JTextField inputField new JTextField(); JButton sendButton new JButton(发送); JPanel inputPanel new JPanel(new BorderLayout()); inputPanel.add(inputField, BorderLayout.CENTER); inputPanel.add(sendButton, BorderLayout.EAST); frame.add(new JScrollPane(userList), BorderLayout.WEST); frame.add(chatScroll, BorderLayout.CENTER); frame.add(inputPanel, BorderLayout.SOUTH);逻辑说明userModel是JList的数据源后面收到的user_list消息直接操作userModelclear后重新addElementJList会自动重绘。JTextPane设置为不可编辑聊天内容统一通过appendMessage方法追加JTextField监听回车键和点击“发送”按钮走同一个发送方法这是桌面端聊天工具的标准习惯。参数说明窗口尺寸600x450在开发期够用私聊窗口可以设小一点比如480x360。窗口关闭行为要注意frame的EXIT_ON_CLOSE会直接结束JVM进程但客户端在退出前应该向服务端发一条logout消息。做法是重写windowClosing事件先发送logout再退出而不是依赖服务端读流时发现异常。正常流程和异常流程都覆盖到服务端的finally清理才有意义。4.2 连接服务端与登录登录对话框先行客户端启动后先弹登录对话框收集昵称、服务器地址和端口然后建立连接、发送login消息最后启动读消息线程。读消息线程必须放在后台子线程里不能放到Swing事件线程否则读不到消息时界面会一直无响应所有UI更新再从子线程里通过invokeLater切回EDT详见第5.1节。连接与登录代码socket new Socket(serverAddress, 8888); out new PrintWriter(new OutputStreamWriter(socket.getOutputStream(), UTF-8), true); in new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF-8)); sendMessage(login, nickname, , ); new Thread(this::readLoop).start();逻辑说明PrintWriter第二个参数true是autoFlush每次println后立即发送不用手动flushInputStreamReader和OutputStreamWriter都显式指定UTF-8与服务端保持一致中文才不乱码。readLoop是一个while循环readLine读到一行就调用dispatchMessage交给消息分发方法返回null表示连接已断开循环退出界面提示“连接已断开”。登录这一步还有一个细节连接成功和登录成功是两回事。先建立socket再发login服务端在login分支里会校验重名。收到system类型的“昵称已被占用”时客户端要提示用户换昵称并关闭socket不能继续进入主界面。这个顺序处理不对就会出现“连接成功但没登录成功依然打开了主窗口”的尴尬状态。4.3 群聊消息发送、接收与本地回显群聊发送就是把输入框内容包装成JSON通过out发送同时本地追加一条自己的消息。接收群聊消息时根据type判断来源不同消息用不同颜色展示群聊默认黑色私聊用蓝色系统消息用灰色。这里用一个appendMessage方法统一处理核心是操作JTextPane的StyledDocument而不是用setText覆盖。群聊发送与消息展示代码private void sendGroupMessage() { String text inputField.getText().trim(); if (text.isEmpty()) { return; } String json buildJson(group, nickname, , text); out.println(json); appendMessage(我, text, Color.BLACK); inputField.setText(); } private void appendMessage(String sender, String content, Color color) { SwingUtilities.invokeLater(() - { try { StyledDocument doc chatPane.getStyledDocument(); doc.insertString(doc.getLength(), String.format(%s: %s%n, sender, content), createStyle(color)); chatPane.setCaretPosition(doc.getLength()); } catch (BadLocationException e) { e.printStackTrace(); } }); }逻辑说明sendGroupMessage在发送群聊消息后本地把自己这条消息追加到聊天区这是必要的——服务端广播群聊时会过滤掉发送者不本地回显的话发送者看不到自己的发言。appendMessage里用StyledDocument.insertString而不是setText是为了保留历史消息同时更新滚动条位置让最新消息始终可见。参数说明createStyle根据颜色参数生成一个新的Style私聊和群聊的颜色区分就在这个方法的调用处决定insertString的位置参数用doc.getLength()表示追加到末尾。接收消息的分发逻辑里要严格区分群聊和私聊群聊消息直接走appendMessage显示在公共聊天区私聊消息则要看目标是不是当前登录用户是的话除了显示在主聊天区还要转给对应的私聊窗口。这部分在4.4里一起说清楚。4.4 私聊窗口双击用户列表打开、独立会话展示私聊窗口是一个独立的JFrame包含自己的一块消息区和一个输入框。双击左侧用户列表的某项时打开或激活对应目标用户的私聊窗口窗口标题用“与XX私聊”窗口内部保存对方昵称。我一般用一个HashMapString, PrivateWindow维护已打开的私聊窗口避免重复创建。双击打开私聊窗口userList.addMouseListener(new MouseAdapter() { Override public void mouseClicked(MouseEvent e) { if (e.getClickCount() 2) { String target userList.getSelectedValue(); if (target null || target.equals(nickname)) { return; } openPrivateWindow(target); } } }); private void openPrivateWindow(String target) { PrivateWindow window privateWindows.get(target); if (window null) { window new PrivateWindow(target); privateWindows.put(target, window); } window.toFront(); }逻辑说明双击判定是getClickCount()2target为空说明点到了空白处target等于自己昵称时不允许和自己私聊。privateWindows缓存已打开的窗口已存在就直接置前不存在才新建避免同一个对象打开十几个窗口。私聊窗口的发送逻辑和主窗口类似只是buildJson时会填上to字段目标昵称接收到服务端转发回来的私聊消息也要追加显示到当前窗口。客户端收到私聊消息时要根据from判断来源如果from不是自己说明是别人发来的私聊找到对应私聊窗口并追加显示如果from是自己说明是服务端回显的私聊消息也要追加到对应窗口。这个对称逻辑很多人会漏导致私聊会话里看不到自己发过的内容体验上像“我只说了一句话对方回了一串中间缺了上下文”。4.5 用户列表刷新收到user_list后重绘JList用户列表的刷新逻辑比较直接收到type为user_list的JSON后解析出在线昵称数组通过invokeLater更新userModel。具体做法是clear后重新addElement这样JList的选中状态和滚动条会由Swing自行处理比直接setListData更稳定。刷新代码private void refreshUserList(ListString users) { SwingUtilities.invokeLater(() - { userModel.clear(); for (String name : users) { userModel.addElement(name); } }); }逻辑说明clear和addElement都在invokeLater里执行保证不跨线程操作Swing组件。收到的user_list消息可能是登录时的全量列表也可能是上下线时的增量广播结果。客户端不区分这两种情况统一全量刷新因为在几十人规模下重绘一次JList的开销可以忽略而代码逻辑因此简单很多。这是典型的“以空间换时间”思路也是界面完整项目里值得坚持的取舍。5. 踩坑记录聊天室最常见的5个翻车现场聊天室的坑不像算法题那样抽象它们都在运行时才会暴露而且经常是组合出现。下面这几条是我自己调试中踩过的按从“必现”到“偶发”的顺序排每一条都是现象、原因、解决三段。5.1 界面卡死在子线程里直接更新Swing组件现象运行后聊天窗口无响应标题栏出现“Not Responding”点击任何按钮都没反应几分钟后系统提示强制关闭。原因读消息的后台线程收到消息后直接调用了chatPane.insertString或者userModel.addElement。Swing组件不是线程安全的所有UI更新必须在事件分发线程中执行在子线程直接操作组件轻则显示异常重则整个EDT被阻塞界面假死。排查时在堆栈里能看到类似“Thread-x”持有组件锁、“AWT-EventQueue”一直等待的迹象。解决所有跨线程更新UI的地方统一用SwingUtilities.invokeLater包一层例如前面appendMessage和refreshUserList的实现。invokeLater不会立即执行它把任务排到EDT队列后面同一条消息连续多次调用也没问题Swing会按顺序执行。要记住的边界是只有UI更新需要切线程网络IO、JSON解析这些重活放在后台线程里做反而更合理。5.2 用户重名后登录的顶掉先登录的现象两个客户端用同一个昵称登录后登录的用户一进来先登录用户的所有群聊消息和私聊消息都收不到了在线用户列表里只剩下一个人。原因ConcurrentHashMap的key直接用昵称put操作会把同key的旧值覆盖。我的第一版连重名判断都没有后登录者覆盖先登录者先登录者虽然socket还活着但已经不在在线用户表里了自然收不到任何转发消息。解决在handleLogin里先做containsKey检查存在就拒绝登录并回一条system消息客户端收到后提示“昵称已被占用”并关闭连接。更严谨的方案是给每个用户分配唯一ID内部用ID做key界面上显示昵称但课程设计阶段做重名拒绝就够了唯一ID方案可以放进第6章的进阶方向里。注意拒绝时要先把消息发出去再关闭socket顺序反了客户端会收到一个空的连接关闭。5.3 用户下线后列表不更新清理逻辑放错了位置现象一个客户端直接关掉窗口其他所有客户端的用户列表里他还在双击他发私聊消息石沉大海也没有“不在线”提示。原因客户端退出时没有发送logout消息服务端的消息分发里也就没有执行移除操作。真正的关键问题是清理逻辑只存在于logout分支而异常断网、强制关窗口、进程被杀这些情况下服务端根本收不到logoutreadLine只会返回null或者抛异常。如果清理只靠logout这些非正常退出的用户就会一直留在在线用户表里。解决把离线清理统一放在ClientHandler的finally块中无论正常退出还是异常断开都执行onlineUsers.remove和broadcastUserList。logout消息仍然可以保留但只做提前告知不承担维护用户列表正确性的责任。广播要在remove之后执行否则广播出来的列表里还包含刚离线的用户。5.4 中文乱码两端编码各说各话现象A同学发“你好”B同学看到“浣犲ソ”有时同一台机器上跑两端没问题换一台机器就乱码。原因Socket流默认使用JVM的平台编码Windows中文系统是GBKLinux通常是UTF-8。服务端和客户端只要有一边没显式指定编码就可能乱码而且这种乱码不总是出现取决于双方JVM的默认编码排查起来非常“玄学”。另一个隐蔽来源是String.getBytes()不带Charset参数直接用了平台默认编码。解决在服务端和客户端的Socket流初始化处统一指定UTF-8InputStreamReader和OutputStreamWriter的构造参数都写死“UTF-8”。同时约定buildJson里对特殊字符做转义双引号、反斜杠、换行都要处理尤其是换行readLine协议下消息正文里不能包含换行符否则一条消息会被拆成两行第二行解析直接失败。5.5 端口占用服务端重启报BindException现象改完代码重启服务端控制台报Address already in use但上一个进程明明已经关掉了。原因Java进程虽然退出但操作系统可能还有TIME_WAIT状态的socket占用端口或者上一个服务端进程没有真正结束。这是我开发时遇到频率最高的启动期问题浪费的时间比业务bug还多。解决ServerSocket创建后调用setReuseAddress(true)允许端口重用重启前确认旧进程已被杀掉Windows下用netstat -ano查端口对应的PID再按PID结束进程如果没开setReuseAddress即使进程退出了TIME_WAIT状态也可能让端口短时间无法绑定。这一条是开发期的经验总结不属于业务逻辑但能省下不少磕绊时间。6. 进阶心跳检测、离线消息与消息样式基础功能跑通后想让这个项目再上一个台阶我建议优先做三件事心跳检测、离线消息和消息样式。它们分别对应系统稳定性、消息可靠性和界面可用性刚好把聊天室从“能跑”推向“能演示”。第一是心跳检测。目前的实现里客户端正常退出能清理但断网、休眠、强杀进程这些情况服务端的清理依赖finally而finally依赖readLine返回null或抛异常——网络异常时这个触发往往有延迟。可以约定客户端每30秒发一条ping消息服务端记录每个用户最后一次心跳时间再开一个定时任务把超过90秒没有心跳的用户踢下线并广播用户列表刷新。这样用户列表的准确性不再依赖连接状态而是依赖活跃状态。private void checkHeartbeat() { long now System.currentTimeMillis(); for (String name : onlineUsers.keySet()) { Long last lastHeartbeat.get(name); if (last ! null now - last 90000) { kickUser(name); } } }逻辑说明lastHeartbeat是另一个ConcurrentHashMap记录昵称到最后心跳时间的映射。客户端发ping时更新它定时任务周期性地扫描并踢掉超时用户。注意踢人不能只移除map还要关闭对应socket并广播用户列表否则对方的连接还挂在服务端。心跳间隔和超时阈值根据场景调聊天室可以宽松到30秒/90秒局域网即时演示可以更短比如10秒/30秒体验上更敏捷。第二是离线消息。私聊目标不在线时当前处理是回一句“用户不在线”消息本身被丢弃。如果想让消息不丢就给每个用户维护一个离线队列用ConcurrentHashMapString, ListString保存登录时把队列里的消息逐条补发再清空队列。队列要限制上限比如100条防止长期离线的用户积压大量消息。群聊离线消息一般不做因为群聊强调实时性补发历史反而造成刷屏私聊才有补发的价值。第三是消息样式。现在聊天区已经用颜色区分群聊、私聊和系统消息还可以继续加时间戳显示在消息前、系统提示居中、自己的消息靠右、别人的消息靠左。这些用JTextPane的ParagraphAttributes都能实现改动集中在appendMessage一个方法里每加一种样式都只是往styled document里塞一段带样式的文本。界面的“完整感”往往就是这些细节堆出来的。我自己的习惯是每次跑通一个新功能先不急着加下一个而是把正常流程和异常流程各跑一遍重点看服务端日志和客户端界面的表现是否一致。聊天室这种项目正常链路大家都能写出来拉开差距的永远是断线、重连、重名、消息丢失这些边界情况。希望这篇能帮你在这些坑上少花点时间。本文还有配套的精品资源点击获取
