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模型没分离。
