网络阻塞卡死本质是单线程在recv/send/connect/accept等系统调用上无限挂起，非死锁；需用gdb或strace定位堆栈顶部的I/O调用，并检查是否配置SO_RCVTIMEO或非阻塞模式。
网络阻塞导致的卡死，和死锁有本质区别：它通常不涉及多个锁的循环等待，而是单一线程在 recv、send、connect 或 accept 等系统调用上无限期挂起。这类问题不会触发 ThreadSanitizer，gdb 里也看不到锁争用堆栈，容易误判为“死锁”而走错排查路径。
看线程是否卡在系统调用而非 mutex 上
用 gdb attach 进去后，先执行 info threads，再对每个线程做 thread apply all bt。重点不是找 std::mutex::lock，而是看堆栈顶部有没有：
-
recv、send、read、write、connect、accept、epoll_wait、poll、select - 或者更底层的
__libc_read、sys_recvfrom、do_syscall_64
如果某线程堆栈停在这些调用上，且没有超时逻辑（比如没用 setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...)），基本可断定是网络 I/O 阻塞所致。注意区分：若堆栈里同时出现 pthread_mutex_lock 和 recv，说明线程可能在加锁后才进 I/O，那锁本身未必是根因，但临界区范围过大可能加剧阻塞影响。
检查 socket 是否设了超时或非阻塞模式
阻塞式 socket 是默认行为，必须显式配置才能避免卡死。常见遗漏点：
立即学习“C++免费学习笔记（深入）”；
- 用
connect()前没设SO_SNDTIMEO，导致连接远程服务失败时等几十秒 - 用
recv()读取响应时，没对 socket 调用setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) - 误以为
epoll就自动非阻塞——其实 socket 本身仍需fcntl(fd, F_SETFL, O_NONBLOCK) - 在
std::thread启动前忘了把 fd 设为非阻塞，尤其在封装类构造函数里漏掉
验证方式：在 gdb 中用 p call getsockopt($fd, SOL_SOCKET, SO_RCVTIMEO, &tv, &len)（需提前定义 struct timeval tv; socklen_t len = sizeof(tv);）；或直接 ls -l /proc/$PID/fd/ | grep $fd 看是否带 socket:[...] 并结合 cat /proc/$PID/status | grep CapEff 辅助判断权限上下文。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
用 strace 快速确认阻塞点
比 gdb 更轻量、更贴近系统层的定位方式：
- 运行
strace -p $PID -e trace=network,io -T 2>&1 | grep -E "(recv|send|connect|accept).*= -1 EAGAIN|0$" - 若看到大量
recv(12, ...卡住不动，或返回-1 EAGAIN但程序没处理，说明是非阻塞 socket 未正确轮询 - 若看到
connect(12, ..., 16) = -1 EINPROGRESS后无后续epoll_wait或select，说明异步连接逻辑断裂
注意：strace 本身有性能开销，线上紧急排查可用，但别长时开启；另外，若程序用了 io_uring，需加 -e trace=io_uring 才能捕获。
为什么 std::this_thread::sleep_for 不等于网络超时
这是最常被混淆的一点：在 socket 操作前后加 sleep_for，完全不能替代 I/O 超时。原因很直接：
-
sleep_for只是让当前线程休眠，不影响 socket 的阻塞属性 - 即使你 sleep 1ms 后再
recv，只要 socket 是阻塞模式，recv仍可能卡住 30 秒 - 反过来，若 socket 已设
SO_RCVTIMEO，recv会在超时后返回-1并置errno = EAGAIN或EWOULDBLOCK，此时你才能做重试或断连
真正有效的超时控制必须落在 I/O 系统调用入口处，而不是靠外围 sleep 模拟。生产环境建议统一用 libuv、boost.asio 或自封装的非阻塞 socket + epoll 循环，避免裸写 recv/send。
网络卡死最麻烦的地方在于：它不报错、不崩溃、不触发 sanitizer，只安静地停在系统调用里。一旦习惯性只查锁堆栈，就会错过真正的阻塞点。盯住 strace 输出和 gdb 堆栈顶部的系统调用名，比猜“是不是又死锁了”高效得多。
