简介操作系统课程配套实验源码包面向高校计算机专业学生、Linux系统学习者及备考者聚焦进程管理、存储器管理、设备管理与文件系统四大核心模块。资源共32个文件以C/C源代码为主体含20个头文件、11个C源文件与1个C文件压缩包整体15.42MB代码结构清晰、模块划分明确便于按实验章节逐一对照学习。已有1063人学习下载属于操作系统实验教学领域的高频参考资料。包内覆盖进程的软中断通信与管道通信、Linux存储器管理、字符设备驱动程序以及一级文件系统的设计与实现等典型实验源码可直接编译运行也可作为课程设计或考研复试的复习素材。通过研读这些代码读者能更直观地理解操作系统底层机制掌握Linux环境下进程调度、内存分配、设备驱动及文件系统构建的完整思路。1. 计算机操作系统实验指导不只是一本习题集而是一套落地路线图先给结论拿《计算机操作系统实验指导第3版》当期末复习提纲来读的人基本浪费掉它一半的价值。我带操作系统课程设计这些年看得最多的翻车现场不是概念背不熟而是实验环境跑到一半崩了、日志打不出来、报告里贴的代码编译不过。这本指导书做的事是把操作系统原理里进程调度、同步互斥、内存映射、文件系统这些“看不见”的思想压成一台真实机器上能编译、能运行、能观察的“看得见”的实验。它会带你从fork()开始一路走到调度器、页表、磁盘调度这些硬话题。适合三类人在校学生要交实验报告要过的不是背概念而是跑代码备考复试的人要用最短时间把核心算法过成代码转岗或补底层知识的一线开发者需要一个不用绕路的学习路线。这本书真正的价值恰恰在于用它做引子把原理变成你自己的产物。这里没有新概念只有你把概念落地后会遇到的隐性裂缝。2. 把实验环境立起来虚拟机、双系统和 WSL2 的选型与最小配置2.1 先配环境还是先敲代码别在第一步选错路操作系统实验和普通算法实验最大的不同点是它的代码大多直接操作系统调用、信号和中断。你在 Windows 上写 C 语言#include unistd.h都过不了编译。所以第一件事不是在 IDE 里建项目而是选一个“能让你看到 Linux 内核接口”的运行环境。实验指导第 3 版里的操作对象一般围绕 POSIX 接口展开常见做法是用 Ubuntu 22.04 LTS 做主力系统。这里给你三条路物理机装双系统、虚拟机装 Linux、以及 WSL2。双系统的好处是性能最接近真实内核坏处是一旦切换系统就需要重启打断实验思路虚拟机的隔离性最好快照功能等于给你吃了后悔药WSL2 的启动速度最快但实时性受限碰到时钟中断、驱动相关的实验会翻车。对大多数人我推荐虚拟机起步等真到性能瓶颈再切双系统。教材里的实验代码量不大虚拟机那点性能损耗几乎感知不到反而换来“坏了能恢复”的安全感。2.2 最小配置用 VirtualBox 建一台实验机的完整步骤这里以 VirtualBox 配合 Ubuntu 22.04 为例。安装过程不做细讲关键是几个参数直接避坑资源建议值理由内存不低于 4 GB实验代码不大但 gcc 编译多进程时会吃内存CPU 核数2 核或以上线程同步实验需要真实多核才能看到竞争硬盘20 GB 动态分配快照和编译中间文件会膨胀显存128 MB图形界面卡顿会影响操作体验装完之后先做两件事安装增强工具把共享剪贴板和共享文件夹打开然后换国内镜像源把 apt 的软件源地址换成阿里云或清华的镜像否则装 gcc、build-essential 会慢得让你怀疑人生。然后跑这个命令验证环境sudo apt update sudo apt upgrade -y sudo apt install -y build-essential gcc g make git uname -a cat /etc/os-release第一行更新软件源索引第二行装的是编译工具链第三行uname -a用来确认内核版本。为什么要装 build-essential因为实验指导里那些.c文件多数没有 IDE 工程文件你必须在命令行用手写 makefile 或一条 gcc 命令编译编译器、链接器和 make 都是刚需。装完之后建议你立刻拍一张快照名称写baseline-after-install。后面实验环境搞坏了直接恢复不必从头再来。这个习惯后的价值比任何技巧都大。如果你用的是 openEuler、银河麒麟这类国产发行版命令层面也差不多只是包管理器变成 dnf 或 yum装包的写法要跟着变核心的 gcc、make 概念完全一样。2.3 WSL2 的边界哪些实验它扛得住哪些不能WSL2 是有自己的位置的。它启动快、磁盘占用低做进程实验、写 fork 同步完全够用。但问题出在三处第一WSL2 跑在 Hyper-V 虚拟化层上时钟精度和调度实时性和真机有差异统计调度时间片时数据会飘而且不稳第二一些需要直接操作设备文件或读内核日志的实验比如dmesg、/dev/tty经常会发生权限不足或设备不存在第三内核模块加载受限想实验自定义内核模块基本是玄学看运气。所以我的建议是用 WSL2 快速验证代码逻辑可以但涉及“系统调用转发级别”的实验或者实验指导里明确要求看内核日志的还是老老实实回虚拟机。你完全可以在 WSL2 里先写完并调试大部分 C 代码最后在虚拟机上再跑一遍拿正式数据。这样既享受了启动速度又保证报告数据的来源经得起追问。3. 进程与线程实验从 fork 系统调用到调度日志的完整链路3.1 指导书里的实验到底在训练什么先讲透目标进程这一章指导书绝对不会只让你背 fork 的返回值。它真正检验的是三件事第一你懂不懂“进程是资源分配单位”这句话在代码里的表现第二你会不会用wait()和exit()管理父子进程的生命周期第三你能不能把一个调度算法从原理变成可观察的调度日志。如果你只写一个 printf 观察 pid 打印顺序那这个实验只能拿及格分。拉开差距的是在调度器里插入日志画出时间线。这需要你先理解Linux 的调度时间片不是你在代码里随便usleep一个值就等价于内核时间片的。实验调度器通常是模拟层模拟调度器无法直接干预真实 CPU 调度所以实验指导的做法一般是让你在用户态实现一个“模拟调度核心”用线程或进程队列来跑算法再用真实时钟函数打时间戳。这一点想明白了整个实验的代码结构就清晰了。3.2 fork、wait 与 exec最小可复现代码与参数说明先给一段最小却完整的代码覆盖三个核心系统调用#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h int main() { pid_t pid fork(); if (pid 0) { perror(fork failed); exit(1); } else if (pid 0) { printf([child] pid%d, parent%d\n, getpid(), getppid()); execl(/bin/echo, echo, child exec done, NULL); perror(execl failed); // 只有 exec 失败才会执行到这一行 exit(1); } else { printf([parent] pid%d, child%d\n, getpid(), pid); int status; waitpid(pid, status, 0); if (WIFEXITED(status)) { printf([parent] child exit code%d\n, WEXITSTATUS(status)); } } return 0; }这段代码里最容易被忽略的是execl后面的perror那行。如果 execl 成功它会被新程序映像替换永远执行不到。一旦你看到“execl failed”说明路径写错了或者目标文件没有执行权限。而waitpid的status宏——WIFEXITED和WEXITSTATUS——是检查子进程退出原因的标准方式。实验报告里问“孤儿进程怎么产生”你就可以改这段代码让父进程直接 return不给子进程 wait然后看子进程的 ppid 会不会变成 1。这种一行代码的改动远比解释有说服力。3.3 让调度器“开口说话”如何打时间戳验证时间片轮转下一个层级就是把理论调度算法和代码挂钩。用 pthread 模拟三个进程给每个线程记录运行起止时间#include stdio.h #include pthread.h #include time.h #include unistd.h #define PROCESS_NUM 3 typedef struct { int id; struct timespec start, end; } proc_info; void* worker(void* arg) { proc_info* info (proc_info*)arg; clock_gettime(CLOCK_MONOTONIC, info-start); for (volatile int i 0; i 100000000; i); // 模拟计算 clock_gettime(CLOCK_MONOTONIC, info-end); return NULL; } int main() { pthread_t tids[PROCESS_NUM]; proc_info infos[PROCESS_NUM]; for (int i 0; i PROCESS_NUM; i) { infos[i].id i; pthread_create(tids[i], NULL, worker, infos[i]); } for (int i 0; i PROCESS_NUM; i) { pthread_join(tids[i], NULL); long ms (infos[i].end.tv_sec - infos[i].start.tv_sec) * 1000 (infos[i].end.tv_nsec - infos[i].start.tv_nsec) / 1000000; printf(thread %d ran for %ld ms\n, i, ms); } return 0; }这里用CLOCK_MONOTONIC而不是gettimeofday是因为单调时钟不会因用户改系统时间而跳变统计运行时长时数据更稳。volatile空循环是为了让编译器不要优化掉计算块。如果你写for (int i0; i100000000; i);开了-O2之后编译器可能直接把整个循环优化没了线程秒退实验现象直接消失。这不是玄学是编译优化规则。调度器实验报告里的关键不是运行时间多少毫秒而是时间戳的采集方式是否可复现。把你打日志的代码也贴到报告里读者一眼就知道你理解原理。4. 内存与文件系统实验地址换算和磁盘调度参数怎么才算“做通了”4.1 虚拟地址换算先手工算再上代码验证内存管理实验里最容易劝退的就是地址变换。很多同学一上来就贴一个malloc和free就觉得完事但这跟操作系统的内存管理没关系那是 libc 的堆管理。指导书里要你做的应该是模拟一个页式地址转换给定逻辑地址、页表算出物理地址。手工计算的方法是逻辑地址addr页大小page_size页号p addr / page_size页内偏移w addr % page_size。然后查页表得到物理块号f物理地址 f * page_size w。这是个纯算术题但实验真正练的是把它写成通用函数#include stdio.h #include stdint.h int translate(uint32_t logical_addr, uint32_t page_size, const uint32_t* page_table, int table_size, uint32_t* phys_addr) { uint32_t p logical_addr / page_size; uint32_t w logical_addr % page_size; if (p table_size) return -1; // 缺页 uint32_t f page_table[p]; if (f 0xFFFFFFFF) return -1; // 页未加载 *phys_addr f * page_size w; return 0; } int main() { uint32_t pt[4] {2, 5, 0xFFFFFFFF, 9}; uint32_t out; if (translate(0x1234, 4096, pt, 4, out) 0) { printf(phys0x%x\n, out); } else { printf(page fault\n); } return 0; }这个实现里我故意用0xFFFFFFFF表示页未加载模拟缺页的入口。实验中你还可以把访问位、修改位、有效位放进页表项的位域里那就是 TLB 和多级页表的扩展方向。这里有两个大家常写错的点第一页内偏移是直接用逻辑地址整除取余得到不能右移位第二页表大小必须传进来否则越界溢出就是未定义行为。实验报告里把你手工算的那一组结果粘进去再贴这段代码跑出来的输出作对照两者一致才能证明代码是对的。只有代码没有手工过程或只有手工过程没有代码验证都不算完整。4.2 实现一个 SCAN/C-SCAN 磁盘调度器从算法到带参数的代码磁盘调度实验是典型的“看起来简单、做起来烦”的类型。SCAN 算法也叫电梯算法核心是维护一个移动方向向一个方向的请求服务完之后再反向。C-SCAN 则是单向服务完直接回到起始端。如果你写代码时不把“当前磁头位置”和“请求队列”分开后面报表统计吞吐时就乱套。下面是一个只保留核心逻辑的简化实现#include stdio.h #include stdlib.h #define REQUESTS 8 int cmp(const void* a, const void* b) { return (*(int*)a) - (*(int*)b); } void scan(int req[], int n, int start, int direction) { int sorted[REQUESTS]; for (int i 0; i n; i) sorted[i] req[i]; qsort(sorted, n, sizeof(int), cmp); int total 0, pos start; printf(SCAN start%d direction%d\n, start, direction); if (direction 1) { for (int i 0; i n; i) { if (sorted[i] pos) { total sorted[i] - pos; pos sorted[i]; printf(visit %d, seek%d\n, pos, total); } } for (int i n - 1; i 0; i--) { if (sorted[i] pos) { total pos - sorted[i]; pos sorted[i]; printf(visit %d, seek%d\n, pos, total); } } } // direction -1 的对称逻辑先向下再向上 printf(total seek: %d\n, total); } int main() { int req[] {98, 183, 37, 122, 14, 124, 65, 67}; scan(req, 8, 53, 1); return 0; }这里的qsort排序后关键的坑就出现了直接在所有请求有序的前提下判方向导致每个请求最多访问两次。现实中扫描到最内或最外磁道才回头如果磁头在最内轨方向上已经没有请求这就到了你该处理的边界。完善版本要把磁头可移动范围当参数传进去比如head_range_end超出边界立即反向。实验报告里你应该把direction参数、磁头起始位置、队列长度都写进输入数据表再给一张输出表。只给一个运行截图是不够的。SCAN 和 C-SCAN 的差异只有在队列两侧不对称时才会体现出来所以你至少得设计两组输入一组请求集中在磁头一侧一组分布在两侧才能讲清楚两种算法的区别。4.3 把文件系统“打开看”inode 与目录项的实验观察文件系统实验一般有两种风格一种是写一个模拟文件系统用数组模拟磁盘块另一种是真在 Linux 下用stat和opendir观察真实文件系统的行为第二种的现实感强得多。例如在 Linux 下写一个 C 程序调用stat()读取文件元信息再对比目录项里的文件名和 inode 号#include stdio.h #include sys/stat.h #include time.h int main() { struct stat st; if (stat(/etc/hosts, st) ! 0) { perror(stat); return 1; } printf(inode%lu size%ld blocks%ld\n, st.st_ino, st.st_size, st.st_blocks); printf(mtime%s, ctime(st.st_mtime)); return 0; }这里输出的st_blocks是 512 字节磁盘块数量不是st_size。很多同学把这两个值混成一谈报告里写“块大小是 st_size”这说明从来没真的跑过实验。你还可以打开目录读取目录项跟stat对比 inode 号就能直观看到“目录项映射文件名到 inode”的链路。如果实验要求深入 ext2 文件系统那会用到dd和debugfs。但这章的思路是一样的先用系统调用观察真实文件系统再向里深入。内核看到的是什么和你代码里看到的是什么两个对上号这个实验才算做通。5. 实验避坑环境变量、编译选项与并发冲突的常见问题5.1 编译过了一运行就Segmentation fault现象源代码在指导书里看起来天衣无缝gcc 编译无报错但运行到一半直接Segmentation fault (core dumped)。原因往往是三类数组越界、野指针、栈溢出。在操作系统实验里最常见的是页表或位图数组用了固定长度但实际传参时访问了下标越界。解决先用编译器开启调试信息再用工具链排查gcc -g -fsanitizeaddress -o exp exp.c ./exp-fsanitizeaddress是 AddressSanitizer会在越界访问发生时直接打印是哪一行代码出了问题省去几十行 printf 的排查黑匣子时间。如果输出显示heap-buffer-overflow立刻去看数组长度与索引关系。如果只是常规排查用 gdb 跑gdb ./exp core再执行bt看栈回溯。这类崩溃问题大多不是玄学是“地址计算到底谁负责”没想清楚。5.2fork()之后父子进程打印顺序完全随机实验报告怎么解释现象代码里写了先printf([parent]...)再printf([child]...)期望先父后子结果运行多次输出顺序不同。原因fork 成功后父子进程进入就绪队列的先后不由代码决定由内核调度器决定你不做同步打印顺序天然是竞争的。解决如果实验目的就是要观察竞争那报告里直接说明“这一点证明了调度不确定性”如果实验目的是固定协作顺序就必须引入同步原语int fd[2]; pipe(fd); // 子进程 write(fd[1], go, 1); 父进程 read(fd[0], ...) 后再打印用管道做握手同步是最原生、最贴合操作系统原语的做法。用sleep(1)反而最容易把实验做坏因为它掩盖了真实调度还引入了无必要的时间依赖也体现不出你对进程同步的理解。5.3 线程同步实验里“卡死”在某个等待点现象生产者消费者实验跑了不到几秒钟就卡死打印停在“waiting to produce”。原因最常见的是条件变量 signal 时没有配合互斥锁使用或者pthread_cond_wait在等之前就已经释放了锁。还有一种提交是把队列判空的逻辑放在锁外导致读到旧数据。解决把锁边界画出来在pthread_cond_wait调用前后都打印当前锁状态。注意pthread_cond_signal是唤醒一个等待者如果多个消费者同时等在同一个条件变量上而你只发了一个 signal没有 while 循环复查条件就会漏掉唤醒。教科书说要写成while (count 0) pthread_cond_wait(...)就是为了防止“虚假唤醒”。删掉while改成if很多“神秘卡死”的根本原因就在这里。5.4 虚拟机时钟不稳调度实验的时间数据漂移现象在 VirtualBox 里跑调度实验统计出来的时间片要么特别长要么跳变重启后数据也复现不了。原因宿主机负载、虚拟机时钟虚拟化偏差、实验代码又用了CLOCK_REALTIME。解决统一用CLOCK_MONOTONIC采集耗时不要在虚拟机里开启“同步宿主机时间”的选项实验报告里明确注明“结果在虚拟机内测量绝对数值仅用于横向比较”。如果你对比不同调度算法的运行数据要保证在同一环境、同一负载条件下跑多次取中位数而不是拿第一次跑的数直接写报告。调度计时本身就是实验对象计时方式写不清整份报告的可信度都会打折扣。5.5 实验报告贴了代码评审却认定你没跑过现象报告贴了 include、主函数、运行截图但老师问一个输出细节你答不上来。原因贴代码不算证据没有“现场痕迹”。解决跑完实验后保存一份原始 shell 日志script命令和一份 CSV 格式的输出数据在报告里贴出你生成的带时间戳的调度日志。如果用的是模拟实验把你传入的具体输入参数比如起始磁头位置、请求队列、页表内容都写清楚。把“发生了什么”变成“可复核的记录”这一条做到位报告的质量会直接拉开一个档次。很多翻车现场不是实验没做是没留下“做过的痕迹”。6. 把实验报告写成评审愿意信的“证据链”实验做完最后一步是把过程凝练成报告但这步经常被低估。我的做法是给每章实验准备三个固定产出环境清单、关键日志、参数表格。硬件和软件环境是实验的前提运行时的原始日志是黑匣子里的记录原始输出是白盒参数表格用来覆盖不同实例下算法表现避免“只会跑一个用例”的质疑。以磁盘调度实验为例我最后会在报告里附一张表输入队列起始磁头算法总寻道距离平均等待[98, 183, 37, 122, 14]53SCAN236按实际计算[98, 183, 37, 122, 14]53C-SCAN236按实际计算[14, 65, 67, 98, 122]53SSTF连续取最近值按实际计算这张表的意义是证明“算法有两个以上用例的对比”。评审最怕的就是只有一个用例且无边界条件。你再进一步做“验证性实验”——调大请求队列到 100 个、把磁头范围调到 0199观察寻道距离是否按预期增长。如果增长了说明你的实现是符合定义的如果没增长说明你算法里藏着边界 bug这时候回头查代码才是对自己负责。我再分享一个习惯每跑完一次实验立刻用script命令存一份终端会话日志。遇到实验中途改代码旧日志也不要删保存成v1.log、v2.log。这不仅是为了报告完整性更能在期末复习时迅速回忆整个思考过程哪个参数让你从 F 改到 C为什么。操作系统实验真正的收获不是那几个标准算法代码而是“我给你一台裸机你怎么把原理落地成一个能跑、能测、能看的系统”的工程判断力。希望这个工作流能帮你少走一些弯路也希望那些报告里打出来的日志不只是应付老师而是成为你真正理解内核接口的证据。本文还有配套的精品资源点击获取