TCP双进程阻塞send/recv因接收缓冲区满死锁可能性及实现防护问询

先明确场景：两个客户端通过TCP通信，执行逻辑一致，伪代码如下：

recv(...) // 阻塞接收调用
do_work()
send(...) // 阻塞发送给对方客户端

一、TCP协议规范层面是否会出现死锁，有无避免机制？ #

完全可能出现死锁。举个典型场景：
客户端A完成recv和do_work后，调用send向B发消息，但此时B的TCP接收缓冲区已经被填满，B因为卡在自己的send调用上（同样在等待A接收它的消息），根本没机会调用recv来清空缓冲区。此时A的send会因为B的滑动窗口变为0而阻塞；同时B的send也因为A的接收缓冲区已满、窗口为0而阻塞。双方都卡在send调用上，既没法发送自己的消息，也无法执行后续的recv来释放对方的缓冲区，形成死锁。

从TCP协议规范来看，没有专门的机制避免这类死锁。TCP的滑动窗口流量控制只是负责限制发送方的发送速率，当接收方缓冲区满时，会告知发送方停止发送，但它无法感知应用层的执行逻辑，没法区分“正常等待对方接收”和“死锁”的情况，更不会主动干预打破死锁。

二、Linux Socket API等常见实现的防护措施？ #

默认的阻塞Socket调用（recv/send）没有自动防护这类死锁的措施，但可以通过以下手段在应用层规避：

• 设置超时选项：通过setsockopt设置SO_SNDTIMEO（发送超时）和SO_RCVTIMEO（接收超时），当阻塞调用超过指定时间后会返回错误，应用可以根据错误码处理（比如重试、主动断开连接等），避免永久阻塞。
• 改用非阻塞Socket+多路复用：将Socket设置为非阻塞模式，配合select/poll/epoll等多路复用接口，同时监听Socket的读、写事件。这样可以避免卡在单个recv或send调用上，当对方缓冲区可用时再执行发送，有数据可读时再执行接收，从根本上避免这种顺序执行导致的死锁。
• 调整应用层逻辑：比如拆分接收和发送到独立线程，让接收和发送操作并行执行；或者在发送前先尝试处理接收队列中的数据，避免接收缓冲区被填满。

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