socket的recv调用导致CPU占用100%问题排查求助

核心嫌疑：未处理recv返回0的场景 #

你的代码仅处理了recv返回值小于0的错误情况，但完全忽略了返回值为0的场景——这在TCP协议中代表对端已正常关闭连接。当服务器偶发断开连接时，客户端已接收部分数据（0 < offs < len），后续每次调用recv都会立刻返回0，offs不再增长，内层while (offs < len)循环会无限执行，导致单线程CPU占用100%，表现为"卡死"。

从gdb的调用栈和offs的状态来看，完全匹配这个场景：调用栈停在recv是因为循环会高频调用该系统调用，每次返回0后立刻再次发起调用，gdb抓取到的恰好是recv执行中的状态。

验证与修复方案 #

1. 修复核心逻辑：在recv返回后补充对返回值为0的处理：

ssize_t rc = recv(socket, buf + offs, sizeof(buf) - offs, 0);
if (rc < 0) {
    // 根据errno区分处理不同错误（如超时、连接重置等）
    error = 1;
    break;
} else if (rc == 0) {
    // 对端关闭连接，标记错误并退出循环
    error = 1;
    break;
}
offs += rc;

2. 完善错误细节处理：实际代码中需针对recv返回-1时的errno做区分：比如EAGAIN/EWOULDBLOCK是正常超时（符合你设置的4秒超时规则），ECONNRESET是对端重置连接，这些场景都需要触发连接重建逻辑。

其他排查方向（基于musl + ARM64环境） #

• musl libc超时机制验证：虽然概率较低，但可在测试环境模拟服务器断开，确认SO_RCVTIMEO的4秒超时是否正常生效，排除平台特定的实现问题。
• TCP异常场景复现：用工具模拟服务器半关闭、异常断开等场景，复现问题，确认是否确实由未处理rc=0导致死循环。
• 信号干扰排查：单线程程序若收到未处理信号，可能导致recv被中断返回EINTR，但该场景只会触发连接重建，不会导致CPU100%的死循环，可作为次要排查点。

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