简介：这是一份面向高校操作系统课程学习者的C语言实验源码包，聚焦进程管理、内存管理、调度算法、文件系统、设备驱动与系统调用等核心主题，适合配套理论课或课后实操练习使用。压缩包内共12个文件，包含5个C源文件、5个txt说明文件，以及README.md与.gitignore；各lab目录下的main.c和CMakeLists.txt构成可编译的实验框架，txt文件则用于记录实验现象或补充说明，整体约8KB，结构紧凑。包内lab2至lab6覆盖多组典型实验任务，C语言直接操作内存与进程接口，有助于理解底层实现机制，也可作为自主扩展实验的起点。已有96人学习下载，适合希望结合代码验证操作系统原理、提升系统级编程能力的初学者。
1. OS_labs到底在练什么：一上来就懵是常态
记得我第一次打开OS_labs的实验文档时，整个人是蒙的。课堂上老师讲进程调度，PPT上画了几个状态框，箭头标得清清楚楚，我觉得自己懂了。结果实验要求是“实现一个支持抢占式优先级调度的进程模拟器”，我盯着屏幕看了半小时，发现连“进程控制块里到底该放哪些字段”都想不明白。
这不是我一个人的问题。带过几届学弟学妹之后，我越发确定一件事：操作系统实验课是计算机专业里理论和实践落差最大的一门课。数据结构课你写个链表，和课堂讲的差不了太远；但操作系统不一样，课堂讲的是抽象模型，实验要的是在一个真实（或半真实）的环境里处理资源竞争、时间片轮转、内存越界、并发冲突。这中间的沟，比想象中大得多。
这篇文章就是写给正在被OS_labs折磨的人看的。不管你是本科在读、准备考研复试，还是工作后想补操作系统这块短板，我都尽量把实验里真正重要的东西讲透：每个经典实验背后的核心难点是什么、环境工具怎么选、踩坑之后怎么排查、以及怎么从“把实验跑通”进阶到“把实验吃透”。我会用自己的亲身经历和踩过的坑来展开，尽量不说废话。
2. 五个经典实验主题，每个背后都藏着一道坎
2.1 进程调度：不是把算法抄上去就完事
进程调度通常是最早接触的实验。常见要求是实现FCFS、SJF、RR、优先级调度，输入一批进程的到达时间和服务时间，输出完成时间、周转时间、带权周转时间。很多人的做法是：把书上的C代码改一改，跑通样例，完事。
但这里有个被忽略的关键点：调度器是在“进程到来”这个动态过程中做决定的，不是把所有进程读进来再统一排序。SJF在静态模型里就是按服务时间排个序，但在动态模型里，你需要维护一个“当前已到达但未执行”的队列，每个时刻决定下一个执行谁。很多人的实现其实做成了离线排序，遇到“进程还没到但队列空了”的情况就处理错了。
我推荐的做法是走事件驱动：维护一个当前时间，循环里先处理所有到达时间小于等于当前时间的进程，把它们放入就绪队列，再从就绪队列里挑一个执行。这样写出来的调度器，换算法时只需要改“挑选逻辑”那一小块，FCFS就是取队头，SJF就是在就绪队列里找服务时间最短的，RR就是队头执行完一个时间片再挂到队尾。
另外务必理解周转时间和带权周转时间为什么重要。它们衡量的是一个调度策略的“整体效率”和“对短作业是否友好”，这两个指标能帮你解释为什么SJF的平均周转时间最优，但会导致长作业饥饿。实验报告里如果能写清楚这些，比单纯贴代码高一个档次。
2.2 同步互斥：最难的其实是“想清楚”
生产者消费者、读者写者、哲学家进餐，这三个经典同步问题几乎必考。这里最大的坎不是信号量怎么调，而是你根本说不清“谁在等谁”。
以生产者消费者为例，缓冲区满时生产者要等，空时消费者要等。很多人写出的代码在单生产者单消费者下没问题，一换成多生产者多消费者就出数据竞争。原因往往是：把对缓冲区的操作分成了“判断有没有空位”和“写入数据”两步，中间没有加锁。你得明白，信号量解决的是能力约束（空位数量、数据数量），互斥锁解决的是临界区保护（缓冲区的数据结构本身），两者职责不同，缺一不可。
我的建议是：写这类实验前，先画出“每个线程在哪些时刻会阻塞、被谁唤醒”的状态图，再把对共享数据的每一步访问都标出来。我自己就吃过亏：写读者写者问题时，以为是写者优先，实际跑出来是读者一直抢占，写者活活饿死。后来在代码里给写者加了一个“等待写者计数”信号量才解决。这个问题的本质是“优先级反转”的一个变种，理解一次，后面看真实系统的读写锁实现都会轻松很多。
2.3 内存管理：地址空间是最抽象的敌人
内存管理实验一般有两种形式：一种是模拟页式存储管理，实现FIFO、LRU、Clock等页面置换算法并统计缺页率；另一种是模拟内存分配，实现首次适配、最佳适配、最坏适配并展示空闲分区变化。
如果是页面置换算法，核心难点在于维护“页的访问历史”。LRU看上去简单——每次访问把页移到链表头，淘汰链表尾——但如果你用数组实现，每访问一次就要扫描一遍，复杂度是O(n)。实验通常不要求高性能，但你应该意识到真实系统里LRU的代价太高，所以才会有Clock算法（近似LRU）的出现。这就是一个很好的“实验通向真实系统”的切入点。
如果是内存分配模拟，真正的坑在于碎片问题。首次适配会产生大量外部碎片，最佳适配会产生大量难以利用的小碎片。你会在实验里直观地看到：明明总空闲内存够，但一个大作业就是分配不进来。这个体验是很宝贵的，因为现代操作系统的伙伴系统、slab分配器，本质上都是在解决“碎片和分配效率”的平衡问题。
2.4 文件系统与磁盘调度：别小看“模拟”
文件系统实验通常是模拟一个简单的文件系统：磁盘块管理、目录结构、文件分配表。不少同学觉得这题“最没技术含量”，写个FAT表模拟一下就完了。但实际上它的难度在于数据结构的组织。
比如模拟FAT表时，你要决定：是用数组模拟一个“每个表项存下一块地址”的链表结构，还是直接用一个“文件id到块列表”的映射表。前者更接近真实FAT32的设计，后者更像inode的思路。如果你能在实验文档里说清楚你选了哪种、为什么选这个、各自的优缺点是什么，这个实验才算真正做到位了。
磁盘调度（先来先服务、最短寻道时间优先、SCAN、C-SCAN）相对简单，但它隐含的知识点很重要：磁盘的访问瓶颈是寻道时间，调度算法的目标不是“公平”而是“减少机械移动”。我会做一个额外的实验：给不同调度算法喂同一组随机请求序列，统计总寻道距离，你会发现SSTF的平均寻道距离最短但远距离请求会饿死，而SCAN的饿死问题就小得多。
2.5 写一个迷你Shell：这题最接近真实工作
有些学校会安排Shell实验：实现一个支持后台运行、管道、重定向、环境变量的简易命令行解释器。这题给我的感觉是“最不像实验的实验”，因为它直接对应了你日后在Linux下写工具时要面对的真实问题。
核心难点在于进程创建与进程间通信的组合使用。你要用fork创建子进程，用exec族函数替换子进程映像，用pipe建立管道，用dup2重定向标准输入输出。很多同学在这里突然发现：课堂上讲了几节课的“进程地址空间”“文件描述符表”，原来在Shell里是这么用的。一个简单的ls | grep txt，背后是两次fork、一个管道、两次dup2，这种“原来如此”的震撼感，是其他实验给不了的。
写这个实验时我建议你采用“分阶段推进”的办法：先支持不带参数的外部命令，再支持内置命令（cd、exit、export），然后加管道，最后加重定向。每加一个功能就单独测试，别一上来就写一个两百行的parse函数，否则出bug时根本不知道问题出在解析层还是执行层。
3. 实验环境与工具链：选对工具能省一半时间
3.1 语言选择：为什么推荐C而不是Java或者Python
很多学校允许学生自选语言做OS实验。我的强烈建议是：只要实验要求是“贴近操作系统机制”的，就用C。为什么？因为操作系统实验的核心对象是进程、文件描述符、内存地址、信号量，这些概念在C里有直接的一一对应。你可以说“我创建了一个子进程”，然后代码里就真的有一个fork()返回了PID；你可以说“这块内存是共享的”，然后代码里就真的有一个mmap。这种对应关系会帮助你建立非常扎实的心智模型。
用Java写进程调度模拟没有不行，但那种“创建Thread对象”的体验，和你真正见到一个进程实体的感觉是完全不同的。Python更不用说，os.fork()虽然存在，但很多人在Python里写实验，写着写着就变成“用Python模拟操作系统”，而不是“在操作系统之上做实验”。这两者的区别，等找工作面试被问到“你怎么理解进程”时，你会特别感谢当年用C写过的那些实验。
3.2 调试工具：gdb和valgrind是救命稻草
OS实验里最让人崩溃的问题类型，大概是“段错误”和“内存泄漏”。前者表现为程序直接崩掉，后者表现为程序跑完内存占用一直涨。这两种问题，靠printf大法虽然也能定位，但效率太低，我强烈建议你尽早学会用工具。
gdb的用法不需要记太多，掌握这几条就够用了：break设置断点、run启动、bt查看调用栈、print打印变量、next和step控制单步。遇到段错误时，最有效的做法是“run之后直接看bt”，它会直接告诉你崩溃在哪个函数哪一行。我在做内存管理实验时，一个链表指针写错导致的崩溃，就是靠bt定位到的。
valgrind主要是查内存问题。valgrind --leak-check=full ./your_program，它会报告每一块泄漏的内存是在哪一行分配的。虽然输出很长很吓人，但你只需要关心“definitely lost”和“invalid read/write”这两个关键字。前者说明你没释放，后者说明你访问了不该访问的内存——这两种bug在文件系统和内存管理实验里特别常见。
3.3 版本管理：实验代码也要好好管理
这一点可能听起来像废话，但我见过太多人一个文件夹里塞着final.c、final2.c、final_final.c。OS实验的代码迭代非常频繁，尤其是当你尝试不同的调度算法、不同的内存分配策略时，经常需要回退到之前能跑的版本。
用git管理实验代码，每个功能点一个commit，写上“实现了FCFS调度”“修复了就绪队列为空时的死循环”这类信息，效果远好于Ctrl+S另存为。而且当你调了一晚上没调通，第二天想看看昨晚改了什么时，git diff能帮你快速恢复记忆。这不是浪费时间，这是在给你自己的排查过程留后路。
4. 那些年我踩过的坑，以及一套可复用的排查思路
4.1 经典坑一：内存越界，症状出现在“别的地方”
我不止一次遇到过这种情况：代码看起来完全没有问题，但程序跑着跑着，某个变量的值莫名其妙变成了一个巨大的数字。用gdb调试，单步执行每一行都正常，但一跑完整程序就出错。
这种“玄学问题”十有八九是堆内存越界。比如你malloc了一个大小为10的数组，却写到了第11个位置。越界写入不一定立刻崩溃，它可能悄悄破坏了下一次malloc返回的内存块头部的元数据，导致系统在free或者调用printf时突然爆炸。症状和原因分离，这是内存类bug最折磨人的地方。
我的排查建议是：先把所有数组访问都检查一遍边界，特别是循环条件里的<=和<。然后直接上valgrind，它会精确告诉你“第12行写入了1个字节，但这个内存块只有10字节”。说实话，当年我要是第一天就学会用valgrind，至少能省三个通宵。
4.2 经典坑二：并发程序里用了共享变量，没有同步
同步实验里最容易犯的错是：觉得“只要我在关键操作前后加了锁就够了”，但实际上只保护了一部分。比如这样一个场景：生产者线程往缓冲区写入前检查一下“当前数量是否小于上限”，检查完准备加锁，结果另一个线程抢先写入了，当前数量变成满的，但第一个线程的判断结果已经过期，于是两个线程同时写同一个槽位。
这类bug的可怕之处在于：它不是每次都触发，只有两个线程正好在同一时刻遇到临界区边界时才会出问题。你跑十次可能九次是对的，唯一错的那次刚好赶上评测。对于这种问题，我的经验是：把所有对共享状态的访问，不管是读还是写，都放进同一个临界区，不要想当然地认为“我只看一眼数值应该没事”。
4.3 一套可复用的四步排查链路
踩了足够多的坑之后，我总结出一套排查流程，每次遇到诡异问题都按这个顺序来：
- 复现和缩小：想办法让bug稳定复现，然后通过注释代码、更换测试用例，把出问题的范围缩到最小。比如调度实验出bug，先固定输入数据，再用最简单的两个进程测试。
- 看崩溃位置：如果程序崩溃了，先跑gdb看调用栈，不要瞎猜。如果没崩溃但结果错，就先检查“数据是否按预期被更新了”，用一个极小的用例手工算一遍期望结果，再对比程序输出。
- 查内存问题：用valgrind跑一遍，重点关注“invalid read/write”和“definitely lost”。
- 加日志复跑：如果以上都没定位到，就在关键路径上加日志，打上时间戳和关键变量的值。注意日志要“有信息量”，不要只打“进入函数”，要打出每次调度时选中的进程PID和当前时间、队列长之类能帮助反推过程的数据。
这套流程不能解决所有问题，但它能帮你把“瞎试”变成“系统排查”。我觉得操作系统实验里最值得带走的能力，其实不是某个算法的实现，而是这套面对复杂系统问题时保持头脑清晰的方法。
5. 从“做完实验”到“吃透实验”的进阶心法
5.1 实验里的简化，恰恰是理解真实系统的入口
写完页面置换算法实验后，我问过自己一个问题：真实操作系统真的用LRU吗？答案是：不用纯LRU，Linux用的是类似Clock的改进算法，还考虑了进程的访问频率。那实验的意义何在？意义在于——它让你亲手体验到了“LRU听起来很美，实现代价很高”这个矛盾。没有亲手统计过缺页率，你不会理解为什么工程师要做那么多妥协。
用同样的视角看其他实验：你在调度实验里感受到的饥饿问题，在真实Linux的CFS调度器里有对应的解决办法（虚拟运行时间、红黑树）；你在内存分配实验里感受到的碎片问题，在伙伴系统里就是“按2的幂次拆分块，合并时再合并相邻块”。实验是真实系统的“慢动作回放”，你把它看清了，再去看真实系统的代码或文档，就不会觉得那些复杂机制是凭空冒出来的。
5.2 我给自己的一个额外作业：读一份真实源码
做完实验后，给自己留一个进阶作业：去读一段真实操作系统的源码。不需要读完整的Linux内核，只需要聚焦一个点。比如，读一下Linux内核里进程调度相关的核心数据结构（task_struct里的调度字段、CFS就绪队列结构），或者看一个简化版内核的教学项目（比如xv6）里的proc.c和sched相关代码。
xv6其实是很适合做OS实验之后进阶阅读的：它只有一万多行代码，但包含了进程、内存、文件系统、锁的完整实现。你实验里模拟过的东西，在xv6里都是“真材实料”的代码。我第一次打开xv6的sched函数时，看到那种“一个CPU上只有一个进程在跑、切换时保存上下文”的写法，才真的把课堂上的“进程切换”四个字变成了脑子里的一幅画面。
5.3 实验报告怎么写才算没白做
最后聊一个现实问题：很多学校的OS实验要交报告。不少人的报告就是贴代码加运行截图，老师看一眼就给分。但我觉得，报告是对自己思考的一次整理。我会建议你在报告里重点写三块内容：一是“我遇到的难点”，二是“我怎么排查的”，三是“如果换一种设计会不会更好”。
“难点”不必写多高级，写真实过程就好，比如“在写SJF时忽略了新进程到达时间，导致就绪队列空了还要等，后来加了时间推进逻辑”。这种记录一段，价值远超一份完美贴代码的报告。因为等学期结束、知识淡忘之后，你回头看这篇报告，能想起当时是怎么思考的，这比任何分数都值钱。
本文还有配套的精品资源，点击获取
