简介一份面向高校操作系统课程学习者的山东大学实验资源内容覆盖进程控制、线程与管道通信、命令行解释器简易Shell设计以及理发店问题、抽烟者问题等经典同步互斥场景。资源共51个文件以源代码、头文件、构建脚本和实验报告文档为主另有编译生成的可执行程序、测试输入与自动清理脚本压缩包仅1.37MB按五个实验划分目录结构便于对照实践。已有3757人学习下载。通过这五个实验学习者可以系统掌握进程生命周期管理、多线程协作、管道通信、命令解析与执行流程以及信号量、互斥锁等同步原语的实际用法包内各实验的主体代码、配套报告和自动构建脚本可直接用于复现实验现象、检查边界条件适合作为课程设计、期末复习或自学操作系统的参考资料也能为理解经典并发问题提供可运行的示例。1. 操作系统实验为什么大家都在补这门课操作系统实验几乎是每个计算机相关专业绕不开的一道坎。拿到实验要求时你面对的往往是一份写了十几页的文档里面讲清楚了要做什么、输入输出长什么样、评分标准是什么但没告诉你第一步该敲哪条命令。更常见的情况是实验环境是某高校课程组自己封装的模拟器或内核框架文档里只给了几个样例截图代码全靠自己摸。这门课真正要练的不是“会用某个函数”而是让你亲手把一个精简的操作系统内核模块跑起来——线程调度、进程通信、内存布局、文件系统每一项都对应着真实系统里那些看不见的底层机制。这篇文章想解决的就是这个问题拿到一份操作系统实验题时怎么从“看懂题目”走到“跑通代码”再走到“能应付答辩和检查”。我会从环境搭建、同步原语、调度算法、内存管理这几个最常出现的实验方向展开重点放在每一步的命令、参数和坑上。不管你做的是某高校的课程实验还是在慕课平台找的开放实验项目这套路径都通用——先理解要验证的核心机制再把机制落实成可运行的代码最后学会用调试器和 trace 日志证明它真的工作。适合正在做实验的学生也适合想补操作系统底层经验的开发者。2. 环境准备与工具链先把最小框架搭起来2.1 用 QEMU GCC 交叉编译搭出可调试的实验环境多数操作系统实验会提供一个模拟硬件环境因为真机上直接写内核代码的风险太高——一个指针错误就可能把系统搞崩重启代价太大。常见的做法是使用 QEMU 模拟一台无盘机器把你的实验内核编译成 ELF 镜像再用 QEMU 直接引导运行。这样不仅安全而且配合 GDB 可以做断点调试能看到寄存器、栈和内存内容比在真机上靠 printk 排查高效得多。第一步是确认工具链完整。在 Ubuntu 或 Debian 系环境下最小依赖一般是sudo apt-get install build-essential gdb qemu-system-x86 qemu-utils这里 build-essential 提供 gcc 和 makeqemu-system-x86 提供模拟器本体qemu-utils 用来制作磁盘镜像gdb 是后面排查内核崩溃的主力工具。如果你用的是 macOS 或 Windows也可以用 Homebrew 或 WSL 装同样的包但注意交叉编译时不要用系统自带的 clang因为很多实验框架的链接脚本只适配了 GNU ld。2.2 Makefile 模板链接脚本和启动流程是第一个坑实验框架一般会给你一个start.s或boot.s作为入口汇编文件它负责设置栈指针、清空 BSS 段、然后跳转到 C 语言写的kernel_main()。这个文件的正确性直接决定内核能不能启动而它也是最容易被忽略的部分——很多人拿到框架后直接改 C 文件结果编译过了却没有任何输出最后发现是入口汇编里栈指针初始化错了。一个典型的最小 Makefile 长这样CROSS_COMPILE x86_64-linux-gnu- CC $(CROSS_COMPILE)gcc LD $(CROSS_COMPILE)ld CFLAGS -m32 -fno-pic -fno-builtin -nostdinc -fno-stack-protector -c LDFLAGS -m elf_i386 -T linker.ld all: kernel.bin kernel.bin: start.o main.o $(LD) $(LDFLAGS) -o kernel.elf start.o main.o objcopy -O binary kernel.elf kernel.bin start.o: start.s $(CC) $(CFLAGS) start.s -o start.o main.o: main.c $(CC) $(CFLAGS) main.c -o main.o clean: rm -f *.o *.elf *.bin这里有几个必须注意的参数-m32指定生成 32 位代码因为很多实验内核跑在 32 位保护模式下-fno-pic关闭位置无关代码不然链接时地址计算会出问题-fno-builtin防止编译器把 printf 之类的调用优化成内建函数这个在裸机环境里会导致无法解析的符号引用。-nostdinc是不用系统的头文件目录防止 framework 自带的头文件和 glibc 冲突。如果你的实验框架是基于 64 位模式的就把-m32换成-m64但绝大多数课程设计还停留在 32 位这个选择通常由框架的链接脚本决定不要自作主张改。QEMU 启动命令一般是qemu-system-i386 -kernel kernel.bin -display none -serial stdio-kernel直接加载内核镜像-serial stdio把串口输出重定向到当前终端这样printf打印的内容就能直接看到。如果你把printf实现成了往串口写那么这里就是唯一的观察窗口。3. 进程与线程同步实验从忙等到信号量的正确姿势3.1 生产者-消费者模型为什么要用信号量而不是标志位进程同步实验里最经典的就是生产者-消费者问题。很多同学第一次做的时候会想我用一个count变量判断缓冲区满不满不就行了吗实际跑起来就会发现当生产者执行count的时候消费者线程同时执行count--两个操作互相覆盖最后count的值完全错乱缓冲区满的时候还在写入空的时候还在读取。这个问题的本质是竞争条件。count在 CPU 层面并不是一个原子操作它要经过读取内存、寄存器加一、写回内存三步。两个线程交错执行时一个线程的加一结果会被另一个线程的写回覆盖。解决办法是引入临界区保护操作系统课程里教的工具是信号量或互斥锁。一个基于 POSIX 信号量的标准实现如下#include semaphore.h #include pthread.h #define BUFFER_SIZE 16 sem_t empty; /1* 空槽位数 *1/ sem_t full; /1* 已填充槽位数 *1/ pthread_mutex_t mutex; /1* 保护缓冲区索引 *1/ int buffer[BUFFER_SIZE]; int in_index 0, out_index 0; void *producer(void *arg) { for (int i 0; i 100; i) { sem_wait(empty); // 申请一个空槽位没有则阻塞 pthread_mutex_lock(mutex); buffer[in_index] i; in_index (in_index 1) % BUFFER_SIZE; pthread_mutex_unlock(mutex); sem_post(full); // 通知消费者有数据了 } return NULL; } void *consumer(void *arg) { for (int i 0; i 100; i) { sem_wait(full); // 等待有数据可读 pthread_mutex_lock(mutex); int val buffer[out_index]; out_index (out_index 1) % BUFFER_SIZE; pthread_mutex_unlock(mutex); sem_post(empty); // 释放一个空槽位 printf(consume %d\n, val); } return NULL; }这段代码里sem_wait(empty)和sem_wait(full)的位置是有讲究的。生产者必须先申请空槽位再锁缓冲区消费者必须先申请数据再锁缓冲区。如果把锁放在信号量前面就会出现死锁——两个线程各自持锁等待对方释放资源谁也走不下去。顺序原则是先资源后锁释放时先锁后资源。参数上要特别留意信号量的初值。empty初始化为BUFFER_SIZE表示一开始所有槽位都是空的full初始化为 0表示还没有数据。如果把初值写反跑起来会立刻因为在空缓冲上做sem_post和sem_wait的混乱而卡死。用 gdb 调试时可以先给producer和consumer的入口打断点确认线程被创建后是否按预期阻塞。3.2 为什么用 sleep(1) 永远刷不掉你的玄学 bug很多人在同步实验里遇到诡异现象时第一反应是在敏感位置加sleep(1)寄希望于让另一个线程“先跑完”。这种做法在单核环境下偶尔有效因为时间片切换是确定性的但一旦上了多核两个线程真正并行执行sleep只是降低竞争概率并没有消除竞争。它属于典型的“改了好像好了再跑一次又坏了”的翻车操作。正确的排查方式是使用 ThreadSanitizer。GCC 从 4.9 版本开始支持-fsanitizethread编译时加上这个参数和-g运行时检测到数据竞争会直接告诉你哪一行、哪个变量、涉及哪两个线程gcc -g -fsanitizethread -pthread producer_consumer.c -o pc_test ./pc_test如果代码里有竞争ThreadSanitizer 会输出类似WARNING: ThreadSanitizer: data race的报错并给出调用栈。值得说明的是这个工具在实验场景里有时候会误报尤其是当你的代码里用了自旋锁或用了atomic_flag这类原语时它会因为无法识别自定义同步逻辑而误判。遇到这种情况先用互斥锁和信号量的标准写法再跑检测确认正常后再尝试优化成自旋锁。还有一个容易被忽略的坑printf本身就是有缓冲的。如果你的main线程在创建生产者消费者后直接 return整个进程退出时printf的缓冲区可能还没刷到终端你会看到消费日志缺了后半截。这不算同步 bug但很容易让人误判。正确做法是在主线程pthread_join所有子线程后fflush(stdout)或正常退出。4. 调度算法实验时间片、优先级、饥饿与负载4.1 从 FCFS 到时间片轮转调度器最少需要哪几个数据结构调度实验通常要求实现几种算法——先来先服务、短作业优先、时间片轮转、优先级调度有的进阶版本还要做多级反馈队列。如果你只是按“排序后执行”的思路来做实验也能跑过但实际上没有练到操作系统的核心因为真实调度器要面对的问题是“进程运行到一半时钟中断来了怎么把它切换出去再切到另一个”。一个最小的时间片轮转调度器需要三类数据任务控制块TCB、就绪队列、时钟中断处理。TCB 至少保存进程 ID、上下文寄存器现场、时间片剩余量、状态。就绪队列用循环链表或数组实现都可以实验规模一般不超过 64 个进程数组足够。核心代码结构如下#define MAX_TASKS 64 #define TIME_SLICE 10 // 每个任务一次运行 10 个时钟中断 typedef struct task { int id; unsigned long context; // 简化版上下文存一个值代表入口/恢复点 int remaining_ticks; // 当前时间片剩余 int total_ticks; // 累计运行时间 int status; // 0 ready, 1 running, 2 blocked } task_t; task_t tasks[MAX_TASKS]; int current 0; void scheduler_tick(void) { if (tasks[current].status ! 1) return; tasks[current].remaining_ticks--; tasks[current].total_ticks; if (tasks[current].remaining_ticks 0) { tasks[current].status 0; current (current 1) % MAX_TASKS; while (tasks[current].status ! 0) { current (current 1) % MAX_TASKS; } tasks[current].status 1; tasks[current].remaining_ticks TIME_SLICE; // 触发上下文切换跳转到新任务的 context } }TIME_SLICE这个参数是实验里最值得调的。如果设得太大比如 100 个中断才切换一次那轮转调度就退化成了 FCFS如果设得太小比如 1 个中断切一次大部分时间都花在保存和恢复现场上有效执行率极低。课程实验一般推荐 10~20 之间。判断一个时间片是否合适的方法统计所有任务的平均完成时间和平均等待时间观察切换时保存现场的耗时是否大于任务实际执行的时间片占比。4.2 多级反馈队列怎么避免短作业被长任务饿死进阶版调度实验是 MLFQ多级反馈队列。它的核心思想是新任务进入最高优先级队列执行一个时间片没结束就降级到下一级低优先级队列只在更高优先级队列为空时才有机会运行。这个机制看起来合理但有个经典 bug——如果不断有新任务进入高优先级队列低优先级的任务永远得不到 CPU这叫饥饿。解决饥饿的标准做法是周期性提升优先级。实现方式是在scheduler_tick里加一个计数器每运行 100 个时间片把所有任务的优先级恢复到最高级int global_ticks 0; void boost_if_needed(void) { global_ticks; if (global_ticks 100) { for (int i 0; i MAX_TASKS; i) { if (tasks[i].status ! 2) { // 不提升阻塞态 tasks[i].priority 0; // 回到最高优先级 } } global_ticks 0; } }这里的status ! 2是一个容易忽略的细节如果阻塞态任务也被提权那么第一次它被唤醒时反而可能抢占正在运行的 CPU 密集型任务导致调度抖动。通常阻塞任务在唤醒时就应该进入它当时的优先级队列而不是无脑提到最高。MLFQ 的验证方式需要构造不同行为的任务样本一个循环里只有少量计算的短任务、一个长时间计算的 CPU 密集任务、一个频繁 sleep 的 I/O 密集任务。观察指标是三个任务的加权时间和。正确实现的 MLFQ 应该让 CPU 密集任务的优先级逐渐降低短任务可以快速完成I/O 密集任务的响应时间保持在很低的水平。5. 内存管理实验分页、页面置换与缺页中断的坑5.1 用 FIFO 和 LRU 跑一个本地页面置换命中率数据比代码重要内存管理实验常见题目是实现页面置换算法最佳、FIFO、LRU、Clock。很多人纠结的是“哪个算法代码最难写”但实验最核心的不是代码而是怎么用同一组访问序列对比两种算法的命中率差异并给出解释。FIFO 用一个队列就够了新页面进队尾淘汰时从队头出int fifo_replace(int page_table[], int table_size) { int victim queue_front; queue_front (queue_front 1) % table_size; return victim; }LRU 的实现稍微麻烦一点需要用数组维护访问时间戳int lru_replace(int page_table[], int time_stamp[], int table_size) { int oldest 0; for (int i 1; i table_size; i) { if (time_stamp[i] time_stamp[oldest]) { oldest i; } } return oldest; }每次访问页面时更新time_stamp[page] global_counter。这个实现的问题在于复杂度是 O(n)当页表项数量很大时性能不行。实验规模下没问题但如果想做得更接近真实系统就需要用哈希表 双向链表把 LRU 降到 O(1)。不过课程答辩时不一定要求做到这一步讲明白时间戳方案的原理和复杂度就够了。比较算法的关键是设计访问序列。常见的序列有顺序访问1,2,3,4,1,2,3,4…、循环访问、局部性较强的工作集访问。用同一序列分别跑 FIFO 和 LRU画出命中率曲线你会发现一个有意思的现象当物理页框数增加时FIFO 的命中率可能反降——这就是 Belady 异常。LRU 不会出现 Belady 异常这是因为它的淘汰依据是历史访问信息而 FIFO 只看进入顺序。实验报告里如果能把这个现象跑出来并解释清楚得分通常不低。5.2 缺页中断在模拟器里怎么“看见”别再直接 print 命中了很多同学做页面置换实验时只统计命中/缺页次数最后打印一个数字就结束。这样做的问题在于无法证明你的模拟过程和真实缺页中断的语义一致——真实缺页中断应该发生在 CPU 访问某个虚拟地址、查页表发现不在物理内存的时刻而不是你预先知道“下一个要访问哪个页面”的时刻。更接近真实语义的做法是用一个事件循环模拟 MMU 的行为int mmu_access(int virtual_page) { int frame page_table[virtual_page]; if (frame 0) { // 缺页 page_fault_count; frame allocate_frame(virtual_page); if (frame -1) { // 物理内存已满 int victim lru_replace(page_table, time_stamp, NUM_FRAMES); page_table[victim] -1; // 换出 page_table[virtual_page] victim; } } return frame; }这里frame 0的判断替换了常见的if (hit) hit_count。两种方式统计结果可能是一样的但事件循环方式能让你在 debug 时观察到当物理内存满了替换发生在哪个页面、这个页面是什么时候被访问的、它的时间戳是不是最老的。这些信息是答辩时证明你“理解”而不是“背代码”的关键素材。一个值得实验的对照组是设计一个恰好触发 Belady 异常的访问序列分别跑 FIFO 和 LRU把两次的命中率打印出来对比。常见序列来自经典教材是1 2 3 4 1 2 5 1 2 3 4 5帧数分别设 3 和 4。你会发现 FIFO 在 4 帧时缺页次数反而比 3 帧时还多。6. 操作系统实验避坑指南5 个高频翻车点6.1 编译通过但启动黑屏连内核入口都没进现象QEMU 启动后终端没有任何输出gdb 断点打在kernel_main完全不命中。原因大多是链接脚本里的入口地址和start.s里的org指令不一致或者objcopy转出的二进制格式不对。解决先用nm kernel.elf | grep kernel_main确认符号存在再检查ld -T linker.ld时readelf -h kernel.elf看入口地址。排查顺序是先确认入口汇编里的jmp kernel_main被编译到了正确位置再确认 QEMU 加载的镜像地址和链接脚本起始地址一致。6.2 同步实验加锁后还是数据竞争现象明明给共享变量加了pthread_mutex_lockThreadSanitizer 依然报 race。原因大多是锁的初始化是错的——有人用了pthread_mutex_t mutex;但忘了pthread_mutex_init直接用零初始化的锁这在某些实现里会直接 UB。另一个常见问题是两个线程用了不同的锁保护同一个变量形同没加。解决统一使用PTHREAD_MUTEX_INITIALIZER静态初始化检查所有访问共享变量的代码路径是否落在同一个锁的临界区内。6.3 时间片轮转跑起来像 FCFS现象多个任务跑完统计平均完成时间发现和先来先服务几乎一样。原因是scheduler_tick里切换条件写成了remaining_ticks 0而remaining_ticks在任务被创建时没有初始化默认是 0第一次进入就触发连续切换第二个任务执行完第一个时间片后又切回第一个任务实际上每个任务都有足够长的时间连续运行到结束。解决在任务创建时把remaining_ticks显式初始化成TIME_SLICE不要依赖所在内存区域的默认值。6.4 内存置换实验把页表数组下标当物理地址用现象缺页次数统计正确但打印页面内容时读出来的值完全不对。原因是page_table[virtual_page]存的是帧号frame number不是物理地址。实验要求输出物理地址时需要做physical_addr frame * PAGE_SIZE offset的换算。这个坑在报告里很难查只能靠检查输出数值量级来发现问题——帧号一般是 0~63物理地址应该是帧号乘以 4096。6.5 用全局变量记录调度状态却忘了多核现象本地跑单核 QEMU 没问题迁移到真机或开启-smp 2就随机卡死。原因是所有调度状态都用全局变量保存没有任何原子保护两个核心同时访问就竞争。解决实验里如果要求支持多核调度器的就绪队列操作必须加自旋锁或者关闭中断。最简单的做法是实验阶段保持单核等单核版本完全稳定后再处理-smp的情况但如果框架本身默认多核启动就需要在kernel_main里先关掉辅助 CPU只让主 CPU 跑实验代码。7. 实验收尾用 trace 日志和自动化验证让成果真正可信写到这里我觉得操作系统实验最有价值的不是最后跑出来的那几行数字而是你调试过程里积累的那堆 trace 日志。我自己的习惯是从第一次让内核在 QEMU 里启动成功的那个版本开始每个功能点都留一个带时间戳的日志输出格式固定成[cpu_id][task_id][event_type] detail。这样不光是答辩时有话可说更重要的是当你改到后面某一步把前面的功能改崩了你能直接回看日志定位到是哪一次提交引入了回归。试想一个常见的验收场景实验文档要求展示生产者-消费者在 5 秒内完成 1000 次交换且无数据竞争。你说“跑过了”但评委大概率会问一句怎么证明这时候如果你能当场跑一条命令输出一个包含完整事件序列的日志文件并把消费端收到的数据总量和生产者发送的总量做核对这个证据就比口头描述有力得多。自动化验证脚本可以用最简单的 bash 加 grep 完成#!/bin/bash ./pc_test trace.log consumed_count$(grep -c consume trace.log) produced_count$(grep -c produce trace.log) if [ $consumed_count -eq $produced_count ]; then echo PASS: consumed$consumed_count produced$produced_count else echo FAIL: mismatch consumed$consumed_count produced$produced_count exit 1 fi这个脚本的价值不只是验证“有没有跑完”更重要的是它把验证标准从“人肉看输出”变成了“机器检查一致性”。以后你改生产者逻辑比如把缓冲区从 16 改成 32或者把信号量换成了自旋锁跑一遍这个脚本就能立刻告诉你有没有破坏原有语义。这是从“实验做完”到“实验做对”的分水岭。最后一个建议是时间片轮转调度的日志格式里加上task_id cpu_time state这样你可以在实验报告里画出一个甘特图——每个任务在哪个时间段占用 CPU、什么时候主动让出、什么时候被抢占。这张图不仅让报告看起来专业更重要的是它能暴露一个纯统计数字看不出的小问题某个任务是否长时间占有 CPU 导致其他任务响应延迟。如果你用的是我那套 QEMU 加 GDB 的流程甘特图还可以和 gdb 断点捕获的上下文切换点做对照进一步验证调度器是否按预期工作。操作系统实验说到底不是写给老师看的作业它是一次亲手揭开计算机系统黑匣子的机会。你踩过的每一个坑——从汇编入口错位到信号量死锁从页面置换失效到多核竞争——都是别人在面试里讲不出来的实战细节。希望这些经验能帮你少走几段弯路也希望你能在调试日志里找到那种“原来机制是这么转起来的”的确定感。本文还有配套的精品资源点击获取