最近在整理C后端面试的知识点发现“socket多进程并发”属于那种看着简单、往深处一问就露怯的题。很多人能背出“socket - bind - listen - accept - fork”这条流水线但你再追问一句“accept之前fork还是之后fork”“父进程要不要close掉连接fd”“并发十几个子进程同时退出会不会出事”大部分人就卡住了。所以我把这块内容重新过了一遍边验证边整理成一篇完整的笔记既是给自己查漏补缺也给准备面试或者正在写TCP服务端的朋友一个参考。先说清楚这篇文章覆盖什么多进程并发模型能解决什么问题、两种fork时机各自的原理、文件描述符引用计数、僵尸进程回收、accept惊群、端口复用和TIME_WAIT最后是压测对比和选型建议。如果你已经能熟练写出一个单线程echo server这篇可以直接帮你往并发方向跨一步如果你在准备面试后面几节的“追问点”可以当模拟题用。1. 多进程并发要解决的本质问题让服务端“同时”接客1.1 单线程服务端的瓶颈在哪里一个最基础的TCP服务端代码往往长这样int listen_fd socket(AF_INET, SOCK_STREAM, 0); bind(listen_fd, ...); listen(listen_fd, SOMAXCONN); for (;;) { int conn_fd accept(listen_fd, ...); handle_request(conn_fd); // 同步处理直到这个连接结束 close(conn_fd); }这段代码的问题一眼就能看出来handle_request是同步的一个连接不处理完后面的连接只能排队哪怕客户端只是发一个“hello”然后等着服务端也无法再调用accept。如果每个连接处理时间很短比如几十毫秒内的一个查询或写入单线程勉强能撑一旦出现某个连接长时间不发送数据、或者业务处理需要1秒以上整个服务端的吞吐量就会被一个慢连接拖死。这个问题在面试里有固定的问法“一个单线程socket服务器为什么扛不住长连接”原因就是accept和handle_request都在一个循环里程序的控制流只有一条连接之间没有并发。1.2 从单线程到多进程的演进逻辑解决并发只有两条路让CPU在一个进程内快速切换执行流多线程、协程、事件驱动或者一次性创建多个独立的执行体让内核去调度多进程。多进程是其中最简单、最符合直觉的一种每次来到一个连接就fork()出一个子进程由子进程去处理业务父进程立刻回到accept继续等下一个连接。因为每个连接都有一份独立的进程上下文谁慢谁快互不干扰。换句话说单线程是“一个人排着队处理所有客户”多进程是“每来一个客户就派一个专人去接待前台继续叫号”。这里要补充一个理解误区很多人以为fork()之后父子进程各自复制了一份内存所以在“双核跑”其实刚fork出来的子进程和父进程共享物理内存页面只有双方开始写入不同的数据时内核才做写时复制。所以短时间内的多次fork()并没有大多数人想象中那么昂贵代价主要体现在进程表项、文件描述符表和内核栈的创建上。1.3 简单模型先跑通每次accept之后fork为了直观感受并发效果可以先写一个最朴素的版本父进程accept到一个新连接后立刻fork()子进程负责读取数据、回写响应并关闭连接父进程关闭这个连接在自己手里的副本后继续accept。#include sys/types.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #include unistd.h #include cstring #include cstdio #include cerrno int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd 0) { perror(socket); return 1; } int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); sockaddr_in addr{}; addr.sin_family AF_INET; addr.sin_port htons(9876); addr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(listen_fd, (sockaddr*)addr, sizeof(addr)) 0) { perror(bind); return 1; } if (listen(listen_fd, 128) 0) { perror(listen); return 1; } printf(server listen on 9876, pid%d\n, getpid()); for (;;) { sockaddr_in client{}; socklen_t len sizeof(client); int conn_fd accept(listen_fd, (sockaddr*)client, len); if (conn_fd 0) { if (errno EINTR) continue; perror(accept); continue; } pid_t pid fork(); if (pid 0) { perror(fork); close(conn_fd); continue; } if (pid 0) { // 子进程处理这个连接 close(listen_fd); char buf[1024]; ssize_t n read(conn_fd, buf, sizeof(buf) - 1); if (n 0) { buf[n] \0; printf([child %d] recv: %s\n, getpid(), buf); const char* resp HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\nok; write(conn_fd, resp, strlen(resp)); } close(conn_fd); _exit(0); } // 父进程这个连接交给子进程了自己手里的描述符要关掉 close(conn_fd); } }这段代码已经能跑通多进程并发了。注意两个细节第一子进程处理完之后用的是_exit(0)而不是exit(0)因为exit()会刷掉标准C库的缓冲区而子进程是fork出来的缓冲区里可能残留着父进程的数据一旦子进程刷新缓冲区就把父进程没写完的数据给出卖了这在网络服务里是一个隐形的数据错乱来源第二父进程在fork之后立刻关闭conn_fd下一节详细讲为什么必须这么做。2. fork的位置和fd引用计数父子进程各自的“账本”必须算清楚2.1 先fork再acceptprefork模型的思路第一种经典的多进程并发形态是“一个listen fd多个进程同时accept”。服务启动后先把listen_fd创建好然后一次性fork()出N个子进程每个子进程自己进入accept循环。谁抢到连接谁来处理。const int WORKERS 4; int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); // bind/listen 同上 ... listen(listen_fd, 1024); for (int i 0; i WORKERS; i) { pid_t pid fork(); if (pid 0) { // 子进程 for (;;) { sockaddr_in client{}; socklen_t len sizeof(client); int conn_fd accept(listen_fd, (sockaddr*)client, len); if (conn_fd 0) { if (errno EINTR) continue; perror(accept); continue; } handle_request(conn_fd); close(conn_fd); } } } // 父进程在这里只需要wait for (;;) pause(); }这种模式也叫prefork优点是子进程在启动阶段一次性创建好连接到达时不需要临时fork()进程创建开销被摊平了适合短连接高频请求的场景。缺点就是多个子进程同时阻塞在同一个accept上会出现惊群问题第4节细讲。2.2 文件描述符的引用计数为什么父子进程都要closefork()之后子进程会复制父进程的全部文件描述符表但底层打开文件对象是共享的。也就是说同一个conn_fd同时被父进程和子进程引用内核里这个socket的引用计数变成2。现在看第一次accept之后fork的版本父进程手里有listen_fd和conn_fd子进程复制了这两个fd也持有listen_fd和conn_fd的副本问题是如果父进程不关掉conn_fd即使子进程处理完毕后把conn_fd关掉了内核里的socket引用计数仍然是1父进程还握着这个连接永远不会真正断开。反过来如果子进程不关掉listen_fd父进程那边即使想close(listen_fd)只要子进程还开着监听socket就不会真正关闭端口就一直被占用。所以规范做法是父子进程各自关掉自己不需要的fd让每个socket的引用计数最终归到唯一的持有者身上。用一个生活类比同样一份文件你和同事手里各自有一把钥匙你们共用一个柜子你离职时只交了你那把钥匙没用必须把两把钥匙都收回来柜子才真正闲置。fd到底是什么时候关闭的问题面试里能问到“如果父进程不close(conn_fd)会怎样”熟悉引用计数之后答案就很清楚。2.3 fork的时机选择直接决定处理复杂度对比一下两种fork时机对比项先accept再fork先fork再acceptprefork进程创建频率每个连接fork一次开销大启动时一次性fork运行期无fork开销谁负责accept父进程统一accept再分发给子进程每个子进程自己acceptfd关闭要求子进程关listen_fd父进程关conn_fd子进程只需要管自己的listen_fd副本适合场景连接数少、处理时间长短连接、并发量高、进程可预先规划主要问题高频短连接下fork开销吃掉吞吐accept惊群、子进程数量固定不够灵活如果面试官问“多进程模型有哪些写法”别只说一种。你先说“连接来到后fork”再说“批量prefork各自accept”把两种形态的取舍讲清楚这题基本就稳了一半。2.4 一个容易被忽略的边界fork失败时的处理fork()不是一定成功的。进程数达到系统上限、内存不足都可能导致fork失败返回-1。如果父进程刚刚accept到一个连接此时fork出错你必须在父进程里决定这个连接怎么处理。最稳妥的做法是父进程自己接手处理或直接关闭同时记录错误日志而不是假装什么都没发生继续循环。如果你直接不处理这个conn_fd它就一直敞着连接既不关闭也没人处理客户端那边会一直等响应直到超时。在实际压测中出现过这种情况大量短连接打过来子进程还没退出多少新请求又持续进来系统进程数逼近上限后面fork全失败服务端表现为大量连接“建立成功但没人理”。排查时加了一句static int child_count 0; if (pid 0) { // fork失败当前进程至少要把这个连接处理掉或关掉 close(conn_fd); continue; }这一步在教科书里往往不写但线上它是保命的一环。3. 子进程的生死账单僵尸进程、SIGCHLD信号与回收时机3.1 僵尸进程是怎么出现的子进程结束之后它的内核栈、数据段、代码段会被释放但进程表项中仍然保留着PID、退出状态、CPU占用这些信息直到父进程调用wait()或waitpid()取走退出状态。如果父进程一直不取这个子进程就变成僵尸进程永久占着一个PID。僵尸进程本身不消耗CPU和内存但PID是有限资源进程数一多系统就无法创建新进程fork()直接返回失败。你写了一个accept之后fork的服务端如果不在父进程里做任何回收压测几百个短连接之后你去看“ps -ef | grep defunct”能攒出一大排僵尸。3.2 写一个安全的SIGCHLD信号处理函数子进程退出时内核会向父进程发送SIGCHLD信号。标准做法是在父进程里拦截这个信号在信号处理函数中调用waitpid()回收子进程。void handle_sigchld(int) { pid_t pid; int status; while ((pid waitpid(-1, status, WNOHANG)) 0) { // 回收一个子进程WNOHANG保证这里不阻塞 } } int main() { signal(SIGCHLD, handle_sigchld); // ... }这里有两个必须写对的细节。第一waitpid(-1, ..., WNOHANG)中的-1表示等待任意一个子进程WNOHANG表示如果当前没有已退出的子进程则立即返回0而不是阻塞。之所以在函数里用while循环是因为多个子进程可能在同一个信号到达之前同时退出——信号会被内核合并成一次。如果你只用一次waitpid回收一个进程其他几个子进程就全变成僵尸了下次是否还有SIGCHLD完全不确定这就是经典的“信号合并丢失”问题。第二accept在信号处理返回后可能被中断返回EINTR错误。前两节代码里已经写了if (errno EINTR) continue;很多新手会漏掉这行导致服务端莫名停止accept其实是被信号打断了。这是Linux下写系统调用最常见的坑之一。3.3 子进程里的_exit与父进程的wait顺序回到那个accept后fork的模型有一个问题子进程处理完连接后调用_exit(0)退出但它还没有机会把自己清理干净它的父进程如何知道回收答案就是父进程预先注册的SIGCHLD处理函数。子进程一退出父进程收到信号waitpid把子进程的退出状态取走僵尸进程也就被清掉了。如果你不在父进程里回收也可以让孤儿进程被一号进程收养后再回收父进程先死子进程就会被托付给init进程。但这属于“父进程自己先挂了”的极端场景不应该作为正常设计依赖。正常服务里父进程的生命周期一般比子进程长所以父进程必须承担回收义务。3.4 多进程并发的另外一个信号坑SIGPIPE服务端程序还有一个常见信号问题向一个已经关闭的连接写入数据时操作系统会发送SIGPIPE默认行为是直接终止进程。多进程模型下一个子进程因为客户端断开而写入失败如果被SIGPIPE干掉这个子进程就白白牺牲了。解决办法是在程序启动时忽略这个信号signal(SIGPIPE, SIG_IGN);这也是服务端程序里几乎必备的一行。写的时候不留心压测中大量并发断开时服务端进程会莫名消失看日志也没有任何崩溃信息排查到最后大多是这一个信号在搞鬼。3.5 压测时如何确认回收机制生效我通常会在压测前后对比一下系统里的进程总数和僵尸进程数确认回收逻辑没有漏。简单跑一条命令watch -n 0.5 ps -eo stat,pid,ppid,comm | grep server如果看到STAT列出现一堆Z说明回收没生效优先检查信号处理和waitpid循环。如果在pid列看到大量数字一直在涨不回落到基线说明一次回收数量不足或者回收窗口短于产生速度这时候把while循环改成直到返回-1更保险。4. 高频追问一网打尽惊群、SO_REUSEPORT、TIME_WAIT和端口复用4.1 accept惊群多个进程同时醒来只有一个能接到连接在prefork模型里多个子进程同时阻塞在同一个listen_fd的accept调用上。当一个连接到达接收队列时内核会唤醒所有等待在这个队列上的进程但最终只有一个进程能成功accept其余进程发现队列已经被抢走只能再次睡眠。这个现象就是惊群thundering herd。它的代价是每次有连接到来多个进程被无谓唤醒白白进行几次上下文切换高并发下这会吃掉不少CPU。早期Linux内核的accept确实是这样后来内核做了互斥唤醒优化当多个进程同时阻塞在同一个accept队列时新连接到达只会唤醒其中一个进程。所以现代Linux上普通prefork accept的惊群问题已经没有早年那么严重。但如果你把多个进程共享同一个epoll fd监听同一个socket在引入EPOLLEXCLUSIVE之前惊群问题依然存在。好消息是Linux 4.5之后提供了EPOLLEXCLUSIVE在epoll层面上也只唤醒一个进程。面试中遇到惊群要说清楚两层一是传统accept模型内核怎么处理二是epoll模型里的处理方案千万别混为一谈。4.2 完全绕开惊群SO_REUSEPORT让每个进程绑定自己的listen fd如果想彻底绕开惊群Linux 3.9开始提供SO_REUSEPORT选项。它允许多个进程各自创建独立的socket绑定完全相同的IP和端口由内核在接收数据包时做负载均衡分发。每个进程有自己的accept队列不共享同一个listen fd自然就没有惊群问题。int reuseport 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEPORT, reuseport, sizeof(reuseport));注意SO_REUSEPORT和SO_REUSEADDR是两个完全不同的选项不要混用。网上很多文章把两者放在一起说但它们的用途差异很大。选项解决的问题适用场景SO_REUSEADDR允许在TIME_WAIT状态下重新绑定同一地址也允许绑定处于TIME_WAIT状态的连接占用的本地端口服务端重启后立刻绑定原端口默认必备SO_REUSEPORT允许多个不同进程绑定同一IP端口内核负责负载均衡分配连接多进程/多实例横向扩展、拆分发实际工程里这两个经常同时设置但原理上彼此独立。如果你面试时能把两者分开讲清楚并且说出SO_REUSEPORT的分发机制是内核哈希而不是严格的轮询会非常加分。4.3 谁是主动方谁进入TIME_WAITTCP四次挥手结束后主动关闭连接的一方会进入TIME_WAIT状态默认等待2MSL一般是1到4分钟Linux上是60秒左右。这期间端口不能被重新使用。很多人知道TIME_WAIT这个概念但没好好想它为什么存在。第一个原因最后一次ACK如果被网络丢了被动关闭方会重发FIN主动方必须在TIME_WAIT状态下重发ACK否则被动方永远等不到关闭确认。第二个原因要确保旧连接中已经发出、还在网络中游荡的延迟包不会到达一个四元组相同的新连接造成数据错乱。在多进程socket服务端里TIME_WAIT一般出现在“服务端主动关闭连接”的场景比如超时断开、协议错误处理。如果服务端作为主动方关闭大量短连接你会看到系统里有一堆TIME_WAIT。这时候如果不设置SO_REUSEADDR服务端重启时bind会报“Address already in use”服务就起不来。所以第1、2节代码开头都加了setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt))这是服务端程序的标配。4.4 服务端调优之路连接上限与等待队列除了上面几个socket层面的问题多进程服务端能支撑的并发还受几个系统参数约束ulimit -n每个进程能打开的fd数量上限。如果一个连接占用一个fd进程能支持的并发连接就是fd上限减掉标准输入输出等默认fd。net.core.somaxconnlisten队列的最大长度。listen()里传的backlog参数超过系统上限不会生效实际以上限为准。并发量高而accept速度跟不上时队列满了客户端会收到连接建立失败。net.ipv4.ip_local_port_range客户端发起主动连接时端口范围。注意这是指这台机器自己作为客户端发起连接时能用的端口区间收到这个限制的是“这个服务端同时连接其他服务”的能力不是对外监听的端口数量。大多数情况下一个服务端进程的并发能力瓶颈首先出现在fd上限其次是业务处理速度再往后才是系统网络参数。我见过有人开2万个并发连接改了一堆内核参数结果发现ulimit -n还停在1024连接数到一千就拒绝建立新连接了。排查顺序要按“fd极限 - 业务耗时 - 内核参数”来走。5. 压测结果和选型建议什么场景下多进程该退场5.1 跑一组简单对比实验我在本机用同样的echo逻辑分别写了三个版本单线程阻塞式、accept后fork每次连接fork一个进程、prefork 4个进程。客户端用并发工具一次性压1000个短连接数据包很小不做业务逻辑只看RPS。结果符合模型预期服务端模式短连接场景能力长连接场景体验单线程循环吞吐最高但一个慢连接会阻塞所有后续连接一个连接阻塞全部完蛋accept后fork吞吐最低每个连接都有一次fork开销独立进程互不阻塞能扛慢客户端prefork多进程吞吐居中但比逐连接fork高出不少每个子进程独立accept某个连接慢只拖垮一个worker单线程模型在短连接上吞吐最高是因为没有进程创建和上下文切换开销但它的致命弱点就是长连接场景下的头阻塞。逐连接fork最稳但最贵一旦每秒要处理几千个请求fork成本会直接拖垮吞吐。prefork是在两者之间比较均衡的做法也是很多成熟服务端的选择。5.2 多进程 vs 多线程面试常考的对比矩阵面试里问完socket多进程下一个问题几乎必然是“那多进程和多线程怎么选”。这里需要给出一个清晰的对比框架对比项多进程多线程隔离性一个进程崩溃不影响其他进程一个线程段错误可能拖垮整个进程共享数据需要IPC管道、信号、共享内存、消息队列等成本高天然共享进程内存加锁即可创建和切换开销fork开销高于pthread_create创建线程和上下文切换成本更小调试体验需要跟进程号多进程调试更繁琐多线程调试相对集中竞态条件进程间数据不共享几乎没有数据竞争锁没上好各种并发bug稳定性适合作为核心服务能容忍单个子进程死掉业务代码质量要求高一个野指针可能全挂如果你的服务是无状态的、每个连接的数据基本独立多进程最省心写起来几乎不需要加锁如果需要在多个连接之间共享大缓存、做全局计数器、维护会话热数据多线程或IO多路复用加线程池会更合适。5.3 什么情况下多进程模型确实该退场了多进程模型并不适合所有场景至少有这么几类情况我会明确不选它第一超高并发短连接场景。每秒几万甚至几十万个新建连接每次fork的成本是不可接受的哪怕用prefork也会被进程内同步处理阻塞住这时应该上事件驱动epoll配合非阻塞IO或者epoll 线程池。第二连接数量很大、每个连接有大量空闲时段。比如物联网设备的TCP长连接几十万台设备连着但大多数时候不发数据多进程模型会为每个连接占用一个进程或线程资源浪费严重事件模型才能以极低的内存消耗支撑几十万空闲fd。第三多个连接之间需要频繁交换数据。进程间的数据交换要走IPC开发效率低延迟也比共享内存加锁更高。同一进程内的多线程反而更直接。我自己的习惯判断标准是连接数几百到几千、并发模型想尽量简单、出错时不想让整个服务挂掉优先prefork多进程一旦连接数上万、或者业务上需要大量共享状态转epoll事件驱动。多进程绝不是所有问题的银弹但它确实是把“简单稳定”四个字贯彻得最彻底的方案之一。5.4 面试时怎么把这个话题组织成满分的回答如果你在面试中遇到“C的socket多进程并发”或者“如何设计一个高性能TCP服务端”可以按这个顺序组织答案第一步先说清楚并发模型解决什么问题从单线程阻塞到多进程的演进动机。第二步给出两种fork形态accept后fork和prefork各自的特点。第三步重点讲fd引用计数为什么父子进程都要关闭多余的fd子进程退出如何回收。第四步把惊群、SO_REUSEADDR、SO_REUSEPORT、TIME_WAIT这些深层机制主动抛出来。第五步落到选型什么时候选多进程、什么时候该用epoll/线程池。这套组织方式的优势在于既有代码层面的细节又有系统层面的认知还包含了工程取舍的思考比单纯背概念要立体得多。面试官无论从哪个方向追问你都有话可接。最后再分享一个我实际踩过的教训多进程socket服务的进程数不是越大越好。早期给prefork配了32个进程8核机器上反而出现了明显的性能下滑原因是一堆进程争抢accept队列和CPU时间片锁竞争和上下文切换开销盖过了并行收益。后来按CPU核心数的两倍去配置worker数量再加上SO_REUSEPORT让每个进程有独立的accept队列实测吞吐反而比32进程时还高。这个比例当然不普适但你至少应该记住多进程并发不是“进程数越多越好”它背后有一道由CPU核数、fd上限、业务处理耗时共同决定的算术题。动手写一个最小例子压一压比背什么结论都实在。