操作系统课设参考资料：进程调度、页面置换与银行家算法解析

简介：这是一份面向操作系统课程设计/大作业场景的完整参考资源，由西安电子科技大学计算机科学与技术专业的课程设计资料整理而成，适合需要完成类似任务的高校学生、初期项目研究者参考。资源包为zip压缩格式，文件总数上游未提供，大小约41.16MB，主要文件类型涉及课程设计报告、实验代码与原始上机截图，其中报告可帮助理解设计方案与实现思路，代码可用于对照调试，截图则利于核对实验环境与运行结果。目前已有608人学习浏览，适合具备一定基础、想要自主扩展功能的学习者。该资料的价值在于提供了一套可直接拆解的操作系统课程设计范例，包括核心代码逻辑、实验记录与关键截图，有助于读者快速梳理整体框架、排查实验报错，并能在此基础上二次开发。需要特别说明的是，资料仅作为参考资料，不应照搬，读者应结合自身基础进行消化与改进。

1. 操作系统课程设计：一份能扛住答辩的参考资料长什么样

操作系统课程设计大概是计算机类大作业里最容易出现“代码能跑但讲不清”的一种。很多人拿到题目第一反应是上网翻代码，结果找到的资源要么只有源码没有报告，要么报告写成了流水账，答辩时老师一句“PCB 为什么这么设计”就能问住。这份参考资料把课程设计报告、实验代码、原始上机截图三样东西打包在一起，等于给了一个完整蓝本：报告教你“怎么把设计和结果讲明白”，代码让你看到可运行实现的真实结构，截图则对应实验过程的可视化证据。适合正准备做操作系统课设、想对照已有实现查漏补缺的读者，也适合拿来做毕设前期的摸底参考。它定位是参考资料而不是定制答案，直接照抄会死得很难看。

2. 核心实验模块拆解：进程调度、页面置换与银行家算法怎么做

这份资料覆盖了操作系统课设最常见的三个方向：进程管理、内存管理、并发与死锁。下面拆一下这三个方向在一个合格实现里应该做到什么程度，以及选型时通常怎么考虑。

2.1 进程控制块与调度算法：从数据结构看设计思路

进程管理类题目通常要求模拟一个调度器，输入一批进程的到达时间和服务时间，输出调度顺序、周转时间和带权周转时间。这类题的核心不是算法本身，而是 PCB（进程控制块）怎么设计。PCB 至少要包含 pid、状态、到达时间、需要运行时间、已运行时间、完成时间，选优先级调度还要有 priority。一个常见定义长这样：

#define MAX_TASK 32 typedef enum { READY, RUNNING, BLOCKED, FINISHED } state_t; typedef struct { int pid; // 进程号 state_t state; // 当前状态 int priority; // 优先级，数值越大越优先 int arrive_time; // 到达时间，单位 ms int need_time; // 需要运行的总时间 int run_time; // 已经运行的时间 int wait_time; // 累计等待时间 int finish_time; // 完成时刻，用于计算周转时间 } pcb_t;

state_t 对应进程三态模型，课设做 READY、RUNNING、FINISHED 三态就够。wait_time 不是摆设，算平均等待时间时要用。finish_time 在进程完成时写入，用来算周转时间。这里故意把时间用 int 而不是 float，一是避免浮点比较的精度问题，二是整数结果方便和手算对照。

调度算法选 FCFS、SJF、RR 还是优先级，取决于题目要求。FCFS 最好实现也最好答辩，但演示效果平淡，老师容易追问“两个进程同时到达时你怎么排序”。所以我一般建议至少实现两个算法做对比。FCFS 核心逻辑是按到达时间排序后依次执行：

int cmp_by_arrive(const void *a, const void *b) { pcb_t *p1 = (pcb_t *)a; pcb_t *p2 = (pcb_t *)b; if (p1->arrive_time != p2->arrive_time) { return p1->arrive_time - p2->arrive_time; } return p1->pid - p2->pid; // 同时到达按 pid 排，保证输出稳定 } void fcfs_schedule(pcb_t tasks[], int n) { qsort(tasks, n, sizeof(pcb_t), cmp_by_arrive); int cur_time = 0; for (int i = 0; i < n; i++) { if (cur_time < tasks[i].arrive_time) { cur_time = tasks[i].arrive_time; // 处理 CPU 空闲等待的情况 } tasks[i].finish_time = cur_time + tasks[i].need_time; tasks[i].state = FINISHED; tasks[i].wait_time = cur_time - tasks[i].arrive_time; cur_time = tasks[i].finish_time; } }

这段代码的逻辑是：先按到达时间排好序，然后从头扫描。cur_time 表示 CPU 当前时刻，如果 CPU 空闲，就让时间直接跳到下一个进程的到达时刻。每个进程的等待时间等于开始执行时刻减去到达时刻。注意 cmp 函数里加了一个用 pid 做二级排序的规则，保证同样的输入每次输出顺序完全一致。

原理层面有一个高频追问点：你的调度器支不支持抢占。FCFS 是非抢占的，实现简单；如果选抢占式优先级调度，就要额外处理“新进程到达时是否中断当前进程”，复杂度立刻上去。从课设性价比看，先把非抢占的 FCFS/SJF 跑通，再扩展抢占版本写对比结论，是最稳的路径。

2.2 页面置换算法：FIFO、LRU 与 OPT 的实现差异

内存管理模块的常客是页面置换。给定一个访问序列和物理块数，统计不同算法下的缺页次数。这个题目的价值不在代码量，而在统计口径。LRU（最近最久未使用）最直观的实现是时间戳法：

int lru_page_faults(int pages[], int n, int frame_num) { int frames[frame_num]; int last_used[frame_num]; // 记录每帧最近一次被访问的时刻 int faults = 0, clock = 0; for (int i = 0; i < frame_num; i++) { frames[i] = -1; last_used[i] = -1; } for (int i = 0; i < n; i++) { int hit = 0; for (int j = 0; j < frame_num; j++) { if (frames[j] == pages[i]) { hit = 1; last_used[j] = clock++; // 访问命中，刷新时间戳 break; } } if (!hit) { faults++; int victim = 0; for (int j = 1; j < frame_num; j++) { if (last_used[j] < last_used[victim]) { victim = j; // 找最久没被使用的帧 } } frames[victim] = pages[i]; last_used[victim] = clock++; } } return faults; }

每次页面命中或装入新页，时钟计数加一，记录该帧最后一次被访问的全局时刻。缺页时遍历所有帧，找到 last_used 最小的那一个作为淘汰对象。这个实现的时间复杂度是 O(n·m)，m 是物理块数，课设规模完全够用。真正的坑在统计口径：有些同学把初始空帧全部算成缺页，有些只统计页面装入次数。题目的答案对不上时，往往就是这里口径不一致。建议在代码里加一个参数控制是否把冷启动缺页计入，演示时统一用“只统计访问缺失”的口径，并把口径写进报告。

2.3 并发与死锁：生产者消费者、银行家算法怎么模拟

并发控制出现频率最高的是生产者消费者和银行家算法。生产者消费者的难点在信号量初值和操作顺序：sem_empty 初始为缓冲区容量，sem_full 初始为 0，mutex 为 1；生产者先 P(empty) 再 P(mutex)，消费者先 P(full) 再 P(mutex)。顺序反了会死锁。这个细节答辩时经常被追问，答不上来会显得对 PV 操作的理解停留在背代码层面。

银行家算法一般做成“安全序列判断”模块：输入已分配矩阵、需求矩阵和可用资源向量，输出安全序列或判定不安全。

#define R 3 #define P 5 int is_safe(int available[], int allocation[][R], int need[][R], int p_count) { int work[R], finish[p_count]; int safe_seq[p_count], seq_len = 0; for (int i = 0; i < R; i++) work[i] = available[i]; for (int i = 0; i < p_count; i++) finish[i] = 0; for (int turn = 0; turn < p_count; turn++) { int found = -1; for (int i = 0; i < p_count; i++) { if (finish[i]) continue; int can_alloc = 1; for (int r = 0; r < R; r++) { if (need[i][r] > work[r]) { can_alloc = 0; break; } } if (can_alloc) { found = i; break; } } if (found == -1) return 0; // 当前轮找不到可执行进程，判定不安全 for (int r = 0; r < R; r++) work[r] += allocation[found][r]; finish[found] = 1; safe_seq[seq_len++] = found; } return 1; }

银行家算法的核心一句话：每次找“需求能被当前剩余资源满足”的进程，模拟执行完收回它占用的资源，循环直到所有进程完成。找一圈找不到可执行的进程时，判定为不安全。注意 must 用多轮扫描而不是只扫一轮，否则会把安全状态误判为死锁。

顺着这个逻辑你会发现，银行家算法代码量很小，难点在测试用例构造：要构造一个“当前剩余资源能满足部分进程、但最终死锁”的用例来证明判断有效。手写一组数据再用程序跑一遍，报告里才有对比素材。

3. 环境搭建与运行：Linux 下的编译、输入输出与数据采集

代码拿到手后第一件事不是打开编辑器看逻辑，而是先把环境搭起来、把程序跑通。操作系统课设对环境的依赖比一般数据库大作业要高得多。

3.1 开发环境选型：虚拟机、WSL 与原生 Linux 怎么选

课设代码多基于 C 和 POSIX 接口，比如 fork、pthread、sem_t，这些在 Windows 原生环境跑起来很别扭，pthread 要额外装库或用 Win32 线程 API 改写。最稳妥的方案是装一个 Linux 虚拟机或者使用 WSL。

如果你的课设只是纯模拟算法（页面置换、银行家算法、调度算法），用 WSL 就够了，文件共享方便，截图也简单。如果涉及进程同步、父子进程这类真实系统调用演示，建议装完整虚拟机，因为 WSL 对某些内核模块的支持有限，演示时出问题反而麻烦。从学习价值看，虚拟机更接近真实环境，遇到网络或权限问题时还能顺便练一下 Linux 基本操作。

从答辩角度，Linux 下有一个额外优势：gcc 的警告信息比 Windows 下的集成开发环境直白，编译不过就是不过，逼着你把代码写干净。提交报告时写“开发环境：Ubuntu + gcc”也比写“某某集成开发环境”显得更贴近操作系统课程本身。

3.2 编译与运行：Makefile、输入文件格式与参数说明

课设工程通常有多个 .c 文件和头文件，手动敲 gcc 命令容易漏文件，写一个 Makefile 是一劳永逸的事：

CC = gcc CFLAGS = -Wall -g -O0 TARGET = scheduler OBJS = main.o scheduler.o pcb.o $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $(TARGET) $(OBJS) main.o: main.c scheduler.h pcb.h $(CC) $(CFLAGS) -c main.c scheduler.o: scheduler.c scheduler.h pcb.h $(CC) $(CFLAGS) -c scheduler.c pcb.o: pcb.c pcb.h $(CC) $(CFLAGS) -c pcb.c clean: rm -f $(OBJS) $(TARGET)

几个参数值得说明：-Wall 打开所有常规警告，看到未使用变量、类型不匹配的警告都应该当 error 处理；-g 保留调试信息，后面用 gdb 定位段错误全靠它；-O0 关闭优化，避免“源码顺序和实际执行顺序看着对不上”的情况。

注意一个隐藏坑：Makefile 规则里的命令前必须是 Tab 字符，复制到编辑器里如果被转成空格，make 会报 missing separator。这个报错看起来莫名其妙，实际就是缩进问题。

程序的输入建议用文件而不是硬编码。常见的输入文件格式：

# 进程数 4 # pid 到达时间 服务时间 1 0 10 2 2 5 3 3 8 4 5 2

第一行是进程数，从第二行开始每行三列：pid、到达时间、服务时间。用 # 做注释行，读文件时跳过，调试时就可以在输入文件里写备注。main 函数里用文件输入而不是硬编码，批量改参数做对比实验会轻松很多。

gcc -o scheduler main.c scheduler.c pcb.c -lm ./scheduler input.txt output.txt

输出文件里按进程顺序打印完成时间、周转时间、带权周转时间，再算一份平均值。报告里的表格可以直接从输出文件复制粘贴，不需要手动誊写。

3.3 上机截图与数据采集：让实验过程可复现

截图不能随便截，至少包含三样：编译成功的终端窗口、带参数的运行命令和输出结果、输入数据文件的内容。截图的目的不是证明“我跑了”，而是让老师能在几秒内确认“这组输入对应这组输出”。

我一般建议按实验编号组织文件，例如 lab2_1_input.txt、lab2_1_output.txt、lab2_1.png。提交前重新跑一遍，确认输出文件内容和截图一致。很多同学提交的材料里输出和截图对不上，基础分就悄悄丢了。

改完代码后还有一个实用验证方法：用 diff 对比新旧输出。重新编译后跑一遍，用 diff -u output_old.txt output_new.txt 查看差异，如果除了预期改动之外多出其他变化，大概率改动了公共逻辑。这个方法在迭代算法时能帮你快速发现回归。

4. 课程设计报告写法：从实验数据到答辩问答的组织方法

代码能跑只是第一步，操作系统课设的成绩很大程度取决于报告和答辩。报告不是开发文档，别几十页堆代码。

4.1 报告骨架：从需求分析到问题与解决的七个部分

一份结构合理的课设报告通常包含七个部分，每部分篇幅有讲究：

需求分析里最常见的毛病是把题目抄一遍就完事，其实要写清楚“输入是什么、输出是什么、特殊边界怎么处理”。设计方案部分要用数据结构定义说话，直接把第 2 章里的结构体贴进去，再解释每个字段为什么存在。实验过程部分是截图的地盘，也是证明真实动手的证据。

结束语不是让你抒发感想，写清楚这次课设解决了什么问题、哪些地方还值得扩展即可，半页就够，别写感谢学校培养之类的话。

4.2 实验数据组织：周转时间怎么算、表格怎么排

算法结论不是靠感觉，是靠数据。调度实验里最基础的计算公式：

周转时间 T = finish_time - arrive_time，带权周转时间 W = T / need_time。平均周转时间和平均带权周转时间对全部进程求平均。一组 FCFS 手算示例如下：

带权周转时间越接近 1，说明作业在系统中的相对等待时间越短，这是衡量调度策略的重要指标。报告里放一张这样的手算表，再放一张程序输出的结果表，两者一致，老师就会确认你真的理解了计算过程。

4.3 答辩问答：三个必被追问的细节

答辩不是代码演示，问的通常是设计层面的问题。根据课设常见套路，以下三个问题基本必被问。

第一个是“你的调度算法优缺点是什么”。如果只写“SJF 平均等待时间最短”而说不出“可能导致长作业饥饿”，就显得没有全面理解算法。

第二个是“你的 PCB 为什么这么设计，有没有冗余字段”。准备时把每个字段和课本概念对应上，例如 state 对应状态模型、wait_time 对应等待时间统计。

第三个是“你的结果怎么验证”。标准答法是：用小规模数据手算一遍，和程序输出对照，并把对照过程放进报告。这个回答比“我跑了没问题”有力得多。

5. 操作系统课设避坑指南：五个高频翻车点的排查记录

操作系统课设的翻车点相对集中，下面按“现象 → 原因 → 解决”的顺序记录五个最常见的。

5.1 段错误：程序一运行就崩

现象：输入数据一多就 Segfault，用 printf 逐行打印也看不出哪里崩。

原因：进程数组越界；PCB 里的字段未初始化就读；输入文件行数与数组容量不符。

解决：优先用 gdb 跑一遍。编译保留 -g，执行 gdb ./scheduler，输入 run，崩溃后输入 bt 查看调用栈，能直接定位到出错的源文件行号。定位到数组越界后，把 PCB 数组从固定长度改成动态初始化，或者在循环里加上界检查。从那以后写类似模拟程序，我都会在数组外层加边界宏检查下标合法性。

5.2 页面置换缺页数与课本对不上

现象：LRU 跑出来的缺页次数和例题答案不一样。

原因：初始空帧是否计为一次缺页；访问序列从 0 号页还是从 1 号页编号；循环边界是 <=n 还是 <n。这三处口径只要有一处不同，结果就会偏。

解决：在代码顶层定义统一口径，例如“冷启动缺页计入统计”，并在报告里写清楚。对比课本例题时，先按例题的输入手工推一遍再对照程序结果。缺页统计这类题，结果对不对不在算法实现，在口径定义。

5.3 调度输出不稳定：两次运行结果不同

现象：同一份输入连跑两次，输出顺序不一样。

原因：qsort 的比较函数只按到达时间比，两个进程同时到达时排序结果依赖当前系统环境的比较实现。

解决：在比较函数里加二级排序字段，比如按 pid 排序。这类问题换一台机器后才暴露，看起来像玄学，实际上就是比较函数没写全。

5.4 编译链接报错：-lm 顺序和 Makefile 缩进

现象：编译报 undefined reference to 'pow'，或者提示 pthread 相关函数找不到。

原因：数学库、线程库没有显式链接。-lm、-lpthread 必须放在编译命令的最后，Makefile 里同样要注意位置。

解决：Makefile 链接命令写成 $(CC) $(CFLAGS) -o $(TARGET) $(OBJS) -lm -lpthread。只要用到 math.h、pthread.h、sem.h，就必须带对应库。这个坑在裸 Linux 环境第一次跑基本都会遇到。

5.5 参考代码下载后本地跑不起来

现象：从网上下载的参考代码或资料里的源码，在自己电脑上编译失败。

原因：编译器版本不同、发布环境是特定内核版本、代码里依赖某些本地路径，或者头文件缺失。

解决：先看资料里的环境说明，把 gcc、make 版本对齐。再按模块拆分编译，逐个 .c 文件执行 gcc -c 看哪个头文件缺失。最后把路径硬编码改成相对路径。参考代码不改就直接跑通的是少数，跑不通才是常态——这也是这类资料定位为“参考资料”而不是“成品作业”的原因。

6. 把参考资料变成自己的：二次开发、性能图表与内存检查

拿到这份参考资料，第一步不是打开代码文件夹，而是先读报告里的设计方案章节——它决定你对整个项目的理解深度，然后再按第 3 章的步骤把环境搭起来、编译跑通。接下来这三个小技巧，能让参考代码真正变成你自己的东西。

6.1 换算法：把 FCFS 替换成 SJF 只改一个函数

参考代码的调度逻辑如果收敛在某个调度函数里，加算法就非常容易。在 main 里加一个命令行参数做选择，新算法写成独立函数即可。SJF 非抢占版本的核心实现：

void sjf_schedule(pcb_t tasks[], int n) { int done = 0, cur_time = 0; while (done < n) { // 选出到达且未完成、剩余服务时间最短的进程 int next = -1; for (int i = 0; i < n; i++) { if (tasks[i].state == FINISHED || tasks[i].arrive_time > cur_time) { continue; } if (next == -1 || tasks[i].need_time - tasks[i].run_time < tasks[next].need_time - tasks[next].run_time) { next = i; } } if (next == -1) { cur_time++; // CPU 空闲，时间前进 continue; } cur_time += tasks[next].need_time - tasks[next].run_time; tasks[next].run_time = tasks[next].need_time; tasks[next].finish_time = cur_time; tasks[next].state = FINISHED; done++; } }

这个实现每轮扫描剩余进程里剩

本文还有配套的精品资源，点击获取