本文详解 java.net.SocketException: Socket is closed 的根本原因，重点剖析因过早关闭 IO 流导致套接字意外终止的问题，并提供 WHOIS 等典型协议下安全复用 Socket 的实践策略。
本文详解 `java.net.socketexception: socket is closed` 的根本原因，重点剖析因过早关闭 io 流导致套接字意外终止的问题，并提供 whois 等典型协议下安全复用 socket 的实践策略。
在 Java 网络编程中，java.net.SocketException: Socket is closed 是一个高频但极易被误解的异常。它并非表示网络中断或远程断连，而是明确指出：当前 Socket 实例已被本地主动关闭，却仍被尝试用于 I/O 操作。正如你在 WHOIS 示例中所见——首次请求成功后，第二次调用 socket.getOutputStream() 却抛出该异常，其根源不在网络层，而在代码逻辑本身。
? 根本原因：IO 流关闭即 Socket 关闭
Java 的 Socket 设计遵循严格资源耦合原则：
✅ socket.getInputStream() 和 socket.getOutputStream() 返回的流与 Socket 实例强绑定；
❌ 一旦任一方向的流被显式关闭（如 out.close() 或 input.close()），底层 Socket 会立即被关闭——这是 JDK 的强制语义（参见 [JavaDoc](https://www.php.cn/link/83d165df8a35a163dea7821654e0efcf())）。
观察你的 sendRequest 方法：
private void sendRequest(Socket socket, String domain) throws IOException {
OutputStream out = socket.getOutputStream();
out.write((domain + "\r\n").getBytes());
try (BufferedReader input = new BufferedReader(new InputStreamReader(socket.getInputStream()))) {
// ... 读取逻辑
} // ← 此处 try-with-resources 自动调用 input.close()
out.flush();
out.close(); // ← 此处显式关闭输出流 → Socket 被彻底关闭！
}两次调用 sendRequest 后，第一次执行完 out.close() 时，socket 已失效。第二次再调用 socket.getOutputStream() 必然触发 Socket is closed。
✅ 正确复用 Socket 的前提：协议兼容性
能否复用 Socket，首要取决于通信协议是否支持长连接（Keep-Alive）：
立即学习“Java免费学习笔记（深入）”；
- WHOIS 协议（RFC 3912）是典型的“请求-响应-关闭”模式：服务端在返回完整响应后主动 FIN 关闭连接；客户端亦应单次请求后关闭 Socket。强行复用不仅无效，还会因服务端已关闭连接而收到 Connection reset by peer。
- HTTP/1.1、Redis、MySQL 等协议明确支持连接复用：需配合 Connection: keep-alive、管道化请求或连接池实现。
⚠️ 验证方式：使用 netstat -an | grep :43 或 Wireshark 抓包，可清晰看到 WHOIS 会话在响应结束即断开 TCP 连接。
? 安全复用实践方案（以支持长连接的协议为例）
若目标协议允许复用（如自建 TCP 服务），请严格遵循以下原则：
1. 绝不提前关闭任何 Socket 流
// ✅ 正确：流对象复用，仅在 Socket 生命周期结束时统一关闭 Socket socket = new Socket(host, port); socket.setSoTimeout(5000); OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream(); // 多次请求共用同一 out/in sendRequest(out, in, "req1"); sendRequest(out, in, "req2"); // 所有操作完成后，仅关闭 Socket socket.close(); // 自动关闭关联的 in/out
2. 使用 try-with-resources 时需谨慎
避免对 socket.getInputStream() / socket.getOutputStream() 使用 try (Resource r = ...)，因其会触发流关闭 → Socket 关闭。如需自动管理，应封装为 SocketWrapper 类，在 close() 中仅关闭 Socket。
3. 生产环境强烈推荐连接池
对于高并发场景，手动管理 Socket 易出错。使用成熟连接池（如 Apache Commons Pool + 自定义 SocketFactory）：
// 伪代码：连接池管理 Socket 复用 PooledObjectFactory<Socket> factory = new SocketFactory(host, port); GenericObjectPool<Socket> pool = new GenericObjectPool<>(factory); Socket socket = pool.borrowObject(); // 获取可用连接 // ... 使用 pool.returnObject(socket); // 归还，非关闭
? 总结：关键检查清单
| 检查项 | 正确做法 | 错误示例 |
|---|---|---|
| 流关闭时机 | 所有读写操作完成后，仅调用 socket.close() | 在每次请求后调用 out.close() 或 in.close() |
| 协议适配性 | WHOIS、SMTP（部分模式）等不支持复用 → 每次新建 Socket | 强行复用 WHOIS Socket 导致 Socket is closed 或 Connection reset |
| 异常处理 | 捕获 SocketException 并检查 socket.isClosed()，及时重建连接 | 忽略异常或仅打印堆栈，导致后续操作持续失败 |
| 资源泄漏防护 | 使用 finally 块或 try-with-resources 包裹 Socket 本身（JDK 19+ 支持 AutoCloseable） | 无关闭逻辑，耗尽系统文件描述符 |
? 终极建议：对 WHOIS 场景，请放弃复用幻想，改为每次请求创建新 Socket —— 这不仅是规范要求，更是性能与稳定性的最优解。真正的复用价值，体现在 HTTP 客户端（如 OkHttp 连接池）、数据库连接池等经过充分验证的基础设施中。
