单Socket处理多消息：Java BufferedReader读取阻塞问题排查

首先咱们先定位问题核心：你用单Socket处理多条消息时，第一条正常但第二条开始阻塞，结合Java 1.4的限制，大概率是发送端未正确刷新输出流或者响应读取逻辑不符合协议要求导致的，下面给你一步步分析解决：

一、先排查发送端的关键问题：确保消息真正发送到服务器 #

很多时候阻塞的根源不是读取，而是消息根本没发出去。Socket的输出流（比如OutputStreamWriter或PrintWriter）默认带缓冲，如果不手动刷新，消息会留在本地缓冲区，服务器收不到请求自然不会返回响应，导致读取端一直等待。

修复方式很简单：每次发送完消息后，必须调用flush()强制输出缓冲区的内容：

// 初始化Socket和输出流（示例）
Socket socket = new Socket("your-server-host", yourPort);
OutputStreamWriter out = new OutputStreamWriter(socket.getOutputStream(), "UTF-8");

// 循环处理每条消息
for (String msg : yourMessageList) {
    // 发送消息
    out.write(msg);
    out.flush(); // 关键！必须手动刷新，确保消息立即发送到服务器
    
    // 读取响应并保存
    String response = decrypt(br);
    saveResponseToDB(response);
}

如果你用的是PrintWriter，注意初始化时如果用了new PrintWriter(out, true)，它只会在调用println()等方法时自动刷新，直接write()的话还是要手动调用flush()。

二、修正响应读取逻辑：不要固定错误的读取长度 #

你的decrypt方法固定读取165个字符，但从你给出的响应示例来看，实际响应长度远超过165。这会导致两个问题：

1. 第一条响应只读取了前165个字符，剩余内容留在BufferedReader的缓冲区里；
2. 处理第二条消息时，你读取的内容会是第一条残留的字符 + 第二条响应的内容，既读错了数据，还可能因为需要凑够165个字符而阻塞。

你需要根据服务器的响应协议来调整读取逻辑：

场景1：响应长度是固定值（服务器约定每条响应长度一致） #

如果服务器明确每条响应是固定长度（比如250个字符），修改decrypt方法读取正确的长度：

public String decrypt(BufferedReader br, int fixedResponseLength) throws IOException {
    StringBuffer sb = new StringBuffer(fixedResponseLength);
    int charsRead = 0;
    while (charsRead < fixedResponseLength) {
        int ch = br.read();
        if (ch == -1) {
            throw new IOException("Truncated response: server closed connection early");
        }
        sb.append((char) ch);
        charsRead++;
    }
    return sb.toString();
}

调用时传入正确的长度，比如decrypt(br, 250)。

场景2：响应带长度前缀（服务器返回的前N位是响应总长度） #

这是更常见的协议设计，比如响应开头用4位十进制数字表示后续内容的长度（比如0250abc...表示后面有250个字符的内容）。这种情况下，先读取长度前缀再读取对应内容：

public String decrypt(BufferedReader br) throws IOException {
    // 先读取4位长度前缀
    char[] lengthPrefix = new char[4];
    int prefixRead = br.read(lengthPrefix);
    if (prefixRead != 4) {
        throw new IOException("Failed to read response length prefix");
    }
    int responseLength = Integer.parseInt(new String(lengthPrefix));
    
    // 读取完整响应内容
    StringBuffer sb = new StringBuffer(responseLength);
    int charsRead = 0;
    while (charsRead < responseLength) {
        int ch = br.read();
        if (ch == -1) {
            throw new IOException("Truncated response: expected " + responseLength + " chars, got " + charsRead);
        }
        sb.append((char) ch);
        charsRead++;
    }
    return sb.toString();
}

可选：直接用InputStream读取（避免BufferedReader缓冲干扰） #

如果担心BufferedReader的缓冲特性导致数据残留，也可以直接操作底层的InputStream（Java 1.4完全支持），这样能更精准控制读取的字节数（注意字符编码匹配）：

public String decrypt(InputStream is, Charset charset) throws IOException {
    // 读取4位长度前缀（字节形式）
    byte[] lengthBytes = new byte[4];
    int prefixRead = is.read(lengthBytes);
    if (prefixRead != 4) {
        throw new IOException("Failed to read response length");
    }
    int responseLength = Integer.parseInt(new String(lengthBytes, charset));
    
    // 读取响应内容字节数组
    byte[] responseBytes = new byte[responseLength];
    int totalRead = 0;
    while (totalRead < responseLength) {
        int bytesRead = is.read(responseBytes, totalRead, responseLength - totalRead);
        if (bytesRead == -1) {
            throw new IOException("Truncated response from server");
        }
        totalRead += bytesRead;
    }
    return new String(responseBytes, charset);
}

三、连接复用的额外注意事项 #

• 确认服务器支持单连接复用：有些服务器会在处理完一条请求后主动关闭Socket，这种情况下你需要捕获连接断开的异常，重新建立连接后继续处理剩余消息；
• 资源清理：所有消息处理完成后，务必依次关闭输入流、输出流和Socket，避免资源泄漏。

总结 #

你遇到的阻塞问题，优先检查发送端的flush()调用，再修正响应读取的长度逻辑，这两个点解决后，单Socket逐条处理消息的逻辑就能正常运行了。

内容的提问来源于stack exchange，提问作者koutheir