Java TCP聊天室需为每个客户端创建独立线程处理通信，服务端用ServerSocket.accept()接收连接后启动新线程，维护独立BufferedReader/PrintWriter，广播消息时遍历clients列表并flush；客户端异常断开需捕获IOException并清理资源。
Java中用ServerSocket和Socket实现基础TCP聊天室
单线程的ServerSocket只能处理一个客户端，实际聊天室必须支持并发。核心是为每个连接启动独立线程，用Socket收发文本消息。注意：Java 8+ 可用ExecutorService替代裸线程，但初学者先理解线程模型更稳妥。
常见错误现象：IOException: Connection reset by peer——客户端异常关闭（比如直接关窗口）而服务端还在读，没做try-catch；或客户端写完没调flush()，服务端readLine()一直阻塞。
- 服务端监听固定端口（如
8080），accept()后立即交给新线程处理 - 每个客户端线程维护自己的
BufferedReader和PrintWriter，别共用 - 消息广播时，遍历所有存活的
PrintWriter逐个println()并flush() - 客户端断开需在
catch中清理对应输出流，并从全局列表移除
public class ChatServer {
private static final List clients = new ArrayList<>();
public static void main(String[] args) throws IOException {
ServerSocket server = new ServerSocket(8080);
System.out.println("Chat server started on port 8080");
while (true) {
Socket client = server.accept();
new Thread(() -> handleClient(client)).start();
}
}
private static void handleClient(Socket socket) {
try (BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
PrintWriter out = new PrintWriter(socket.getOutputStream(), true)) {
synchronized (clients) {
clients.add(out);
}
String msg;
while ((msg = in.readLine()) != null) {
System.out.println("Received: " + msg);
// 广播给其他所有人
synchronized (clients) {
for (PrintWriter writer : clients) {
if (writer != out) { // 不回显给自己
writer.println(msg);
writer.flush();
}
}
}
}
} catch (IOException e) {
System.out.println("Client disconnected: " + e.getMessage());
} finally {
synchronized (clients) {
clients.removeIf(writer -> writer.checkError());
}
}
}
}
客户端用Swing写界面时避免Swing线程安全问题
Swing组件不是线程安全的，所有UI更新（如JTextArea.append()）必须在事件调度线程（EDT）中执行。如果在Socket读取线程里直接调textArea.append()，可能卡死或抛IllegalStateException。
使用场景：用户输入框（JTextField）回车发送、接收消息实时显示、连接状态提示。
立即学习“Java免费学习笔记（深入）”；
- 发送消息走
ActionListener，天然在EDT中，可直接操作Socket输出流 - 接收消息必须用
SwingUtilities.invokeLater()包装UI更新逻辑 - 连接失败或断开要弹出
JOptionPane，也必须在EDT中调用 - 不要在EDT中做
socket.getInputStream().readLine()这种阻塞操作，会冻结整个界面
为什么不用UDP而坚持用TCP实现聊天室
初学者容易被“UDP更快”误导，但聊天室要求消息不丢、不错序、不重复。DatagramSocket发包无确认、无重传、无顺序保证，一次send()可能根本没到对方，或乱序到达，或重复送达——这会导致“消息消失”“别人说话顺序错乱”“同一句话刷屏两次”等不可接受的问题。
性能影响：TCP三次握手建立连接稍慢，但聊天室是长连接，只在登录时发生一次；后续消息吞吐量对局域网或普通宽带完全够用。真正瓶颈在广播逻辑和IO阻塞，不在协议本身。
- 用TCP能直接依赖操作系统内核保证可靠交付，代码逻辑干净
- 若强行用UDP，得自己实现序列号、ACK、重传、去重——这已超出初学者项目范围
- Wireshark抓包验证：TCP会自动分段/重组，应用层看到的仍是完整行；UDP包超过MTU会被IP层分片，丢一片整条消息就废
调试时常见的连接拒绝与超时错误
Connection refused基本等于服务端根本没运行，或端口不对；Connection timed out通常是防火墙拦截、服务端绑定localhost导致外部连不上，或客户端填了错误IP。
关键检查点：
- 服务端
new ServerSocket(8080)是否成功？加System.out.println("Server bound")确认 - 客户端连接地址是否写成
"127.0.0.1"（本机）或真实局域网IP（跨设备测试）？别用"localhost"——某些系统解析异常 - Windows/macOS防火墙是否放行
java进程的入站连接？临时关闭防火墙测试 - IDE运行服务端后，终端再起一个
telnet 127.0.0.1 8080，能连上说明服务端OK，问题在客户端代码
多客户端测试时，别用同一个端口起多个服务端实例——BindException会明确告诉你端口已被占用。
