基于epoll的P2P客户端死锁风险问题咨询

这个问题可是非阻塞TCP + epoll模式下的经典坑啊——说白了就是双向循环等待的写死锁，核心原因就是双方都因为对方接收窗口满了（自己write返回EAGAIN）就死等可写，却完全忘了去处理自己的读事件，结果对方的窗口永远打不开，就这么僵住了。我在实际项目里踩过这个坑，下面几个方案亲测有效，按优先级给你列出来：

1. 永远别丢了读事件的监听（最核心的解法） #

绝大多数人踩这个坑，都是因为write失败返回EAGAIN后，直接把该FD的epoll事件改成只监听EPOLLOUT，把EPOLLIN给丢了。但你想想：对方为啥让你写不进去？很大概率是你的接收缓冲区里已经堆了一堆对方发的数据，你没去读，导致对方的TCP发送窗口被压到0了。

正确的姿势是：

• 从连接建立开始，每个FD就一直带着EPOLLIN事件，除非连接彻底断开。
• 当write返回EAGAIN时，只需要额外加上EPOLLOUT事件（不是替换掉EPOLLIN），这样epoll会同时告诉你什么时候能读、什么时候能写。
• 只要你及时处理读事件，把自己接收缓冲区的数据读空，对方的TCP发送窗口立刻就会打开，对方就能继续写，它也会去处理自己的读事件，你的发送窗口也跟着打开，死锁自然就解开了。

给你贴个简化的伪代码片段，一看就懂：

// 初始化时注册EPOLLIN（用ET模式更高效）
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &(struct epoll_event){.events = EPOLLIN | EPOLLET, .data.fd = sockfd});

// 处理epoll事件的循环里
if (event->events & EPOLLIN) {
    // 读数据要读到EAGAIN才算完（ET模式要求）
    ssize_t n;
    do {
        n = read(sockfd, buf, sizeof(buf));
        // 处理读到的数据，比如存到业务缓冲区或者直接处理
    } while (n > 0);
    // 如果还有待发送的数据，确保加上EPOLLOUT
    if (has_pending_data(sockfd)) {
        epoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &(struct epoll_event){.events = EPOLLIN | EPOLLOUT | EPOLLET, .data.fd = sockfd});
    }
}
if (event->events & EPOLLOUT) {
    // 写数据也要写到EAGAIN或者写完所有待发数据
    ssize_t n = write(sockfd, pending_buf, pending_len);
    if (n == -1) {
        if (errno != EAGAIN) {
            // 真出问题了，断开连接清理资源
            close(sockfd);
            epoll_ctl(epfd, EPOLL_CTL_DEL, sockfd, NULL);
        }
    } else {
        // 更新待发缓冲区的指针和长度
        pending_buf += n;
        pending_len -= n;
        // 所有数据发完了，就把EPOLLOUT去掉，避免epoll一直触发空转
        if (pending_len == 0) {
            epoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &(struct epoll_event){.events = EPOLLIN | EPOLLET, .data.fd = sockfd});
        }
    }
}

2. 给写等待加个超时兜底 #

就算你一直监听读事件，也可能遇到极端情况——比如对方进程挂了但TCP连接没断，或者网络卡到天荒地老。这时候给每个待发连接加个超时就很有必要：

• 可以用epoll_wait的超时参数（比如每次等1秒），每次超时后扫一遍所有有待发数据的连接，看看谁等的时间太长了。
• 或者用Linux的timerfd，把定时器FD也加到epoll里，每隔一段时间触发一次超时检查。
• 要是某个连接等可写超过了阈值（比如30秒），直接断开连接或者触发重试逻辑，别在一棵树上吊死。

3. 给发送缓冲区设个上限，别让数据堆成山 #

如果你的业务会产生大量待发数据，一定要给每个连接设个最大待发缓冲区大小：

• 当待发数据量超过上限时，就告诉上层业务“暂时发不出去，稍后再试”，别硬塞。
• 这样既能避免程序一直卡在等可写的状态，还能防止内存被待发数据撑爆，一举两得。

4. 用边缘触发（ET）模式优化事件处理 #

虽然水平触发（LT）也能干活，但ET模式能减少很多不必要的事件触发，更高效：

• 用ET模式的话，读的时候一定要读到EAGAIN才算完，写的时候也要写到EAGAIN或者所有数据发完。
• 这样能避免epoll反复触发同一个事件，减少CPU消耗，还能确保你不会漏掉任何该处理的数据。

最后再总结一句：这类死锁的本质就是忽略了读事件的处理，导致TCP窗口打不开的循环依赖，只要你死死守住“永远监听读事件”这条底线，再配合超时和缓冲区限制，绝对能把这个坑填上。

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