简介这是一份面向湖南科技大学计算机相关专业学生的操作系统课程设计完整资料包覆盖进程管理、内存管理、文件系统、设备管理、系统调用、并发与线程、保护与安全、网络编程等核心实验方向内含可编译运行的源码与演示程序也适合其他高校操作系统课程设计与自学参考。压缩包共26个文件约4.97MB其中12个cpp源程序实现了磁盘调度、内存管理、生产者和消费者、读者写者、银行家算法、虚拟内存页面置换等经典题目对应12个exe可直接运行验证效果另有docx课程设计报告和c验证性程序便于对照学习与二次开发。已有856人浏览学习。资源将源码、可执行文件与报告组合在一起既能帮助理解各类操作系统算法的实现思路又能为撰写课程设计报告提供可参考的框架是完成课设、备战系统方向面试或复试上机的实用材料。1. 操作系统课设不是背理论先把四个经典方向摸清楚操作系统课设和操作系统期末复习是两回事。期末复习背的是知识点课设要求你在真实系统上把线程同步、进程调度、文件系统这些概念落地成能编译、能运行、能讲清楚的代码。常见的方向就四类多线程同步生产者消费者、读者写者、处理机调度时间片轮转、优先级调度、简易shell、内存分配或文件系统模拟。很多人卡住不是因为不懂概念而是因为并发问题在单核机器上不出现、编译参数不对、代码看起来对但一压测就崩。这篇笔记就按“先搭环境、再写最小实现、最后验证”的顺序把课设从选题到提交的关键步骤和坑一次讲清。2. 环境与前置知识在虚拟机里搭出能复现并发问题的实验台2.1 用 VirtualBox 还是 VMware课设选型要看什么课设阶段的虚拟机选型不需要纠结“哪个更强”真正该看的是三件事能不能手动指定 CPU 核数、能不能方便地做快照、能不能让虚拟机里的 Linux 和宿主机之间拷贝文本和文件。我一般用 VMware Workstation 或 VirtualBox 都行但默认配置一定要改。以 Ubuntu 22.04 Server 为例安装时如果不手动指定虚拟机创建向导经常给出“1 核 2G 内存”的保守配置。这个配置跑通小程序没毛病但做生产者消费者这类题目时单核会让并发问题极难复现——你写了一个有竞争条件的程序在单核虚拟机上可能连续跑 50 次都不出错交到双核机器上直接卡死。这就是为什么要在第二章先讲环境参数。一个更实际的问题是 VMware Tools 的版本匹配。新版 Workstation 不再随旧版客户机操作系统一起提供 VMware Tools安装时如果发现“VMware Tools 不再随旧版客户机操作系统的 VMware Workstation 一起提供”这类提示说明客户机系统的内核版本太老或者安装介质不匹配。这种问题不是你的代码问题别在课设代码里找原因去换一个和 Workstation 版本匹配的 Ubuntu 镜像22.04 或 20.04 的 Server 版都行装完再单独安装 open-vm-tools 即可。2.2 Ubuntu Server 虚拟机的最小安装流程拿到课设题目后第一件事不是写代码而是把 Linux 环境装到一个“随时可以推倒重来”的虚拟机上。Ubuntu Server 版比 Desktop 版更适合课设因为它内存占用小而且大部分调度、同步、shell 题目根本不需要图形界面。安装时磁盘给 20G 就够内存给 2GCPU 核数在创建阶段就手动指到 2 或 4。安装完成后登进系统先做三件事更新软件源、安装编译工具链、确认内核版本。以下是我每次新建课设虚拟机都会跑的一组命令# 更新软件源与系统基础包 sudo apt update sudo apt upgrade -y # 安装编译工具链gcc、make、gdb 一个都不能少 sudo apt install -y build-essential gdb # 确认内核版本与 CPU 拓扑写代码前先看清运行环境 uname -a nproc cat /proc/cpuinfo | grep -c processor逻辑说明apt update刷新软件源索引apt upgrade把系统已有的内核和库升到源里的最新版本避免后面编译时因为 glibc 版本太老而踩坑。build-essential这个元包会把 gcc、g、make、libc-dev 一起装上是课设环境的最小集。nproc和/proc/cpuinfo用来确认虚拟机实际的 CPU 数量这一步很重要——如果你在创建虚拟机时明明指定了 2 核但nproc返回 1说明虚拟化层出了问题做并发实验时会被假象误导。参数说明磁盘 20G 是底线做文件系统题时如果只用 20G格式化一个 512M 的虚拟磁盘分区用dd生成镜像文件也足够不需要真的大容量。内存 2G 是给 Server 版用的如果选了 Desktop 版建议 4G否则打开浏览器查资料都会卡。2.3 让并发问题暴露出来虚拟机 CPU 与内存参数怎么设这是整个环境搭建里最容易偷懒、但最影响课设质量的一步。默认向导给的“按宿主机自动检测核心数”看似省事实际会掩盖你在并发编程里写出的竞争条件。我在做课设和带课设时给的参数建议是CPU 核数固定为 2不要超过 4内存固定为 2G开启 PAE/NX 这类默认选项不要给虚拟机分配超过宿主机物理内存一半以上的内存。为什么 2 核而不是 1 核因为 1 核虚拟机下两个线程靠时间片轮换执行临界区的冲突概率远低于双核真并行。很多经典的死锁和竞争条件题目在单核上需要跑很久才出现一次甚至完全不出现学生就会误认为自己的实现是对的。2 核是能稳定复现并发问题的最小配置。不要超过 4 核是因为课设的并发题目一般只创建 2 到 8 个线程核数再多调度器的行为会掩盖你算法里的不少问题。内存 2G 也够。生产者和消费者、读者写者这类题目线程栈默认 8M4 个线程也就 32M 的栈空间2G 内存跑这些绰绰有余。内存给太大反而没有意义还拖慢宿主机。提示如果你的虚拟机启动时提示“客户机操作系统已禁用 CPU。请关闭或重置虚拟机”通常不是操作系统问题而是虚拟化引擎没选对。在 VMware 的虚拟机设置里把“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”选项打开或者改用“自动检测”即可。这个提示和你的课设代码无关先处理环境再继续。2.4 快照是你的后悔药每次改内核相关代码前先存一份课设里最常出现的翻车场景是想试一个内核模块比如自定义调度器或内存分配器结果写崩了系统启动不起来又不知道刚才改了什么。这种情况在没快照的虚拟机上等于重装系统一晚上白干。我在做系统类实验时的习惯是每完成一个阶段就拍一次快照。阶段分割点大致是这样刚装完系统、跑通apt update后拍一个“clean-ubuntu”写完生产者消费者并能稳定跑 100 轮后拍一个“sync-done”做调度器或内核模块改动前永远先基于上一个快照新建一个分支快照。快照不是备份是后悔药。它的价值在于让你敢改内核参数、敢装带 DKMS 的驱动、敢rm -rf玩出问题后一键还原。不夸张地说我见过太多学生在最后一周重装环境原因就是不敢动系统或者动了没存快照。提交课设前把虚拟机里的关键代码同步到宿主机的 Git 仓库共享文件夹或直接git push到自己的私有仓库这算是双保险。2.5 三类题目的环境差异不是所有题目都需要图形界面拿到课设题目后先判断自己属于哪一类因为环境要求完全不同。如果是进程调度、线程同步、shell、内存管理这类纯用户态题目Ubuntu Server 的字符界面就够甚至不需要桌面环境。这类题目重点在写 C 代码和验证算法图形界面反而让你分心。如果是内核相关的题目比如简单驱动、自定义系统调用、文件系统实现建议给虚拟机装一个轻量桌面Xfce 或 GNOME或者至少配置好串口日志。因为内核崩溃时字符界面下你只能看到黑屏和一串寄存器有桌面环境和日志工具journalctl -k能帮你快速定位是什么操作触发了Oops。另外这类题目必须用与内核版本匹配的 gcc装完内核头文件linux-headers-$(uname -r)再开始写代码否则make时一定会报找不到头文件。如果是纯理论验证类题目比如用 C 语言模拟页面置换算法那连虚拟机都可以不用直接在宿主机上编译运行也行。但这种题往往会让课设“看起来很单薄”如果你的评分标准里有“系统调用交互”这类要求还是建议至少把程序跑在虚拟机里让实验报告里能出现真实的进程 PID 和/proc文件系统内容。训练营里很多高分报告都是因为截图里带了ps -ef和/proc/cpuinfo的输出让评审一眼看出程序在真实操作系统上运行过。3. 三大经典题目的最小实现从伪代码到可提交的 C 代码3.1 生产者-消费者条件变量比信号量容易写对生产者消费者是操作系统课设里出现频率最高的题目因为它能覆盖线程创建、互斥锁、条件变量、共享缓冲区四个核心考点。很多教材先用信号量讲但如果你自己写我建议用互斥锁加条件变量理由后面说。下面是可提交的最小实现框架缓冲区大小和线程数都定义为宏方便你按题目要求修改// prod_cons.c // 编译gcc -o prod_cons prod_cons.c -lpthread #include stdio.h #include stdlib.h #include pthread.h #define BUFFER_SIZE 8 // 缓冲区大小可改 #define PRODUCER_NUM 2 // 生产者线程数 #define CONSUMER_NUM 2 // 消费者线程数 #define LOOP_TIMES 100 // 每个生产者/消费者循环次数 int buffer[BUFFER_SIZE]; int count 0; // 当前缓冲区物品数 int in 0, out 0; pthread_mutex_t mutex PTHREAD_MUTEX_INITIALIZER; pthread_cond_t not_full PTHREAD_COND_INITIALIZER; pthread_cond_t not_empty PTHREAD_COND_INITIALIZER; void *producer(void *arg) { long id (long)arg; for (int i 0; i LOOP_TIMES; i) { pthread_mutex_lock(mutex); while (count BUFFER_SIZE) { // 必须用 while不能用 if pthread_cond_wait(not_full, mutex); } buffer[in] i; // 生产一个数据 in (in 1) % BUFFER_SIZE; count; printf(Producer %ld produced %d, count%d\n, id, i, count); pthread_cond_signal(not_empty); // 唤醒一个消费者 pthread_mutex_unlock(mutex); } return NULL; } void *consumer(void *arg) { long id (long)arg; for (int i 0; i LOOP_TIMES; i) { pthread_mutex_lock(mutex); while (count 0) { pthread_cond_wait(not_empty, mutex); } int data buffer[out]; out (out 1) % BUFFER_SIZE; count--; printf(Consumer %ld consumed %d, count%d\n, id, data, count); pthread_cond_signal(not_full); pthread_mutex_unlock(mutex); } return NULL; } int main() { pthread_t producers[PRODUCER_NUM], consumers[CONSUMER_NUM]; for (long i 0; i PRODUCER_NUM; i) pthread_create(producers[i], NULL, producer, (void*)i); for (long i 0; i CONSUMER_NUM; i) pthread_create(consumers[i], NULL, consumer, (void*)i); for (int i 0; i PRODUCER_NUM; i) pthread_join(producers[i], NULL); for (int i 0; i CONSUMER_NUM; i) pthread_join(consumers[i], NULL); printf(all threads done, final count%d\n, count); return 0; }逻辑说明pthread_mutex_lock保护共享缓冲区while (count BUFFER_SIZE)是生产者的阻塞条件pthread_cond_wait会原子地释放 mutex 并挂起线程。这里用 while 而不是 if 是关键因为pthread_cond_wait可能被虚假唤醒如果用 if唤醒后不会重新检查条件会直接往满缓冲区里写数据导致越界。消费者侧的 while 同理。两个条件变量分别对应“缓冲区不满”和“缓冲区非空”它们必须配合同一个 mutex 使用。参数说明BUFFER_SIZE是核心参数必须小于生产总量否则消费者永远不会阻塞题目里“同步”这个考点就体现不出来。一般设成 4 到 16 比较合适。PRODUCER_NUM和CONSUMER_NUM是另一个关键参数验证正确性时把生产者设 4、消费者设 1会极大提高竞争概率让潜在问题更容易暴露。最容易被忽略的参数是LOOP_TIMES如果设太小比如 1程序瞬间就跑完看不到阻塞和唤醒的过程建议设 100 以上最后用final count是否为 0 来粗判正确性。为什么推荐条件变量而不是信号量信号量方案里你需要同时维护一个互斥信号量、一个空位信号量和一个物品信号量三个信号量的 P/V 操作顺序错了就会死锁。条件变量方案只需要一把锁加两个条件变量逻辑更直观而且条件变量的广播功能在读者写者题里几乎是必需品。如果你只有信号量可用有些题目限定了那记住一个口诀先申请资源信号量再申请互斥锁释放顺序反过来。3.2 时间片轮转调度用 C 语言实现一个可打印的调度过程处理机调度是另一类高频题目常见要求是“模拟时间片轮转调度算法输出进程状态变化”。这类题不一定要真的修改内核用 C 语言写一个模拟器即可关键是把 PCB、就绪队列、时间片、上下文切换这些概念在代码里具象化。下面是一个最小实现重点在调度逻辑和打印格式可以直接在此基础上扩展优先级、动态时间片等附加要求// rr_sched.c // 编译gcc -o rr_sched rr_sched.c #include stdio.h #include stdlib.h #include string.h #define MAX_PROC 10 #define TIME_SLICE 2 // 时间片大小单位单位时间 #define TOTAL_TIME 30 // 模拟总时长 typedef struct { int pid; int arrival; // 到达时间 int remain; // 剩余服务时间 int wait_time; // 累计等待时间用于算平均等待 int finished; // 是否已完成 } PCB; PCB proc[MAX_PROC]; int proc_count; // 简单队列这里直接用数组循环查找课设规模不需要循环队列 void schedule_rr() { int current_time 0; int done 0; while (current_time TOTAL_TIME done proc_count) { int scheduled 0; for (int i 0; i proc_count; i) { if (proc[i].arrival current_time !proc[i].finished) { int run (proc[i].remain TIME_SLICE) ? proc[i].remain : TIME_SLICE; proc[i].remain - run; current_time run; printf([t%d] PID %d running for %d, remain%d\n, current_time, proc[i].pid, run, proc[i].remain); if (proc[i].remain 0) { proc[i].finished 1; proc[i].wait_time current_time - proc[i].arrival - run; done; } scheduled 1; // 真实时间片轮转应让出 CPU这里重新扫描队列模拟队尾入队 } } if (!scheduled) { current_time; // CPU 空闲时间推进 } } } int main() { // 测试用例3 个进程到达时间分别为 0,1,2 proc[0].pid 1; proc[0].arrival 0; proc[0].remain 5; proc[1].pid 2; proc[1].arrival 1; proc[1].remain 3; proc[2].pid 3; proc[2].arrival 2; proc[2].remain 4; proc_count 3; schedule_rr(); int total_wait 0; for (int i 0; i proc_count; i) { total_wait proc[i].wait_time; printf(PID %d wait_time%d\n, proc[i].pid, proc[i].wait_time); } printf(average wait time%.2f\n, (float)total_wait / proc_count); return 0; }逻辑说明这个模拟器做的事情是每个时间点从就绪队列里找出第一个到达且未完成的进程让它运行一个时间片或它的剩余时间。current_time是全局推进的时钟每次调度后打印一次当前时间。wait_time的计算方式是“完成时间减去到达时间再减去实际运行时间”这相当于进程从进入系统到完成中间除了执行外的所有等待时间。循环扫描代替了真实的队列出队入队操作——课设规模下几个进程这个简化不会影响算法正确性但如果你要写“队列”这个考点可以用数组实现环形队列在while循环里维护一个queue_head和queue_tail。参数说明TIME_SLICE是核心参数设为 2 时剩余时间 5 的进程要分 3 次执行完能清晰看到轮转过程。如果设为大于所有进程剩余时间的值轮转退化成先来先服务就没有“轮转”的演示效果了。TOTAL_TIME必须足够大否则可能出现调度到一半被强制中止的情况最稳妥的设置是比所有进程的到达时间与服务时间之和再大 30% 以上。刚开头的两个宏TIME_SLICE和TOTAL_TIME就是你实验报告里“参数对算法的影响”的素材。交实验报告时分别用时间片 1、2、5 跑三组数据平均等待时间的变化一目了然。如果你只交了程序没跑对比这题的区分度就没了。3.3 简单 shellfork、exec 与 wait 的最小组合shell 类题目要求不多读入一行命令解析出参数创建子进程执行父进程等待。看着简单真正写完会发现坑在细节——命令解析时怎么处理多个空格、路径怎么找、命令带参数时怎么传给 execvp。下面是能通过大部分验收的最小实现// minishell.c // 编译gcc -o minishell minishell.c #include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h #define MAX_LINE 1024 #define MAX_ARGC 64 void parse_command(char *line, char **argv, int *argc) { int i 0; char *token strtok(line, \t\n); while (token ! NULL i MAX_ARGC - 1) { argv[i] token; token strtok(NULL, \t\n); } argv[i] NULL; *argc i; } int main() { char line[MAX_LINE]; char *argv[MAX_ARGC]; int argc; while (1) { printf(mysh ); fflush(stdout); if (fgets(line, MAX_LINE, stdin) NULL) break; parse_command(line, argv, argc); if (argc 0) continue; if (strcmp(argv[0], exit) 0) break; pid_t pid fork(); if (pid 0) { perror(fork); continue; } if (pid 0) { // 子进程用 execvp 在 PATH 中查找命令 if (execvp(argv[0], argv) 0) { perror(execvp); exit(1); } } else { // 父进程等待子进程结束 int status; waitpid(pid, status, 0); } } return 0; }逻辑说明parse_command用strtok按空格、制表符和换行切分命令并且把最后一个参数后的位置置为 NULL这是 execvp 要求的参数数组格式。fork创建子进程子进程调用execvp执行命令execvp会在 PATH 环境变量列出的目录里查找可执行文件所以你可以直接输入ls -l而不是/bin/ls -l。父进程的waitpid阻塞等待子进程结束保证 shell 在子进程运行期间不返回提示符。fflush(stdout)是为了让提示符立刻显示因为 stdout 在管道模式下是全缓冲的不加这个脚本测试时看不到提示符。参数说明MAX_LINE和MAX_ARGC是两个必须保留的边界宏一个限制单行输入长度一个限制参数个数。检查代码时评审会专门输入超长命令或超过 64 个参数的命令看你会不会崩。strtok会修改原字符串所以line不能是只读字符串字面量fgets读入的缓冲区没问题但如果你自己造测试用例时写成parse_command(ls -l, ...)会段错误——这是新手常踩的坑因为字符串字面量存在只读段。这个 shell 是后续所有 shell 题的骨架支持cd需要额外写内建命令、支持输入输出重定向需要对 做解析并调用dup2、支持管道需要在命令里拆出|并创建 pipe。如果你的题目只要求“能执行外部命令 一个内建 exit”这份代码已经够了。3.4 内存管理与文件系统适合放进小组分工里的边界题除了上面三个高频方向湖南科技大学操作系统课设里还有内存管理模拟首次适应、最佳适应、最坏适应页面置换算法和文件系统模拟模拟空闲块管理、目录结构这两类题目。这类题目的特点是逻辑比前三类简单但代码量更大因为要模拟很多数据结构。如果你是小组成员我的建议是把这类题安排给代码风格比较好的同学做。因为它不涉及真实的内核接口不依赖 fork 和线程纯粹是数据结构和算法的组合只要把数组和链表用得熟练就能做出来。但正因为它太“模拟”很多人在实验报告里写不出“这和我用的 Linux 有什么关系”导致答辩时答不上来。针对文件系统题有一个能提升答辩质量的改法不要只模拟内存里的数据结构用 Linux 的真实接口做一件小事。比如用open、read、write自己实现一个“无缓冲的文件拷贝”在报告里对比 glibc 的fread/fwrite谁快并解释为什么。这样你的题目就从“模拟”变成了“实现”展示的是真实系统调用能力这比打印 100 行内存状态更能说服评分老师。针对内存管理题类似的做法是读取/proc/meminfo里的真实内存数据用你的算法在真实数据上跑一遍首次适应和最佳适应比较碎片率。这个“用真实数据输入”的技巧是让模拟类题目脱离“玩具”感的最快方式。4. 操作系统课设避坑指南5 个最常翻车的点4.1 现象单核虚拟机下并发程序怎么跑都不出错这是并发类课设最常见的假象。我见过不止一个学生拿着一个明显有竞争条件的生产者消费者程序在笔记本上连续跑 20 次全对觉得自己写完了结果提交到学校服务器多核上几秒钟就卡死。原因虚拟机默认单核时两个线程是时间片轮换执行临界区操作的间隔被拉长冲突概率极低。而在双核机器上两个线程真正并行count这种非原子操作会被拆成多步在另一个核上交错执行数据就错了。gcc 编译默认不加-O2时count可能对应多条汇编指令更容易暴露问题。解决创建虚拟机时手动指定 2 核代码里加上-O2再编译一次跑一遍看是否正确。-O2优化下的竞争条件暴露概率远高于-O0。如果你用的是前面 3.1 节的代码在 2 核虚拟机上增加PRODUCER_NUM到 8大概率能看到打印里出现两次相同或跳变的 count 值这就是竞争条件。4.2 现象gcc 编译报错教程里的代码直接复制过来不能编译很多同学从网上下载生产者消费者或 shell 代码gcc xxx.c编译时直接报undefined reference to pthread_create然后就开始怀疑代码有问题。原因pthread 库在较老版本的 glibc2.34 之前不是 libc 的一部分必须在编译命令里显式链接。这是链接错误不是语法错误。新版 Ubuntu 22.04 的 glibc 2.35 已经将 pthread 合并进 libc所以同一份代码在 22.04 上不加-lpthread能过在 18.04 上就报错。解决统一在编译命令里加-lpthread并且把编译命令写进 Makefile 或实验报告不要只发一个.c文件。很多评分老师会直接重新编译你的代码编译不过先扣一半分。对于有 Makefile 的课设我一般要求学生在提交前把整个目录放进一个全新虚拟机里执行make能过才算数。4.3 现象共享内存或管道程序打印结果乱序但代码逻辑没问题用printf在父进程和子进程里各自打印结果输出顺序和计划的不一致甚至同一行输出被截断拼在一起。这是用户态程序课设里最容易被误判为“程序写错了”的情况。原因printf是 stdio 库函数内部有缓冲区并且进程间的缓冲区刷新时机不同。父进程可能因为没主动fflush而让输出留在缓冲区里子进程退出时 flush 一下顺序就乱了。另外多个进程/线程共享一个文件描述符表printf的单次调用不一定是一个原子写线程 A 写到一半线程 B 插入。解决如果你只是需要“看到输出”在每条printf后面加fflush(stdout)或者改用write(1, buf, len)这种系统调用直接写文件描述符 1。如果输出内容重要比如要作为实验报告的证据建议不要依赖printf把调度记录写到一个日志文件里用open(O_APPEND)加O_APPEND标志保证每次写入是原子的然后在实验报告里贴日志文件内容。这样既避免了顺序混乱也让老师可以直接查看完整运行结果。4.4 现象AI 辅助工具生成的代码“看起来对”一压测就崩近一年用 CodeGeeX 或通义灵码这类工具辅助写课设代码很常见。但很多人发现生成的代码逻辑完整、注释齐全编译能过一跑就段错误或死锁。这不是工具不能用而是你没给它完整的上下文。原因代码生成工具是根据你给的提示和它学到的模式生成代码它不知道你的虚拟机是 2 核还是 1 核不知道你的 glibc 版本不知道你的题目要求“必须使用信号量”还是“只能用条件变量”。它生成的生产者消费者代码缓冲区大小可能设成 1024而你实际压测时开了 16 个生产者栈上直接放不下。解决不要把题目描述直接丢给它然后复制代码。正确用法是自己先把 3.1 节这种最小框架写出来然后让工具只填充某个函数比如“帮我写一个用两个条件变量实现的缓冲区操作”生成后自己审查它使用的接口是否在你的系统上存在。压测前用ulimit -s检查栈大小用strace -f -e traceread,write,wait跑一遍看系统调用序列是否合理。工具能帮你从零写出一个像样的原型但不能替你做测试这个边界要在报告里写清楚不要全盘甩锅给 AI也不要全盘吹它。4.5 现象文件系统题格式化“空白”分区后挂载还能看到旧文件做文件系统模拟题时有人用mkfs.ext4格式化一个虚拟机磁盘分区格式化完成后重新挂载发现里面还有旧文件误以为自己格式化失败或分区损坏。原因ext4 文件系统有延迟分配和组描述符缓存机制格式化只是重建了超级块和关键元数据如果没有真正写盘sync没有执行或旧的内核缓存还在重新挂载时可能读取到旧的目录缓存。另外如果刚mkfs完立刻mountLinux 可能还没把块设备缓存失效也会看到旧内容。解决格式化后先sync一次再umount并重新挂载或者直接mount -o remount,ro强制刷新。如果要彻底验证格式化后的内容用dumpe2fs /dev/sdX1看文件系统状态然后用debugfs -R ls -l / /dev/sdX1读取根目录内容这才是文件系统内部视角。这个坑提示一个通用问题做文件系统题时不要在宿主机上直接操作真实分区永远是dd生成一个镜像文件再格式化和挂载镜像文件出任何问题都不影响虚拟机系统本身。5. 如何验证课设真的做完压测参数与测试脚本5.1 线程同步题的正确性判定只看“没卡住”是不够的很多学生判断生产者消费者是否正确的标准是“程序跑完了没死锁”。这个标准远远不够。一个程序如果生产者线程因为条件变量写错而根本不阻塞消费者也能跑完表面上也能输出但实际上没有任何同步发生。我的验证方法是加两条断言第一所有线程都结束第二最终count 0所有生产的东西都被消费了。仅仅看打印日志很难人工核对上万次计数所以要在代码里加一个全局计数器每生产一次加一每消费一次减一最后打印。这个计数器的最终值如果不为 0说明同步逻辑有问题。更严格的做法是把缓冲区操作与一个“预期总数”对比。因为每个生产者生产LOOP_TIMES次消费者也消费LOOP_TIMES次所以生产者总生产量 PRODUCER_NUM * LOOP_TIMES消费者总消费量 CONSUMER_NUM * LOOP_TIMES。两者必须相等且等于最终 count 的变动总量。5.2 调度与 shell 题的功能测试边界输入用例表调度题和 shell 题不能只测主流程边界输入是最容易被扣分的地方。以下是我在验收课设时必测的用例表你自己在提交前按这个表跑一遍题目边界用例预期行为时间片轮转进程到达时间都相同严格按顺序轮转不出现某个进程饿死时间片轮转所有进程到达时间都晚于 0前期 CPU 空闲等待不能提前调度到不存在的进程时间片轮转时间片大于单进程总服务时间退化为 FCFS平均等待时间应正确计算简单 shell输入空行和连续多个空格不打印错误重新输出提示符简单 shell输入 exit、exit 加多余参数都能识别 exit 内建命令不卡死简单 shell输入不存在的命令子进程 perror 后返回shell 不退出简单 shell输入带 30 个参数的命令不段错误参数数组不越界这个表你可以直接复制到实验报告的“测试部分”按列逐项截图比贴一大段运行日志更清晰。特别是 shell 题很多老师会自己在终端输入ls -l看能不能跑通却忘了检查ls无参数和ls -l多空格的区别如果你提前处理了 strtok 的连续分隔符这个加分点是白拿的。5.3 用脚本自动跑 100 轮比对作为性能与稳定性数据课设答辩时老师问“你的程序稳定吗”空口说“稳定”没用得拿出数据。我一般会写一个压测脚本把生产者消费者程序循环跑 100 轮统计每次的退出状态和运行时长输出一个汇总。下面是适用于任何可执行程序的压测脚本模板#!/bin/bash # stress_test.sh # 用法./stress_test.sh ./prod_cons BIN$1 PASS0 FAIL0 for i in $(seq 1 100); do if timeout 10 $BIN /tmp/run_$i.log 21; then PASS$((PASS 1)) else FAIL$((FAIL 1)) echo run $i failed, exit code $? /tmp/stress_fail.log fi done echo PASS$PASS FAIL$FAIL逻辑说明timeout 10是核心参数它限制每个单次运行最多 10 秒防止死锁程序让整个脚本卡死。每次运行的标准输出和错误输出都重定向到独立日志失败时会把失败轮次和退出码追加到stress_fail.log。如果你的程序有内在的随机性或竞争条件100 轮里如果出现任何一次FAIL说明代码还有问题不要抱侥幸心理。参数说明timeout的阈值要看你的LOOP_TIMES设置。LOOP_TIMES1000时单次运行可能需要 1 到 3 秒10 秒绰绰有余。如果设成 10000阈值建议改成 60否则正常的慢速运行会被误判为超时。seq 1 100是轮次数实验报告里写“100 轮无失败”最有说服力如果时间紧张做 30 轮也可以但少了不太能说明问题。跑完脚本后顺手统计一下平均运行时间记录 100 次的real时间可以用time命令包裹算出平均值和标准差写进实验报告的性能分析章节。很多性能对比的同学只会说“我的算法效率很高”但拿不出数字这是最容易补的一块。6. 把课设做出“可扩展”的样子分离内核对象与业务逻辑留好两个钩子6.1 让“验证”变成习惯回归测试先于新功能课设提交前最后三天最容易犯的错误是“改一个地方把之前能跑的功能改崩了”。时间片轮转里加了优先级支持结果原来的轮转测试用例跑不过了shell 里加了管道支持结果ls -l都不执行了。这时候才想起要测试已经晚了。我现在的习惯是从第二天开始每次改动前先跑一次现有的全部测试用例改动完再跑一次。测试用例不用写成复杂的测试框架一个 shell 脚本、一个预期输出文件就够。前面 5.2 节的边界用例表就是你的回归测试清单。不要等“写完了”再测要从第一天起就建立“改一点、测一点”的节奏。6.2 两个能加分的进阶方向如果你的课设时间有余量两个进阶方向性价比最高。第一把生产者消费者改造成“超时退出”版本用pthread_cond_timedwait代替pthread_cond_wait让消费者在等待超过 2 秒后主动退出并报告“等待超时”。这能体现你对条件变量 API 边界的理解而不只是会用阻塞版。第二把时间片轮转模拟器加一个简单的“优先级反转”案例一个低优先级进程持锁高优先级进程等锁中优先级进程抢占 CPU让高优先级进程的等待时间异常拉长。然后在报告里解释为什么真实内核需要优先级继承或优先级天花板协议。这个案例展示的是“你会用算法模拟器分析真实系统问题”比单纯打印调度序列高一个层次。6.3 一个收尾的习惯最后一个习惯提交前用一份干净的下载代码重新编译一遍。不要在你自己那个已经配置好各种环境变量的终端里编而是把代码复制到一个新目录删掉 Makefile让命令行的 gcc 从零编译一遍。这一遍如果能过且跑通 5.2 的用例表再写实验报告。我吃过亏代码在我机器上是好的换到学校电脑上因为少一个头文件编译失败又花半天解释其实就一条#include unistd.h的事。操作系统课设是一个少有的、能让你同时接触“并发真实性”和“系统接口”的机会把上面这些命令、参数和测试习惯跑一遍比多看十遍知识点有用得多。希望帮到你。本文还有配套的精品资源点击获取
