C++实现多线程TCP服务器方法

std::thread 直接裸跑 accept 会崩，因多线程竞争监听 socket 导致 EAGAIN/EMFILE、惊群及连接丢失；应单线程 accept + 队列分发或 epoll 线程池，并严控 socket 生命周期。

为什么 std::thread 直接裸跑 accept 会崩

因为 accept() 返回的 socket fd 是非阻塞或未设复用时，多个线程同时 accept() 同一个监听 socket，会触发 EAGAIN 或 EMFILE，更常见的是惊群（Linux 5.12+ 已缓解但未根除），导致部分连接被丢弃、日志里反复出现 Invalid argument 或直接 crash。

实操建议：

• 监听 socket 必须设为 SOL_SOCKET, SO_REUSEADDR，否则重启服务常报 Address already in use
• 不要让多个线程同时调用 accept()；改用单线程 accept() + 队列分发，或用 epoll + 线程池
• 每个工作线程处理的 client socket，必须在 recv() 前设 SO_RCVTIMEO，否则卡死线程不响应中断

用 std::thread + std::queue 分发连接的安全写法

核心是避免数据竞争：std::queue 本身不线程安全，不能裸用；且 socket fd 跨线程传递时，需确保原线程不再 close 它。

实操建议：

• 用 std::mutex + std::condition_variable 包裹队列 push/pop，唤醒用 notify_one() 而非 notify_all()
• client socket fd 传入线程前，用 std::move 语义转移所有权，避免复制 fd 导致双 close
• 线程函数签名推荐：void handle_client(int client_fd)，不要传 sockaddr_in* 指针——地址结构体在 accept() 后就可析构

示例关键片段：

std::queue conn_queue;
std::mutex queue_mtx;
std::condition_variable queue_cv;

// accept 线程
int client_fd = accept(listen_fd, nullptr, nullptr);
{
    std::lock_guard lk(queue_mtx);
    conn_queue.push(client_fd);
}
queue_cv.notify_one();

epoll + 线程池比纯 std::thread 更稳的三个原因

不是“更高级”，而是更贴合 Linux TCP 栈行为：内核已把就绪事件批量通知到用户态，你再分发，比每个线程自己轮询 accept() 或 recv() 少了大量系统调用和锁争用。

实操建议：

• 创建 epoll 实例后，监听 socket 必须用 EPOLLIN | EPOLLET（边缘触发），否则漏事件
• 每个工作线程持有一个独立 epoll_wait() 循环，但只监听 client socket，不监听 listen fd——那个留给主线程
• client socket 加入 epoll 前，务必设为非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)），否则 read() 可能阻塞整个线程

忘记 shutdown() 和 close() 的顺序会怎样

直接 close() client fd，TCP 层可能仍有未发送完的 FIN/ACK 未发出，对方收不到优雅断连信号；若先 shutdown(SHUT_WR) 再等对方 close 后才 close()，能保证全双工关闭，但必须配合 recv() 返回 0 才执行最后的 close()。

实操建议：

• 写完数据后调 shutdown(client_fd, SHUT_WR)，告诉对方“我不再发了”
• 继续 recv() 直到返回 0（对端已关写），此时再 close(client_fd)
• 绝不在线程退出时无条件 close() 所有 fd——可能正处在半关闭状态，强行 close 会发 RST，破坏连接状态机

真正麻烦的从来不是怎么启动多线程，而是每个 socket 生命周期的边界是否清晰。fd 多线程间传递、超时设置、关闭时机，这三处一错，问题就藏得深、复现难。