1. 操作系统实验课到底在折腾什么

1.1 从“一脸懵”到“有点数”的认知转变

操作系统实验课，很多人第一次打开实验指导书的时候，脑子里就三个字：看不懂。进程调度、内存管理、文件系统、信号量、死锁检测，这些词单独拆开每个字都认识，拼在一起就不知道在说什么。我当年第一次做这个实验的时候，对着屏幕发了半小时呆，完全不知道从哪里下手。后来踩了足够多的坑，才慢慢摸清楚这门课到底想让你干什么。

说白了，操作系统实验课的核心目标就一个：让你亲手实现操作系统里的几个关键机制。不是让你从零写一个完整的操作系统，那是另一个量级的工程。实验课做的事情更像是——操作系统这门课讲了进程怎么调度、内存怎么分配、文件怎么读写，但这些都是理论，你只是“知道”有这么回事。实验课就是把这些理论变成代码，让你真正看到进程队列怎么排、页面怎么换入换出、文件描述符怎么被管理。

这个专题我打算把操作系统实验课里最常出现的几个实验方向拆开来讲，包括进程管理与调度、内存管理、文件系统、同步与互斥、死锁处理。每个方向我会说清楚三件事：这个实验到底要你做什么、核心代码怎么写、以及最容易在哪里翻车。适合正在上这门课的同学，也适合想复习操作系统底层机制的人。

1.2 实验课和理论课的关系

很多人把操作系统理论课和实验课当成两门独立的课来对待，这是最大的误区。理论课讲的是“为什么”，实验课做的是“怎么做”。比如理论课告诉你时间片轮转调度算法的原理是每个进程分配一个固定时间片，用完就排到队尾。实验课要你写代码实现这个逻辑，你就会遇到一堆理论课上不会讲的问题：时间片设多大合适？进程的到达时间怎么处理？如果就绪队列为空但还有进程没到达怎么办？

这些问题在理论课上不会出现，因为理论课默认所有进程同时到达、CPU永远不空闲。但实验课里你必须处理这些边界情况。所以我的建议是，做实验的时候不要只盯着实验指导书，回头翻翻理论课的教材，把对应的章节重新看一遍，你会发现很多之前忽略的细节。

提示：实验指导书通常只给框架和接口，不会告诉你完整的实现思路。遇到卡壳的时候，先回去看理论课对应章节的伪代码，大部分实验的核心逻辑都能从教材里找到影子。

2. 进程管理与调度实验的核心拆解

2.1 进程调度实验到底要你实现什么

进程调度实验是操作系统实验课里出现频率最高的一个。典型的实验要求是这样的：给定一组进程，每个进程有到达时间、服务时间、优先级等属性，要求你实现几种调度算法（比如先来先服务、短作业优先、时间片轮转、优先级调度），然后输出每个进程的完成时间、周转时间、带权周转时间等指标。

看起来很简单对吧？但实际写起来，坑非常多。第一个坑是进程状态的建模。很多同学一上来就定义一个结构体，把进程的所有属性塞进去，然后写一个循环去模拟调度。但问题是，进程的状态是动态变化的——它可能在等待、可能在运行、可能在就绪队列里排队。如果你不把状态管理好，代码写到后面就会变成一团乱麻。

我的做法是，用一个枚举类型明确表示进程的几种状态：

typedef enum { STATE_READY, // 就绪 STATE_RUNNING, // 运行 STATE_WAITING, // 等待（比如等待I/O） STATE_FINISHED // 完成 } ProcessState;

然后在进程结构体里加上状态字段。每次调度之前，先根据当前时间和进程的到达时间，把所有应该进入就绪队列的进程状态更新一遍。这个“状态更新”的步骤很多人会忽略，导致调度逻辑和实际时间对不上。

2.2 时间片轮转调度的实现细节

时间片轮转（Round Robin）是看起来最简单但实现起来最容易出错的调度算法。核心逻辑是：维护一个就绪队列，每次从队头取出一个进程运行一个时间片，如果运行完还有剩余服务时间，就把它放回队尾。

听起来很简单，但有几个关键问题需要处理：

第一个问题：新到达的进程什么时候入队？假设时间片大小是2，当前时间从0开始，进程A在时间0到达，进程B在时间1到达。如果你在时间0取出A运行，运行到时间2，那么B在时间1到达的时候应该立刻入队。但如果你在时间2才处理B的入队，B就白白等了1个时间单位。正确的做法是，在每个时间片开始之前，先把所有到达时间小于等于当前时间的进程加入就绪队列。

第二个问题：时间片大小怎么选？实验指导书通常会给定时间片大小，但如果没有给定，你需要自己选一个合理的值。时间片太小会导致频繁的上下文切换，开销增大；时间片太大会退化成先来先服务。一般来说，时间片大小取所有进程平均服务时间的1/2到1/4比较合适。比如平均服务时间是10，时间片可以取3或5。

第三个问题：如果就绪队列为空但还有进程没完成怎么办？这种情况说明CPU空闲了，当前时间需要跳到下一个进程的到达时间。很多同学的代码在这里会死循环，因为就绪队列为空，取不出进程，但时间又没有推进。正确的做法是：

if (ready_queue_is_empty() && !all_finished()) { current_time = next_arrival_time(); // 跳到下一个进程到达的时间 continue; }

这个逻辑一定要加上，否则程序会卡死。

2.3 周转时间和带权周转时间的计算

调度算法跑完之后，通常需要输出每个进程的周转时间和带权周转时间。周转时间 = 完成时间 - 到达时间，带权周转时间 = 周转时间 / 服务时间。这两个公式很简单，但计算的时候要注意：完成时间是指进程最后一次获得CPU并运行完毕的时间，不是进程开始运行的时间。

我见过有同学把开始运行时间当成完成时间，结果算出来的周转时间全是错的。还有一个容易出错的地方是，如果进程有等待I/O的时间，周转时间应该包含等待时间。但大部分实验为了简化，不涉及I/O等待，所以周转时间就是完成时间减去到达时间。

下面是一个典型的输出格式：

这个表格看起来简单，但每个数字背后都是调度逻辑的体现。如果你算出来的带权周转时间小于1，那一定是哪里出错了，因为周转时间不可能小于服务时间。

注意：带权周转时间反映的是进程的等待时间相对于服务时间的比例。带权周转时间越大，说明进程等待的时间越长，调度算法对该进程越不友好。平均带权周转时间是衡量调度算法性能的重要指标。

3. 内存管理实验的实操要点

3.1 页面置换算法的核心逻辑

内存管理实验里最常见的是页面置换算法，包括最佳置换（OPT）、先进先出（FIFO）、最近最久未使用（LRU）和时钟算法（Clock）。这些算法的核心区别在于：当内存满了需要换出页面时，选择哪个页面换出。

最佳置换算法（OPT）是理论上的最优解，它选择未来最长时间不会被访问的页面换出。但问题是，你不可能预知未来的访问序列，所以OPT在实际系统中无法实现，只能作为衡量其他算法性能的基准。实验里实现OPT的时候，你需要遍历未来的访问序列，找到每个页面下一次出现的位置，然后选择位置最靠后的那个页面换出。

先进先出算法（FIFO）最简单，用一个队列维护页面的进入顺序，换出队头页面即可。但FIFO有一个著名的异常现象叫Belady异常——增加物理块数反而可能导致缺页率上升。这个现象在实验里可以通过对比不同物理块数下的缺页次数来观察。

最近最久未使用算法（LRU）选择最长时间没有被访问的页面换出。实现LRU的关键是维护页面的访问顺序。常见的方法是用一个链表，每次访问一个页面就把它移到链表头部，换出的时候选择链表尾部的页面。也可以用计数器或者栈来实现。

时钟算法（Clock）是LRU的近似实现，它给每个页面维护一个访问位，页面排成一个环形队列。当需要换出页面时，从当前指针开始扫描，如果访问位是1就置为0并继续扫描，直到找到访问位为0的页面换出。时钟算法在实际系统中用得很多，因为它实现简单且性能接近LRU。

3.2 缺页率的计算与对比分析

页面置换算法跑完之后，通常需要计算缺页率。缺页率 = 缺页次数 / 总访问次数。这个公式很简单，但实验的重点不是算出缺页率，而是对比不同算法在不同访问序列下的表现。

我建议在做实验的时候，准备几组不同的访问序列，比如：

• 随机序列：模拟随机访问模式
• 局部性序列：模拟程序的时间局部性和空间局部性
• 循环序列：模拟循环访问模式

然后用每种算法跑一遍，把缺页率记录下来，做成表格对比。你会发现一些有意思的现象：LRU在局部性好的序列上表现很好，但在循环序列上可能不如FIFO；OPT永远是最优的，但和其他算法的差距在不同序列下差别很大。

下面是一个对比表格的示例：

这个表格能帮你直观地理解每种算法的适用场景。OPT虽然最优但不可实现，LRU在局部性好的场景下接近OPT，FIFO在循环序列下可能表现更稳定。

3.3 物理块数对缺页率的影响

物理块数（也就是分配给进程的内存页框数）对缺页率的影响非常大。一般来说，物理块数越多，缺页率越低。但这个关系不是线性的，存在一个“拐点”——当物理块数增加到一定程度后，缺页率的下降会变得非常缓慢。

在实验里，你可以固定访问序列和算法，改变物理块数，观察缺页率的变化。比如物理块数从1增加到10，缺页率可能从0.8降到0.3，但从10增加到20，缺页率可能只从0.3降到0.25。这个拐点的位置取决于访问序列的局部性程度。

提示：实验报告里如果要求分析物理块数对缺页率的影响，不要只写“物理块数越多缺页率越低”，要具体说明在什么范围内下降明显、什么范围内趋于平缓，最好附上数据表格或曲线图。

4. 文件系统实验的完整实现路径

4.1 文件系统的核心数据结构

文件系统实验通常要求实现一个简单的文件系统，支持文件的创建、删除、读写、目录管理等功能。这个实验的难点在于数据结构的设计。你需要设计超级块、inode、目录项、数据块等结构，并定义它们之间的关系。

超级块（Superblock）是整个文件系统的元数据，记录文件系统的总块数、空闲块数、inode总数、空闲inode数等信息。超级块通常在文件系统挂载时被读入内存，卸载时写回磁盘。

inode（索引节点）是文件的核心数据结构，记录文件的类型、大小、权限、创建时间、修改时间以及数据块的索引。每个文件对应一个inode，inode号是文件的唯一标识。inode里通常包含多级索引指针，比如直接指针、一级间接指针、二级间接指针等，用来支持大文件。

目录项（Directory Entry）是目录文件的内容，每个目录项记录一个文件名和对应的inode号。目录本身也是一种文件，它的数据块里存放的就是目录项列表。

数据块（Data Block）是实际存储文件内容的地方。文件系统把磁盘分成固定大小的块（比如4KB），每个块可以分配给一个文件使用。

这些数据结构之间的关系可以用一个简单的例子来说明：当你打开一个文件时，系统先根据路径找到目录文件，在目录文件的数据块里查找文件名对应的inode号，然后根据inode号读取inode，再从inode的数据块指针找到文件内容。

4.2 文件创建与删除的实现细节

文件创建的过程分为几步：首先在目录文件中添加一个目录项，分配一个空闲的inode，然后初始化inode的各个字段。这里的关键是空闲inode和空闲块的分配。你需要维护一个空闲inode位图和一个空闲块位图，每次分配时扫描位图找到第一个为0的位，将其置为1，并返回对应的编号。

文件删除的过程相反：先释放inode和它占用的所有数据块（把位图中对应的位清零），然后从目录文件中删除对应的目录项。这里有一个容易忽略的地方：如果文件很大，占用了多级索引块，删除时需要递归释放所有间接索引块。很多同学只释放了直接块，忘记释放间接块，导致空闲块数对不上。

// 释放inode占用的所有数据块 void free_inode_blocks(int inode_num) { Inode *inode = read_inode(inode_num); // 释放直接块 for (int i = 0; i < DIRECT_BLOCKS; i++) { if (inode->direct[i] != 0) { free_block(inode->direct[i]); } } // 释放一级间接块 if (inode->indirect1 != 0) { int *blocks = read_block(inode->indirect1); for (int i = 0; i < BLOCK_SIZE / sizeof(int); i++) { if (blocks[i] != 0) { free_block(blocks[i]); } } free_block(inode->indirect1); } // 二级间接块类似处理... }

4.3 文件读写与目录遍历

文件读写是文件系统实验里最复杂的部分，因为涉及到偏移量的计算和块的定位。当你读取文件的第N个字节时，需要先算出这个字节在哪个数据块里，然后从那个块的对应偏移位置开始读。

假设块大小是4KB，直接块有12个，那么前48KB的数据可以直接通过直接块访问。超过48KB的部分需要通过一级间接块访问，超过48KB + 4KB * 1024 = 4MB + 48KB的部分需要通过二级间接块访问。这个计算过程在实验里一定要写清楚，否则读写大文件的时候会出错。

目录遍历相对简单，就是读取目录文件的数据块，把里面的目录项逐个读出来，匹配文件名。但要注意目录项的结构——通常包含文件名和inode号，文件名有最大长度限制。如果文件名超过限制，需要特殊处理。

注意：文件系统实验里最容易出错的地方是边界条件。比如文件大小为0时怎么处理、读写偏移超过文件大小时怎么处理、目录为空时怎么处理。这些边界条件在实验指导书里通常不会明确说明，但测试的时候一定会考到。

5. 同步与互斥实验的经典问题

5.1 生产者-消费者问题的实现

生产者-消费者问题是同步与互斥实验里最经典的题目。问题描述很简单：一个缓冲区，生产者往里面放数据，消费者从里面取数据，缓冲区满了生产者要等待，缓冲区空了消费者要等待。

这个问题的核心是信号量的使用。你需要三个信号量：一个互斥信号量mutex用来保护缓冲区的互斥访问，一个信号量empty表示空闲缓冲区的数量，一个信号量full表示已占用缓冲区的数量。

sem_t mutex; // 互斥访问缓冲区 sem_t empty; // 空闲缓冲区数量 sem_t full; // 已占用缓冲区数量 // 初始化 sem_init(&mutex, 0, 1); sem_init(&empty, 0, BUFFER_SIZE); sem_init(&full, 0, 0); // 生产者 void producer() { while (1) { produce_item(); sem_wait(&empty); // 等待空闲缓冲区 sem_wait(&mutex); // 进入临界区 insert_item(); sem_post(&mutex); // 离开临界区 sem_post(&full); // 增加已占用缓冲区数量 } } // 消费者 void consumer() { while (1) { sem_wait(&full); // 等待已占用缓冲区 sem_wait(&mutex); // 进入临界区 remove_item(); sem_post(&mutex); // 离开临界区 sem_post(&empty); // 增加空闲缓冲区数量 consume_item(); } }

这段代码看起来简单，但有一个非常容易出错的地方：sem_wait的顺序。如果生产者先wait mutex再wait empty，就会死锁。因为如果缓冲区满了，生产者持有mutex等待empty，消费者无法进入临界区取数据，empty永远不会增加，生产者永远等下去。正确的顺序是先wait资源信号量（empty/full），再wait互斥信号量（mutex）。

5.2 读者-写者问题的变体

读者-写者问题是另一个经典同步问题，分为读者优先、写者优先和公平竞争三种变体。读者优先的策略是：只要有读者在读，写者就必须等待；写者优先的策略是：一旦有写者等待，后续的读者也必须等待。

读者优先的实现相对简单，用一个计数器记录当前读者的数量，第一个读者进入时wait写信号量，最后一个读者离开时post写信号量。写者优先需要额外的信号量来阻止新读者在写者等待时进入。

// 读者优先 int reader_count = 0; sem_t mutex; // 保护reader_count sem_t write_lock; // 写者互斥 void reader() { sem_wait(&mutex); reader_count++; if (reader_count == 1) { sem_wait(&write_lock); // 第一个读者锁住写者 } sem_post(&mutex); read_data(); sem_wait(&mutex); reader_count--; if (reader_count == 0) { sem_post(&write_lock); // 最后一个读者释放写者 } sem_post(&mutex); } void writer() { sem_wait(&write_lock); write_data(); sem_post(&write_lock); }

这个实现有一个潜在问题：如果读者不断到来，写者可能永远等待。这就是读者优先的缺点。如果要实现写者优先，需要增加一个信号量来阻止新读者在写者等待时进入。

5.3 死锁检测与避免

死锁检测实验通常要求实现银行家算法。银行家算法的核心思想是：在分配资源之前，先判断这次分配是否会导致系统进入不安全状态。如果会，就拒绝分配；如果不会，就正式分配。

银行家算法的数据结构包括：可用资源向量Available、最大需求矩阵Max、分配矩阵Allocation、需求矩阵Need。算法步骤如下：

1. 检查Request是否小于等于Need，如果不满足则报错
2. 检查Request是否小于等于Available，如果不满足则等待
3. 试探性地分配资源，修改Available、Allocation、Need
4. 执行安全性算法，判断系统是否处于安全状态
5. 如果安全则正式分配，否则撤销试探分配，恢复原状

安全性算法的逻辑是：寻找一个安全序列，使得所有进程都能顺利完成。具体做法是维护一个Work向量（初始等于Available）和一个Finish向量（初始全为false），然后循环寻找满足Need[i] <= Work且Finish[i] == false的进程，找到后假设它完成并释放资源（Work += Allocation[i]，Finish[i] = true），直到所有进程都完成或者找不到满足条件的进程。

int is_safe() { int Work[NUM_RESOURCES]; int Finish[NUM_PROCESSES] = {0}; int safe_sequence[NUM_PROCESSES]; int count = 0; for (int i = 0; i < NUM_RESOURCES; i++) { Work[i] = Available[i]; } while (count < NUM_PROCESSES) { int found = 0; for (int i = 0; i < NUM_PROCESSES; i++) { if (!Finish[i]) { int possible = 1; for (int j = 0; j < NUM_RESOURCES; j++) { if (Need[i][j] > Work[j]) { possible = 0; break; } } if (possible) { for (int j = 0; j < NUM_RESOURCES; j++) { Work[j] += Allocation[i][j]; } Finish[i] = 1; safe_sequence[count++] = i; found = 1; } } } if (!found) break; // 找不到满足条件的进程，不安全 } return count == NUM_PROCESSES; }

银行家算法的难点不在于代码，而在于理解安全状态和不安全状态的区别。安全状态是指存在至少一个安全序列，不安全状态是指不存在安全序列。不安全状态不一定会导致死锁，但死锁一定发生在不安全状态。这个区别在实验报告里经常被问到。

提示：银行家算法实验里，测试用例的设计很重要。建议准备几组数据，包括安全状态、不安全状态、以及Request导致状态从安全变为不安全的临界情况。这样能全面验证算法的正确性。

6. 实验课避坑指南与经验总结

6.1 代码调试的常见问题

操作系统实验的代码调试和普通编程作业不太一样，因为很多bug不是语法错误，而是逻辑错误。比如调度算法跑出来的结果和预期不符，但你不知道是哪一步出了问题。我的经验是，在关键步骤加日志输出。比如每次调度决策时输出当前时间、就绪队列状态、选择的进程；每次页面置换时输出访问的页面、当前内存中的页面、是否缺页、换出了哪个页面。

这些日志在调试的时候非常有用，能帮你快速定位问题。但要注意，日志不要加得太密，否则输出太多反而看不清。我通常只在关键决策点加日志，比如调度算法的每次选择、页面置换的每次换出。

另一个常见问题是内存泄漏。操作系统实验里经常需要动态分配内存（比如创建进程控制块、分配页面），如果忘记释放，程序跑久了就会出问题。建议在实验开始前就规划好内存管理策略，谁分配谁释放，什么时候释放，心里要有数。

6.2 实验报告的写作要点

实验报告不是代码的堆砌，而是你对实验的理解和思考。我见过很多同学的实验报告，代码贴了一大堆，但分析部分只有几句话。这样的报告拿不到高分。

好的实验报告应该包含：实验目的（用自己的话写，不要抄指导书）、实验原理（核心算法的伪代码或流程图）、实验步骤（关键实现细节）、实验结果（数据表格或截图）、结果分析（为什么是这个结果，和理论预期是否一致，如果不一致原因是什么）、心得体会（踩了什么坑，怎么解决的）。

其中结果分析是最能体现水平的部分。比如页面置换实验，你不能只贴一个缺页率表格，要分析为什么LRU在某个序列上表现好，为什么FIFO会出现Belady异常，物理块数对缺页率的影响曲线为什么是那个形状。这些分析能说明你真的理解了算法，而不是照抄代码跑了一遍。

6.3 时间管理和心态调整

操作系统实验通常比较耗时，一个实验做一两天很正常。我的建议是不要等到截止日期前才开始做。实验课的内容是递进的，前面的实验没搞懂，后面的实验会更难。而且实验环境可能出问题（比如编译不过、运行报错），留出足够的时间处理这些意外情况。

遇到卡壳的时候，不要一个人死磕。可以先看看理论课教材的对应章节，或者在实验群里问问同学。很多时候你卡住的地方别人已经踩过坑了，一句话就能点醒你。但要注意，问问题之前先自己尝试过，把问题描述清楚，不要直接说“我的代码跑不出来”，要说“我在实现LRU的时候，换出页面后缺页率反而上升了，我怀疑是访问顺序维护有问题，这是我的代码片段”。

心态上，操作系统实验确实有难度，但也不是不可逾越。每个实验的核心逻辑其实都不复杂，复杂的是各种边界情况和细节处理。把大问题拆成小问题，一个一个解决，最后你会发现其实没那么难。

6.4 常见问题速查表

这张表是我自己做实验时总结的，基本上覆盖了80%的常见问题。遇到问题的时候先对照这张表排查，能省不少时间。

6.5 一些实用的调试技巧

最后分享几个我在实验里常用的调试技巧。第一个是单元测试。不要等整个程序写完再跑，每写完一个模块就单独测试。比如调度算法写完了，先用一组简单的数据跑一遍，确认输出正确再继续写其他部分。

第二个是可视化。有些实验的结果用文字输出不直观，比如页面置换的过程、进程调度的甘特图。你可以用简单的字符画或者输出到文件再用工具画图。可视化能帮你快速发现异常模式。

第三个是对比验证。如果你不确定自己的实现是否正确，可以找一个已知正确的实现（比如教材上的伪代码）手动模拟一遍，把每一步的结果和自己的程序输出对比。这个方法虽然笨，但非常有效。

第四个是版本控制。实验代码改来改去很容易改乱，建议用Git或者简单的文件备份，每完成一个功能就提交一次。这样如果改出问题了，可以快速回退到上一个可用的版本。

操作系统实验课的内容远不止这些，但这个专题里提到的几个方向是最核心的。把进程调度、内存管理、文件系统、同步互斥、死锁检测这几个实验做扎实了，操作系统这门课的理论知识也就真正变成你自己的了。后面如果还有精力，可以尝试做一些扩展，比如实现一个简单的shell、写一个内存分配器、或者模拟一个简单的文件系统。这些扩展项目能帮你把零散的知识点串起来，形成完整的系统认知。