java聊天室程序的核心是“不崩”，关键在于线程协作与资源释放对齐：每个客户端对应独立thread以暴露底层问题；需正确处理socket生命周期、及时flush和checkerror、安全遍历并移除失效printwriter。
Java 聊天室模拟程序的核心不是“做出来”，而是“不崩”——多数初学者写的版本在多客户端并发发消息时会丢消息、卡死，或 Socket 报 java.net.SocketException: Connection reset。问题不在逻辑，而在线程协作与资源释放没对齐。
为什么用 Thread 而不用 ExecutorService 会更直观？
这是教学场景下的合理选择：每个客户端连接对应一个独立 Thread 实例，能清晰暴露线程生命周期、共享资源竞争、阻塞点等底层问题。用 ExecutorService 容易掩盖 InputStream.read() 阻塞、PrintWriter 缓冲未刷新、ConcurrentHashMap 误用等真实坑。
- 新手常把
BufferedReader.readLine()放在while (true)外，导致只读一次就退出 - 忘记对
PrintWriter调用flush()，客户端收不到消息（尤其用new PrintWriter(outputStream, false)时） - 多个线程同时写同一个
System.out或共享List，输出错乱或抛ConcurrentModificationException
ServerSocket.accept() 必须在循环里，且不能共用 Socket 引用
每个客户端连接都会触发一次 accept() 返回新 Socket，若把它赋给同一个变量再启动线程，后一个连接会覆盖前一个，导致前一个线程操作已关闭的 socket。
while (!isShutdown) {
Socket client = serverSocket.accept(); // 每次都 new 出来
new Thread(new ClientHandler(client)).start();
}
- 不要写成
Socket client = null; while(...) { client = serverSocket.accept(); ... } -
ClientHandler构造器必须保存该Socket的副本，而不是引用外部变量 - 客户端断开时，
client.getInputStream().read()会返回-1，应主动break循环并close()
广播消息时，ConcurrentHashMap 不等于线程安全的“发送”
存客户端 PrintWriter 到 ConcurrentHashMap<string printwriter></string> 是常见做法，但遍历时仍可能遇到 NullPointerException 或 IOException——因为某个客户端已断开，但 writer 还没被移除。
立即学习“Java免费学习笔记（深入）”；
- 每次广播前，用
entry.getValue().checkError()判断是否还可用（比!= null更可靠） - 捕获
IOException后，必须从 map 中remove(key)，否则下次广播又失败 - 不要在遍历 map 时直接
remove()，改用Iterator或先收集失效 key 再批量删
Iterator<Map.Entry<String, PrintWriter>> iter = clients.entrySet().iterator();
while (iter.hasNext()) {
Map.Entry<String, PrintWriter> entry = iter.next();
PrintWriter pw = entry.getValue();
if (pw.checkError()) {
iter.remove(); // 安全删除
continue;
}
pw.println("[BROADCAST] " + msg);
pw.flush();
}
真正难的不是启动十个线程，而是让它们在消息边界、连接状态、IO 缓冲、异常路径上全部对齐。少一个 flush()，少一次 checkError()，少一步 remove()，程序就能跑十分钟然后静默失联。这些细节不写进日志，也不报错，只悄悄漏掉消息。
