17370845950

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 是常见做法，但遍历时仍可能遇到 NullPointerException 或 IOException——因为某个客户端已断开，但 writer 还没被移除。

• 每次广播前，用 entry.getValue().checkError() 判断是否还可用（比 != null 更可靠）
• 捕获 IOException 后，必须从 map 中 remove(key)，否则下次广播又失败
• 不要在遍历 map 时直接 remove()，改用 Iterator 或先收集失效 key 再批量删

Iterator> iter = clients.entrySet().iterator();
while (iter.hasNext()) {
    Map.Entry entry = iter.next();
    PrintWriter pw = entry.getValue();
    if (pw.checkError()) {
        iter.remove(); // 安全删除
        continue;
    }
    pw.println("[BROADCAST] " + msg);
    pw.flush();
}

真正难的不是启动十个线程，而是让它们在消息边界、连接状态、IO 缓冲、异常路径上全部对齐。少一个 flush()，少一次 checkError()，少一步 remove()，程序就能跑十分钟然后静默失联。这些细节不写进日志，也不报错，只悄悄漏掉消息。