Java聊天室核心是用ServerSocket配合多线程实现并发连接：accept()后立即启新线程处理客户端，避免阻塞；广播消息需异步、容错、不阻塞；客户端须分离读写线程；严格按行协议处理TCP粘包。
如何用ServerSocket和多线程处理多个客户端连接
Java聊天室最核心的问题不是“怎么发消息”，而是“怎么同时跟几十个客户端保持通信”。ServerSocket本身是阻塞的，单线程调用accept()只能串行处理连接。必须为每个客户端分配独立线程，否则新用户会卡在等待队列里。
实操建议：
- 每次
accept()返回一个Socket后，立即丢给新线程处理，主线程立刻回到下一轮accept() - 不要在线程里直接操作
System.out或Swing组件——多线程UI更新会崩溃，改用线程安全的集合或回调机制 - 客户端断开时，
readLine()会返回null，这是正常退出信号，不是异常，别误判成IOException - 避免用
while(true)死循环读取而不设超时，客户端网络闪断可能导致线程永久挂起
为什么不能直接共享PrintWriter数组来广播消息
初学者常把所有客户端的PrintWriter存进ArrayList，然后遍历调用write() + flush()。这看似能广播，但实际极易出错：某个客户端网络卡顿，flush()阻塞，整个广播就卡住，后面所有人收不到消息。
更稳妥的做法是：
立即学习“Java免费学习笔记（深入）”；
- 用
CopyOnWriteArrayList替代ArrayList，避免遍历时并发修改异常 - 每个
PrintWriter写操作单独try-catch，失败就从列表中移除该对象（对应客户端已掉线） - 广播逻辑不放在接收线程里，而是投递到一个共享的
ConcurrentLinkedQueue，由专用广播线程异步消费 - 不要在
write()后立刻flush()，可批量缓冲几条再刷，减少系统调用次数
客户端输入阻塞导致无法实时接收服务端消息
典型现象：客户端用Scanner.nextLine()等用户输入，但服务端发来的消息全堆在输入流缓冲区，直到你敲回车才一并吐出来——这不是服务端问题，是客户端I/O模型没分离。
必须拆成两个线程：
- 一个线程专职监听
System.in，读到内容就发给服务端 - 另一个线程专职调用
BufferedReader.readLine()读服务端响应，收到就打印 - 两个线程共用同一个
Socket，但输入输出流互不干扰——Socket.getInputStream()和Socket.getOutputStream()本身就是线程安全的 - 注意
Scanner内部有缓冲，且不支持中断；换成BufferedReader配合System.in更可控
忽略TCP粘包/半包导致消息解析错乱
聊天室里如果用户快速连发“hi”和“how are you”，服务端可能一次读到"hi\nhow are you\n"，也可能只读到"hi\nho"。这不是Bug，是TCP流式传输的天然特性。
简单可靠的解法是强制换行分隔：
- 客户端每次发送都确保以
\n结尾（pw.println("msg")自动加） - 服务端统一用
BufferedReader.readLine()读取，它会等完整一行才返回 - 绝对不要用
InputStream.read(byte[])手动拼包，除非你实现完整的协议解析器 - 如果将来要支持二进制消息（比如图片），就必须自定义协议头，包含长度字段——但基础文本聊天室没必要
真正难的不是写通功能，而是让10个客户端同时上线、发50条消息、随机断网重连后，服务器日志里没有NullPointerException、没有线程泄漏、没有消息丢失。这些细节藏在try-catch-finally块里，不在主流程代码中。
