未调用fork()时执行read系统调用是否会发生进程切换？

你这个疑问本质是两个前置认知存在偏差：

• 调用系统调用不等于一定会发生进程切换
• 就算你自己的代码里一行fork()都没写，系统里也绝不可能只运行你写的这一个进程

先讲系统调用的基本逻辑 #

系统调用的本质是用户态程序没有权限执行特权操作，主动通过特殊指令触发陷入，从用户态（低权限级）切到内核态（高权限级）请内核帮忙干活的过程，整个流程的第一步只是CPU权限级别的切换，根本不是一进内核就必须把当前进程换下去。
举个最常见的例子：你调用read读一个之前已经读过、已经缓存在内存页缓存里的小文件，内核只需要在内核态把缓存里的数据拷贝到你提供的用户态缓冲区，干完活就会直接切回你进程的用户态继续执行后续代码，全程CPU上跑的都是你的进程，没有任何进程切换，自然不存在所谓的“进程B”。

再讲触发切换时的“进程B”到底是什么 #

只有当read碰到必须等待的场景时，才会发生进程切换：比如你要读的内容存在磁盘上还没加载进内存、读标准输入等用户敲键盘、读网络套接字等对端发数据，这时候内核会把当前进程标记为阻塞等待状态，暂时从CPU上换下来，再由调度器从系统全局的就绪进程队列里，挑一个已经准备好运行的进程上CPU执行，这个被选中的进程就是你说的“进程B”。

这个“进程B”和你有没有调用fork()没有任何关系：操作系统从启动完成开始，就已经运行着大量进程，包括1号init/systemd进程拉起的各类系统服务、你用来启动当前程序的Shell进程（它正阻塞等待你的程序退出）、内核负责磁盘IO、网络收发、内存回收的各类内核线程，这些进程只要处于就绪可运行状态，都可能被调度器选中，根本不需要你自己在代码里创建子进程。

额外补充 #

哪怕read本身不会触发阻塞等待，如果你的进程刚好耗尽了操作系统分配的CPU时间片，调度器也可能在系统调用返回前切到其他就绪进程运行，这时候被调度上来的进程同样属于你提到的“进程B”范畴。

内容的提问来源于stack exchange，提问作者Blue And Red