简介《Linux系统编程实战技巧》是一份系统编程技术资料源于Packt出版社2021年推出的同名英文图书作者为瑞典Linux顾问杰克-本尼·佩尔松。内容面向已有一定Linux基础、希望深入系统级开发的中高级开发者聚焦如何编写高效、稳定、可维护的Linux程序并提供从系统调用到多进程/多线程协作的完整思路。资源包内为1个PDF文档共1份文件大小约4.82MB轻量便携便于离线阅读和按章节检索。目前已有102人加入学习。资料从开发环境搭建开始逐步覆盖共享库的创建与使用、终端I/O控制、进程间通信含管道、消息队列等、多线程并发以及调试工具实战等主题每章均配有实际案例和动手练习帮助读者在实验过程中理解底层机制、积累常见问题的排查思路最终形成一套可落地的Linux系统编程知识体系。1. Linux 系统编程实战技巧从文件 IO 到进程通信一份能照着踩坑的笔记不少搞后端和嵌入式的朋友都有过这种体验shell 脚本跑得风生水起一到用 C 写守护进程或者多进程调度就开始被僵尸进程、短读短写、信号竞争整得头皮发麻。操作系统课上学过的 read、write、fork、pipe 落到生产环境每个原语都有脾气。这份 Linux 系统编程实战笔记本质上就是我平时排查系统故障时沉淀下来的操作集——不聊内核源码逐行注释只讲 open/mmap/fork/signal/IPC 里你一定会撞上的边界和参数。它的适用人群很明确写服务端中间件、做嵌入式 Linux、或者被线上 CPU 毛刺和 fd 泄漏折磨的系统工程师。跟着做一遍比翻三遍 APUE 更能救急。2. 文件 IO 的选型逻辑read/write 与 mmap 的边界到底在哪文件 IO 是系统编程最基本的肌肉训练。很多人一上来就 while 循环 read 到 EOF但真到了高并发或大文件场景read/write 和 mmap 的取舍能直接影响吞吐。这一章把两种方式的关键参数和坑位拆开讲。2.1 read/write 的短读与缓冲区别把返回值当摆设用 read 读文件时最常见的翻车是把返回值当成「期望长度」。read 不保证一次返回你要求的字节数这在管道、socket、信号打断时尤其明显。我一般会写一个 read_full 循环把缺口补齐#include unistd.h #include errno.h #include stddef.h /* 读满 nbytes 字节避免短读导致数据不完整 */ ssize_t read_full(int fd, void *buf, size_t nbytes) { size_t done 0; char *p (char *)buf; while (done nbytes) { ssize_t n read(fd, p done, nbytes - done); if (n 0) { if (errno EINTR) /* 被信号打断直接重试 */ continue; return -1; } if (n 0) /* EOF返回实际读到的量 */ break; done (size_t)n; } return (ssize_t)done; }这段代码的逻辑核心是两点第一EINTR时 read 会带着errno返回 -1但没有消费任何数据所以continue重试是安全做法第二n 0表示文件结束这时不能继续追读否则就是死循环。参数上需要注意fd必须是非阻塞或阻塞模式下都能用的普通描述符如果O_NONBLOCK已置位EINTR之外还可能出现EAGAIN那就要交给上层事件循环去等就绪。基于同样逻辑写也要封装一层write_full。另外一个和缓冲区直接相关的参数是st_blksize。用stat查出来的这个值通常跟文件系统块大小一致比如 ext4 是 4096。把用户态 buffer 设为这个值的整数倍read/write 拷贝次数最少能省掉不少内核与用户空间之间的往返开销。这个倍数关系属于系统编程里最容易被忽略的宽字节优化不是什么玄学是实打实在/usr/bin/time的 user time 里看得到的差异。2.2 mmap 不是银弹页对齐、MAP_SHARED 与 SIGBUSmmap 把文件映射进进程地址空间省掉了 read/write 的用户态拷贝大文件顺序读时确实香。但它的要求更苛刻。最常见的坑是offset必须按页大小对齐通常是 4096否则mmap直接返回EINVAL。下面这段是把文件内容映射后按 64KB 块写校验和#include sys/mman.h #include sys/stat.h #include fcntl.h #include stdint.h #include unistd.h int verify_file_checksum(const char *path) { int fd open(path, O_RDONLY); if (fd 0) return -1; struct stat st; if (fstat(fd, st) 0) { close(fd); return -1; } size_t len (size_t)st.st_size; uint8_t *map mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0); close(fd); /* 映射建立后即可关闭 fd */ if (map MAP_FAILED) return -1; uint64_t sum 0; for (size_t i 0; i len; i 65536) { /* 按 64KB 分块累加 */ size_t chunk (len - i) 65536 ? 65536 : (len - i); for (size_t j 0; j chunk; j) sum map[i j]; } munmap(map, len); return (int)(sum 0xffffffff); }这段代码的参数说明MAP_PRIVATE适合只读校验如果业务要写回文件就得用MAP_SHARED而且要在msync之前确认没有其他进程同时修改同一区域mmap之后立刻close(fd)是合法且推荐的页表已经建立fd 只是句柄而已。边界坑在于len必须是正数空文件映射长度 0 会导致EINVAL这是空文件场景下一定会撞上的问题。更危险的是如果文件在被映射期间被别的进程ftruncate截短后面访问超出新长度的页会触发SIGBUS整个进程当场崩掉。所以生产环境下 mmap 大文件我一般会配合文件锁或F_SETLEASE防止别人把文件改短宁可加锁也不赌它不动。关于选型经验值是文件小于 4KB 或者需要频繁小写用 read/write 反而更快读几百 MB 以上的大文件、或者做共享内存管理mmap 优势明显。这个阈值不是拍脑袋perf stat对比一下 syscall 次数和 minor page fault 数你自己就能画出那条分界线。3. 进程管理不翻车fork 与信号处理的落地姿势进程管理这一章论坛上的讨论永远是热度最高的——因为它直接嵌着 linux 底层原理的关键机制写时复制、僵尸进程、信号异步安全。这块做不对线上程序不是 CPU 100% 就是进程消失得莫名其妙。3.1 fork 与 exec 的边界僵尸进程和 fd 继承fork之后子进程在exec之前是和父进程共享代码段的完整副本。写时复制COW保证的是物理内存不立即复制但文件描述符表是直接继承的。这就带出两个经典事故fd 泄漏和僵尸进程。看下面这段防护性写法#include sys/wait.h #include unistd.h #include stdio.h #include fcntl.h pid_t spawn_worker(const char *path) { pid_t pid fork(); if (pid 0) return -1; if (pid 0) { /* 子进程关闭不需要的 fd再执行真正的业务 */ close(0); /* 标准输入按需重定向到 /dev/null */ int nullfd open(/dev/null, O_RDWR); dup2(nullfd, 0); close(nullfd); execl(path, path, --worker, (char *)NULL); perror(execl); /* exec 失败只能靠退出码通知父进程 */ _exit(127); } /* 父进程立即记录 pid后续统一 waitpid 收割 */ return pid; }这段代码解决的是两个具体问题。子进程里如果直接调用业务代码而不是exec那么父进程打开过的所有 fd 全都带进了子进程数据库连接、监听 socket 全部被继承一旦用户态程序 fork 后不 exec就等着 fd 被一个个耗尽吧。所以我的习惯是子进程路径上尽早exec把这个隐形的继承链掐断。第二个问题是收割每次fork出来的子进程退出后不会自动消失要父进程waitpid才能回收它的退出状态。如果父进程先退出、子进程变成孤儿进程会被 init 收养但如果是父进程常驻而没有waitpid这个进程就永久变成defunct僵尸占着 PID 和 task_struct 直到父进程退出。尤其在高频 fork 的调度器里僵尸堆积会让 pid 空间直接爆掉。3.2 信号处理的 async-signal-safe别在 handler 里写日志信号是系统编程里另一大「黑匣子」。信号处理函数可能发生在主线程的任何一条指令边界它调用的函数必须满足 async-signal-safe。很多人第一个念头是「我就打印个日志」然后fprintf在内部加锁或调用malloc一旦主线程正好持锁就直接死锁或堆损坏。正确姿势是把信号转成字节写进一个自管管道主线程从管道读。这就是经典的 self-pipe trick#include signal.h #include unistd.h #include stdatomic.h static int sig_pipe[2]; static volatile sig_atomic_t g_sig_count 0; void sig_handler(int signo) { (void)signo; unsigned char ch 1; g_sig_count; /* sig_atomic_t 保证原子读写 */ ssize_t unused write(sig_pipe[1], ch, 1); /* 管道写是 async-signal-safe */ (void)unused; } int init_signal_handling(void) { if (pipe(sig_pipe) 0) return -1; struct sigaction sa; sa.sa_handler sig_handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; /* 让 read/write 被信号打断后自动重启 */ if (sigaction(SIGTERM, sa, NULL) 0) return -1; if (sigaction(SIGINT, sa, NULL) 0) return -1; return 0; }这段代码里参数含义很关键。SA_RESTART表示被这个信号打断的read、write、ioctl等慢系统调用在内核里自动重启不会返回EINTR——但注意socket上的connect和poll不受SA_RESTART保护所以线上程序里这两个调用照样要手写EINTR分支。sigemptyset清空阻塞集合防止 handler 执行时嵌套进新信号。管道写操作在信号上下文是安全的但write也可能被打断所以返回值忽略前要把变量赋给unused避免编译告警。主线程侧用epoll或select等管道可读然后读出来就知道收到了几个信号。这比 handler 里凑sigqueue传数据安全得多也是我所有常驻进程的统一入口。信号还有一个让人头疼的点是fork以后 handler 会继承。子进程如果不重新设置父进程定制的 signal handler 就会被带到exec之前。因为exec会重置 handler 为默认动作所以问题的突破口还是尽早exec。另外 SIGCHLD 的处理我一般设在父进程在SA_NOCLDSTOP之外配合waitpid(-1, NULL, WNOHANG)循环收割这样就能把所有子进程的退出事件收敛到一个信号里避免一次一个 waitpid 漏掉多个退出子进程。4. 进程间通信的取舍管道、共享内存与锁的正确用法Linux 系统编程里进程间通信是最容易写出「看起来对、跑起来随机挂」的一类代码。这一章不是概念回顾是给你一杆秤什么场景用管道、什么场景用共享内存以及锁放哪个位置才不出事。4.1 socketpair 与 pipe啥时候用哪个pipe 是半双工的数据只往一个方向流子进程从 stdin 读、往 stdout 写这种模型够用。但一旦父子进程要互相问答就得建两根 pipe或者干脆上socketpair(AF_UNIX, SOCK_STREAM)。socketpair 返回两个相连的描述符全双工而且语义走的是流式 socket有read返回 0 的半关闭状态有EAGAIN的非阻塞节奏行为比 pipe 更成熟。下面是典型的事件通知通道#include sys/socket.h #include unistd.h #include stdio.h #include errno.h int create_event_channel(int *read_fd, int *write_fd) { int sv[2]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) 0) return -1; /* 两端都设置非阻塞避免事件循环被一个卡住的读拖死 */ for (int i 0; i 2; i) { int flags fcntl(sv[i], F_GETFL, 0); fcntl(sv[i], F_SETFL, flags | O_NONBLOCK); } *read_fd sv[0]; *write_fd sv[1]; return 0; }参数和逻辑说明AF_UNIX只在本机内核里走不经过协议栈延迟和 CPU 开销都低SOCK_STREAM保证有序字节流通知消息不会被拆乱。注意 socketpair 创建的 socket 不像 TCP 有SIGPIPE的默认凶狠动作——不对它照样触发SIGPIPE如果对端已经关闭write会返回EPIPE并默认终止进程。所以生产代码里要么在send/write外层屏蔽SIGPIPE要么把MSG_NOSIGNAL标志给到send否则一个小小的事件通道就能把整个守护进程带走。管道的 64KB 内核缓冲也是需要记住的边界。写端如果一直写而读端不及时读write会阻塞到缓冲满非阻塞模式下则返回EAGAIN。事件通知场景下的任务是「宁可丢一次通知、不能丢一个状态」。所以我在事件 fd 里传语义而不是传数据一条消息只表示「有事发生」具体状态放在共享内存里由读进程去取。这样即使多条信号合并成一条事件业务状态也不会丢失。4.2 共享内存与锁把并发写摁在初始化阶段共享内存是最高效的 IPC但也最危险。Linux 下推荐 POSIX 共享内存shm_open配mmap共享和sem_t同步。有很多教程教你把sem_t直接放在共享内存头部这没问题但初始化时机必须赶在所有进程 attach 之前。看下面的初始化片段#include fcntl.h #include sys/mman.h #include semaphore.h #include stdio.h #define SHM_NAME /my_shm #define SHM_SIZE 4096 typedef struct { sem_t lock; /* 放在共享内存的第一个字段 */ int counter; char buf[256]; } shared_block; shared_block *create_or_attach_shm(void) { int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0660); if (fd 0) { perror(shm_open); return NULL; } if (ftruncate(fd, SHM_SIZE) 0) { perror(ftruncate); return NULL; } shared_block *p mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); close(fd); if (p MAP_FAILED) { perror(mmap); return NULL; } return p; }初始化时的坑有两个。ftruncate必须在 mmap 之前做否则映射长度 0mmap直接EINVAL。semaphore 的初始化要区分情况第一个创建共享内存的进程负责sem_init(p-lock, 1, 1)但sem_init时的 pshared 参数必须传非 0且要保证其他进程在 sem_init 完成前不要访问这块内存——常见做法是再配合一个pthread_once或文件锁来做「谁先创建谁初始化」的仲裁。如果你不想自己判断谁是第一个也可以在 shm_open 成功后先flock一个目录锁文件初始化完锁再释放避开竞争。共享内存加锁之后最容易被忽视的是sem_wait会被信号打断返回EINTR。很多人写 while(true) { sem_wait(p-lock); } 然后就等着死锁——信号一来sem_wait返回 -1锁没拿到下一轮直接sem_post把别人锁给解开互斥彻底失效。规范写法是循环判sem_wait返回值和errnoEINTR才继续重试。这个毛病我见过不止一次线上进程随机出现两次并发写同一块 buffer查到最后都是这里缺了重试。5. 避坑指南五个系统编程常见问题的定位与修复这一章等于我的血泪台账。每一条都是从线上告警或故障复盘里筛出来的不搞理论推演。按「现象 → 原因 → 解决」写对照你自己的代码排查就行。5.1 现象fork 之后新程序莫名占用旧 fd原因fork继承整个 fd 表没有O_CLOEXEC标志的 fd 在exec成功后依然打开。比如父进程的日志文件 fd3子进程跑的是第三方客户端客户端里用 fd3 去写 socket就直接把日志文件内容冲坏了。解决open时统一带上O_CLOEXEC。对代码里已有的现成 fd用fcntl(fd, F_SETFD, FD_CLOEXEC)补上。我的习惯是封装一个open_clean(char *path)的 lib所有内部 open/socket 都从这里走强制O_CLOEXEC。从那以后这类「幽灵 fd」的事故频率直接降为零。5.2 现象读管道数据总是缺最后一段原因read 在管道对端关闭前如果返回n 0并不代表消息边界而很多程序只在n 0时判断 EOF忽略了短读时还有更多数据在缓冲里。一旦消息超过 PIPE_BUF就被 read 切成两半业务拿半截消息直接解析就崩。解决用自封装read_full按消息长度循环读读满一条消息的长度再进解析。对变长消息先读 4 字节的 big-endian 长度头再按长度读 body。如果你不想改协议至少在 read 循环里把EINTR和n sizeof(header)的情况都处理掉。这个习惯能救下八成管道乱序 bug。5.3 现象多线程进程 fork 后子进程在 printf 卡死原因fork只复制调用线程其他线程持有的锁状态会变成永久上锁。子进程里如果printf走了stdout的锁而那个锁恰好是被另一个已消失的线程持着的子进程就死在 libc 内部。解决最稳妥的是子进程在fork返回后立刻exec否则不碰任何非 async-signal-safe 的函数。如果架构要求在子进程中继续跑逻辑那就注册pthread_atfork的 prepare/parent/child 三个回调在 child 回调里把全局锁重新初始化一遍。这属于低概率高破坏力的坑架构评审的时候我一定要过一遍。5.4 现象程序退出时端口依然被占但 lsof 显示已无进程原因socket fd 没有关闭干净在 fork 出的孤儿子进程里仍持有监听 socket或者已经close但 TCP TIME_WAIT 还没走完SO_REUSEADDR没设置导致 bind 失败。解决监听 socket 一律加SO_REUSEADDRfd 统一走 RAII 封装进程退出前显式close所有 fd。排测时用ss -srcn看 TIME_WAIT 统计正常值应该小于几百如果掉不下来就查代码里有没有 fork 后没 exec 的 io 线程。5.5 现象mmap 的大文件读着读着就 SIGBUS原因文件被另一个进程ftruncate截短。mmap 建立的是映射关系不是快照文件长度一旦比映射区域小访问超出的页面会直接触发总线错误信号。解决映射前记录文件真实大小每次读之前用fstat或statx复核当前st_size同时用fcntl设置共享锁防止写端在业务进行中截短文件。如果实在无法加锁就要注册SIGBUShandlerhandler 里只能_exit或longjmp然后在上层入口判断访问范围是否重新映射。我评估过不少方案最后选择了「读之前校验文件大小 控制写端不可截断」作为标准实践这个组合最简单也最不易裂开。6. 用 strace 给系统调用做体检一次内核交互的完整复盘系统编程调到最后心里没底我都会把 strace 拉出来做一轮内核态回归。它能看到进程到底跟内核说了什么、谁在失败、失败是什么错误码。下面这套命令是我每季度对线上常驻进程必跑的体检项目。# 跟踪文件、进程、网络相关系统调用带时间戳和耗时 strace -ff -tt -T -yy -e tracefile,process,network \ -o /tmp/trace_$(date %F).log ./your_daemon # 只看错误快速定位哪一步在返回 EAGAIN/EBADF strace -f -e tracedesc -Z ./your_daemon 21 | grep -B 5 -1 # 故障注入模拟第 3 次 write 时 I/O 失败验证业务重试逻辑 strace -e injectwrite:errorEIO:when3 -e tracewrite ./your_daemon逐条解读一下参数。-ff表示跟随 fork/exec给每个子进程生成独立日志-tt打印微秒级时间戳-T输出每个 syscall 的耗时这两项合起来就能把 CPU 毛刺定位到具体是read还是poll-yy会解析 fd 对应的文件路径或 socket 四元组日志里直接看到write(3/etc/passwd)不用再用 lsof 反查。-Z是最新版本 strace 保留成功的 syscall 但只显示出错的部分适合长时间压测时只刷错误。故障注入-e inject...则是我验证重试逻辑的魔法比如故意让某次写失败看代码是立刻重试还是错误地当作成功处理。这一轮复盘会让很多「永远不重现」的问题露出狐狸尾巴。比如某次线上延迟陡增strace 显示 epoll_wait 返回了巨大的 timeout 值说明有进程忘了设置非阻塞又比如某个「正常退出」的程序 trace 里最后是close(-1)立刻暴露出 fd 变量被意外置负号。每次跑完我看的不只是错误列表而是调用序列是否符合预期顺序open 完是否有对应 closefork 后子进程第一桩事是不是 execsocket 有没有监听后忘记 accept。从那以后我每次上线系统程序都强制走一遍strace -ff -tt -T -yy不是不信任单元测试是内核交互的坑真的只有盯着调用序列才看得见。你可以从这一套命令开始把你手头那个「时好时坏」的守护进程拉出来做一次体检结果多半会让你吓一跳。希望帮到你。本文还有配套的精品资源点击获取