1. 从单进程到并发为什么网络编程绕不开多进程与多线程刚接触Linux网络编程那会儿我写过一个最简单的TCP回声服务器socket()、bind()、listen()、accept()然后在一个while(1)里处理连接。代码不到五十行跑起来也没问题。但当我用两个客户端同时连上去的时候问题立刻暴露了——第二个客户端要等第一个客户端断开之后才能被处理。这就是典型的单进程阻塞式服务器的致命缺陷同一时刻只能服务一个连接。这个问题的根源在于accept()和recv()都是阻塞调用。当服务器阻塞在第一个连接的recv()上时内核的已完成连接队列里即使已经排了新的连接程序也没有机会去accept()它。要解决这个问题核心思路只有一个让服务器具备同时处理多个连接的能力。在Linux环境下实现这种并发能力的主流方案有三类——多进程模型、多线程模型、I/O多路复用模型。这篇博文聚焦前两类也就是标题里的“多进程、多线程”把它们的实现方式、适用场景、踩坑经验一次讲透。你可能会问现在都2025年了epoll和io_uring这么成熟还有必要学多进程多线程吗我的答案是非常有必要。原因很实际——大量存量服务端代码仍然基于这两种模型很多中间件比如某些Web服务器、数据库连接池的底层就是多进程或多线程架构。更重要的是理解多进程和多线程在Linux网络编程中的具体落地方式是理解后续I/O多路复用、协程、事件驱动等更高级模型的基础。跳过这一步直接上epoll你大概率只是抄了个模板遇到问题根本不知道怎么排查。这篇文章适合已经掌握基本socket编程、能写出单进程TCP服务器的读者。如果你还没写过socket()和bind()建议先把基础打牢再来看。全文会从设计思路、核心API、完整代码实现、常见问题排查四个维度展开每个环节都会解释“为什么这么做”而不只是“怎么做”。代码部分我会给出可直接编译运行的完整示例并标注关键参数的计算依据。2. 多进程模型fork出来的并发世界2.1 多进程服务器的核心设计思路多进程模型的基本逻辑非常直观主进程负责accept()新连接一旦拿到一个新的客户端文件描述符就调用fork()创建一个子进程让子进程去处理这个连接的所有读写操作主进程则立刻回到accept()等待下一个连接。这样每个客户端连接都有独立的进程为其服务彼此之间互不干扰。这个模型最大的优势是隔离性强。每个子进程拥有独立的地址空间一个子进程崩溃了不会影响其他子进程也不会影响主进程。这在需要高稳定性的场景下非常有价值。另一个优势是编程简单——你不需要考虑锁、竞态条件、线程安全这些问题因为进程之间天然隔离。但代价也很明显。fork()的开销不容忽视每次创建子进程内核需要复制父进程的页表、文件描述符表等数据结构。虽然Linux采用了写时复制Copy-On-Write技术避免了立即复制整个地址空间但fork()本身的系统调用开销加上进程调度的上下文切换开销在连接数很大时仍然会成为瓶颈。另外每个进程都有独立的内存空间内存占用会随着并发连接数线性增长。注意多进程模型适合并发量中等几百到几千、连接生命周期较长的场景。如果你的服务器需要同时处理上万个短连接多进程模型的fork()开销会让你吃不消。2.2 fork()的关键细节与文件描述符处理写多进程服务器时fork()之后文件描述符的处理是最容易出错的地方。先看一段核心代码#include stdio.h #include stdlib.h #include string.h #include unistd.h #include arpa/inet.h #include sys/socket.h #include signal.h #include sys/wait.h #define PORT 8080 #define BUF_SIZE 1024 void handle_client(int client_fd) { char buf[BUF_SIZE]; ssize_t n; while ((n read(client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(client_fd, buf, n); // 回声 } close(client_fd); exit(0); } int main(void) { int listen_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); signal(SIGCHLD, SIG_IGN); // 关键自动回收子进程 while (1) { struct sockaddr_in cli_addr; socklen_t cli_len sizeof(cli_addr); int client_fd accept(listen_fd, (struct sockaddr *)cli_addr, cli_len); if (client_fd 0) continue; pid_t pid fork(); if (pid 0) { // 子进程 close(listen_fd); // 子进程不需要监听套接字 handle_client(client_fd); } else if (pid 0) { // 父进程 close(client_fd); // 父进程不需要客户端套接字 } else { perror(fork); close(client_fd); } } return 0; }这段代码里有几个关键点值得展开说。第一signal(SIGCHLD, SIG_IGN)这行非常重要。子进程退出时内核会向父进程发送SIGCHLD信号。如果父进程不处理这个信号子进程会变成僵尸进程占用内核的进程表项。设置SIG_IGN让内核自动回收子进程资源省去了手动调用waitpid()的麻烦。当然如果你需要知道子进程的退出状态就得自己注册信号处理函数并在里面调用waitpid()。第二父进程和子进程各自关闭不需要的文件描述符。子进程继承了父进程的listen_fd但它不需要监听新连接所以关掉。父进程持有client_fd也没有意义因为连接已经交给子进程处理了父进程不关的话这个文件描述符会一直占用最终耗尽父进程的可用描述符数量。这个细节很多人会忽略但在高并发场景下是致命的。第三listen()的第二个参数我设成了128。这个参数叫backlog表示内核已完成连接队列的最大长度。如果队列满了新的连接请求会被拒绝或忽略取决于内核版本和tcp_abort_on_overflow设置。对于多进程服务器因为accept()的调用频率受限于fork()的速度backlog可以适当设大一些128到1024都是常见值。2.3 多进程模型的性能瓶颈与优化方向多进程模型在并发量上升后瓶颈主要出现在三个地方。fork()的开销。每次fork()大约需要几十到几百微秒取决于进程的地址空间大小。连接数一多CPU大量时间花在创建和销毁进程上真正处理业务逻辑的时间反而被压缩。优化方向是使用进程池——预先fork()一批子进程主进程通过管道或共享内存把新连接的文件描述符传递给空闲子进程。这样避免了频繁fork()但实现复杂度显著上升。上下文切换开销。进程数量超过CPU核心数之后操作系统需要在不同进程之间切换每次切换都要保存和恢复寄存器、刷新TLBTranslation Lookaside Buffer。进程切换比线程切换更重因为涉及地址空间的切换。实测下来当活跃进程数超过CPU核心数的2到3倍时吞吐量增长会明显放缓甚至下降。内存占用。每个进程即使有写时复制仍然需要独立的页表、内核栈等结构。一个空转的子进程大约占用几百KB到1MB的内存。1000个并发连接就是1GB左右的内存开销这在资源受限的环境下是不可接受的。实操心得如果你的服务器并发量在500以下连接持续时间较长比如长连接推送服务多进程模型完全够用而且稳定性最好。超过这个量级就该考虑多线程或I/O多路复用了。3. 多线程模型更轻量的并发选择3.1 多线程服务器的架构设计多线程模型和多进程模型在结构上非常相似区别在于把fork()换成了pthread_create()。主线程负责accept()每来一个连接就创建一个新线程去处理。线程共享进程的地址空间所以不需要像进程那样复制页表创建开销小得多。但共享地址空间也带来了新的问题数据竞争。如果多个线程需要访问同一个全局变量或堆上的数据结构就必须加锁保护。在网络编程中最常见的共享资源是连接列表、统计计数器、配置信息等。设计多线程服务器时一个重要的原则是尽量减少共享状态。每个线程只操作自己的局部变量和传入的文件描述符就能避免大部分锁的问题。先看一个基础的多线程回声服务器实现#include stdio.h #include stdlib.h #include string.h #include unistd.h #include pthread.h #include arpa/inet.h #include sys/socket.h #define PORT 8080 #define BUF_SIZE 1024 void *client_thread(void *arg) { int client_fd *(int *)arg; free(arg); // 释放主线程malloc的内存 char buf[BUF_SIZE]; ssize_t n; while ((n read(client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(client_fd, buf, n); } close(client_fd); return NULL; } int main(void) { int listen_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); while (1) { struct sockaddr_in cli_addr; socklen_t cli_len sizeof(cli_addr); int client_fd accept(listen_fd, (struct sockaddr *)cli_addr, cli_len); if (client_fd 0) continue; int *pfd malloc(sizeof(int)); *pfd client_fd; pthread_t tid; if (pthread_create(tid, NULL, client_thread, pfd) ! 0) { perror(pthread_create); free(pfd); close(client_fd); continue; } pthread_detach(tid); // 关键分离线程自动回收资源 } return 0; }编译时需要链接pthread库gcc -o thread_server thread_server.c -lpthread3.2 线程参数传递与资源回收的坑上面代码里有两个容易踩坑的地方我逐个说。参数传递。pthread_create()的第四个参数是void *类型用来传给线程函数。你不能直接把client_fd的地址传进去因为client_fd是主线程栈上的局部变量下一轮循环就会被覆盖。必须用malloc()在堆上分配一块内存把client_fd的值拷进去然后把堆地址传给线程。线程函数里用完这块内存后要free()掉否则就内存泄漏了。我见过不少初学者在这里翻车——传了栈地址结果多个线程读到同一个文件描述符连接全乱套了。线程回收。pthread_create()创建的线程默认是可连接joinable状态线程退出后需要另一个线程调用pthread_join()来回收资源否则线程的栈和线程描述符不会释放变成类似僵尸进程的存在。但服务器主线程在while(1)里忙得很不可能去join每个线程。解决办法是调用pthread_detach(tid)把线程设为分离状态线程退出时系统自动回收资源。这一步千万别漏。注意pthread_detach()可以在创建后立即调用也可以在线程函数内部调用pthread_detach(pthread_self())。两种方式效果一样选一种就行。3.3 线程池避免频繁创建销毁线程和进程一样频繁创建销毁线程也有开销。虽然线程创建比进程快但在高并发短连接场景下这个开销仍然可观。线程池的思路是预先创建一批线程它们阻塞在一个任务队列上主线程把新连接封装成任务放入队列空闲线程被唤醒后取出任务执行。线程池的核心组件包括任务队列通常用链表或环形缓冲区实现、互斥锁保护队列、条件变量用于唤醒等待的线程。下面是一个简化但可用的线程池实现#include pthread.h #include stdlib.h #include unistd.h #define POOL_SIZE 8 #define QUEUE_MAX 1024 typedef struct { int client_fd; } task_t; typedef struct { task_t tasks[QUEUE_MAX]; int head, tail, count; pthread_mutex_t lock; pthread_cond_t not_empty; pthread_cond_t not_full; } task_queue_t; task_queue_t queue; void queue_init(task_queue_t *q) { q-head q-tail q-count 0; pthread_mutex_init(q-lock, NULL); pthread_cond_init(q-not_empty, NULL); pthread_cond_init(q-not_full, NULL); } void queue_push(task_queue_t *q, task_t t) { pthread_mutex_lock(q-lock); while (q-count QUEUE_MAX) pthread_cond_wait(q-not_full, q-lock); q-tasks[q-tail] t; q-tail (q-tail 1) % QUEUE_MAX; q-count; pthread_cond_signal(q-not_empty); pthread_mutex_unlock(q-lock); } task_t queue_pop(task_queue_t *q) { pthread_mutex_lock(q-lock); while (q-count 0) pthread_cond_wait(q-not_empty, q-lock); task_t t q-tasks[q-head]; q-head (q-head 1) % QUEUE_MAX; q-count--; pthread_cond_signal(q-not_full); pthread_mutex_unlock(q-lock); return t; } void *worker(void *arg) { while (1) { task_t t queue_pop(queue); char buf[1024]; ssize_t n; while ((n read(t.client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(t.client_fd, buf, n); } close(t.client_fd); } return NULL; }主线程只需要调用queue_push()把新连接放入队列工作线程会自动取出处理。线程池的大小需要根据CPU核心数和任务类型来定。对于网络I/O密集型任务线程数可以设为CPU核心数的2到4倍对于计算密集型任务线程数等于CPU核心数比较合适。你可以通过sysconf(_SC_NPROCESSORS_ONLN)获取CPU核心数。4. 多进程与多线程的选型对比与实战建议4.1 两种模型的量化对比选多进程还是多线程不能凭感觉得看具体指标。我整理了一张对比表覆盖了实际选型时最关心的几个维度对比维度多进程模型多线程模型创建开销高fork复制页表低共享地址空间上下文切换开销高需切换地址空间低同一地址空间内存占用高每进程独立空间低共享进程空间隔离性强进程间互不影响弱一个线程崩溃可能拖垮整个进程数据共享困难需IPC容易直接读写全局变量同步复杂度低天然隔离高需锁、条件变量等调试难度较低较高竞态条件难复现适合场景长连接、高稳定性要求短连接、高并发、需共享数据从表里可以看出来两种模型各有取舍。多进程胜在稳定和简单多线程胜在轻量和高效。实际项目中还有一种混合模型主进程fork()出多个子进程每个子进程内部再创建线程池。Nginx就是类似的多进程架构每个worker进程是单线程的事件循环而某些Java应用服务器则采用单进程多线程模型。4.2 信号处理在多进程模型中的特殊考量多进程模型下信号处理有几个容易忽略的细节。除了前面提到的SIGCHLD还有SIGPIPE。当子进程向一个已经关闭的连接写入数据时内核会发送SIGPIPE信号默认行为是终止进程。如果你不希望子进程因为客户端异常断开而挂掉就需要忽略这个信号signal(SIGPIPE, SIG_IGN);或者在write()时使用MSG_NOSIGNAL标志send(client_fd, buf, n, MSG_NOSIGNAL);另一个需要注意的是惊群效应。如果多个子进程同时阻塞在accept()上比如进程池模式当新连接到来时内核会唤醒所有子进程但只有一个能成功accept()其他的白白被唤醒又继续睡眠。这在连接频繁的场景下会造成大量无效的上下文切换。Linux内核从2.6版本开始对accept()的惊群做了优化但并不是所有场景都能完全避免。解决办法是使用文件锁或互斥锁确保同一时刻只有一个子进程在accept()。4.3 线程安全与锁的粒度控制多线程模型下锁的使用是一门艺术。锁的粒度太粗并发性能上不去粒度太细死锁风险增加代码也难以维护。我的经验是遵循几条原则。第一能不用锁就不用锁。每个连接的状态数据放在线程局部变量或连接私有结构体里不跨线程共享。这样大部分操作都是无锁的。第二必须共享的数据用读写锁。比如一个全局的连接计数器读多写少用pthread_rwlock_t比互斥锁更高效。第三锁的持有时间尽可能短。不要在持锁期间做I/O操作或调用可能阻塞的函数。先把数据拷出来释放锁再处理。第四避免嵌套锁。如果确实需要多把锁确保所有线程以相同的顺序获取锁否则很容易死锁。实操心得我调试过多线程服务器的死锁问题最后发现是两把锁的获取顺序不一致导致的。排查这类问题的利器是gdb的thread apply all bt命令能一次性打印所有线程的调用栈快速定位哪两个线程在互相等待。5. 常见问题与排查技巧实录5.1 文件描述符泄漏最隐蔽的杀手文件描述符泄漏是多进程和多线程服务器里最常见的bug之一。症状是服务器运行一段时间后accept()开始返回EMFILE错误新连接无法建立。用lsof -p pid或ls /proc/pid/fd | wc -l可以查看进程当前打开的描述符数量。泄漏的常见原因有几个。一是accept()之后fork()或pthread_create()失败没有关闭client_fd。二是子进程或线程处理完连接后忘记close()。三是父进程忘记关闭client_fd前面代码里强调过。四是dup()或dup2()之后没有关闭原始描述符。排查方法在代码里加日志记录每次accept()返回的client_fd和每次close()的描述符对比一下就能发现哪个没关。更系统的方法是使用valgrind --track-fdsyes运行程序退出时会报告未关闭的描述符。5.2 僵尸进程与孤儿进程的处理僵尸进程前面提过用signal(SIGCHLD, SIG_IGN)或waitpid()解决。孤儿进程则是父进程先于子进程退出子进程被init进程PID 1收养。孤儿进程本身不是问题但如果孤儿进程还在持有监听套接字可能会导致端口无法释放。解决办法是父进程退出时向所有子进程发送终止信号或者让子进程在父进程退出后自行检测并退出。5.3 线程数暴涨与资源耗尽多线程服务器如果每个连接创建一个线程并发量一高线程数会迅速膨胀。Linux默认的线程栈大小是8MB可通过ulimit -s查看1000个线程就是8GB虚拟内存。虽然虚拟内存不等于物理内存但线程调度和上下文切换的开销会急剧增加。解决办法有两个一是使用线程池限制最大线程数二是通过pthread_attr_setstacksize()减小线程栈大小比如设为512KB或1MB对于网络I/O线程来说完全够用。pthread_attr_t attr; pthread_attr_init(attr); pthread_attr_setstacksize(attr, 512 * 1024); // 512KB pthread_create(tid, attr, worker, arg); pthread_attr_destroy(attr);5.4 常见问题速查表问题现象可能原因排查方法解决方案accept返回EMFILE文件描述符泄漏ls /proc/pid/fd | wc -l检查所有close路径出现僵尸进程未处理SIGCHLDps aux | grep defunctsignal(SIGCHLD, SIG_IGN)子进程写数据导致退出收到SIGPIPE查看退出信号忽略SIGPIPE或用MSG_NOSIGNAL线程数持续增长未限制并发或未detachps -eLf | wc -l线程池detach吞吐量上不去锁竞争严重perf top查看锁热点减小锁粒度或无锁化连接被拒绝backlog队列满netstat -s查看溢出统计增大backlog或加快accept5.5 调试工具与手段排查多进程多线程服务器的问题光靠printf是不够的。几个我常用的工具strace -f -p pid可以跟踪所有线程和子进程的系统调用看卡在哪个调用上gdb配合thread apply all bt查看所有线程栈perf top定位CPU热点valgrind --toolhelgrind检测多线程竞态条件。这些工具组合使用大部分问题都能定位到具体代码行。6. 从多进程多线程到更远的路上写到这里多进程和多线程在网络编程中的核心要点基本覆盖了。从单进程阻塞服务器出发多进程模型用隔离性换来了稳定多线程模型用共享内存换来了轻量。两种模型都不是银弹选型时要看并发量、连接时长、稳定性要求和团队熟悉程度。我个人在实际项目中的体会是先用最简单的模型把功能跑通再根据压测结果决定是否优化。很多项目一开始就上复杂的线程池或进程池结果代码复杂度上去了性能瓶颈却根本不在并发模型上而在数据库查询或业务逻辑里。先用多进程或简单的多线程把服务跑起来用ab或wrk压一压看看瓶颈到底在哪再针对性优化这才是务实的做法。另外提一个后续可以深入的方向当并发连接数达到万级以上时多进程和多线程的上下文切换开销都会成为瓶颈这时候就该转向I/O多路复用select/poll/epoll或异步I/O了。但那是另一个话题而且有了多进程多线程的基础理解事件驱动模型会容易得多——本质上都是用某种方式管理多个连接的状态机只是调度机制不同而已。
1. 从单进程到并发为什么网络编程绕不开多进程与多线程刚接触Linux网络编程那会儿我写过一个最简单的TCP回声服务器socket()、bind()、listen()、accept()然后在一个while(1)里处理连接。代码不到五十行跑起来也没问题。但当我用两个客户端同时连上去的时候问题立刻暴露了——第二个客户端要等第一个客户端断开之后才能被处理。这就是典型的单进程阻塞式服务器的致命缺陷同一时刻只能服务一个连接。这个问题的根源在于accept()和recv()都是阻塞调用。当服务器阻塞在第一个连接的recv()上时内核的已完成连接队列里即使已经排了新的连接程序也没有机会去accept()它。要解决这个问题核心思路只有一个让服务器具备同时处理多个连接的能力。在Linux环境下实现这种并发能力的主流方案有三类——多进程模型、多线程模型、I/O多路复用模型。这篇博文聚焦前两类也就是标题里的“多进程、多线程”把它们的实现方式、适用场景、踩坑经验一次讲透。你可能会问现在都2025年了epoll和io_uring这么成熟还有必要学多进程多线程吗我的答案是非常有必要。原因很实际——大量存量服务端代码仍然基于这两种模型很多中间件比如某些Web服务器、数据库连接池的底层就是多进程或多线程架构。更重要的是理解多进程和多线程在Linux网络编程中的具体落地方式是理解后续I/O多路复用、协程、事件驱动等更高级模型的基础。跳过这一步直接上epoll你大概率只是抄了个模板遇到问题根本不知道怎么排查。这篇文章适合已经掌握基本socket编程、能写出单进程TCP服务器的读者。如果你还没写过socket()和bind()建议先把基础打牢再来看。全文会从设计思路、核心API、完整代码实现、常见问题排查四个维度展开每个环节都会解释“为什么这么做”而不只是“怎么做”。代码部分我会给出可直接编译运行的完整示例并标注关键参数的计算依据。2. 多进程模型fork出来的并发世界2.1 多进程服务器的核心设计思路多进程模型的基本逻辑非常直观主进程负责accept()新连接一旦拿到一个新的客户端文件描述符就调用fork()创建一个子进程让子进程去处理这个连接的所有读写操作主进程则立刻回到accept()等待下一个连接。这样每个客户端连接都有独立的进程为其服务彼此之间互不干扰。这个模型最大的优势是隔离性强。每个子进程拥有独立的地址空间一个子进程崩溃了不会影响其他子进程也不会影响主进程。这在需要高稳定性的场景下非常有价值。另一个优势是编程简单——你不需要考虑锁、竞态条件、线程安全这些问题因为进程之间天然隔离。但代价也很明显。fork()的开销不容忽视每次创建子进程内核需要复制父进程的页表、文件描述符表等数据结构。虽然Linux采用了写时复制Copy-On-Write技术避免了立即复制整个地址空间但fork()本身的系统调用开销加上进程调度的上下文切换开销在连接数很大时仍然会成为瓶颈。另外每个进程都有独立的内存空间内存占用会随着并发连接数线性增长。注意多进程模型适合并发量中等几百到几千、连接生命周期较长的场景。如果你的服务器需要同时处理上万个短连接多进程模型的fork()开销会让你吃不消。2.2 fork()的关键细节与文件描述符处理写多进程服务器时fork()之后文件描述符的处理是最容易出错的地方。先看一段核心代码#include stdio.h #include stdlib.h #include string.h #include unistd.h #include arpa/inet.h #include sys/socket.h #include signal.h #include sys/wait.h #define PORT 8080 #define BUF_SIZE 1024 void handle_client(int client_fd) { char buf[BUF_SIZE]; ssize_t n; while ((n read(client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(client_fd, buf, n); // 回声 } close(client_fd); exit(0); } int main(void) { int listen_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); signal(SIGCHLD, SIG_IGN); // 关键自动回收子进程 while (1) { struct sockaddr_in cli_addr; socklen_t cli_len sizeof(cli_addr); int client_fd accept(listen_fd, (struct sockaddr *)cli_addr, cli_len); if (client_fd 0) continue; pid_t pid fork(); if (pid 0) { // 子进程 close(listen_fd); // 子进程不需要监听套接字 handle_client(client_fd); } else if (pid 0) { // 父进程 close(client_fd); // 父进程不需要客户端套接字 } else { perror(fork); close(client_fd); } } return 0; }这段代码里有几个关键点值得展开说。第一signal(SIGCHLD, SIG_IGN)这行非常重要。子进程退出时内核会向父进程发送SIGCHLD信号。如果父进程不处理这个信号子进程会变成僵尸进程占用内核的进程表项。设置SIG_IGN让内核自动回收子进程资源省去了手动调用waitpid()的麻烦。当然如果你需要知道子进程的退出状态就得自己注册信号处理函数并在里面调用waitpid()。第二父进程和子进程各自关闭不需要的文件描述符。子进程继承了父进程的listen_fd但它不需要监听新连接所以关掉。父进程持有client_fd也没有意义因为连接已经交给子进程处理了父进程不关的话这个文件描述符会一直占用最终耗尽父进程的可用描述符数量。这个细节很多人会忽略但在高并发场景下是致命的。第三listen()的第二个参数我设成了128。这个参数叫backlog表示内核已完成连接队列的最大长度。如果队列满了新的连接请求会被拒绝或忽略取决于内核版本和tcp_abort_on_overflow设置。对于多进程服务器因为accept()的调用频率受限于fork()的速度backlog可以适当设大一些128到1024都是常见值。2.3 多进程模型的性能瓶颈与优化方向多进程模型在并发量上升后瓶颈主要出现在三个地方。fork()的开销。每次fork()大约需要几十到几百微秒取决于进程的地址空间大小。连接数一多CPU大量时间花在创建和销毁进程上真正处理业务逻辑的时间反而被压缩。优化方向是使用进程池——预先fork()一批子进程主进程通过管道或共享内存把新连接的文件描述符传递给空闲子进程。这样避免了频繁fork()但实现复杂度显著上升。上下文切换开销。进程数量超过CPU核心数之后操作系统需要在不同进程之间切换每次切换都要保存和恢复寄存器、刷新TLBTranslation Lookaside Buffer。进程切换比线程切换更重因为涉及地址空间的切换。实测下来当活跃进程数超过CPU核心数的2到3倍时吞吐量增长会明显放缓甚至下降。内存占用。每个进程即使有写时复制仍然需要独立的页表、内核栈等结构。一个空转的子进程大约占用几百KB到1MB的内存。1000个并发连接就是1GB左右的内存开销这在资源受限的环境下是不可接受的。实操心得如果你的服务器并发量在500以下连接持续时间较长比如长连接推送服务多进程模型完全够用而且稳定性最好。超过这个量级就该考虑多线程或I/O多路复用了。3. 多线程模型更轻量的并发选择3.1 多线程服务器的架构设计多线程模型和多进程模型在结构上非常相似区别在于把fork()换成了pthread_create()。主线程负责accept()每来一个连接就创建一个新线程去处理。线程共享进程的地址空间所以不需要像进程那样复制页表创建开销小得多。但共享地址空间也带来了新的问题数据竞争。如果多个线程需要访问同一个全局变量或堆上的数据结构就必须加锁保护。在网络编程中最常见的共享资源是连接列表、统计计数器、配置信息等。设计多线程服务器时一个重要的原则是尽量减少共享状态。每个线程只操作自己的局部变量和传入的文件描述符就能避免大部分锁的问题。先看一个基础的多线程回声服务器实现#include stdio.h #include stdlib.h #include string.h #include unistd.h #include pthread.h #include arpa/inet.h #include sys/socket.h #define PORT 8080 #define BUF_SIZE 1024 void *client_thread(void *arg) { int client_fd *(int *)arg; free(arg); // 释放主线程malloc的内存 char buf[BUF_SIZE]; ssize_t n; while ((n read(client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(client_fd, buf, n); } close(client_fd); return NULL; } int main(void) { int listen_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); while (1) { struct sockaddr_in cli_addr; socklen_t cli_len sizeof(cli_addr); int client_fd accept(listen_fd, (struct sockaddr *)cli_addr, cli_len); if (client_fd 0) continue; int *pfd malloc(sizeof(int)); *pfd client_fd; pthread_t tid; if (pthread_create(tid, NULL, client_thread, pfd) ! 0) { perror(pthread_create); free(pfd); close(client_fd); continue; } pthread_detach(tid); // 关键分离线程自动回收资源 } return 0; }编译时需要链接pthread库gcc -o thread_server thread_server.c -lpthread3.2 线程参数传递与资源回收的坑上面代码里有两个容易踩坑的地方我逐个说。参数传递。pthread_create()的第四个参数是void *类型用来传给线程函数。你不能直接把client_fd的地址传进去因为client_fd是主线程栈上的局部变量下一轮循环就会被覆盖。必须用malloc()在堆上分配一块内存把client_fd的值拷进去然后把堆地址传给线程。线程函数里用完这块内存后要free()掉否则就内存泄漏了。我见过不少初学者在这里翻车——传了栈地址结果多个线程读到同一个文件描述符连接全乱套了。线程回收。pthread_create()创建的线程默认是可连接joinable状态线程退出后需要另一个线程调用pthread_join()来回收资源否则线程的栈和线程描述符不会释放变成类似僵尸进程的存在。但服务器主线程在while(1)里忙得很不可能去join每个线程。解决办法是调用pthread_detach(tid)把线程设为分离状态线程退出时系统自动回收资源。这一步千万别漏。注意pthread_detach()可以在创建后立即调用也可以在线程函数内部调用pthread_detach(pthread_self())。两种方式效果一样选一种就行。3.3 线程池避免频繁创建销毁线程和进程一样频繁创建销毁线程也有开销。虽然线程创建比进程快但在高并发短连接场景下这个开销仍然可观。线程池的思路是预先创建一批线程它们阻塞在一个任务队列上主线程把新连接封装成任务放入队列空闲线程被唤醒后取出任务执行。线程池的核心组件包括任务队列通常用链表或环形缓冲区实现、互斥锁保护队列、条件变量用于唤醒等待的线程。下面是一个简化但可用的线程池实现#include pthread.h #include stdlib.h #include unistd.h #define POOL_SIZE 8 #define QUEUE_MAX 1024 typedef struct { int client_fd; } task_t; typedef struct { task_t tasks[QUEUE_MAX]; int head, tail, count; pthread_mutex_t lock; pthread_cond_t not_empty; pthread_cond_t not_full; } task_queue_t; task_queue_t queue; void queue_init(task_queue_t *q) { q-head q-tail q-count 0; pthread_mutex_init(q-lock, NULL); pthread_cond_init(q-not_empty, NULL); pthread_cond_init(q-not_full, NULL); } void queue_push(task_queue_t *q, task_t t) { pthread_mutex_lock(q-lock); while (q-count QUEUE_MAX) pthread_cond_wait(q-not_full, q-lock); q-tasks[q-tail] t; q-tail (q-tail 1) % QUEUE_MAX; q-count; pthread_cond_signal(q-not_empty); pthread_mutex_unlock(q-lock); } task_t queue_pop(task_queue_t *q) { pthread_mutex_lock(q-lock); while (q-count 0) pthread_cond_wait(q-not_empty, q-lock); task_t t q-tasks[q-head]; q-head (q-head 1) % QUEUE_MAX; q-count--; pthread_cond_signal(q-not_full); pthread_mutex_unlock(q-lock); return t; } void *worker(void *arg) { while (1) { task_t t queue_pop(queue); char buf[1024]; ssize_t n; while ((n read(t.client_fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; write(t.client_fd, buf, n); } close(t.client_fd); } return NULL; }主线程只需要调用queue_push()把新连接放入队列工作线程会自动取出处理。线程池的大小需要根据CPU核心数和任务类型来定。对于网络I/O密集型任务线程数可以设为CPU核心数的2到4倍对于计算密集型任务线程数等于CPU核心数比较合适。你可以通过sysconf(_SC_NPROCESSORS_ONLN)获取CPU核心数。4. 多进程与多线程的选型对比与实战建议4.1 两种模型的量化对比选多进程还是多线程不能凭感觉得看具体指标。我整理了一张对比表覆盖了实际选型时最关心的几个维度对比维度多进程模型多线程模型创建开销高fork复制页表低共享地址空间上下文切换开销高需切换地址空间低同一地址空间内存占用高每进程独立空间低共享进程空间隔离性强进程间互不影响弱一个线程崩溃可能拖垮整个进程数据共享困难需IPC容易直接读写全局变量同步复杂度低天然隔离高需锁、条件变量等调试难度较低较高竞态条件难复现适合场景长连接、高稳定性要求短连接、高并发、需共享数据从表里可以看出来两种模型各有取舍。多进程胜在稳定和简单多线程胜在轻量和高效。实际项目中还有一种混合模型主进程fork()出多个子进程每个子进程内部再创建线程池。Nginx就是类似的多进程架构每个worker进程是单线程的事件循环而某些Java应用服务器则采用单进程多线程模型。4.2 信号处理在多进程模型中的特殊考量多进程模型下信号处理有几个容易忽略的细节。除了前面提到的SIGCHLD还有SIGPIPE。当子进程向一个已经关闭的连接写入数据时内核会发送SIGPIPE信号默认行为是终止进程。如果你不希望子进程因为客户端异常断开而挂掉就需要忽略这个信号signal(SIGPIPE, SIG_IGN);或者在write()时使用MSG_NOSIGNAL标志send(client_fd, buf, n, MSG_NOSIGNAL);另一个需要注意的是惊群效应。如果多个子进程同时阻塞在accept()上比如进程池模式当新连接到来时内核会唤醒所有子进程但只有一个能成功accept()其他的白白被唤醒又继续睡眠。这在连接频繁的场景下会造成大量无效的上下文切换。Linux内核从2.6版本开始对accept()的惊群做了优化但并不是所有场景都能完全避免。解决办法是使用文件锁或互斥锁确保同一时刻只有一个子进程在accept()。4.3 线程安全与锁的粒度控制多线程模型下锁的使用是一门艺术。锁的粒度太粗并发性能上不去粒度太细死锁风险增加代码也难以维护。我的经验是遵循几条原则。第一能不用锁就不用锁。每个连接的状态数据放在线程局部变量或连接私有结构体里不跨线程共享。这样大部分操作都是无锁的。第二必须共享的数据用读写锁。比如一个全局的连接计数器读多写少用pthread_rwlock_t比互斥锁更高效。第三锁的持有时间尽可能短。不要在持锁期间做I/O操作或调用可能阻塞的函数。先把数据拷出来释放锁再处理。第四避免嵌套锁。如果确实需要多把锁确保所有线程以相同的顺序获取锁否则很容易死锁。实操心得我调试过多线程服务器的死锁问题最后发现是两把锁的获取顺序不一致导致的。排查这类问题的利器是gdb的thread apply all bt命令能一次性打印所有线程的调用栈快速定位哪两个线程在互相等待。5. 常见问题与排查技巧实录5.1 文件描述符泄漏最隐蔽的杀手文件描述符泄漏是多进程和多线程服务器里最常见的bug之一。症状是服务器运行一段时间后accept()开始返回EMFILE错误新连接无法建立。用lsof -p pid或ls /proc/pid/fd | wc -l可以查看进程当前打开的描述符数量。泄漏的常见原因有几个。一是accept()之后fork()或pthread_create()失败没有关闭client_fd。二是子进程或线程处理完连接后忘记close()。三是父进程忘记关闭client_fd前面代码里强调过。四是dup()或dup2()之后没有关闭原始描述符。排查方法在代码里加日志记录每次accept()返回的client_fd和每次close()的描述符对比一下就能发现哪个没关。更系统的方法是使用valgrind --track-fdsyes运行程序退出时会报告未关闭的描述符。5.2 僵尸进程与孤儿进程的处理僵尸进程前面提过用signal(SIGCHLD, SIG_IGN)或waitpid()解决。孤儿进程则是父进程先于子进程退出子进程被init进程PID 1收养。孤儿进程本身不是问题但如果孤儿进程还在持有监听套接字可能会导致端口无法释放。解决办法是父进程退出时向所有子进程发送终止信号或者让子进程在父进程退出后自行检测并退出。5.3 线程数暴涨与资源耗尽多线程服务器如果每个连接创建一个线程并发量一高线程数会迅速膨胀。Linux默认的线程栈大小是8MB可通过ulimit -s查看1000个线程就是8GB虚拟内存。虽然虚拟内存不等于物理内存但线程调度和上下文切换的开销会急剧增加。解决办法有两个一是使用线程池限制最大线程数二是通过pthread_attr_setstacksize()减小线程栈大小比如设为512KB或1MB对于网络I/O线程来说完全够用。pthread_attr_t attr; pthread_attr_init(attr); pthread_attr_setstacksize(attr, 512 * 1024); // 512KB pthread_create(tid, attr, worker, arg); pthread_attr_destroy(attr);5.4 常见问题速查表问题现象可能原因排查方法解决方案accept返回EMFILE文件描述符泄漏ls /proc/pid/fd | wc -l检查所有close路径出现僵尸进程未处理SIGCHLDps aux | grep defunctsignal(SIGCHLD, SIG_IGN)子进程写数据导致退出收到SIGPIPE查看退出信号忽略SIGPIPE或用MSG_NOSIGNAL线程数持续增长未限制并发或未detachps -eLf | wc -l线程池detach吞吐量上不去锁竞争严重perf top查看锁热点减小锁粒度或无锁化连接被拒绝backlog队列满netstat -s查看溢出统计增大backlog或加快accept5.5 调试工具与手段排查多进程多线程服务器的问题光靠printf是不够的。几个我常用的工具strace -f -p pid可以跟踪所有线程和子进程的系统调用看卡在哪个调用上gdb配合thread apply all bt查看所有线程栈perf top定位CPU热点valgrind --toolhelgrind检测多线程竞态条件。这些工具组合使用大部分问题都能定位到具体代码行。6. 从多进程多线程到更远的路上写到这里多进程和多线程在网络编程中的核心要点基本覆盖了。从单进程阻塞服务器出发多进程模型用隔离性换来了稳定多线程模型用共享内存换来了轻量。两种模型都不是银弹选型时要看并发量、连接时长、稳定性要求和团队熟悉程度。我个人在实际项目中的体会是先用最简单的模型把功能跑通再根据压测结果决定是否优化。很多项目一开始就上复杂的线程池或进程池结果代码复杂度上去了性能瓶颈却根本不在并发模型上而在数据库查询或业务逻辑里。先用多进程或简单的多线程把服务跑起来用ab或wrk压一压看看瓶颈到底在哪再针对性优化这才是务实的做法。另外提一个后续可以深入的方向当并发连接数达到万级以上时多进程和多线程的上下文切换开销都会成为瓶颈这时候就该转向I/O多路复用select/poll/epoll或异步I/O了。但那是另一个话题而且有了多进程多线程的基础理解事件驱动模型会容易得多——本质上都是用某种方式管理多个连接的状态机只是调度机制不同而已。
![打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
