接收最后一段数据后直接close() SSL socket是否安全？

这其实是个很典型的Socket通信竞态问题，直接在接收完最后一段数据就调用close()关闭Socket并不安全，尤其是在Java TLS这类有额外状态检查的场景下，很容易触发异常。

咱们先看你提到的Java TLS发送端write方法实现：

/** 
 * Write the data out, NOW. 
 */ 
@Override 
public synchronized void write(byte[] b, int off, int len) throws IOException { 
    if (b == null) { 
        throw new NullPointerException(); 
    } else if (off < 0 || len < 0 || len > b.length - off) { 
        throw new IndexOutOfBoundsException(); 
    } else if (len == 0) { 
        return; 
    } 

    // check if the Socket is invalid (error or closed)
    socket.checkWrite(); 

    // Delegate the writing to the underlying socket.
    try { 
        socket.writeRecord(b, off, len); 
        socket.checkWrite(); 
    } catch (Exception e) { 
        // shutdown and rethrow (wrapped) exception as appropriate
        socket.handleException(e); 
    } 
}

这段代码里有个关键细节：发送完核心数据（socket.writeRecord）之后，会第二次调用socket.checkWrite()，用来确认Socket的可写状态是否正常。

这就埋下了竞态的隐患：当接收端刚收到最后一段数据，立刻调用close()关闭Socket时，发送端可能还没执行完第二次checkWrite()。此时发送端的Socket状态已经被接收端的关闭操作置为cs_SENT_CLOSE = 5，第二次状态检查就会直接触发SocketException——这正好是你遇到的问题场景。

我之前也见过类似的生产问题，比如消息队列客户端在接收完最后一批消息后直接断连，导致服务端的发送线程抛出Socket异常，甚至影响后续的连接处理。

正确的做法应该遵循TCP的优雅关闭流程：

• 接收端在确认收到所有数据后，先调用shutdownInput()，明确通知发送端“我这边不再接收数据了”
• 发送端收到关闭输入的信号后，确认自身所有数据都已发送完毕，再调用shutdownOutput()和close()
• 接收端在收到发送端的关闭输出信号后，再最终调用close()关闭Socket

这样能避免跨端的状态检查竞态，保证双方的Socket状态同步。

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