Java-readLine()阻塞问题及解决过程

socket编程中readLine()阻塞问题

在Ja va Socket编程中，readLine()方法是个让人又爱又恨的角色。它用起来方便，但稍不留神，程序就会莫名其妙地“卡住”，尤其是在构建双向通信或聊天室这类应用时。很多开发者初次遇到这个问题，都会花上不少时间排查，最后才发现症结就出在这个看似简单的读取方法上。今天，我们就来彻底拆解一下readLine()的阻塞问题及其解决方案。

readLine()的API说明

先看看官方文档是怎么定义它的行为的，理解规则是解决问题的第一步。

• public String readLine() throws IOException

中文核心释义：

• 读取一行文本。一行的终止被定义为：换行符（‘\n’）、回车符（‘\r’），或者回车符后紧跟换行符中的任何一种。
• 返回值：包含该行内容的字符串，不包含任何行终止符；如果已到达流的末尾，则返回null。

英文原版对照：

• Reads a line of text. A line is considered to be terminated by any one of a line feed (‘\n’), a carriage return (‘\r’), or a carriage return followed immediately by a linefeed.
• Returns: A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached.

问题现场还原：

• 很多人在编写双向通信的服务端时，会发现程序总是接收不到客户端发来的消息。和标准代码反复比对后，才发现问题出在readLine()的等待机制上。
• 此外，客户端和服务端的初始状态设定（比如谁先发送、谁先接收）如果不匹配，也会加剧这个问题的复杂性。

第一种情况：基础通信中的“无限等待”

这是最常见的一种场景：一个客户端连接一个服务端。当服务端使用readLine()来读取客户端消息时，它会一直等待，直到从输入流中识别到一个“行终止符”（即‘\n’或‘\r’）。如果客户端发送的消息末尾没有带上这个终止符，那么readLine()就会一直阻塞，主线程也就卡在那里，程序仿佛停止了响应。

解决方法很直接：在客户端发送消息时，主动在消息字符串的末尾追加一个换行符。

//用户发送消息的线程
class SentMessage extends Thread{
    private Socket socket;
    private BufferedWriter bw;
    private BufferedReader mysc;
    SentMessage(Socket socket){
        this.socket = socket;
        try {
            bw = new BufferedWriter(new OutputStreamWriter(client.getOutputStream()));
            mysc = new BufferedReader(new InputStreamReader(System.in));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    @Override
    public void run(){
        try{
            while (true){
                String mymessage = mysc.readLine(); // 从控制台读取，本身是带换行符的
                bw.write(mymessage+"\n"); // 关键在这里：写入网络流时，必须显式加上“\n”
                bw.flush();
                if("bye".equals(mymessage)){
                    break;
                }
            }
        }catch (IOException e){
            e.printStackTrace();
        }finally {
            try{
                if(mysc!=null){
                    mysc.close();
                }
                if(bw!=null){
                    bw.close();
                }
            }catch (IOException e){
                e.printStackTrace();
            }
        }
    }
}

注意看代码中的注释，从控制台读取的mysc.readLine()虽然会去掉换行符，但我们需要在向网络流bw写入时，重新手动加上“\n”，这样才能告诉服务端的readLine()：“这一行已经结束了，你可以返回了。”

第二种情况：聊天室广播中的线程阻塞

在构建多客户端聊天室时，问题会变得更隐蔽。假设你设计了一个“转发消息”的方法，它负责读取一个客户端的消息然后广播给所有人。如果这个方法直接在主线程或某个共享线程中调用readLine()，会发生什么？

思考一下：当客户端A在等待输入，没有发送带换行符的消息时，负责读取A消息的那个readLine()就会阻塞。如果所有客户端都共用这一个“转发通道”，那么整个广播功能就会被A“卡住”，其他客户端即使发了消息也无法被及时转发。

核心解决方案就是“专线专用”：为每一个连接的客户端创建一个独立的线程，专门负责读取该客户端的消息并进行广播。这样，每个客户端的readLine()阻塞只会影响它自己的读取线程，而不会干扰到其他客户端的消息收发。

//内置线程类用于接收消息，并广播
class AcceptMessage extends Thread{
    private Socket clientsocket;
    private BufferedReader br;
    AcceptMessage(Socket clientsocket){
        this.clientsocket = clientsocket;
    }
    /**
     * 服务器将所有接收的消息广播（显示在每一个客户的聊天窗口中）
     * 注意：如果这里不用线程，会出现问题，思考---其实就是readLine()阻塞的问题
     */
    private void tellEveryone(Socket socket){
        try{
            //先从发送消息的客户读内容
            br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            String message = br.readLine(); // 每个线程独立等待自己的输入流
            chatArea.append("用户"+socket.getPort()+": "+message+"\n");
            //然后将内容广播到每一个客户接口
            Iterator it = list.iterator();
            while (it.hasNext()){
                Socket socket2 = it.next();
                //对自己就不要广播了
                if(socket!=socket2){
                    bw = new BufferedWriter(new OutputStreamWriter(socket2.getOutputStream()));
                    bw.write(socket2.getInetAddress().getHostAddress()+": "+message+"\n");
                    bw.flush();
                }
            }
        }catch (IOException e){
            e.printStackTrace();
        }
    }
    @Override
    public void run(){
        while (true){
            //每个客户端连接在此独立运行，接收并广播
            tellEveryone(clientsocket);
        }
    }
}

这段代码的关键在于，每个AcceptMessage线程对象只服务于一个特定的clientsocket。这样，即使客户端B暂时没有输入，线程B的readLine()在等待，也完全不会影响客户端C的线程C去读取和转发消息。这就是用线程隔离来解决阻塞问题的典型思路。

总结

说到底，readLine()的阻塞特性本身不是Bug，而是一种设计。问题往往出在我们对它的行为预期与实际情况不符。记住两个要点：第一，发送方必须发送行终止符；第二，在需要同时处理多个可能阻塞的输入源时，用独立的线程进行隔离是避免相互影响的有效策略。把握住这两点，就能让readLine()在Socket编程中既听话又好用。