一次 write() 系统调用在现代 x86-64 Linux 上耗时 300–800 ns，约 60% 开销来自态切换本身，比用户态调用高 1–2 个数量级。
系统调用一次到底多贵？
不是“慢”，而是有明确的纳秒级开销：现代 x86-64 Linux 上一次 write() 系统调用，典型成本在 300–800 ns（不含实际 I/O），其中约 60% 花在态切换本身——保存用户寄存器、切换栈、验证参数、恢复上下文。这比纯用户态函数调用高 1–2 个数量级。
实操建议：
- 用
strace -T ./your_program直接看每个系统调用耗时，-T显示真实时间，不是估算 - 对比
write(fd, buf, 1)和write(fd, buf, 4096)：小量高频写会把切换开销放大数倍，而批量写几乎不增加切换次数 - 别信“一次系统调用无所谓”——高并发服务里每秒几万次切换，CPU 时间就悄悄被吃掉 5–10%
mmap 为什么能绕过切换？
mmap() 把文件直接映射进用户地址空间后，读写就像操作普通内存，不再触发 read()/write() 切换。但代价是：首次映射仍需一次系统调用，且页错误（page fault）时内核要介入加载数据——这不是“无切换”，而是把切换延迟到真正访问时，并可能合并多次访问。
容易踩的坑：
- 映射大文件后没
msync()就退出，修改可能丢失（尤其MAP_PRIVATE） -
MAP_POPULATE参数看似预加载能避免页错误，但会阻塞映射过程，反而拉长首次响应时间 - 小文件用
mmap反而更慢：映射/解映射开销 > 节省的切换收益
为什么 strace 会让程序变慢十倍？
strace 不是“只看不碰”，它通过 ptrace() 强制每个系统调用都陷入内核并通知 tracer 进程——相当于每次切换后多加一次完整上下文切换 + IPC 开销。真实开销常达原生的 5–15 倍，尤其对高频调用如 gettimeofday() 或 epoll_wait()。
替代方案更轻量：
- 查系统调用频次用
perf stat -e 'syscalls:sys_enter_*' ./app（开销低至 1–2%） - 定位热点系统调用用
perf record -e 'syscalls:sys_enter_write' -g ./app && perf report - 调试权限或路径问题，优先用
ls -l /proc/<pid>/fd</pid>看 fd 状态，而非全程strace
内核态耗时高 ≠ 切换太多
看到 top 中 %sy（内核态 CPU 使用率）飙升，第一反应不该是“减少系统调用”，而要区分：是切换太频繁（cs 高），还是单次内核工作太重（比如加密、压缩、复杂路由）？
快速判断方法：
- 运行
vmstat 1，观察cs（context switch）列：持续 > 50k/s 才算高频切换 - 用
pidstat -w 1看具体进程的cswch/s（自愿切换）和nvcswch/s（非自愿切换）：前者多说明频繁等资源（如锁、I/O），后者多才真可能是调度压力大 -
%sy高 +bi/bo（块设备 I/O）也高 → 大概率是磁盘驱动在内核里忙，不是你的代码切多了
真实成本藏在组合效应里：一次 sendfile() 看似一个系统调用，但它内部可能触发页锁定、DMA 设置、中断处理——这些都在内核态完成，却不额外增加“切换次数”。优化时盯住的是最终延迟和吞吐，不是单纯数 strace 输出的行数。
