系统调用慢常因用户态阻塞或 strace 误判，真实内核处理仅微秒级；应优先聚合 i /o、合理设缓冲、慎用 mmap，并用 perf 而非 strace 精准分析。
系统调用太慢？先看是不是 strace 误判了开销
很多同学一看到 strace -T 里某个 read() 耗时 10ms，就认定是内核慢，其实大半时候是用户态阻塞或上下文切换拖的后腿。比如在阻塞 I/O 场景下，read() 看似“执行久”，实际是进程挂起等数据，真正内核处理可能只占微秒级。
实操建议：
- 用
perf record -e syscalls:sys_enter_read,syscalls:sys_exit_read区分进入 / 退出时间，比strace更准 - 检查是否真在等磁盘：对比
iostat -x 1中 %util 和 await，若 %util 接近 100% 且 await 高，问题在存储层，不是系统调用本身 - 注意
strace自身开销：它强制每次系统调用都 trap 到 tracer，单次调用耗时可能被放大 5–10 倍，不能直接当真实延迟
减少 write() 和 read() 调用次数比优化单次更快
系统调用本质是用户态到内核态的切换，固定成本约 100–500 纳秒（取决于 CPU 和内核版本），远高于 memcpy 或函数调用。频繁小尺寸读写（如每次 1 字节）会让切换开销彻底压倒实际工作。
实操建议：
- 用缓冲区聚合操作：C 里优先用
fread()/fwrite()（它们自带 FILE* 缓冲），而不是裸read()/write() - 对网络 socket，启用
TCP_NODELAY前先确认是否真需要低延迟；默认 Nagle 算法本就是为合并小包而生，盲目关掉反而增加系统调用频次 - 文件 I/O 场景下，用
posix_fadvise(fd, offset, len, POSIX_FADV_DONTNEED)主动丢弃已读缓存，避免下次read()触发 page fault 和锁竞争
epoll_wait() 返回后别急着挨个 read()
这是高并发服务最常踩的坑：epoll_wait() 告诉你 3 个 fd 就绪，结果代码立刻对每个 fd 调一次 read()，哪怕其中两个刚收到 1 字节。这不仅浪费系统调用，还可能因非阻塞 fd 返回 EAGAIN 白忙活。
实操建议：
- 对每个就绪 fd，用循环 +
read()直到返回EAGAIN或0（对 socket 是对端关闭），确保一次性收完当前所有可用数据 - 注意
read()的 size 参数：传太小（如 1024）会导致多次调用；传太大（如 1MB）可能触发内存分配或拷贝开销；推荐 8KB–64KB，兼顾 cache line 和常见报文大小 - 如果业务允许，考虑
recv(fd, buf, flags | MSG_DONTWAIT)替代非阻塞模式下的反复试探，减少条件分支
mmap() 替代 read() 不总是更快
很多人以为 mmap() 能绕过拷贝就一定赢，但实际中它引入了页错误、TLB 压力和更复杂的内存管理。尤其小文件或随机访问场景，mmap() 可能比 read()+malloc() 慢 2–3 倍。
实操建议：
- 顺序读大文件（>1MB）且后续会多次访问时，
mmap()才有优势；否则老实用read()+ 用户态 buffer - 务必用
MAP_POPULATE标志预加载页表，否则首次访问每页都触发缺页中断，延迟不可控 - 避免对普通文件用
MAP_SHARED写，除非真要同步到磁盘；多数场景MAP_PRIVATE更安全，也避免 writeback 带来的锁争用
系统调用性能不是单点优化问题，而是用户态缓冲策略、内核调度行为、硬件路径（比如 io_uring 出现后，部分场景可绕过传统 syscall 路径）共同作用的结果。最容易被忽略的是：你以为在优化系统调用，其实瓶颈早就在用户态锁、内存分配器或 CPU cache miss 里了。
