任务调度器课程设计：用C/C++实现堆、链表与时间片轮转

简介：面向大二数据结构课程设计任务的“任务调度器”C/C++实现，提供一套基于VS2019可运行、可调试的完整工程，适合作为课程设计选题参考、代码复现或综合复习样例。压缩包内包含Task.hpp、Queue.hpp、WhTaskManager.hpp等核心模块和Test.cpp主程序，并附带编译生成的可执行文件、调试符号与类图，便于对照代码理解任务队列、调度策略、优先级管理等关键设计，也能直接查看运行产物验证整体效果。资源共38个文件，以源代码、Visual Studio工程配置、调试记录和日志为主，压缩包约40.97MB，目录结构清晰；其中既有.sln、.vcxproj等工程入口，也有exe、pdb、obj等构建与调试产物，可还原完整开发过程。目前已有207人学习下载，适合在此基础上进一步扩展功能，或用于学习如何用数据结构组织实际调度系统，也能帮助梳理课设答辩中的实现思路。

1. 数据结构课程设计里的任务调度器：这份资源到底能帮你少走多少弯路

做课程设计时最焦虑的时刻，是拿到“任务调度器设计与实现”题目后，发现它既要数据结构又要操作系统概念，两头都要懂。这份 C/C++ 编写的任务调度器资源包，解决的正是这个卡点：它用最小堆维护就绪队列、用双向链表串起任务控制块、用环形队列实现时间片轮转，把堆、队列、链表、哈希表一次性串进一个可运行的程序。适合三类人：课设选题撞上调度器的在校生、想补数据结构综合应用的同学，以及需要一份完整参考实现再改造的从业者。

2. 数据结构选型：为什么堆、队列、链表一个都不能少

课程设计报告最容易翻车的部分，就是“数据结构设计”这一章。很多同学抄个数组加冒泡排序就交差，结果答辩时评委一问“你的就绪队列为什么用数组实现、复杂度多少”就卡住。任务调度器里每个数据结构都有明确职责：就绪队列决定下一个跑谁，任务控制块记录每个任务的现场，阻塞队列管理等待事件的任务，时间片轮转需要一个能循环遍历的结构。下面逐个拆。

2.1 就绪队列：最小堆才是优先级调度的正解

就绪队列要回答的问题是“当前优先级最高的任务是谁”。如果任务数量在几十个以内，用数组每次线性扫描也能跑，但复杂度是 O(n)，而且调度器每次时钟中断都要做一次选择，累积开销很可观。用最小堆实现优先队列，插入任务和取出最高优先级任务都是 O(log n)，这是教科书上优先队列的标准答案，也是这份资源里默认的实现。

// 最小堆节点，prio 数值越小优先级越高 typedef struct { int task_id; int prio; int remaining_ticks; } HeapNode; typedef struct { HeapNode *nodes; int size; int capacity; } MinHeap; // 向上调整：插入节点后恢复堆序 void heap_up(MinHeap *h, int idx) { while (idx > 0) { int parent = (idx - 1) / 2; if (h->nodes[parent].prio > h->nodes[idx].prio) { swap(&h->nodes[parent], &h->nodes[idx]); idx = parent; } else { break; } } } // 取出堆顶：与堆尾交换后向下调整 HeapNode heap_pop(MinHeap *h) { HeapNode top = h->nodes[0]; h->nodes[0] = h->nodes[--h->size]; heap_down(h, 0); return top; }

逻辑说明：这个堆把 prio 小的节点放在堆顶，用来表示“数值越小优先级越高”的约定；如果你的题目要求数值大表示优先级高，把比较符号反过来即可。取出堆顶的标准做法是先把堆顶和堆尾交换，缩小 size 后再从根节点向下调整，这样避免数组元素整体搬移。

参数说明：capacity 在初始化时按任务总数上限设定，比如 64；remaining_ticks 记录任务剩余时间片，用于后面实现时间片轮转和抢占式调度。这里要提醒一件事：堆节点里存的是任务 ID 和优先级快照，真正的任务上下文要放在 TCB 里，堆只负责“排队”，不要让堆承担状态管理。

关于大根堆还是小根堆的问题：我见过很多同学在报告里写“用大根堆实现优先级最高的任务先出队”，代码里却写成了小根堆逻辑，答辩时被指出来非常尴尬。建议在注释里直接写清比较规则，并把“prio 越小越优先”的约定放到全局头文件里，这样报告和代码能对上。

2.2 任务控制块：双向链表管理所有任务生命周期

任务控制块（TCB）是调度器的“户口本”。每个任务被创建时都要分配一个 TCB，记录任务 ID、状态、优先级、剩余时间片、上下文指针。为什么用双向链表而不是数组？因为任务会动态创建和销毁，数组删除中间元素要搬移，双向链表删除节点只需改两个指针，O(1)。而且调度器经常要正向遍历就绪队列、反向回溯父子任务，双向的灵活性在调试时特别有用。

typedef enum { READY, RUNNING, BLOCKED, DONE } TaskState; typedef struct TCB { int task_id; TaskState state; int prio; int remaining_ticks; int (*entry)(void *arg); // 任务入口函数 struct TCB *prev, *next; // 双向链表指针 } TCB; // 将节点插入链表尾部 void list_append(TCB **head, TCB *node) { if (*head == NULL) { *head = node; node->prev = node->next = NULL; return; } TCB *tail = *head; while (tail->next) tail = tail->next; tail->next = node; node->prev = tail; node->next = NULL; }

逻辑说明：TCB 里的 entry 函数指针是任务“跑起来”的入口，调度器切换上下文时只需要保存当前任务的现场、加载下一个任务的入口，不关心任务内部逻辑，这正是操作系统中进程控制块的设计思路。list_append 是通用的尾部插入，删除节点时要记得同时修复 prev 和 next 的指向，漏掉一个就会出现链表断裂，程序表现为偶发崩溃。

参数说明：task_id 建议从 0 开始递增，和数组下标对应的地方尽量一致；remaining_ticks 在每次 tick 中断里减 1，减到 0 时触发时间片轮转。prev 指针在普通单向链表里没有，但在实现“任务调度序列回放”时非常有用——你可以从运行结束的任务沿 prev 指针回溯完整调度历史，这份资源的演示数据就是这么生成的。

这里有一个常见的玄学问题：链表节点用完没释放，C 程序不报错，但跑几百个任务后内存占用肉眼可见地上涨。后面避坑章会专门讲，先记住一条：TCB 的 free 要写在任务状态变成 DONE 之后的清理流程里，不要写在调度主循环里。

2.3 时间片轮转：环形队列处理同优先级任务

就绪队列用堆能解决优先级最高的任务选择，但同优先级任务之间得公平轮转。常见做法是给每个优先级维护一个 FIFO 队列，调度器先按优先级从高到低找队列，再在当前优先级的队列里做环形遍历。这份资源里用环形数组实现这个 FIFO，而不是直接用链表，原因有两个：环形数组的缓存局部性更好，节点复用不需要频繁 malloc/free。

#define QUEUE_CAPACITY 32 typedef struct { int items[QUEUE_CAPACITY]; int head, tail; int size; } RingQueue; // 入队 int ring_push(RingQueue *q, int task_id) { if (q->size == QUEUE_CAPACITY) return -1; // 队列满 q->items[q->tail] = task_id; q->tail = (q->tail + 1) % QUEUE_CAPACITY; q->size++; return 0; } // 出队 int ring_pop(RingQueue *q, int *task_id) { if (q->size == 0) return -1; // 队列空 *task_id = q->items[q->head]; q->head = (q->head + 1) % QUEUE_CAPACITY; q->size--; return 0; }

逻辑说明：环形队列的 head 指向下一个要取出的任务，tail 指向下一个要写入的位置，取模运算让下标在队列满时绕回开头。size 字段是判断空和满的关键——如果不维护 size，光靠 head == tail 无法区分空队还是满队，这是环形队列最容易踩的坑。

参数说明：QUEUE_CAPACITY 取多大取决于你的任务数上限。课设场景 32 通常够用，但如果你要模拟几百个任务，建议改成动态扩容版本，或者直接用链表队列。ring_push 返回 -1 表示队列满，这里的处理策略是让任务保持 READY 状态留在堆里等待，而不是丢弃任务，丢任务在答辩时会被追问。

3. 实现路径：五步把调度器从空文件搭成可运行程序

选型讲完了，下面是这份资源里真正能照着抄的搭建顺序。我一般不建议一次写完再编译，而是按“状态机 → 调度算法 → 模拟器 → 日志 → 测试”五步推进，每一步都能独立验证。这样写的好处是出了问题知道去哪儿查，而不是面对一个几百行的文件无从下手。

3.1 第一步：定义任务状态机和转换表

任务调度器的核心不是调度算法，而是状态机。一个任务的生命周期有四个状态：就绪（READY，等待被调度）、运行（RUNNING，占用 CPU）、阻塞（BLOCKED，等待某个事件）、完成（DONE，执行结束）。状态转换的合法路径只有四条：READY→RUNNING（被调度选中）、RUNNING→READY（时间片耗尽或被抢占）、RUNNING→BLOCKED（任务主动等待 I/O）、BLOCKED→READY（事件到达）。

const char *state_name(TaskState s) { switch (s) { case READY: return "READY"; case RUNNING: return "RUNNING"; case BLOCKED: return "BLOCKED"; case DONE: return "DONE"; default: return "UNKNOWN"; } } // 检查状态转换是否合法：返回 0 合法，返回 -1 为非法转换 int check_transition(TaskState from, TaskState to) { if (from == READY && to == RUNNING) return 0; if (from == RUNNING && (to == READY || to == BLOCKED)) return 0; if (from == BLOCKED && to == READY) return 0; if (from == RUNNING && to == DONE) return 0; return -1; }

逻辑说明：把状态转换写成一张显式检查表，看似多写了代码，实际上帮了大忙。调度器在切换任务前先调用 check_transition 做合法性校验，任何非法转换（比如从 BLOCKED 直接到 DONE）都会在运行时暴露，而不是让程序带着错误状态跑下去。调试时在 check_transition 返回 -1 的分支里打印 from 和 to，能省下大量查错时间。

参数说明：state_name 用于日志输出，这份资源的每个任务事件都会打印“时间戳、任务ID、旧状态、新状态”，配合后面的模拟器就能画出完整的调度甘特图。check_transition 的返回值约定为 0 或 -1，而不是 1/0，这样 if 语句里可以直接判断负值，避免把 0 当成功和失败搞混。

3.2 第二步：实现核心调度函数 schedule_next

调度函数只有一个责任：从就绪队列里挑出下一个要运行的任务。这里用到的策略是可抢占的静态优先级调度：新任务到达时如果优先级高于当前运行任务，立即发生抢占；否则进入就绪队列等待。对于同优先级任务，按先来先服务处理。

TCB *schedule_next(TCB *current, MinHeap *ready_heap) { if (ready_heap->size == 0) { return NULL; // 没有就绪任务，调用方进入 idle 分支 } HeapNode next = heap_pop(ready_heap); TCB *next_tcb = find_tcb(next.task_id); if (current != NULL && current->state == RUNNING) { if (next.prio < current->prio) { // 新任务优先级更高，抢占当前任务 current->state = READY; heap_push(ready_heap, make_node(current->task_id, current->prio)); } else { // 当前任务继续运行，把刚取出的节点放回堆 heap_push(ready_heap, next); return current; } } next_tcb->state = RUNNING; return next_tcb; }

逻辑说明：这个函数的判断顺序很关键——先看堆是否为空，再看当前任务是否存在，最后比较优先级。很多同学的翻车点在于把“当前任务重新入堆”写在了“取出新任务”之前，导致当前任务又可能被自己抢走，形成活锁。正确的顺序是先从堆里弹出候选者，再决定是换人还是把候选者放回去，这样堆的平衡次数最少。

参数说明：make_node 是包装函数，负责把 task_id 和 prio 组装成 HeapNode；find_tcb 用线性查找或哈希表根据 task_id 找到 TCB 指针。这里的抢占条件是 next.prio < current->prio，也就是数值小的优先级高；如果你的题目约定反过来，抢占条件要同步反转，否则高优先级任务永远无法抢占。

3.3 第三步：搭建模拟时钟和任务生成器

调度器本身不产生时间，它靠外部的 tick 信号驱动。这份资源里用一个模拟时钟线程或者一个简单的 for 循环来模拟时钟中断：每 tick 一次，就遍历所有任务，给 RUNNING 任务的 remaining_ticks 减 1，减到 0 就触发一次调度。任务生成器则负责按预定义的到达时刻创建任务。

TCB *current = NULL; // 全局当前运行任务 typedef struct { int arrive_tick; // 任务到达时刻 int prio; // 优先级 int exec_ticks; // 需要的 CPU 时间 int (*func)(void*); // 任务入口 } TaskSpec; void run_simulation(TaskSpec specs[], int n, int total_ticks) { MinHeap heap; init_heap(&heap, 64); int next_spec = 0; for (int tick = 0; tick < total_ticks; tick++) { // 1. 到达的任务进入就绪堆 while (next_spec < n && specs[next_spec].arrive_tick == tick) { create_task(specs[next_spec], &heap); next_spec++; } // 2. 时钟中断：当前任务消耗一个时间片 if (current && current->state == RUNNING) { current->remaining_ticks--; if (current->remaining_ticks <= 0) { current->state = DONE; schedule(&heap); } } // 3. 完成阻塞任务的唤醒检查 wake_up_blocked(tick); // 4. 输出当前时刻的快照 log_snapshot(tick, current, &heap); } }

逻辑说明：这个模拟器的骨架是“每 tick 依次做四件事：收新任务、消耗当前任务时间片、唤醒阻塞任务、记录日志”。顺序不能乱——先收新任务，才能让新任务有机会在同一个 tick 内抢占；先消耗时间片，才能触发自然完成。wake_up_blocked 里只负责把阻塞条件满足的任务从阻塞队列挪回就绪堆，不参与调度决策。

参数说明：total_ticks 是模拟总时长，取多少取决于你的任务集，一般取所有任务 exec_ticks 之和的两倍以上，留出阻塞等待的余量；next_spec 是任务生成器的游标，任务数组要按 arrive_tick 升序排列，否则 while 里的相等判断会漏掉任务。这个生成器的设计是这份资源里比较实用的部分，你可以只改 specs 数组来构造不同压力场景，不需要改调度代码。

3.4 第四步：日志和调度序列回放

没有日志的调度器是黑匣子，跑完你不知道它到底干了什么。这份资源里所有调度事件都写到一份 CSV 格式的日志文件，事件类型包括 task_create、task_start、task_preempt、task_done、task_block、task_wake。每行记录统一格式：tick，task_id，event，detail。这样后面可以用脚本统计分析调度延迟、响应时间、CPU 利用率。

void log_event(int tick, int task_id, const char *event, int detail) { // 输出格式: tick,task_id,event,detail fprintf(log_fp, "%d,%d,%s,%d\n", tick, task_id, event, detail); } // 记录一次的优先级抢占 if (preempted) { log_event(tick, current->task_id, "task_preempt", next->task_id); }

逻辑说明：log_event 里的 detail 字段是灵活使用的：抢占事件里它是被抢任务的 ID，任务完成事件里它是实际消耗的 tick 数。日志文件用逗号分隔是为了后续能用 Python 或 Excel 直接打开做图表，这是课设报告里最加分的素材——一张调度时间线图就够证明你的调度器行为正确。

参数说明：log_fp 是全局的文件指针，初始化时用 fopen("schedule_log.csv", "w") 打开并在 main 结束时 fclose。要注意 fprintf 的频繁调用会拖慢模拟速度，如果你要模拟十万个 tick，建议先写入缓冲区再一次性 flush，或者用 log_batch 结构攒一批再写。否则模拟跑几分钟才出结果，会怀疑是调度算法写错了。

这里还有个细节，任务进入 DONE 状态后，它的原执行现场要不要保留？保留可以，但堆节点已经 pop 走了。我一般会把 DONE 任务的执行信息单独存一个完成列表，方便报告里统计“平均周转时间”。“平均周转时间 =（完成时刻 − 到达时刻）之和 / 任务数”，这个公式写在报告里是基本分，能给出对比数据才算亮点。

4. 任务调度器常见问题与避坑手册：五个必查点

写调度器最折磨人的不是写不出来，而是跑起来之后的表现“看起来对但说不准”。以下五条踩坑记录来自这份资源反复调试中最常被问到的点，每一条我都标了现象、原因和解决方式。建议你的程序出现问题的时候，按这个顺序排查。

4.1 现象：高优先级任务迟迟得不到运行

你构造了一个高优先级任务在低优先级任务之后到达，按理说应该立即抢占，但日志显示低优先级任务一直跑到结束。

原因：抢占逻辑里取了堆顶后没有和当前任务比较优先级，而是直接切换了任务；或者是当前任务在 schedule_next 里被重新压回堆时，堆的大小没变，但优先级比较用的是“弹入顺序”而不是“优先级值”。

解决：第一步在 schedule_next 入口处打印 current 和 next 的 prio，确认数值方向正确；第二步检查 make_node 包装时是否把优先级字段传反。我见过最多的翻车是把 high_prio 用数值 1 表示、low_prio 用数值 10 表示，但比较符号写成了大于号，导致低优先级数字 10 反而被认为更“大”而优先。建议全代码里统一用 PRIO_HIGH=0、PRIO_LOW=255 这种跨度大的数值，数字越大优先级越低，一眼不容易反。

4.2 现象：模拟几千个任务后内存持续上涨

任务创建、销毁循环跑，内存占用却只增不减。用工具看进程的内存，稳定上涨不回落的曲线。

原因：最典型的是 TCB 从链表上卸载后没有被 free；其次是环形队列已满时 ring_push 返回 -1，但调用方忽略返回值，任务 ID 没有入队却也进入了后续处理流程，造成逻辑节点泄漏。还有一个小众原因：堆里的节点扩容时机不对，重新分配时把部分节点遗留在旧内存里。

解决：先统计任务创建数和销毁数是否相等，在 log_event 里加 task_free 事件。TCB 的卸载函数 list_remove 和 free 必须成对出现。ring_push 的调用处改为：

int ret = ring_push(&rq, task_id); if (ret != 0) { // 队列满时任务进入“延迟入队”集合，下一 tick 重试 push_delay_queue(task_id); }

这条改完基本就能堵住大部分泄漏。另外，动态扩容堆时把旧的 HeapNode 数组指针先保存在局部变量里，free 掉再赋值新指针，避免覆盖导致内存块丢失。

4.3 现象：相同输入两次运行，调度序列不一样

程序的日志输出两次不一致，执行顺序发生变化，没法复现，写报告时根本无法说明实验结论。

原因：多半是用了未初始化的局部变量，或者哈希表遍历顺序依赖了链表地址。在 C 语言里，malloc 返回的内存不一定清零，结构体里遗留的随机值会干扰链表比较和堆排序的稳定性。也可能是因为你的模拟器里用了随机数做阻塞任务的唤醒顺序，而随机种子没有固定。

解决：第一，所有 TCB、HeapNode 分配后立即 memset 清零或者用 calloc；第二，避免依赖系统时钟做任何调度决策，模拟场景里统一用 tick 序号。第三，如果你用了 rand() 模拟任务执行时间，必须在 main 开头固定 srand(42)，并且把种子值写进配置头文件，这样报告里能声明“随机种子固定，实验结果可复现”。这是答辩时非常拉好感的一个细节。

4.4 现象：时间片轮转后任务“丢”了

某个任务运行完一个时间片后，下一次轮到它时日志里找不到它的记录，整个任务就好像从调度器里消失。

原因：时间片减到 0 时，代码把任务状态直接置为 DONE，却没有检查这个任务是否还需要继续执行。比如 exec_ticks 已经用光但不是最后一次使用，或者剩余时间片归零但任务还没执行完。另一种可能是环形队列的 head 和 tail 更新时少写了一个取模，越界写覆盖了任务 ID。

解决：把“时间片耗尽”和“任务执行完成”两个条件分清楚。时间片耗尽只触发轮转，任务重新入队并重置时间片；任务执行完成以 entry 函数返回值为准。检查环形队列的下标更新是否都带 % QUEUE_CAPACITY，尤其是 head 自增的那一条。我习惯在 ring_pop 的入口处打印 q->head 和 q->tail 的值，轮回几次就能看出下标是否越界。

4.5 现象：空堆时 schedule_next 返回非法指针

模拟器跑批任务，全部完成后调度器仍然被 tick 驱动调用，此时堆已空，函数返回了野指针，程序崩溃。

原因：schedule_next 里只处理了堆不为空的分支，堆为空时没有 return。C 语言不会自动补默认返回值，函数末尾的返回值是上次调用遗留在寄存器里的垃圾值，运行结果完全看运气。

解决：堆为空时返回 NULL，并且调用方要处理 NULL 的情形——通常进入 idle 分支，什么都不做，等下一个 tick。这看起来简单，但很多同学把 NULL 检查写在了堆操作之前，导致堆本身还没初始化就调用 heap_pop，同样崩溃。顺序应该是：先检查堆指针和 size，再调用 heap_pop，最后再判断拿回来的节点合法性。

5. 验证调度器正确性：构造任务集、画时间线、算指标

代码写完只是第一步，课程设计能不能拿高分，取决于你能不能证明调度器是“对”的。这里提供一个可复现的验证流程，从构造任务集到计算指标，每一步都有明确标准。这份资源里的演示数据和验证脚本就是按这个流程生成的，你可以直接改参数复现。

5.1 构造一组能覆盖所有转换的任务集

验证不是随便扔几个任务进去跑通就完了。要覆盖每个状态转换分支，你的任务集里至少要有：不同到达时刻的任务、不同优先级的任务、会主动阻塞的任务、执行时间不同的任务。下面是一个参考任务集，5 个任务覆盖了抢占、阻塞、轮转三种情况。

任务ID	到达时刻	优先级(数值)	总执行时间	行为
T1	0	1	4 tick	纯计算
T2	1	3	6 tick	第2个tick阻塞1个tick
T3	2	0	7 tick	纯计算
T4	3	1	3 tick	与T1同优先级，验证FIFO
T5	10	1	2 tick	晚到短任务

逻辑说明：这个任务集故意设计了几个关键点——T3 在 T1、T2 之后到达但优先级最高，用来验证抢占；T1 和 T4 同优先级且到达时刻不同，用来验证同优先级队列的 FIFO 行为；T2 在运行途中主动阻塞一次，用来验证 BLOCKED→READY 的唤醒路径；T5 晚到且只需要短时间，用来验证调度器能否在尾部快速收尾。如果日志里这四类行为都出现了，才算覆盖完整。

参数说明：优先级数值越小优先级越高的约定不变。T2 的“第 2 个 tick 阻塞”要在任务入口函数里自己写一个“模拟 IO”的调用，参考代码如下：

int task_with_block(void *arg) { // 第 2 个 tick 模拟 IO 等待 if (current_tick() == 2) { block_self(5); // 阻塞 5 个 tick 后自动唤醒 } do_compute(); return 0; }

逻辑说明：block_self 会把当前任务状态改为 BLOCKED，并将它移出就绪堆、挂到阻塞队列，阻塞时间到后再由 wake_up_blocked 移回就绪堆。没有阻塞任务的调度器验证是不完整的，因为 BLOCKED 状态是整个状态机里最容易写错的一环。

5.2 用日志生成时间线并核对调度序列

跑完模拟后，schedule_log.csv 里每一行是一个事件。我常用的验证方法是从日志里抽取 task_start 和 task_preempt 事件，按 tick 排序后画一条横向时间线，每个任务的执行区间用不同符号表示。核对标准也很简单：同一时刻只能有一个 RUNNING 任务；任务的状态转换顺序必须合法；高优先级任务的响应时间应明显短于低优先级任务。

# 提取任务开始事件，按 tick 数字排序 grep ",task_start\|,task_preempt" schedule_log.csv | awk -F',' '{print $1" "$2" "$3" "$4}' | sort -n -k1,1 | head -50

逻辑说明：awk 按逗号切分出 tick、task_id、event、detail 四个字段，只保留开始和抢占事件。排序后用肉眼扫一遍，重点看有没有两个任务在同一个 tick 处于 RUNNING——如果有，说明上一个任务没被正确置为 READY。这个检查我给同学查过无数次，是能最快定位“串行执行被破坏”的命令。

参数说明：如果日志量很大，head -50 可以改成 awk 的区间条件限定时间窗口；sort -n -k1,1 按第一列做数字排序，而不是默认字典序——字典序里 10 会排在 2 前面，初学者很容易对着错乱的时间线白调试半天。

除了事后核查，更可靠的是在模拟器里加运行时断言。下面这个不变式检查函数，每个 tick 末尾调用一次，发现异常立即终止并报错：

// 不变式检查：同一时刻最多只能有一个 RUNNING 任务 void check_invariants(TCB *list, TCB *current) { int running_count = 0; for (TCB *p = list; p; p = p->next) { if (p->state == RUNNING) running_count++; } if (running_count > 1 || (current == NULL && running_count > 0)) { log_event(-1, -1, "invariant_violation", running_count); exit(1); } }

逻辑说明：check_invariants 的价值在于把“肉眼核对”变成“自动校验”。只要不变式被破坏，程序立刻停在出错点附近，而不是带着错误继续跑几百个 tick 后产生一份看似正常的日志。我在 debug 版本里每个 tick 末尾都调用它，release 版本再关掉，因为链表遍历有额外开销。

参数说明：current 为空但 running_count 大于 0 的情况，说明调度器已经认为没有任务在运行、链表里却还有任务停留在 RUNNING，这是状态机清理不彻底导致的，属于逻辑 bug，不是性能问题。

5.3 计算三项核心性能指标

课程设计报告里最好用的三个指标是：平均周转时间、平均响应时间、CPU 利用率。周转时间可以验证调度整体效率，响应时间可以验证高优先级抢占是否生效，CPU 利用率可以验证空闲处理是否正常。

平均周转时间 =（完成时刻 − 到达时刻）之和 / 任务数；平均响应时间 =（首次运行时刻 − 到达时刻）之和 / 任务数；CPU 利用率 = 非空闲 tick 数 / 总 tick 数。

typedef struct { int arrive_tick; int first_run_tick; int done_tick; } TaskStat; void compute_stats(TaskStat stats[], int n, int total_ticks) { int sum_turnaround = 0, sum_response = 0, busy_ticks = 0; for (int i = 0; i < n; i++) { sum_turnaround += stats[i].done_tick - stats[i].arrive_tick; sum_response += stats[i].first_run_tick - stats[i].arrive_tick; } // busy_ticks 在模拟时每 tick 累加一次：current != NULL 时 +1 printf("平均周转时间: %.2f\n", (double)sum_turnaround / n); printf("平均响应时间: %.2f\n", (double)sum_response / n); printf("CPU利用率: %.2f%%\n", 100.0 * busy_ticks / total_ticks); }

逻辑说明：三个指标是答辩时最常被追问的。compute_stats 里 first_run_tick 的赋值时机很关键——任务第一次从 READY 变 RUNNING 的时刻，而不是任务被创建的时刻。很多同学把这个搞混，导致响应时间算成负的。busy_ticks 的累加位置应该在模拟时钟的主循环里，而不是在调度函数里，否则一个 tick 内多次调度会把计数重复累加。

参数说明：注意三个指标都是平均值，当任务数 n 很大时，周转时间容易受单个长任务的延迟影响。如果你要比较不同调度策略的优劣，固定任务集，分别跑“优先级调度”和“时间片轮转”，然后对比这两个平均值，这是报告里最有含金量的实验数据。对于小任务集，CPU 利用率高低说明不了调度策略的好坏，别单独拿它当结论。

6. 进阶：让调度器从课设变成可扩展的调度内核

如果时间有余，我建议给这个调度器加一个通用性改造，从写死的一组函数变成可以面向不同策略的框架。这份资源里已经有最初的钩子设计，你可以顺着下面的路径继续扩展。加一个调度策略接口，用函数指针数组保存不同策略的 schedule_next 实现，在配置头文件里用宏选择当前策略。

typedef TCB* (*SchedulerFn)(TCB*, MinHeap*); SchedulerFn schedulers[] = { priority_schedule, // 策略0：优先级抢占 round_robin_schedule, // 策略1：时间片轮转 priority_rr_schedule, // 策略2：优先级+时间片混合 }; #define CURRENT_SCHEDULER 2

逻辑说明：这个设计把调度策略和模拟器主循环解耦。改策略只需要换一个函数指针，不需要动模拟时钟、任务生成器和日志模块，非常适合做不同调度算法的对比实验。你可以在这个基础上写一个“对比三组指标”的测试入口，一次模拟分别跑三种策略，输出对比表格。策略 2 往往比纯优先级抢占更实用，因为它兼顾了低优先级任务的公平性，也是课设报告里展示深度的好例子。

参数说明：CURRENT_SCHEDULER 用宏定义而不是运行时参数，是为了让编译器在编译期就确定函数指针，减少调度路径上的分支。如果你需要运行时切换，可以把宏改成全局变量，但要注意调度函数里不能有局部状态的累积——因为切换策略后，堆里的残留节点可能不符合新策略的不变量。我第一次做这个改造时，就因为在优先级调度下运行一半切到轮转策略，结果堆里积压的高优先级任务全部乱序，日志输出像乱码，花了一晚上才意识到是“策略切换时应该清空堆并重置 TCB 状态”。

从那以后，我每次做调度器的课设改造，都会先画一张状态转换图、固定优先级数值方向、再把日志事件类型统一定义在头文件里。这几步看起来基础，但它们决定了后续排查问题的时间是一个小时还是一上午。这份资源的代码和数据也是按这个顺序整理的，希望帮到你。

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