简介：这是一份面向操作系统课程学习者的C语言实验源码包，围绕进程管理、内存管理、调度算法、文件系统与系统调用等核心主题展开，适合计算机专业本科生或自学者在完成OS实验时参考对照。压缩包共12个文件，包含5个C源程序、5个txt文本说明、1个Markdown文档及.gitignore配置，整体大小仅8KB；各实验按独立模块组织，可快速定位到对应lab的源码与配套说明。目前已有96人学习下载。借助源码可直观理解fork、wait等系统调用用法，也可配合txt和Markdown中的讲解梳理调度、内存分配等算法的实现流程，对提升C语言底层编程能力和操作系统原理认知都有实际帮助。 做了这么多年操作系统相关的学习和技术分享，我一直觉得单纯刷书、背概念是低效的。操作系统这门课，真正的分水岭在于动手做实验，也就是常说的OS_labs这一类项目。它不是一个固定的开源仓库，而是一整套围绕操作系统原理的实践训练：从实现一个能执行命令的迷你 shell，到写进程调度、内存管理，再到搭一个简单文件系统，每一个 lab 都在逼你回答一个核心问题——操作系统到底是怎么跑起来的。
这篇文章适合正在上操作系统课的学生、准备面试的开发者，也包括想自底向上理解计算机系统的爱好者。我会把 OS 实验的体系、核心知识点、实操过程和踩坑记录全部拆开讲清楚，很多内容是我在实际调试中反复折腾出来的经验，文档里不会写。
1. OS_labs的核心思路：整个实验体系到底在练什么
1.1 经典实验体系的构成与能力目标
大多数操作系统实验课，无论采用哪种教学内核，实验清单都绕不开这几个方向：
- 进程与线程管理：实现 PCB、上下文切换、调度算法。
- 同步与互斥：信号量、锁、条件变量，解决生产者消费者等问题。
- 内存管理：地址空间布局、物理内存分配、页表操作、虚拟内存映射。
- 文件系统：inode、目录项、块管理、系统调用接口。
- 设备驱动：外设中断、键盘/磁盘等基础驱动。
这些实验看起来是零散的，但实际上是围绕一个内核把各个环节串起来的。我见过不少同学做 lab 时只盯着“这个函数怎么写”，忽略了实验之间的关联。比如你在做调度器实验时，如果没理解时钟中断和上下文切换，后面做内核线程就寸步难行；做内存分配时如果对页表不熟悉，后续加虚拟内存映射会被 segmentation fault 折磨到怀疑人生。
做这套实验的真正价值不是“把实验报告写满”，而是建立一个整体心智模型：CPU 怎么从用户态切到内核态、内核如何保存现场、内存如何从物理页变成进程地址空间、文件如何从磁盘块变成open/read/write的系统调用。这些概念在面试里被反复追问，但只有亲手调过、跑过、画过时序，才能真正给出令人信服的答案。
1.2 选择合适的教学内核与路线
自主实现一个完整的操作系统当然不现实，所以绝大多数 OS_labs 基于某个教学内核。最常见的几个选择：
| 内核/框架 | 特点 | 适合人群 |
|---|---|---|
| xv6 (MIT) | 代码量小、结构清晰，文档完善 | 初学者，适合通读源码后做扩展 |
| ucore (清华) | 中文文档丰富，实验由浅入深 | 中文学习者、课程配套 |
| Nachos | 用Java/C++模拟OS，上手快 | 偏软件工程、不想碰硬件的同学 |
| 自己从零搭 | 极度硬核，适合进阶 | 已经做过一轮完整实验的同学 |
我第一次做 OS_labs 用的就是基于 xv6 改的框架。理由很简单：代码量在 1 万行左右，能在几天内读完核心部分，但麻雀虽小五脏俱全，进程、锁、文件系统、驱动全都有，非常适合拿来练手。如果你已经有了一定基础，我建议不要止步于跑通实验，可以去改写调度算法、加一个系统调用、换一种内存分配策略，这些扩展才是真正的加分项。
2. 核心细节解析：实验里最容易卡住的几个技术点
2.1 进程与线程：PCB、上下文切换与调度
进程管理是所有 OS 实验的地基。你需要实现的第一个模块通常是 PCB（进程控制块），它本质上就是一个结构体，用来保存进程的运行状态。关键字段至少包括：
- 进程 ID、父进程 ID。
- 运行状态：就绪、运行、阻塞、退出。
- 保存的寄存器现场。
- 内核栈指针、用户栈指针。
- 调度相关信息：优先级、时间片剩余量。
一个非常容易犯的错误是：只保存了 CPU 的通用寄存器，忽略了对栈指针和程序计数器的维护。上下文切换的代码在 xv6 里叫swtch，它做的事情就是把当前 CPU 的寄存器保存到旧进程的 PCB，然后从新进程的 PCB 恢复寄存器。这里有一个很反直觉的地方——你不需要在切换函数里显式保存 PC，因为call指令已经把返回地址压到栈上了；你只需要保存栈指针，切换时自然就切到了正确的执行流。
调度算法的选择也容易让人纠结。时间片轮转（RR）是最基础也最容易实现的策略，核心就是维护一个就绪队列，每次时钟中断就把当前进程的剩余时间片减一，减到 0 就触发上下文切换。我做实验时写过多级反馈队列（MLFQ），效果更好，但代码复杂度明显上升，需要为每个优先级维护队列，还得处理优先级提升。我的建议是：先跑通 RR，理解整套切换流程，再考虑优化调度算法，否则你会在调试并发 bug 时彻底崩溃。
2.2 同步与互斥：信号量、锁与条件变量
同步实验是 OS_labs 里最容易暴露问题的地方，因为很多 bug 是间歇性出现的，甚至只在多核环境下复现。下面这段是我做生产者消费者实验时写的信号量实现简化版：
void sem_init(sem_t *s, int value) { s->count = value; s->lock = 0; // 用关中断或原子指令保护 wait_queue_init(&s->wait); } void sem_wait(sem_t *s) { disable_interrupts(); while (s->count <= 0) { // 当前进程进入等待队列并让出CPU enqueue(&s->wait, current_process); block_current(); } s->count--; enable_interrupts(); } void sem_signal(sem_t *s) { disable_interrupts(); s->count++; if (!wait_queue_empty(&s->wait)) { wakeup(dequeue(&s->wait)); } enable_interrupts(); }这个实现里有几个关键点值得展开。首先，对count的操作必须在关中断的保护下进行，否则两个进程在单核上可能因为时钟中断而交错执行，导致并发错误。其次，block_current之后enable_interrupts必须放在合适的位置，绝不能提前。我见过有人把开中断写在enqueue之后，结果进程还没来得及切换，另一个进程就进来了，直接把等待队列结构破坏了。
同步实验里最常见的问题是死锁。经典场景是两个进程各自持有一把锁，然后互相等待对方释放另一把锁。排查死锁没有捷径，唯一的办法是仔细画资源分配图，并且在做实验时就养成良好的加锁顺序规范——所有需要多把锁的地方，统一按相同顺序获取。我后面在第 4 节会详细写我怎么用一个死锁案例一步步定位和修复。
2.3 内存管理：物理页分配与地址空间
内存管理实验一般分两阶段。第一阶段是物理内存页分配器，第二阶段是虚拟内存与页表。第一阶段相对简单，常用的策略有：
- 首次适配算法：维护空闲链表，每次从头查找第一块足够大的内存。
- 伙伴算法：把内存按 2 的幂次拆分，分配和释放高效，碎片化少，但实现复杂度高。
- slab 分配器：专门针对内核对象复用，减少初始化和回收开销。
我在课程实验中首次实现的是最朴素的空闲链表分配器。核心数据结构就是一个双向链表，每个节点记录页数、起始地址和使用状态。分配时遍历链表找一块空闲页，释放时合并相邻空闲区间。这个实验虽然不算难，但它能帮你理解内存碎片化的本质：频繁分配和释放小块内存，会导致大块连续内存越来越少，最终明明有空余空间却分配不出一个大对象。
虚拟内存部分则是 OS 实验里的硬骨头。你需要理解分页机制：
- 虚拟地址如何通过多级页表翻译成物理地址。
- TLB 的作用和如何使失效。
- 缺页异常（page fault）的处理流程。
- 用户态和内核态的地址空间隔离。
我在做缺页异常实验时，遇到一个很经典的问题：用户程序访问未映射地址时，内核死循环打印 page fault，但不杀掉进程。后来发现是trap处理函数里没有检查异常地址所在区域，也没把错误码返回给用户态。正确的做法是：缺页异常发生后，判断异常地址是否在进程合法地址空间内，如果不在，直接释放进程并回收内存，而不是在那里反复重试。
2.4 文件系统：从磁盘块到系统调用
文件系统实验通常放在最后，因为它的知识点最综合：需要用到内存管理的 buffer cache、同步机制的锁、块设备驱动的读写接口，还要实现 inode、目录和路径解析。我在这个实验里最大的体会是：文件系统是一个典型的“倒着思考”的问题——应用层看到的是char *path和fd，而内核层要逐级解析目录，最终定位到一个磁盘块。理解了这一层，再看应用层的open()系统调用，瞬间豁然开朗。
3. 实操记录：把三个 lab 真正跑通的完整过程
3.1 实验环境与工具链配置
我建议无论如何都不要在裸机上直接做 OS_labs，除非你想天天按重启键。我用的是 QEMU 模拟器 + GCC 交叉编译链 + GDB，这套组合足够完成大部分实验：
# 安装依赖（Ubuntu/Debian 系） sudo apt install build-essential gdb qemu-system-x86如果是学校的实验框架，比如 xv6，官方仓库里一般会带 Makefile，直接make qemu就能启动。我第一次编译时就碰到工具链版本问题，xv6 原本的 Makefile 假设的是老版本的 gcc，后来我改用riscv64-unknown-elf-gcc（针对 RISC-V 版 xv6）就顺畅多了。这里想强调一个实操心得：不要一上来就手工敲命令，先读一遍 Makefile，搞清楚它到底调用了哪些工具，这能帮你避免很多环境问题。
3.2 Lab 1：实现一个支持管道和重定向的迷你 Shell
第一个实验通常是写一个简单的 shell，虽然它不是一个内核模块，但它能让你体会到“操作系统是给用户用的”这个视角。需求通常包括：
- 解析命令行，支持空格分隔的参数。
- 支持
cd、exit等内建命令。 - 支持标准输入输出重定向，以及管道
|。 - 支持后台运行
&。
我用 C 语言实现了一个约 300 行的 shell。核心逻辑并不复杂：主循环里用fork()创建子进程，子进程里调用execvp()执行程序，父进程用waitpid()等待子进程结束。管道处理的关键在于pipe()系统调用创建的文件描述符，以及dup2()重定向。
一段简化的管道处理代码：
int pid; int pipefd[2]; pipe(pipefd); pid = fork(); if (pid == 0) { // 子进程1：把标准输出重定向到管道写端 dup2(pipefd[1], STDOUT_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(build_cmd1[0], build_cmd1); } else { pid = fork(); if (pid == 0) { // 子进程2：把标准输入重定向到管道读端 dup2(pipefd[0], STDIN_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(build_cmd2[0], build_cmd2); } } close(pipefd[0]); close(pipefd[1]); wait(NULL);这个实验里最常见的错误是忘记关闭多余的 fd，尤其那些没有用到的读写端，如果不关闭，管道就不会因为所有写端关闭而收到 EOF，程序会一直阻塞。这做 OS_labs 的时候，我建议你每次dup2之后都仔细检查 fd 的打开和关闭情况。
3.3 Lab 2：添加一个系统调用
第二个实验是给内核添加一个系统调用。这个实验非常有价值，因为它强迫你把用户态、内核态、软中断和传参机制全部串起来。在 xv6 里，大致步骤是：
- 在
syscall.h中定义系统调用号。 - 在
syscall.c中添加系统调用处理函数。 - 实现内核态
sys_xxx函数，真正的逻辑写在这里。 - 在用户态
user.h中声明接口，并在usys.S中添加跳板代码。
我当时尝试添加了一个能获取进程运行时长的系统调用gettick()。用户态调用时会触发ecall或int 0x80，CPU 陷入内核态，通过系统调用号在分发表里找到sys_gettick，然后从内核维护的全局 tick 计数器读取值返回。
这个实验让我真正理解了“用户态不能直接访问内核数据”这句话。同理，如果你用 Python 写应用，直接调用os模块的接口，比如os.getpid()，它内部走的就是类似的系统调用路径。很多人在学习热词里提到的 Pythonos模块时，只把它当成“调文件操作的工具包”，其实它就是在封装操作系统抽象，和你能手写一个系统调用的理解完全在两层。做一遍 Lab 2，再看os模块，会有一种“原来如此”的感觉。
3.4 Lab 3：实现时间片轮转调度
第三个实验是实现一个可用的调度器。在基于 xv6 的实验里，系统已经默认带了 RR 调度，但实验要求往往不允许你直接使用现成的，而是让你理解并改写。我的实现思路是：
- 为每个进程维护
ticks和priority字段。 - 在
clock interrupt处理函数里，把当前进程的剩余时间片减 1。 - 如果剩余时间片为 0，设置一个标志，退出中断前触发一次真正的
yield()。
这里有一个特别值得提到的调试坑：中断处理函数在c语言层面会调用到yield()，但yield()最终要切换到另一个进程的上下文。如果你直接在中断上下文里调用schedule()，很容易在恢复寄存器时发生混乱，因为中断处理函数本身就有一套压栈/出栈流程。正确做法是用汇编跳板处理上下文切换，保证切换发生时，栈和寄存器状态是干净且可控的。我在第一次做这个实验时偷懒直接用 C 函数调，结果进程一多就黑屏，调试了两天才意识到是这个原因。
4. 常见问题与排查技巧实录
4.1 问题一：时钟中断不触发，调度失效
表现：进程一旦运行就独占 CPU，其他进程永远得不到执行。排查思路：
- 先确认中断控制器是否开启了时钟中断。
- 再确认
trap分发函数的向量表里是否注册了时钟中断处理逻辑。 - 最后确认时钟中断处理函数是否调用了
yield/schedule。
我踩过最隐蔽的一个坑是：时钟中断处理函数本身可以执行，但它清除了中断标志之后忘了重新开启，导致后续中断不再触发。用 GDB 看寄存器一眼就能发现IF标志位为 0，但如果不看寄存器，光靠阅读代码很难定位。给所有做实验的同学一个建议：遇到不可理喻的现象，第一件事不是盯着代码看，而是用调试器看寄存器和栈。
4.2 问题二：条件变量和信号量的并发竞态
表现：生产者消费者程序运行时，偶尔出现panic、卡死或数据不一致。这个问题一般在多核或者开启了抢占时才会出现。排查时我通常会在锁/信号量操作前后打印 CPU 进程 ID 和当前栈，形成日志后逐行分析。日志多了以后，可以用一个小脚本过滤关键事件：
dmesg | grep "acquire\|release\|signal" | tail -200从日志里看到最典型的问题就是同一个进程重复acquire了同一把锁，导致死锁。修复方法一般是检查锁的初始化，以及是否可能在同一个逻辑路径里没释放锁就返回了。
4.3 问题三：段错误反复出现且栈不干净
这个现象在写内核模块时很常见。原因可能是栈指针越界、未初始化局部变量、或内核栈溢出。我遇到过一个特别典型的案例：PCB 里分配的内核栈只有 4KB，而我在中断处理里调用了一个较深的函数链，结果直接爆栈，随机破坏附近内存。排查手段是用 GDB 查看返回地址和栈指针：
(gdb) bt (gdb) info registers rsp看到栈指针非常接近内核栈底部，就能确认是栈溢出。解决办法很简单：把内核栈从 4KB 扩大到 16KB，并检查所有alloca或大数组的使用。
4.4 实用调试经验一览
这些经验都是常规文档里不会写的，建议你在做实验时对照使用：
| 场景 | 工具/手段 | 心得 |
|---|---|---|
| 想知道某个内核变量变化 | GDB 断点 +print | 在关键路径上打断点，不要只看崩溃现场 |
| 上下文切换异常 | 打印 PCB 里的ra/sp | 切换前先打印，确定谁是被切换者 |
| 并发竞态 | 关中断/加锁后再打印 | 打印本身也会引发竞态，注意消除副作用 |
| 文件系统数据不一致 | fsck或自己写块级 dump | 先在 block 层做位图核对 |
| 内存越界 | AddressSanitizer 或mprotect守护页 | 内核实验里不如页表mprotect可靠 |
还需要提到的是，实验时我会频繁用assert和 panic 在关键不变式处，比如“持锁状态不能 sleep”“当前进程必须在就绪队列中”。这能让 bug 在最早的时刻暴露，而不是拖到系统崩溃才被察觉。这种经验放到工程开发里同样适用。
5. 实验之外的扩展思考
做完一轮 OS 实验，你会发现整个 OS 领域的基础知识被系统性地串起来了。这时候再去看各种新的 OS 项目、嵌入式 OS、云桌面系统、甚至某些手机厂商的内核魔改，你都不会觉得它是一个黑盒。最近我在看一些轻量级云桌面 OS 镜像方案，它们之所以能在瘦客户端上跑得流畅，本质上还是靠高效的进程调度、精简的内存管理和合理的驱动抽象，这些都是 OS_labs 里反复训练的东西。反过来，如果你想做嵌入式方向，比如研究 AUTOSAR OS 这类汽车软件标准里的操作系统规范，核心也在任务调度、资源管理和时间确定性，原理完全相通。
最后分享一个我自己的习惯：每完成一个 lab，我会在实验报告之外，用画图的方式把“用户态调用→系统调用→内核处理→返回用户态”的完整路径画一遍。画不出来就说明还有知识断层，画出来之后再回来看代码，会发现所有细节都串成了一条线。这种“从抽象到具体再回到抽象”的循环，是我觉得做 OS 实验最有价值的地方。
如果你正在做或者准备做 OS_labs，请务必记住：不要只求跑通，要敢于改写、敢于破坏并修复。只有当你亲眼看过系统崩溃、亲手定位过死锁、手动改对过栈帧，你才算真正迈过了这门课的门槛。
本文还有配套的精品资源，点击获取
