进程池这个东西网上一搜一半是线程池教程另一半是各语言自带的高级封装真讲用管道pipe从零手搓一个进程池的大多点到为止。我最近在做一个批量任务调度模块任务里要接入一套第三方库那套库自带一堆全局状态和静态缓存而且线程不安全的坏味道很重crash起来连前兆都没有。线程池根本兜不住这种风险——线程一崩整个进程跟着没。最后我只能自己撸一个基于管道通信的进程池任务放在独立进程里跑崩了不拖累主进程还能自动拉起。写这篇文章就是把我从第一个fork到最后一版踩坑记录完整捋一遍。适合正在纠结“线程池隔离性不够、手写进程池又不知道从哪儿下手”的开发者抄作业也适合想搞明白管道到底怎么用来做进程间通信的人。1. 我为什么放着线程池不用非要用管道搓一个进程池在动手写代码之前我得先把“为什么是进程池”和“为什么是管道”这两件事讲明白。这不是废话之前有朋友拿着我的方案反推自己的需求发现他的场景其实用线程池更省事代码还更好维护。说明这个选择是有代价、有前提的不是无脑最能打。1.1 线程池处理不了的那类“脏活累活”线程池看起来很美好创建线程成本低共享内存天然零拷贝加锁就能同步。但它的命门是地址空间共享。一个线程写出越界指针、踩坏堆结构、陷入死循环、泄漏大量内存整个进程一起遭殃。更麻烦的是很多第三方库的崩溃你是拦不住的你甚至没法知道它什么时候开始不稳定。进程池的核心价值不是性能是故障隔离和资源边界。每个任务跑在独立进程里进程有独立地址空间、独立堆、独立文件描述符表。最坏情况下任务把内存吃到只剩1MB主进程把它的管道一关、发个终止信号、回收掉就行完全不影响其他worker。还有一点容易被忽略内存回收。线程池里如果某个任务泄漏了20MB内存你很难察觉日积月累rss涨到吓人。进程池里任务结束退出操作系统负责回收全部内存根本不用你操心。所以我的结论很直接你调用的库是黑盒、可能崩溃、可能有静态状态 → 进程池你需要长时间稳定运行、任务失败不能拖垮主服务 → 进程池你的任务是纯计算、可信任、内存可控 → 线程池就够了别学我你的任务还需要越过解释器的锁限制 → 进程池天然多进程顺路也解决了1.2 管道作为IPC方案到底够不够用定下“用进程池”之后还有一个问题主进程和worker之间怎么通信我当时把常见IPC方案都过了一遍。共享内存最快但同步问题很麻烦。你要自己维护信号量或锁最怕的是某个worker崩溃前把锁状态搞坏了其他进程全部卡死在抢锁上排查难度极高。Unix域套接字socketpair是正经方案但操作对象是套接字看日志、抓包、调试都比管道绕一层。管道pipe是Linux进程通信最朴素的通道read/write两个接口天然自带阻塞流控不需要额外同步原语。管道的代价也摆在那里数据要内核缓冲拷贝一次不适合传超大块数据管道缓冲有限写多了会阻塞。但这些在我们场景里完全能接受——任务帧本身就是几十KB级别的控制信息真正的重数据处理放到任务内部去读写磁盘文件不走IPC。最终方案定为每个worker一对管道任务用自定义帧格式在管道里传输。没有共享内存没有socketpair够用而且出问题了非常好排查。2. 开工前的方案设计两对管道、阻塞读、长度前缀帧整个池子的架构其实不复杂主进程负责接收任务、记录worker状态、投递任务worker从管道里读任务、执行、写回结果。难的地方全在细节里尤其是文件描述符的继承关系和消息边界。2.1 每个worker要有独立的“指令管道”和“结果管道”注意措辞这里说的是一对管道还是两对管道得说清楚。pipe()一次只能创建一条单向管道一端写、一端读。主进程需要给worker发任务worker也需要给主进程回结果所以每个worker最少需要两条单向管道也就是两个pipe()调用。我习惯分别叫它们控制管道和结果管道控制管道主进程写任务帧和终止指令给worker结果管道worker写结果帧和异常信息给主进程为什么非要分开如果共用一条管道数据流就是双向混杂的主进程read的时候根本不知道读到的字节是任务请求还是任务结果逻辑上拧成一团。分开之后“主进程发任务”和“worker回结果”是两条独立的数据流互不干扰出问题还能用lsof分别看哪条管道堵了。每个worker拥有自己独立的两条管道好处是天然不需要在结果管道上做多路复用标记读到的结果必定属于当前worker任务和结果天然一一对应。2.2 fork之后的描述符继承是第一个隐藏的地雷这是新手最容易翻车的地方必须一开始就想清楚。pipe()之后紧接着fork()父子进程各自持有两个文件描述符。管道是字节流自带一个缓冲和一个引用计数只有当所有写端都被关闭读端read()才会返回0。也就是说如果父进程不显式关闭自己该关的fd子进程不显式关闭自己该关的fd那么一条管道上可能同时挂好几个人。最直接的后果是你期待的一个worker退出能让另一个进程read()返回0结果它永远不返回。因为还有别的进程握着写端不放。所以在创建worker时父子进程必须立刻做“分工切割”int ctrl[2]; int res[2]; pipe(ctrl); // 控制管道 pipe(res); // 结果管道 pid_t pid fork(); if (pid 0) { // 子进程读控制管道、写结果管道 close(ctrl[1]); close(res[0]); worker_main(ctrl[0], res[1]); } // 父进程写控制管道、读结果管道 close(ctrl[0]); close(res[1]);这就是整个池子最核心的fd纪律。后面所有诡异问题往上追都会追到这一条纪律没做到位。2.3 任务帧用长度前缀解决消息边界管道是字节流write和read之间没有消息边界。你写了一次100字节对端可能分两次各读50字节也可能一次读到200字节如果读端缓冲里已经积了两条消息。所以必须在应用层定义“一帧”的概念。我用的方案是经典的长度前缀struct frame_header { uint32_t len; // 负载长度不含头 };帧结构就是4字节长度头 负载数据负载是任意二进制字节。发命令时先写头再写负载收命令时先读满4字节头解析出长度再读满对应长度的负载。长度前缀比分隔符方案靠谱多了。任务内容可能包含任意字节换行符、空字节都可能出现用分隔符解析必然炸。长度前缀只需要保证len字段不会和真实负载混淆就行而len字段本身是定长整形编码后不可能和负载“粘”在一起。还有一个约定帧长度为0表示终止指令。真正的空负载任务我在业务里用不到所以把len 0当作“worker请退出”的信号复用现有帧格式不需要另起一套控制协议。3. worker侧实现一个从管道里扣任务的循环worker本身是一个简单的常驻进程。它的生命周期就是阻塞在控制管道的读端等任务执行回结果再等下一个。3.1 worker入口先关掉所有不该持有的fdworker_main进来后的第一件事不是读管道而是把继承来的乱七八糟fd全部关掉。多worker场景下每个子进程都从父进程那里继承了其他worker的控制管道写端、结果管道读端。这些fd对本worker来说毫无用处却会让其他通道的关闭检测失效。我写了一个简单的关闭函数显式传入不需要的fd逐个clean。static void close_unused_fds(int keep1, int keep2) { // 实际项目中可能通过遍历 /proc/self/fd 来关闭 // 这里简单示意只保留 keep1、keep2其余close for (int fd 3; fd 1024; fd) { if (fd ! keep1 fd ! keep2) { close(fd); } } }严格说遍历/proc/self/fd再close更稳但绝大多数情况下显式关掉已知fd就够了。关键是宁可多关不可漏关。3.2 readn/writen操作系统不会保证一次读完管道读有个特点read(fd, buf, 100)可能只读回来37字节剩下的还在管道里。你必须写一个循环函数保证“要么读满指定长度要么确定出错”。static ssize_t readn(int fd, void *buf, size_t len) { size_t left len; char *p buf; while (left 0) { ssize_t n read(fd, p, left); if (n -1) { if (errno EINTR) continue; return -1; } if (n 0) break; // 对端全部关闭 p n; left - n; } return len - left; }对应地写一个writen处理部分写入和EINTR。这两个函数是后面所有读写的基础任何地方出现裸read、裸write都要回头打自己手。关于阻塞IO我特意选了阻塞模式没有改成非阻塞。理由很简单——worker没有任务的时候就该挂起不该空转占CPU。阻塞read让worker自动睡眠等任务到达内核唤醒它这是最省电、最省CPU的模型。3.3 worker主循环解析帧、执行任务、回写结果worker主循环的逻辑非常直白void worker_main(int ctrl_r, int res_w) { for (;;) { uint32_t len 0; ssize_t n readn(ctrl_r, len, sizeof(len)); if (n ! sizeof(len)) break; // 管道关闭或异常 if (len 0) break; // 收到终止指令 void *payload malloc(len); if (readn(ctrl_r, payload, len) ! len) { free(payload); break; } uint32_t res_len 0; void *result run_task(payload, len, res_len); free(payload); // 回写结果 if (writen(res_w, res_len, sizeof(res_len)) ! sizeof(res_len)) break; if (res_len 0) { if (writen(res_w, result, res_len) ! res_len) { free(result); break; } } free(result); } close(ctrl_r); close(res_w); exit(0); }run_task这里的实现就是业务分发逻辑。我建议任务帧的前几个字节固定放一个task_type字段worker根据类型调到对应的处理函数。注意任务负载里面不能直接传指针更不能传堆地址因为地址空间不共享。所有参数必须是值语义内存交给malloc拷贝这是进程隔离给你的一课你想传的不是地址是数据。还有一个容易忽略的细节worker在任务执行中如果崩溃那么结果管道写端自动关闭主进程那边读端会感知到。这反而是好事进程池天然自带“任务崩溃检测”能力。4. 主进程调度器一个事件循环把任务喂给空闲worker主进程侧的工作更像一个“分发中枢”。它自身不执行任务只负责维护worker状态、投递任务、接收结果。4.1 调度器需要记录哪些状态我给每个worker维护一个结构体typedef struct worker_item { pid_t pid; int ctrl_w; // 主进程写任务worker读 int res_r; // worker写结果主进程读 int busy; // 0空闲1正在跑任务 uint64_t start_time; // 最近一次任务开始时间用于超时看护 } worker_item;主进程持有一个worker_item数组大小就是池容量。整个调度状态非常简单找到一个busy0的worker往它的ctrl_w写任务帧把busy置1记下时间等到res_r可读读结果帧把busy清0。4.2 批量创建worker时的fd管理创建N个worker循环N次每次都是创建两条管道、fork、分工close。这里最容易犯的错是父进程在fork完第一个worker后还留着第一个worker的read端应该保存到数组里结果第二个fork时又把它们继承给第二个子进程了。我的做法是每个worker创建完立刻把父进程该关的关掉只保留写端和读端存进数组不留给下一个fork周期。顺序上“创建管道 → fork → 父子各自close → 保存fd → 下一个”总要保持清晰。4.3 主循环poll结果管道 投递排队任务主进程不能傻乎乎地read某个结果管道因为任何一个worker都可能先完成。我用poll()统一监听所有worker的结果管道读端struct pollfd fds[POOL_SIZE]; for (int i 0; i POOL_SIZE; i) { fds[i].fd workers[i].res_r; fds[i].events POLLIN; } for (;;) { int ret poll(fds, POOL_SIZE, timeout_ms); if (ret 0) { /* 处理EINTR */ } for (int i 0; i POOL_SIZE; i) { if (fds[i].revents POLLIN) { read_result_from_worker(i); } if (fds[i].revents POLLHUP) { handle_worker_exit(i); } } // 从任务队列里取任务投给空闲worker dispatch_pending_tasks(); }read_result_from_worker内部用和worker侧对称的帧读取逻辑先读4字节长度再读负载然后标记worker为空闲。dispatch_pending_tasks的逻辑就是遍历worker数组找到一个空闲worker从任务队列头取一个任务构造帧写控制管道标记busy。任务队列为空就什么都不做。这套结构本质上是一个单线程事件循环整个调度过程没有任何锁。主进程不会并发操作worker结构体任务队列只被主进程访问。这是进程池方案一个巨大的优势你省掉了所有锁相关的烦恼。如果哪天觉得这里需要加锁多半是设计出了问题。4.4 投递大帧时的可写性检查我前面说控制管道主要是中小任务帧但如果业务里真的出现了几MB的帧你就得注意write()会在管道缓冲满时阻塞。主进程一旦阻塞在write里整个poll循环就卡住了其他worker的结果没人收这是致命的。所以投递帧之前应该先poll该控制管道的写端确认POLLOUT才写。或者更简单粗暴限制任务帧大小超过阈值的任务不通过管道传而是让worker自己从指定路径读取大数据。我这边的选择是后者——管道只传小命令大块数据走磁盘文件把IPC的负担降到最低。5. 实测踩坑记录进程池不是fork完就结束的项目第一次跑通“主进程能发任务、worker能执行并返回结果”时我以为万事大吉。结果后面几天陆陆续续踩了四个坑每一个都让我觉得前面设计时的“经验主义”换来了真实教训。5.1 僵尸进程堆积漏了waitpid的下场现象很典型跑一段时间ps -ef一看一堆defunct状态的僵尸进程挂在池子下面。原因是worker在执行终止指令或者异常退出后它的进程描述符还留在内核里等待父进程waitpid()收尸。我一直没处理结果僵尸越堆越多最后系统进程数爆表。修复方法是注册一个SIGCHLD信号处理函数里面用waitpid(-1, NULL, WNOHANG)把所有已经退出的子进程回收掉。注意信号处理函数里不能干复杂的事打印日志、加锁都不行我只做waitpid然后置一个全局标志位让主循环在合适的时候去处理worker失踪问题。static void on_sigchld(int sig) { while (waitpid(-1, NULL, WNOHANG) 0) {} g_child_changed 1; }5.2 read永远不返回0子进程继承了不该继承的写端有个现象很奇怪某个worker执行了退出指令exit()也调了结果主进程在poll它对应的管道路径时没有立刻感知到甚至另一个worker的结果管道永远等不到EOF。查了半天才发现问题出在子进程继承了其他worker的结果管道写端。前面说过管道EOF的语义是“所有写端关闭”。现在有4个worker它们各自的子进程都从父进程那里继承了所有结果管道的写端。A worker退出时它的写端确实关了但B、C、D的进程里还开着A的结果管道写端所以主进程读A的结果管道永远不会返回0poll只会得到可读但读不到EOF的暧昧状态。解决方案就是我在3.1里强调的子进程入口立刻关闭所有无关fd尤其其他worker的管道。排查这个问题的过程很痛苦因为我一开始根本没意识到fork天然会复制整个fd表还以为每个worker只拿到了自己该有的fd。5.3 大任务帧把管道写满双方互等造成死锁当时为了让框架支持更大任务把帧上限调得很大。结果某次压测时整个池子卡死任务既不完成也不报错。复盘下来是这样的主进程写一个大帧到控制管道管道缓冲满了主进程阻塞在write等待worker读取而worker那边读完任务后处理完又写回一个大结果帧结果结果管道也满了worker阻塞在write等待主进程读取。一个等对方读一个等对方写两边谁都没法继续。这是典型的管道缓冲有限带来的死锁。解决办法有三层第一层投递前检查控制管道可写不要闷头write第二层限制单帧大小大数据走文件路径截断第三层主进程写大帧时先处理其他结果避免单帧阻塞拖垮整个poll循环我最终用的是第二层为主第一层兜底。限制任务帧不超过1MB实际上业务任务很难超过这个量级。5.4 SIGPIPE主进程自己把自己干掉了这个坑最阴险。某天worker异常退出后主进程还试图往它的控制管道写下一个任务这时管道读端已经关闭write触发SIGPIPE信号。SIGPIPE的默认行为是终止进程于是主进程莫名其妙就死了连core dump都没有。修复是一行代码的事signal(SIGPIPE, SIG_IGN);忽略掉SIGPIPE之后write返回EPIPE错误代码里检测到这个错误再去走worker清理流程就好。这个坑建议所有做IPC的开发者都提前打预防针否则上线后你会接到“服务很神秘地挂掉”的告警查半天都查不到原因。6. 从能跑到好用超时回收、优先级与池大小调优基础框架稳定之后我又加了几层“工业化”特性让这个池子不再只是实验室玩物。6.1 watchdog与超时回收任务有可能卡死可能是第三方库死循环也可能是IO永久阻塞。主进程需要知道每个worker最近一个任务的开始时间并在poll的超时路径上检查如果busy时间超过阈值就kill(pid, SIGKILL)杀掉。SIGCHLD处理器会回收它然后我在g_child_changed标志位里感知到再重新fork一个worker补位。实现上不需要额外线程复用poll的超时参数就行poll返回0意味着超时此时遍历所有busy worker做时间比较。这比单独起一个看护线程更简单也更符合事件循环的理念。6.2 任务优先级多级队列如果所有任务都是平等的一个单任务队列就够了。但实际业务里“紧急请求”和“后台批处理”经常混在一起。我给主进程维护了三个队列高、中、低。dispatch的时候从高队列开始取高队列空再看中队列中空再看低。这样紧急任务最多等一个worker跑完就能被拉起来不会背后台长任务堵死。进程池本身不感知优先级优先级完全在主进程的调度策略里体现。这也很符合“主进程只管分配worker只管执行”的分工边界。6.3 池大小与任务粒度一个成本模型最后聊一下池子配置多少worker合适。我的经验模型是单任务执行时间TIPC和调度的开销Cfork一个worker的摊销成本随任务吞吐量递减。如果T只有零点几毫秒那么C在里面占比可能超过一半进程池的性价比会很低不如线程池如果T是几十毫秒甚至更久进程池的开销占比就完全可以接受了。池容量我一般按CPU核数 * 1.5来起步如果任务里还有大量阻塞IO就往上调让机器在等待IO的时间里也能并行多跑几个。我现在的模块里worker数量、任务超时阈值都做成了配置项压测之后就长期固定下来了。最后再分享一个细节经验给每个worker起名字时加上序号在日志里只输出worker序号和task_type不输出负载内容。排障的时候“哪个worker在处理哪类任务”比“任务里具体是什么数据”有用得多。进程池这东西难的不是写出来是写完之后还能从容地面对它隔三差五出点幺蛾子。 
长河君 · 2026/10/17 14:15:57 · 阅读 1.2k 用管道从零手搓进程池：原理、踩坑与工程实践
进程池这个东西网上一搜一半是线程池教程另一半是各语言自带的高级封装真讲用管道pipe从零手搓一个进程池的大多点到为止。我最近在做一个批量任务调度模块任务里要接入一套第三方库那套库自带一堆全局状态和静态缓存而且线程不安全的坏味道很重crash起来连前兆都没有。线程池根本兜不住这种风险——线程一崩整个进程跟着没。最后我只能自己撸一个基于管道通信的进程池任务放在独立进程里跑崩了不拖累主进程还能自动拉起。写这篇文章就是把我从第一个fork到最后一版踩坑记录完整捋一遍。适合正在纠结“线程池隔离性不够、手写进程池又不知道从哪儿下手”的开发者抄作业也适合想搞明白管道到底怎么用来做进程间通信的人。1. 我为什么放着线程池不用非要用管道搓一个进程池在动手写代码之前我得先把“为什么是进程池”和“为什么是管道”这两件事讲明白。这不是废话之前有朋友拿着我的方案反推自己的需求发现他的场景其实用线程池更省事代码还更好维护。说明这个选择是有代价、有前提的不是无脑最能打。1.1 线程池处理不了的那类“脏活累活”线程池看起来很美好创建线程成本低共享内存天然零拷贝加锁就能同步。但它的命门是地址空间共享。一个线程写出越界指针、踩坏堆结构、陷入死循环、泄漏大量内存整个进程一起遭殃。更麻烦的是很多第三方库的崩溃你是拦不住的你甚至没法知道它什么时候开始不稳定。进程池的核心价值不是性能是故障隔离和资源边界。每个任务跑在独立进程里进程有独立地址空间、独立堆、独立文件描述符表。最坏情况下任务把内存吃到只剩1MB主进程把它的管道一关、发个终止信号、回收掉就行完全不影响其他worker。还有一点容易被忽略内存回收。线程池里如果某个任务泄漏了20MB内存你很难察觉日积月累rss涨到吓人。进程池里任务结束退出操作系统负责回收全部内存根本不用你操心。所以我的结论很直接你调用的库是黑盒、可能崩溃、可能有静态状态 → 进程池你需要长时间稳定运行、任务失败不能拖垮主服务 → 进程池你的任务是纯计算、可信任、内存可控 → 线程池就够了别学我你的任务还需要越过解释器的锁限制 → 进程池天然多进程顺路也解决了1.2 管道作为IPC方案到底够不够用定下“用进程池”之后还有一个问题主进程和worker之间怎么通信我当时把常见IPC方案都过了一遍。共享内存最快但同步问题很麻烦。你要自己维护信号量或锁最怕的是某个worker崩溃前把锁状态搞坏了其他进程全部卡死在抢锁上排查难度极高。Unix域套接字socketpair是正经方案但操作对象是套接字看日志、抓包、调试都比管道绕一层。管道pipe是Linux进程通信最朴素的通道read/write两个接口天然自带阻塞流控不需要额外同步原语。管道的代价也摆在那里数据要内核缓冲拷贝一次不适合传超大块数据管道缓冲有限写多了会阻塞。但这些在我们场景里完全能接受——任务帧本身就是几十KB级别的控制信息真正的重数据处理放到任务内部去读写磁盘文件不走IPC。最终方案定为每个worker一对管道任务用自定义帧格式在管道里传输。没有共享内存没有socketpair够用而且出问题了非常好排查。2. 开工前的方案设计两对管道、阻塞读、长度前缀帧整个池子的架构其实不复杂主进程负责接收任务、记录worker状态、投递任务worker从管道里读任务、执行、写回结果。难的地方全在细节里尤其是文件描述符的继承关系和消息边界。2.1 每个worker要有独立的“指令管道”和“结果管道”注意措辞这里说的是一对管道还是两对管道得说清楚。pipe()一次只能创建一条单向管道一端写、一端读。主进程需要给worker发任务worker也需要给主进程回结果所以每个worker最少需要两条单向管道也就是两个pipe()调用。我习惯分别叫它们控制管道和结果管道控制管道主进程写任务帧和终止指令给worker结果管道worker写结果帧和异常信息给主进程为什么非要分开如果共用一条管道数据流就是双向混杂的主进程read的时候根本不知道读到的字节是任务请求还是任务结果逻辑上拧成一团。分开之后“主进程发任务”和“worker回结果”是两条独立的数据流互不干扰出问题还能用lsof分别看哪条管道堵了。每个worker拥有自己独立的两条管道好处是天然不需要在结果管道上做多路复用标记读到的结果必定属于当前worker任务和结果天然一一对应。2.2 fork之后的描述符继承是第一个隐藏的地雷这是新手最容易翻车的地方必须一开始就想清楚。pipe()之后紧接着fork()父子进程各自持有两个文件描述符。管道是字节流自带一个缓冲和一个引用计数只有当所有写端都被关闭读端read()才会返回0。也就是说如果父进程不显式关闭自己该关的fd子进程不显式关闭自己该关的fd那么一条管道上可能同时挂好几个人。最直接的后果是你期待的一个worker退出能让另一个进程read()返回0结果它永远不返回。因为还有别的进程握着写端不放。所以在创建worker时父子进程必须立刻做“分工切割”int ctrl[2]; int res[2]; pipe(ctrl); // 控制管道 pipe(res); // 结果管道 pid_t pid fork(); if (pid 0) { // 子进程读控制管道、写结果管道 close(ctrl[1]); close(res[0]); worker_main(ctrl[0], res[1]); } // 父进程写控制管道、读结果管道 close(ctrl[0]); close(res[1]);这就是整个池子最核心的fd纪律。后面所有诡异问题往上追都会追到这一条纪律没做到位。2.3 任务帧用长度前缀解决消息边界管道是字节流write和read之间没有消息边界。你写了一次100字节对端可能分两次各读50字节也可能一次读到200字节如果读端缓冲里已经积了两条消息。所以必须在应用层定义“一帧”的概念。我用的方案是经典的长度前缀struct frame_header { uint32_t len; // 负载长度不含头 };帧结构就是4字节长度头 负载数据负载是任意二进制字节。发命令时先写头再写负载收命令时先读满4字节头解析出长度再读满对应长度的负载。长度前缀比分隔符方案靠谱多了。任务内容可能包含任意字节换行符、空字节都可能出现用分隔符解析必然炸。长度前缀只需要保证len字段不会和真实负载混淆就行而len字段本身是定长整形编码后不可能和负载“粘”在一起。还有一个约定帧长度为0表示终止指令。真正的空负载任务我在业务里用不到所以把len 0当作“worker请退出”的信号复用现有帧格式不需要另起一套控制协议。3. worker侧实现一个从管道里扣任务的循环worker本身是一个简单的常驻进程。它的生命周期就是阻塞在控制管道的读端等任务执行回结果再等下一个。3.1 worker入口先关掉所有不该持有的fdworker_main进来后的第一件事不是读管道而是把继承来的乱七八糟fd全部关掉。多worker场景下每个子进程都从父进程那里继承了其他worker的控制管道写端、结果管道读端。这些fd对本worker来说毫无用处却会让其他通道的关闭检测失效。我写了一个简单的关闭函数显式传入不需要的fd逐个clean。static void close_unused_fds(int keep1, int keep2) { // 实际项目中可能通过遍历 /proc/self/fd 来关闭 // 这里简单示意只保留 keep1、keep2其余close for (int fd 3; fd 1024; fd) { if (fd ! keep1 fd ! keep2) { close(fd); } } }严格说遍历/proc/self/fd再close更稳但绝大多数情况下显式关掉已知fd就够了。关键是宁可多关不可漏关。3.2 readn/writen操作系统不会保证一次读完管道读有个特点read(fd, buf, 100)可能只读回来37字节剩下的还在管道里。你必须写一个循环函数保证“要么读满指定长度要么确定出错”。static ssize_t readn(int fd, void *buf, size_t len) { size_t left len; char *p buf; while (left 0) { ssize_t n read(fd, p, left); if (n -1) { if (errno EINTR) continue; return -1; } if (n 0) break; // 对端全部关闭 p n; left - n; } return len - left; }对应地写一个writen处理部分写入和EINTR。这两个函数是后面所有读写的基础任何地方出现裸read、裸write都要回头打自己手。关于阻塞IO我特意选了阻塞模式没有改成非阻塞。理由很简单——worker没有任务的时候就该挂起不该空转占CPU。阻塞read让worker自动睡眠等任务到达内核唤醒它这是最省电、最省CPU的模型。3.3 worker主循环解析帧、执行任务、回写结果worker主循环的逻辑非常直白void worker_main(int ctrl_r, int res_w) { for (;;) { uint32_t len 0; ssize_t n readn(ctrl_r, len, sizeof(len)); if (n ! sizeof(len)) break; // 管道关闭或异常 if (len 0) break; // 收到终止指令 void *payload malloc(len); if (readn(ctrl_r, payload, len) ! len) { free(payload); break; } uint32_t res_len 0; void *result run_task(payload, len, res_len); free(payload); // 回写结果 if (writen(res_w, res_len, sizeof(res_len)) ! sizeof(res_len)) break; if (res_len 0) { if (writen(res_w, result, res_len) ! res_len) { free(result); break; } } free(result); } close(ctrl_r); close(res_w); exit(0); }run_task这里的实现就是业务分发逻辑。我建议任务帧的前几个字节固定放一个task_type字段worker根据类型调到对应的处理函数。注意任务负载里面不能直接传指针更不能传堆地址因为地址空间不共享。所有参数必须是值语义内存交给malloc拷贝这是进程隔离给你的一课你想传的不是地址是数据。还有一个容易忽略的细节worker在任务执行中如果崩溃那么结果管道写端自动关闭主进程那边读端会感知到。这反而是好事进程池天然自带“任务崩溃检测”能力。4. 主进程调度器一个事件循环把任务喂给空闲worker主进程侧的工作更像一个“分发中枢”。它自身不执行任务只负责维护worker状态、投递任务、接收结果。4.1 调度器需要记录哪些状态我给每个worker维护一个结构体typedef struct worker_item { pid_t pid; int ctrl_w; // 主进程写任务worker读 int res_r; // worker写结果主进程读 int busy; // 0空闲1正在跑任务 uint64_t start_time; // 最近一次任务开始时间用于超时看护 } worker_item;主进程持有一个worker_item数组大小就是池容量。整个调度状态非常简单找到一个busy0的worker往它的ctrl_w写任务帧把busy置1记下时间等到res_r可读读结果帧把busy清0。4.2 批量创建worker时的fd管理创建N个worker循环N次每次都是创建两条管道、fork、分工close。这里最容易犯的错是父进程在fork完第一个worker后还留着第一个worker的read端应该保存到数组里结果第二个fork时又把它们继承给第二个子进程了。我的做法是每个worker创建完立刻把父进程该关的关掉只保留写端和读端存进数组不留给下一个fork周期。顺序上“创建管道 → fork → 父子各自close → 保存fd → 下一个”总要保持清晰。4.3 主循环poll结果管道 投递排队任务主进程不能傻乎乎地read某个结果管道因为任何一个worker都可能先完成。我用poll()统一监听所有worker的结果管道读端struct pollfd fds[POOL_SIZE]; for (int i 0; i POOL_SIZE; i) { fds[i].fd workers[i].res_r; fds[i].events POLLIN; } for (;;) { int ret poll(fds, POOL_SIZE, timeout_ms); if (ret 0) { /* 处理EINTR */ } for (int i 0; i POOL_SIZE; i) { if (fds[i].revents POLLIN) { read_result_from_worker(i); } if (fds[i].revents POLLHUP) { handle_worker_exit(i); } } // 从任务队列里取任务投给空闲worker dispatch_pending_tasks(); }read_result_from_worker内部用和worker侧对称的帧读取逻辑先读4字节长度再读负载然后标记worker为空闲。dispatch_pending_tasks的逻辑就是遍历worker数组找到一个空闲worker从任务队列头取一个任务构造帧写控制管道标记busy。任务队列为空就什么都不做。这套结构本质上是一个单线程事件循环整个调度过程没有任何锁。主进程不会并发操作worker结构体任务队列只被主进程访问。这是进程池方案一个巨大的优势你省掉了所有锁相关的烦恼。如果哪天觉得这里需要加锁多半是设计出了问题。4.4 投递大帧时的可写性检查我前面说控制管道主要是中小任务帧但如果业务里真的出现了几MB的帧你就得注意write()会在管道缓冲满时阻塞。主进程一旦阻塞在write里整个poll循环就卡住了其他worker的结果没人收这是致命的。所以投递帧之前应该先poll该控制管道的写端确认POLLOUT才写。或者更简单粗暴限制任务帧大小超过阈值的任务不通过管道传而是让worker自己从指定路径读取大数据。我这边的选择是后者——管道只传小命令大块数据走磁盘文件把IPC的负担降到最低。5. 实测踩坑记录进程池不是fork完就结束的项目第一次跑通“主进程能发任务、worker能执行并返回结果”时我以为万事大吉。结果后面几天陆陆续续踩了四个坑每一个都让我觉得前面设计时的“经验主义”换来了真实教训。5.1 僵尸进程堆积漏了waitpid的下场现象很典型跑一段时间ps -ef一看一堆defunct状态的僵尸进程挂在池子下面。原因是worker在执行终止指令或者异常退出后它的进程描述符还留在内核里等待父进程waitpid()收尸。我一直没处理结果僵尸越堆越多最后系统进程数爆表。修复方法是注册一个SIGCHLD信号处理函数里面用waitpid(-1, NULL, WNOHANG)把所有已经退出的子进程回收掉。注意信号处理函数里不能干复杂的事打印日志、加锁都不行我只做waitpid然后置一个全局标志位让主循环在合适的时候去处理worker失踪问题。static void on_sigchld(int sig) { while (waitpid(-1, NULL, WNOHANG) 0) {} g_child_changed 1; }5.2 read永远不返回0子进程继承了不该继承的写端有个现象很奇怪某个worker执行了退出指令exit()也调了结果主进程在poll它对应的管道路径时没有立刻感知到甚至另一个worker的结果管道永远等不到EOF。查了半天才发现问题出在子进程继承了其他worker的结果管道写端。前面说过管道EOF的语义是“所有写端关闭”。现在有4个worker它们各自的子进程都从父进程那里继承了所有结果管道的写端。A worker退出时它的写端确实关了但B、C、D的进程里还开着A的结果管道写端所以主进程读A的结果管道永远不会返回0poll只会得到可读但读不到EOF的暧昧状态。解决方案就是我在3.1里强调的子进程入口立刻关闭所有无关fd尤其其他worker的管道。排查这个问题的过程很痛苦因为我一开始根本没意识到fork天然会复制整个fd表还以为每个worker只拿到了自己该有的fd。5.3 大任务帧把管道写满双方互等造成死锁当时为了让框架支持更大任务把帧上限调得很大。结果某次压测时整个池子卡死任务既不完成也不报错。复盘下来是这样的主进程写一个大帧到控制管道管道缓冲满了主进程阻塞在write等待worker读取而worker那边读完任务后处理完又写回一个大结果帧结果结果管道也满了worker阻塞在write等待主进程读取。一个等对方读一个等对方写两边谁都没法继续。这是典型的管道缓冲有限带来的死锁。解决办法有三层第一层投递前检查控制管道可写不要闷头write第二层限制单帧大小大数据走文件路径截断第三层主进程写大帧时先处理其他结果避免单帧阻塞拖垮整个poll循环我最终用的是第二层为主第一层兜底。限制任务帧不超过1MB实际上业务任务很难超过这个量级。5.4 SIGPIPE主进程自己把自己干掉了这个坑最阴险。某天worker异常退出后主进程还试图往它的控制管道写下一个任务这时管道读端已经关闭write触发SIGPIPE信号。SIGPIPE的默认行为是终止进程于是主进程莫名其妙就死了连core dump都没有。修复是一行代码的事signal(SIGPIPE, SIG_IGN);忽略掉SIGPIPE之后write返回EPIPE错误代码里检测到这个错误再去走worker清理流程就好。这个坑建议所有做IPC的开发者都提前打预防针否则上线后你会接到“服务很神秘地挂掉”的告警查半天都查不到原因。6. 从能跑到好用超时回收、优先级与池大小调优基础框架稳定之后我又加了几层“工业化”特性让这个池子不再只是实验室玩物。6.1 watchdog与超时回收任务有可能卡死可能是第三方库死循环也可能是IO永久阻塞。主进程需要知道每个worker最近一个任务的开始时间并在poll的超时路径上检查如果busy时间超过阈值就kill(pid, SIGKILL)杀掉。SIGCHLD处理器会回收它然后我在g_child_changed标志位里感知到再重新fork一个worker补位。实现上不需要额外线程复用poll的超时参数就行poll返回0意味着超时此时遍历所有busy worker做时间比较。这比单独起一个看护线程更简单也更符合事件循环的理念。6.2 任务优先级多级队列如果所有任务都是平等的一个单任务队列就够了。但实际业务里“紧急请求”和“后台批处理”经常混在一起。我给主进程维护了三个队列高、中、低。dispatch的时候从高队列开始取高队列空再看中队列中空再看低。这样紧急任务最多等一个worker跑完就能被拉起来不会背后台长任务堵死。进程池本身不感知优先级优先级完全在主进程的调度策略里体现。这也很符合“主进程只管分配worker只管执行”的分工边界。6.3 池大小与任务粒度一个成本模型最后聊一下池子配置多少worker合适。我的经验模型是单任务执行时间TIPC和调度的开销Cfork一个worker的摊销成本随任务吞吐量递减。如果T只有零点几毫秒那么C在里面占比可能超过一半进程池的性价比会很低不如线程池如果T是几十毫秒甚至更久进程池的开销占比就完全可以接受了。池容量我一般按CPU核数 * 1.5来起步如果任务里还有大量阻塞IO就往上调让机器在等待IO的时间里也能并行多跑几个。我现在的模块里worker数量、任务超时阈值都做成了配置项压测之后就长期固定下来了。最后再分享一个细节经验给每个worker起名字时加上序号在日志里只输出worker序号和task_type不输出负载内容。排障的时候“哪个worker在处理哪类任务”比“任务里具体是什么数据”有用得多。进程池这东西难的不是写出来是写完之后还能从容地面对它隔三差五出点幺蛾子。