简介东北大学操作系统课程设计完整项目包面向计算机科学专业本科生及需要操作系统实验参考的学习者。项目围绕进程管理、内存管理、文件系统、设备管理四大主题实现了调度算法模拟、同步互斥、页面置换、目录与文件操作等关键功能并配有课程设计报告可对照理解原理到代码的落地过程。压缩包共24个文件以21个C源码文件为主辅以头文件、可执行程序和Word报告源码注释清晰、模块划分明确便于直接编译运行与二次修改。包体仅2.11MB下载与部署都很方便。从进程创建、调度到文件分配与回收代码覆盖了课设常见考点报告也给出了实验设计和排错思路可大幅节省从零编写与调试的时间。目前已有279人学习适用于课程设计借鉴、操作系统复习巩固及算法复盘。1. 操作系统课设不是写代码是让代码在受限环境里“讲清楚计算机怎么干活”操作系统课设是计科专业里挂科率和“玄学”感都比较高的一道坎。很多人以为写一个“调度算法”交差结果验收时一跑全是段错误甚至不知道为什么程序没有输出。课设真正考察的是把进程、内存、文件、同步这几条主线拆开再用一套工程手段把它们合起来。写代码只是表象把每一个状态切换和资源分配讲出依据才是拿分点。这篇文章是一线辅导视角的经验笔记怎么选环境怎么写骨架怎么把调度、内存、文件系统、同步四个模块拆开做到了验收又该拿什么证据说话。适合正在做课设的计科学生也适合想认真补一遍操作系统基本功的同学。下面按我实际带课设的顺序来写。2. 先定环境与代码骨架为什么我用 Linux C以及最小可运行工程2.1 课设里 Linux C 为什么是压倒性优势操作系统教材里的 PCB、进程队列、页表、信号量几乎全部是在类 Unix 语境下定义的。用 C 语言写结构体字段和内存布局可以直接对应概念用 Java、C# 这类托管语言对象帮你管理了内存反而把地址空间掩盖住了。拿一个最简单的例子来说fork()在 Linux 下是真实存在的系统调用你在 Windows 上要学两套 API最后还不能完全对上教材语义。Linux 环境下还有一套适合边写边查的工具链gcc负责编译gdb负责断点valgrind负责查内存泄漏git负责留后悔药。Windows 上用虚拟机或者 WSL 都能快速拿到这套环境成本低还不影响日常使用。如果你现在还在犹豫用哪个系统我的建议很直接课设期间把主力开发环境迁到 Linux 终端里遇到问题搜报错也容易。环境组合能看到的边界典型风险Linux C内存布局、系统调用、信号量语义指针问题多需要调试工具托底Windows Java只能模拟调度看不到真实机制概念与教材语境有偏差Windows C可用 WinAPI 勉强实现代码量翻倍验收时容易讲不清补环境只需要一条命令不是你调包调一天那种玄学问题。常见做法是先更新软件源再安装编译工具链和调试器sudo apt update sudo apt install -y build-essential git gdb装完后用gcc --version和git --version各跑一遍能输出版本说明就绪。注意不要在环境上花太多时间后面真正耗时的是数据结构设计和调试。2.2 最小可运行骨架先让工程编译再谈算法很多同学第一阶段就直接开写调度算法结果编译不过半天找不着北。我习惯先搭一个“能空转”的最小工程一个 PCB 结构体、一个任务数组、一个打印函数。这个骨架跑得起来后面加任何模块都有落点。/* main.c —— 课设最小骨架先跑起来再谈算法 */ #include stdio.h #include string.h #define MAX_TASKS 16 /* 最多支持 16 个任务防止数组越界 */ #define NAME_LEN 32 typedef struct { int pid; /* 进程 id从 0 开始分配 */ char name[NAME_LEN]; /* 进程名演示用 */ int priority; /* 优先级数值越小越优先 */ int state; /* 0: ready, 1: running, 2: blocked */ } pcb_t; static pcb_t tasks[MAX_TASKS]; static int task_count 0; /* 注册一个新任务返回 pid失败返回 -1 */ int add_task(const char *name, int priority) { if (task_count MAX_TASKS) { fprintf(stderr, task table full\n); return -1; } tasks[task_count].pid task_count; snprintf(tasks[task_count].name, NAME_LEN, %s, name); tasks[task_count].priority priority; tasks[task_count].state 0; /* 初始化为 ready */ return task_count; } int main(void) { add_task(init, 0); add_task(shell, 1); /* 先打印一张任务表后续的调度器要在这里做 */ for (int i 0; i task_count; i) { printf([%d] %s priority%d stateready\n, tasks[i].pid, tasks[i].name, tasks[i].priority); } return 0; }这段代码的逻辑很简单用静态数组管理任务PCB 字段先留出 priority 和 state后续调度器要依赖这两个字段做选择。MAX_TASKS必须设一个足够小的值课设里 16 个任务足矣这能防止未来队列操作越界。注意我用snprintf而不是strcpy就是防止名字超长把缓冲区写穿。配套的 Makefile 如下CC gcc CFLAGS -Wall -Wextra -g -fsanitizeaddress TARGET os_demo $(TARGET): main.c $(CC) $(CFLAGS) -o $(TARGET) main.c clean: rm -f $(TARGET)-Wall -Wextra开启警告-g保留调试信息-fsanitizeaddress是 AddressSanitizer可以帮你提前抓到越界和释放后使用。这三个参数是课设阶段的黄金组合。第一次编译如果没报错说明骨架已经立住后续模块可以一个一个往里挂。2.3 从骨架到完整课设一次只加一个功能课设题目一般覆盖进程调度、内存分配、文件系统、同步互斥四项但很少有题目强制你一次全做完。我带过的某开发者就是因为贪快第二周就把六种调度算法全部写完结果合并时全是冲突。正确的节奏是分阶段交付阶段交付物验收标志1最小骨架 Makefile编译通过能打印任务表2就绪队列 调度器能按一种策略输出执行顺序3内存分配模块分配和释放后内存位图正确4文件系统模块能创建、写入、读取文件5同步原语 测试用例多任务运行无随机崩溃每一阶段都把手上的宏参数集中放到一个头文件里比如TIME_SLICE、MAX_LEVELS、BLOCK_SIZE。不要散落在各种.c文件里否则后面调参的时候你会发现改一个参数要 grep 十个位置。用git在每个阶段结束打一次标签翻车时能快速退回上一版这是最便宜的后悔药。3. 把课设拆成四个核心模块调度、内存、文件系统与同步原语很多做课设失败的人不是算法不会而是不知道模块之间怎么通信。这一章按最常见的课设要求把四个模块逐个拆开每个模块先讲原理选型再给可抄作业的代码骨架最后说参数怎么调。3.1 进程调度用多级反馈队列理解“切换”的本质调度算法里FCFS 太简单写不出深度时间片轮转又像在调定时器。真正能体现操作系统思想的是多级反馈队列MLFQ它同时处理了优先级、时间片和“防止低优先级任务饿死”的问题。课设里实现一个三级 MLFQ已经足够在验收时讲出东西。/* sched.c —— 多级反馈队列核心只列出最关键的片段 */ #define LEVELS 3 /* 3 条队列 */ #define TIME_SLICE 4 /* 时间片单位是“次调度” */ typedef struct pcb pcb_t; struct pcb { int pid; int level; /* 当前所在队列下标 */ int remaining; /* 本轮剩余时间片 */ int priority; pcb_t *next; /* 队列内的 next 指针 */ }; /* 就绪队列数组的每个元素是一条链表的头 */ static pcb_t *ready_queue[LEVELS]; /* 取出下一个要运行的任务从高优先级队列往下找 */ pcb_t *schedule(void) { for (int i 0; i LEVELS; i) { if (ready_queue[i] ! NULL) { pcb_t *p ready_queue[i]; ready_queue[i] p-next; /* 从队列头取出 */ p-next NULL; return p; } } return NULL; /* 没有就绪任务 */ } /* 时间片耗尽或主动让出 CPU 时p 回到就绪队列 */ void enqueue(pcb_t *p) { int lvl p-level; p-next ready_queue[lvl]; ready_queue[lvl] p; }这段代码的关键在于schedule的遍历方向从第 0 级最高优先级往下找第一个非空队列。新任务一开始都放到第 0 级时间片耗尽就降一级再入队。如果直接写while找最低级非空队列交互型任务会被后面的批处理任务饿死这就是算法逻辑选错导致整个演示翻车。参数上我最常调整的是TIME_SLICE。时间片太小切换开销占比过高时间片太大低优先级任务要等很久。实验时先把时间片设成 4跑一组任务观察周转时间再翻倍对比把两组数据放进课设报告里比空谈理论更有说服力。3.2 内存分配用伙伴系统把碎片问题变成日志数据内存模块的常见选题有动态分区分配和伙伴系统两种。动态分区写起来快但外部碎片问题很难展示伙伴系统Buddy System天然按 2 的幂分配释放时可以合并相邻块适合展示完整流程。课设里做伙伴系统核心就是两件事分配时拆块释放时合并。/* buddy.c —— 伙伴系统按 2 的幂分配内存简化版 */ #define MIN_ORDER 4 /* 最小块 16 字节必须大于管理开销 */ #define MAX_ORDER 10 /* 最大块 1024 字节对应总内存 1024 字节 */ typedef struct block block_t; struct block { int order; /* 块大小是 1 order */ int free; /* 1 空闲0 已分配 */ block_t *next; /* 同阶空闲块链表 */ }; static block_t *free_list[MAX_ORDER 1]; /* 每一阶的空闲块链表头 */ int buddy_alloc(int order) { if (order MAX_ORDER) return -1; if (free_list[order] ! NULL) { block_t *b free_list[order]; free_list[order] b-next; b-free 0; return (int)(b - mem_pool); } /* 当前阶没有空闲块向上找大块拆成两个伙伴 */ int larger buddy_alloc(order 1); if (larger 0) return -1; block_t *left mem_pool[larger]; block_t *right mem_pool[larger (1 order)]; right-order order; right-free 1; right-next free_list[order]; free_list[order] right; return (int)(left - mem_pool); }这段代码把内存池当成数组mem_pool管理分配时返回数组下标。递归向上找大块是伙伴系统的核心也是新人最容易绕晕的地方如果第 4 阶没有空闲块就递归到第 5 阶拿一块拆成两个第 4 阶伙伴一个返回给调用者另一个挂入空闲链表。释放时要判断伙伴是否也空闲如果是就向上合并。这步不做碎片率会随着运行时间明显上升。参数调优时注意MIN_ORDER不能太小。如果最小块连存储元数据order、free、next都不够那这个系统就名存实亡。课设里把最小块设为 16 字节以上内存池总量 1KB 到 4KB 足够演示。3.3 文件系统用一个文件模拟整块磁盘文件系统模块最容易犯的错是直接去真实磁盘上创建文件来“模拟”。正确做法是用一个大数组或者一个固定大小的文件充当磁盘在内部格式化出超级块、空闲位图、inode 表和数据区。这样无论怎么折腾都不会伤到宿主机这也是安全底线。/* mini_fs.c —— 用数组模拟一块磁盘只保留最核心的结构 */ #define BLOCK_SIZE 4096 #define DISK_BLOCKS 1024 /* 总容量 4MB足够演示 */ static char disk[DISK_BLOCKS][BLOCK_SIZE]; /* 模拟磁盘块 */ static unsigned char bitmap[DISK_BLOCKS / 8];/* 空闲块位图 */ int fs_alloc_block(void) { for (int i 0; i DISK_BLOCKS; i) { if (!(bitmap[i / 8] (1 (i % 8)))) { bitmap[i / 8] | (1 (i % 8)); return i; /* 返回物理块号 */ } } return -1; /* 磁盘满 */ } void fs_free_block(int block) { bitmap[block / 8] ~(1 (block % 8)); }这个位图是文件系统最小的骨架。fs_alloc_block从第 0 块开始找第一个空闲位找到后把对应 bit 置 1释放时把 bit 清 0。块大小设成 4096 字节是行业惯例但课设里没有硬性要求关键是所有模块都用同一个BLOCK_SIZE宏。最难的不是分配函数而是“格式化”。格式化在真实系统里是写超级块和位图在课设里就是你启动程序时把bitmap全清 0并且在内存里初始化 inode 表。很多同学忘了做这步导致程序重启后位图还是上一次的状态看起来就像“文件消失了”。我一般会单独写一个fs_format()函数在 main 最开始调用它负责重置所有元数据。3.4 同步与互斥自己实现信号量而不是只调 pthread同步模块的课设如果直接用pthread_mutex_lock老师大概率会觉得你在调 API 而不是在学原理。更稳的做法是自己定义一个信号量结构体实现sem_wait和sem_signal再用它去解决生产者消费者问题。这样代码量不大但原理链路完整。/* sem.c —— 课设里自己实现信号量 */ typedef struct { int value; /* 信号量计数值 */ /* 真实的课设环境中wait/signal 需要关中断或加锁保护 */ } sem_t; void sem_init(sem_t *s, int value) { s-value value; } void sem_wait(sem_t *s) { while (s-value 0) { /* 把当前任务挂到等待队列而不是忙等 */ } s-value--; } void sem_signal(sem_t *s) { s-value; /* 唤醒一个等待任务 */ }这里必须讲清楚一个坑上面这段代码只是教学骨架如果直接用 pthread 多线程跑value的自减和自增不是原子的测试会随机挂。常见的做法是给sem_wait内部加一个真正的互斥锁保护或者在注释里说明“这里假设关闭了中断”。验收时老师如果追问你能说出“忙等的危害”和“需要原子操作”这两点就已经超过八成人。我自己做课设时会把sem_wait里的忙等替换成一个线程等待队列用条件变量唤醒这样既展示了底层设计又保证多线程测试稳定。代价是代码多 30 行但答辩时可以多讲两分钟。4. 课设高频踩坑段错误、死循环与“随机挂”的排查顺序四个模块单独写都能跑接起来就崩这是课设最常见的翻车方式。下面按我实际遇到的频率列五条高频踩坑记录每条按现象、原因、解决来写。4.1 打印乱码与顺序错乱先怀疑缓冲区再怀疑栈现象程序明明执行了printf终端里什么也没有或者顺序和预期不符。原因有两个一是printf的缓冲区没有刷到标准输出程序崩溃后缓冲区内容丢失二是 PCB 结构体里某个字段被越界写坏打印字段读出来是乱码。解决调试阶段所有日志走fprintf(stderr, ...)因为stderr默认无缓冲同时把 AddressSanitizer 打开它会直接报出越界写的位置。血泪经验我见过一个同学调了半天乱码最后发现是snprintf的第三个参数传了枚举值而不是字符串属于纯手误。4.2 调度器一运行就卡死检查就绪队列与空转任务现象程序正常运行打印完任务表后没有任何输出CPU 占用 100%。原因多是schedule()返回的进程永远停留在running状态没有合适的时机重新入队或者就绪队列里存在环取出一个任务后插入又回到队头。解决在schedule()入口打印当前选中队列下标和 pid跑两个时间片后看日志。如果日志反复出现同一个 pid说明是“同一个进程被无限调度”要检查时间片耗尽后是否真的执行了enqueue。4.3 文件系统毁掉了真实分区只能用镜像文件练手现象程序里写了“保存到磁盘”的功能运行一次后工作目录下多了几个几百 MB 的文件甚至把实验环境的某个目录写满。原因直接用了真实路径做文件读写没有先规划虚拟磁盘布局。解决强制所有文件系统操作都作用在课设自己维护的disk数组上只有在“写回镜像”时才调用一次真实文件写入。镜像文件固定大小比如 4MB即使逻辑写坏最多损失一个文件。这个坑属于安全和底线问题在报告里写清楚“本设计不直接触碰真实磁盘”是加分项。4.4 多线程同步测试随机挂先查数据竞争再查内存错误现象生产者消费者测试跑 100 次大概有 3 次卡死或崩溃其他时候都正常。原因信号量value自增自减不是原子操作或者任务结构体里有指针在并发场景下被多个线程写入。解决编译时打开-fsanitizethread注意要和 AddressSanitizer 互斥分开两次编译分别跑它会精确报出是哪一行发生了数据竞争。如果确认是信号量本身没有保护回到 3.4 节给sem_wait加锁。4.5 释放后指针还在用PCB 生命周期没管理好现象任务运行一段时间后内存分配器返回的地址被反复释放或者队列里的某个节点变成野指针。原因PCB 结构体在栈上创建地址离开作用域后被其他数据覆盖释放一个内存块后没有把指针置空。解决PCB 分配统一走你写的buddy_alloc不要直接在函数里定义pcb_t pcb;然后pcb到处传。释放后立即置 NULL并且写一个assert(p ! NULL)兜底。课设代码量不大养成“谁分配谁释放”的习惯能省很多调试时间。5. 让课设拿高分自测脚本、指标计算与答辩演示准备5.1 先写好自测脚本别把验收交给运气手动测试最大的问题是你永远不知道上一次改动有没有把旧功能弄坏。课设阶段我会在项目里建一个tests/目录里面放多组输入和期望输出然后写一个脚本批量跑。脚本的核心是比对输出而不是靠人眼盯着看。#!/bin/bash # test.sh —— 用一批小用例验证调度输出避免验收现场裸奔 PASS0 FAIL0 for f in tests/*.in; do name$(basename $f .in) ./os_demo $f /tmp/$name.out 21 if diff -q /tmp/$name.out tests/$name.expected /dev/null; then PASS$((PASS 1)) else FAIL$((FAIL 1)) echo FAIL: $name diff /tmp/$name.out tests/$name.expected fi done echo passed$PASS failed$FAIL这个脚本会把每个.in文件作为标准输入把程序的输出和对应的.expected文件做比对。21很关键它把标准错误也捕获进来这样运行时的报错能被 diff 抓到。新增功能后跑一次./test.sh只要结果是failed0你就有底气去验收。如果某个用例挂了diff 会直接告诉你是哪一行输出不一样定位很快。5.2 三个场景压测与指标解读功能正确只是及格线要想拿高分得能拿出数据。我一般会用三种场景做压测把结果整理成一张表放进报告里场景输入特征核心指标批处理场景长任务多、短任务少平均周转时间交互场景任务频繁主动让出 CPU平均响应时间混合场景长短任务交错吞吐量 等待时间从程序里统计平均周转时间和等待时间只需要在每个任务完成时记录到达时刻、完成时刻和运行时长。公式不用多解释关键是把统计代码写进调度器里而不是事后手动算。压测时把时间片从 4 改成 8再跑一遍同场景两组数据对比就能证明你对调度参数有理解。报告里写“时间片从 4 变为 8 时批处理场景平均周转时间下降 X%交互场景响应时间上升 Y%”这句话比任何图表都值钱。5.3 答辩演示的 30 分钟结构演示阶段不是把功能从头到尾点一遍而是要有叙述逻辑。我习惯控制成三个部分先跑一个正常场景展示功能再打开调试日志讲“这里为什么发生了切换”最后现场改一个参数比如把TIME_SLICE改小重新跑让老师和同学看到结果变化。第三步最好提前准备一个脚本因为现场改参容易手滑脚本能让结果稳定复现。如果演示中间真的崩了不要慌打开gdb现场看栈帧这个临场反应反而能让老师对你的工程能力留下印象。能稳定说出“崩溃在哪个数据结构”的学生比顺滑跑完全程但讲不清原理的得分高一个档次。6. 延伸从“纸上模拟器”到一个能接管中断的小内核课设交完后如果时间允许我强烈建议往前再走半步把代码从“模拟器”变成真正跑在虚拟机里的最小内核。模拟器里你写的是队列和链表真实内核里你会遇到中断、上下文保存这些模拟器永远不暴露的问题。这一步不一定要做完哪怕只是让一个最小内核在 QEMU 里打印一行字你就能明白为什么课设代码里那些“关中断”注释是必须的。/* kernel.c —— 最小内核入口只做两件事关中断、停在这里 */ #define PANIC_MSG kernel: alive void kernel_main(unsigned long magic, unsigned long addr) { (void)magic; (void)addr; /* 这里可以挂时钟中断处理每隔一段时间打印一次 */ for (;;) { /* 空转真实操作系统在这个循环里做“调度决策” */ } }配合一个最少量的启动汇编和链接脚本用 QEMU 的-kernel参数就能引导起来。这一步真正的价值是让你亲手碰到“内核入口到主函数之前发生了什么”这个黑匣子。我见过不止一个同学课设拿了不错的分数但被一问“中断上下文切换要保存哪些寄存器”就愣住。模拟器里永远不会溢出中断栈也不会真的保存上下文但这恰恰是操作系统最核心的功夫。如果你决定尝试先建一个空工程把kernel_main跑起来打印一行字再慢慢加时钟中断。别一上来就想写完整内核从“打印一行字”到“管理一个任务”之间的距离就够你再学一个学期。我自己带课设时看到学生在报告后面附一小节真实内核的探索过程印象分会明显不一样。课设是让我们亲手撕开操作系统的黑匣子能写完模拟器的你去动一次真实内核入口翻车也值得。希望帮到你。本文还有配套的精品资源点击获取
