企业官网建设流程全解析

简介：这是一份围绕操作系统银行家算法实验整理的资料包，包含实验报告与可编译源代码，面向计算机专业学习操作系统课程、需要完成死锁避免实验或课程设计的学生。压缩包共5个文件，以2个cpp源文件、1个h头文件和1个docx实验报告为主，另附1个txt初始化数据，整体约452KB；头文件与实现分离，便于对照理解数据结构与算法流程。目前已有5251人学习下载。代码围绕最大需求、可用资源、已分配与需求矩阵展开，覆盖进程管理、资源请求、安全性检查、资源分配与释放及模拟循环，配合报告可梳理安全序列构造和死锁避免的判断依据。对调试中可能出现的资源分配不当、资源泄露或安全性检查错误，也提供了可对照分析的实验场景，适合用作课程实验参考、代码复盘与答辩准备。

1. 从一次「明明有资源却不敢分」说起

操作系统课设周，银行家算法这道题最容易让人卡住：Available 里明明还躺着空闲资源，程序却判定这次请求不能批。很多同学交上去的实验报告加源代码，基本是把课本伪代码抄了一遍，安全序列跟标准答案对不上，答辩时被问一句「为什么拒绝这个请求」就答不上来。这份资源把两件事放在一起交付：一份结构完整、能直接交的实验报告，和一份能编译、能换数据、能批量跑用例的源码。它适合两类人——赶 OS 课设、需要一份能讲清楚原理的报告的同学，以及想把「死锁避免」从公式落到二维数组上的开发者。银行家算法本身不复杂，真正的门道在状态怎么存、试分配怎么回滚、安全序列怎么证明，这些才是后面几章要拆的东西。

2. 项目组成与技术选型：一份报告加一份能跑的实现

这个项目的交付物是「文档 + 代码」的双份结构，代码用标准 C（C11）写成，不依赖任何第三方库，gcc或clang直接编，Windows 上 Dev-C++、VS Code + MinGW 也能跑。选 C 不是情怀，是因为这门课的实验环境普遍是这种配置，老师看代码时不会因为环境问题打回；同时 C 的数组和指针正好能把四张资源矩阵的「原地试分配 + 回滚」表现得最直白，换成带垃圾回收的语言反而看不出回滚这一步的价值。

2.1 目录结构与两份交付物的分工

源码和报告分开放，是为了让「改代码」和「改文档」互不干扰。报告里贴的代码片段来自src/，测试数据放在data/，批量验证脚本放在tests/。这样老师在验收时，改一个用例只需要动data/下的文本文件，不用重新读代码。

banker/ ├── README.md # 编译方式、用例说明、输出约定 ├── Makefile # make / make run / make clean ├── src/ │ ├── banker.h # 结构体定义、函数声明、返回码枚举 │ ├── banker.c # 主流程、文件读取、矩阵打印、交互循环 │ └── safe.c # 安全性检查 + 资源请求处理 ├── data/ │ ├── case1.txt # 经典 5 进程 3 资源用例（安全） │ ├── case2.txt # 初始状态就不安全的用例 │ └── case3.txt # 单资源退化用例，方便手算核对 ├── tests/ │ └── run_cases.sh # 逐个跑用例并对比期望输出 └── report/ ├── report.md # 实验报告正文 └── figs/ # 流程图、运行截图

提示：report/figs/里的截图建议用同一台机器、同一个终端字号截，报告里图与图之间风格统一，观感差别很大。

把safe.c单独拆出来，是有意为之。安全性检查和资源请求是两个可以独立测试的单元，主流程只负责读数据和打印结果。二次开发时想加「撤销上一次分配」「记录每一步 Work 变化」这类功能，改动点全在safe.c里，不会牵连输入输出。

2.2 四张表定天下：Available / Max / Allocation / Need

银行家算法的全部状态就是四个矩阵加两个向量，写成结构体最省事。下面这份定义把「上限」和「实际规模」分开，是为了后面加越界检查。

/* src/banker.h */ #ifndef BANKER_H #define BANKER_H #include <stdbool.h> #define MAX_PROC 16 /* 进程数上限，够课设用了 */ #define MAX_RES 8 /* 资源类型数上限 */ typedef struct { int n; /* 实际进程数 */ int m; /* 实际资源类型数 */ int available[MAX_RES]; /* 各类资源剩余量 */ int max[MAX_PROC][MAX_RES]; /* 每个进程声明的最大需求 */ int allocation[MAX_PROC][MAX_RES]; /* 当前已分配 */ int need[MAX_PROC][MAX_RES]; /* 还差多少，= max - allocation */ } Banker; typedef enum { REQ_GRANTED = 0, /* 分配成功，状态已更新 */ REQ_WAIT = 1, /* 当前资源不够，进程应等待 */ REQ_INVALID = -1, /* 请求超过自己声明的最大需求 */ REQ_UNSAFE = -2 /* 试分配后不安全，已回滚 */ } ReqResult; bool load_from_file(Banker *b, const char *path); void print_state(const Banker *b); bool is_safe(const Banker *b, int safe_seq[]); ReqResult request_resources(Banker *b, int pid, const int req[]); #endif

need不在每次计算时用max - allocation现减，而是在读文件那一刻就算好存下来，后面所有判断直接取。这个选择看着是小优化，实际是防错：如果某个分支里改了allocation却忘了同步need，实时相减的写法会把错误藏起来，而预存need会在下一轮安全检查里立刻暴露成「负数需求」或者「永远不安全」。

四个矩阵的语义再捋一遍，报告里也必须写清楚：

Max在运行期是只读的，这一点很关键。资源请求算法判断「这个请求合不合法」，比的就是Request[i] <= Need[i]，如果Max被改过，这条判断就失去意义了。

2.3 编译运行：三条命令跑通第一个用例

Makefile保持最朴素的写法，不引入 cmake，是因为课设环境上用 cmake 反而增加解释成本。

CC ?= gcc CFLAGS ?= -std=c11 -Wall -Wextra -O2 -g SRC := $(wildcard src/*.c) BIN := banker $(BIN): $(SRC) $(CC) $(CFLAGS) -o $@ $^ run: $(BIN) ./$(BIN) data/case1.txt clean: rm -f $(BIN)

跑起来就三步：

make # 编译，正常应该零警告 ./banker data/case1.txt # 用经典用例跑一次 # 交互输入形如：1 1 0 2 （进程 1 请求 R1=1 R2=0 R3=2） # 输入 -1 退出

case1.txt的格式是「先规模，再 Available 一行，然后 Max 矩阵 n 行，最后 Allocation 矩阵 n 行」：

5 3 3 3 2 7 5 3 3 2 2 9 0 2 2 2 2 4 3 3 0 1 0 2 0 0 3 0 2 2 1 1 0 0 2

这是课本上那个 5 进程 3 资源的经典例子，手算的安全序列是 P1 → P3 → P4 → P0 → P2（也可能先 P4 再 P2，不唯一）。第一次跑出来能打印出这个结果，说明读文件、算Need、安全性检查整条链路是通的。

-Wall -Wextra一定要留着。这类代码最常见的错误是int i, j里把j < b->m写成j < b->n，不加警告编译能过，运行时只在进程数和资源数不同的时候才崩，排查起来特别费劲。

3. 核心模块拆解：安全性算法与资源请求的完整链路

整个项目真正需要动脑的只有两个函数：is_safe和request_resources。前者回答「当前这个状态还能不能走通」，后者回答「这次请求该不该批」。其余代码都是给这两个函数喂数据和打印结果。

3.1 安全性检查：Work 和 Finish 两个向量怎么滚动

安全性检查的本质是一次「模拟执行」：假设所有进程现在开始申请它剩余需要的资源，看看能不能找到一个顺序让每个进程都跑完。Work是模拟过程中的可用资源，Finish标记哪些进程已经模拟跑完。

/* src/safe.c */ #include <string.h> #include "banker.h" bool is_safe(const Banker *b, int safe_seq[]) { int work[MAX_RES]; bool finish[MAX_PROC]; int count = 0; /* 1. 初始化：Work 拷贝 Available，Finish 全部置 false */ for (int j = 0; j < b->m; j++) work[j] = b->available[j]; memset(finish, 0, sizeof(bool) * b->n); /* 2. 反复扫描，直到所有进程都跑完或一轮下来毫无进展 */ while (count < b->n) { bool progressed = false; for (int i = 0; i < b->n; i++) { if (finish[i]) continue; /* 判断 Need[i] 是否全部 <= Work */ bool ok = true; for (int j = 0; j < b->m; j++) { if (b->need[i][j] > work[j]) { ok = false; break; } } if (!ok) continue; /* 模拟 Pi 跑完，把它手里的资源全部归还 */ for (int j = 0; j < b->m; j++) work[j] += b->allocation[i][j]; finish[i] = true; safe_seq[count++] = i; progressed = true; } /* 3. 一整轮没有任何进程能推进，说明剩下的是死锁集合 */ if (!progressed) return false; } return true; }

逐段看。

第一步的两个初始化，Work = Available是必须的，Finish全 false 也是必须的。曾见过有人复用上一轮调用的finish数组，结果第二次安全检查直接返回「安全」，因为所有进程都被标记成已完成——这种 bug 只在连续请求时出现，单次测试完全测不出来。

第二步的循环结构是这段代码的核心。外层while保证只要有进展就继续下一轮；内层for每轮从头扫一遍所有未完成进程。progressed是防止死循环的保险丝：如果一整轮扫下来没有任何进程能满足Need <= Work，说明剩下的进程互相卡着，直接返回不安全，不用再转。

第三步的work[j] += b->allocation[i][j]容易被写成+= b->need[i][j]。两者结果不同：进程跑完归还的是它「已经拿到的」资源（Allocation），不是它「曾经想要」的资源（Need）。写错的话，安全序列可能还是能算出来，但每一步的 Work 值是错的，报告里的过程表一对就露馅。

safe_seq用count递增写入，而不是用i或者work的下标，保证每个进程在序列里只出现一次。这是第二个高频错误点，下面避坑章会专门讲。

复杂度上，最坏情况每轮只推进一个进程，共 n 轮，每轮扫 n 个进程、每个比 m 个资源，是 O(n²m)。课设规模下完全够用，不用考虑优化。

3.2 资源请求的四道闸门与回滚

request_resources是真正会修改全局状态的地方，也是最容易写错的地方。它要依次过四道闸门，任何一道没过都必须保证状态没被污染。

/* src/safe.c 续 */ ReqResult request_resources(Banker *b, int pid, const int req[]) { if (pid < 0 || pid >= b->n) return REQ_INVALID; /* 闸门一：请求量必须非负 */ for (int j = 0; j < b->m; j++) if (req[j] < 0) return REQ_INVALID; /* 闸门二：不能超过自己声明的最大需求 */ for (int j = 0; j < b->m; j++) if (req[j] > b->need[pid][j]) return REQ_INVALID; /* 闸门三：当前可用资源是否够，不够就让进程等 */ for (int j = 0; j < b->m; j++) if (req[j] > b->available[j]) return REQ_WAIT; /* 闸门四：试探性分配，然后跑一遍安全性检查 */ for (int j = 0; j < b->m; j++) { b->available[j] -= req[j]; b->allocation[pid][j] += req[j]; b->need[pid][j] -= req[j]; } int seq[MAX_PROC]; if (is_safe(b, seq)) return REQ_GRANTED; /* 安全，分配生效 */ /* 不安全：必须原路回滚，否则后面的判断全乱 */ for (int j = 0; j < b->m; j++) { b->available[j] += req[j]; b->allocation[pid][j] -= req[j]; b->need[pid][j] += req[j]; } return REQ_UNSAFE; }

四道闸门的顺序不能调。闸门二（超Need）必须在闸门三（资源不够）之前，因为「请求超过自己声明的最大需求」是逻辑错误，属于进程违规，应该直接报错；而「资源暂时不够」只是时机不对，进程应该等。这两种情况在输出里必须区分开，报告的结果分析部分也要分开讨论。

试分配那一段是三个操作同时做：Available减、Allocation加、Need减。三者必须严格配对，回滚时严格逆序还原。这里用「原地改 + 手工回滚」而不是「拷贝一份副本试算」，是课设里更常见的写法——副本写法内存开销小但代码看着绕，而且Banker结构体里有两个二维数组，拷贝一份要写循环，反而容易漏字段。原地改的风险是回滚必须一处不漏，所以回滚代码最好紧跟在判断后面，中间不要插别的逻辑。

ReqResult用四个返回值而不是简单的true/false，就是为了让主流程能打印不同的提示。如果只返回布尔值，用户看到「分配失败」根本不知道是资源不够还是会被判不安全，调试时只能靠猜。

3.3 主流程：先验证初始状态，再进交互循环

主函数只做三件事：读文件、验证初始状态、循环处理请求。

/* src/banker.c */ #include <stdio.h> #include "banker.h" int main(int argc, char *argv[]) { Banker b; const char *path = (argc > 1) ? argv[1] : "data/case1.txt"; if (!load_from_file(&b, path)) { fprintf(stderr, "读取 %s 失败，检查文件格式\n", path); return 1; } print_state(&b); int seq[MAX_PROC]; if (!is_safe(&b, seq)) { printf("初始状态不安全，请检查 Max / Allocation 矩阵\n"); return 1; } printf("初始状态安全，一个可行安全序列："); for (int i = 0; i < b.n; i++) printf("P%d%s", seq[i], i + 1 < b.n ? " -> " : "\n"); /* 交互：每行输入 进程号 + m 个资源请求量，输入 -1 退出 */ int pid, req[MAX_RES]; while (1) { printf("请求> "); if (scanf("%d", &pid) != 1 || pid < 0) break; for (int j = 0; j < b.m; j++) if (scanf("%d", &req[j]) != 1) return 0; ReqResult r = request_resources(&b, pid, req); switch (r) { case REQ_GRANTED: printf("P%d 请求已批准\n", pid); break; case REQ_WAIT: printf("P%d 资源不足，请等待\n", pid); break; case REQ_INVALID: printf("P%d 请求非法：超过声明的最大需求\n", pid); break; case REQ_UNSAFE: printf("P%d 请求被拒：试分配后系统将进入不安全状态\n", pid); break; } print_state(&b); } return 0; }

启动时先跑一次is_safe是有必要的。如果输入的矩阵本身就是死锁状态，后面任何请求都必然返回不安全，用户会以为是请求逻辑写错了，实际上是初始数据有问题。先验一次能把这层歧义掐掉。

每次请求处理完都print_state，是为了让报告里的过程截图有内容可贴。截图里能看到Available在拒绝请求前后一模一样，正好证明回滚生效了——这比在报告里写十句「本程序实现了回滚」有说服力。

scanf的返回值都做了判断，因为交互输入时用户很容易输个字母，不检查的话pid会保持上一次的值，程序进入诡异状态。

4. 实验报告怎么写：从原理图到结果分析

代码跑通只是及格线，报告才是拿分的地方。很多报告失分不是因为算法写错，而是「原理部分抄书、测试部分只有一张截图、分析部分一句话带过」。这一章按报告的实际章节顺序讲怎么填。

4.1 原理与数据结构：把四张表画成一张状态图

原理章节不要直接抄课本的定义。课本讲的是通用模型，你的报告要讲的是「我这份代码里的数组分别对应什么」。最有效的写法是先摆一张表，说明Available、Max、Allocation、Need各自的维度和更新时机（就是 2.2 节那张），再配一个具体的数值例子走一步。

比如拿case1的初始状态，写清楚：

• Available = [3, 3, 2]，表示系统还剩 3 个 R1、3 个 R2、2 个 R3；
• Need[0] = Max[0] - Allocation[0] = [7,5,3] - [0,1,0] = [7,4,3]；
• 判断 P0 能不能跑，就是看[7,4,3]是否逐分量不大于[3,3,2]，答案是不能。

再往下画安全性检查的流程：初始化 → 找满足Need <= Work的未完成进程 → 假设它跑完并归还资源 → 重复 → 全部完成则安全。流程图用 Visio 或者 draw.io 画都行，关键是每个判断框的分支条件要写具体，比如判断框里写Need[i] <= Work ?，而不是含糊的「是否满足条件」。

数据结构章节要说明为什么用二维数组而不是链表。理由很实在：进程数和资源类型数在运行期不变，数组的随机访问和Max - Allocation这种逐元素运算写起来最直接，链表反而要为每个进程维护 m 个节点。这条理由写进去，比空谈「数组效率高」强。

4.2 测试用例设计：四类输入覆盖所有分支

request_resources有四条返回路径，报告里的测试用例就应该正好覆盖这四条，一条不多一条不少。

第四类用例最容易被漏掉，也最能体现工作量。构造方法：先让系统进入一个「只剩少量资源」的状态，然后让某个进程申请刚好够用但会导致其他进程永远等不到资源的数量。跑出来如果打印的是「试分配后系统将进入不安全状态」，并且紧跟着的状态表里Available和请求前完全一致，就证明回滚是对的。

每个用例除了贴运行截图，还要在旁边写出手算过程。比如 P1 请求 [1,0,2]：Need[1]=[1,2,2]，请求没超；Available=[3,3,2]，够；试分配后Available=[2,3,0]、Allocation[1]=[3,0,2]、Need[1]=[0,2,0]；此时 P1、P3 都能跑完……手算三五行，比截图更有说服力，因为这证明你理解了算法而不是只会按回车。

case2.txt那个「初始就不安全」的用例也要留着，它验证的是启动时那次预检查，输出应该是「初始状态不安全」，程序直接退出。

4.3 结果分析：安全序列不唯一这件事必须说清

分析部分至少写三件事。

第一，安全序列不唯一。case1手算能得到 P1→P3→P4→P0→P2，也能得到 P1→P3→P4→P2→P0。程序输出哪一个，取决于内层for扫描的顺序。这句话必须写进报告，否则老师看到你的结果和答案不一样，第一反应是判错。顺便可以写一句：算法的目标是找到任意一个安全序列，而不是唯一解，所以不同实现给出不同序列是正常的。

第二，为什么某个请求被拒。不要只写「不安全」，要写清楚是哪一步卡住了。比如「试分配后Available=[0,1,0]，剩余进程的Need分别是 [7,4,3]、[6,0,0]、[0,1,1]，没有任何一个能全部满足，因此不存在安全序列」。把 Work 和剩余 Need 摆出来，逻辑就闭环了。

第三，复杂度与局限。安全性检查是 O(n²m)，每次请求都要跑一遍，进程多了会慢。真正的通用系统不会用银行家算法做在线判断，因为进程的最大需求很难事先声明。这句话写在「问题与改进」里，既显示你想过算法的适用边界，也给二次开发留了口子。

5. 避坑与排查：跑出来但答案是错的五种情况

下面五条是这类实现里出现频率最高的故障。它们的共同特点是程序不崩、能输出，所以特别难发现。

5.1 安全性检查把同一个进程算了两遍

现象：安全序列里出现P1 -> P1 -> ...，或者序列长度对但进程号重复，总有一个进程没被列入。

原因：safe_seq的下标用错，写成了safe_seq[i] = i或者safe_seq[work[0]] = i，而不是用独立的计数器count。另一种情况是finish[i]更新了但i在外层也自增，导致跳过。

解决：序列写入只认count，count和finish严格同步递增；循环结束条件用while (count < n)，不要用for (i = 0; i < n; i++)包住整个算法。写完打印一次count和n对比。

5.2 拒绝请求之后状态被污染

现象：第一次请求被拒绝后，后续所有请求都返回「不安全」，Available越跑越小，重启程序才恢复正常。

原因：试分配时直接改了b->available，但走REQ_UNSAFE分支时忘了回滚，或者只回滚了Available忘了Allocation和Need。三个数组只还原一部分，下次判断当然全错。

解决：回滚代码紧跟在安全性检查之后，三个数组（available、allocation、need）一次性全部逆操作还原，中间不插入任何return或其他逻辑。还有一种更保险的做法：先在栈上复制一份Banker试算，安全了再把副本整体拷回去。课设规模下这点内存完全无所谓，我现在更倾向副本写法，因为它天然不会有「漏还原一个字段」的问题。

5.3 Need 出现负数

现象：打印状态表时Need里有-1、-3这种值，后续判断全部异常。

原因：读文件时矩阵顺序搞反了，把Allocation当Max读，或者行主序和列主序弄混。也可能是请求处理里Need减了两次。

解决：文件头写死顺序注释，读的时候严格按「Available 一行 → Max n 行 → Allocation n 行」；读完后立刻算Need并检查是否有负值，有就报错退出。加一道if (b->need[i][j] < 0) return false;的校验，能把数据问题挡在算法之前。

5.4 数组越界但程序不崩

现象：换成 12 个进程的用例后结果错乱，或者在自己机器上正常、换台机器就段错误。

原因：MAX_PROC定成 10，用例却给了 12 个进程；或者嵌套循环里j < b->m写成了j < b->n，当 n > m 时就越界读。

解决：读文件后立刻校验n <= MAX_PROC && m <= MAX_RES，不满足直接退出；开发阶段加上-fsanitize=address,undefined编译一次，越界会立刻报出具体行号。这个开关我在交作业前一定会打开跑一遍，比事后猜快得多。

5.5 交互输入把进程号和资源量吞掉

现象：输入1 1 0 2后程序跳过了一次请求，或者把上一轮的资源量当成了新的进程号。

原因：scanf("%d", &pid)失败后没有清空输入缓冲区，残留字符被下一次读取吃掉；或者退出条件pid < 0写在读完资源量之后，导致-1后面还要求输入 m 个数字。

解决：先读pid并判断退出，再读 m 个资源量；scanf的返回值全部检查，失败的字符用getchar()循环清掉。规范的交互程序应该在任何非法输入后给出提示并继续，而不是静默错位。

6. 二次开发：给它加一个能自证的测试回路

手写用例的覆盖度终究有限，尤其当你把MAX_PROC调到 16 之后，人脑已经算不出正确答案了。这时候我会加一个对拍脚本：随机生成小规模矩阵，用暴力穷举算出「是否存在安全序列」，再跟 C 程序的输出比对。

暴力法的思路很直接——既然是安全性，那就枚举所有可能的推进顺序，只要存在一条能全部跑完的路径就是安全的。规模压到 n ≤ 6、m ≤ 3，穷举量完全可以接受。

import itertools, random, subprocess def brute_safe(avail, alloc, need): """穷举所有排列，判断是否存在安全序列（仅供小规模对拍）""" n, m = len(need), len(avail) for order in itertools.permutations(range(n)): work = list(avail) ok = True for i in order: if any(need[i][j] > work[j] for j in range(m)): ok = False break for j in range(m): work[j] += alloc[i][j] # 进程跑完归还已分配资源 if ok: return True return False # 生成用例 -> 写临时文件 -> 调 ./banker -> 解析第一行输出 -> 与 brute_safe 比对

把这段和./banker的输出接起来，跑上几百组随机用例，凡是「暴力说安全、程序说不安全」或者反过来的，都是真 bug。我用这套办法抓到过一个藏得很深的问题：某个分支里Need减了但Available没减，单看输出完全正常，只有在对拍时才会出现两个实现的结论不一致。

除了对拍，还有两个投入产出比很高的改造方向。一是把is_safe改造成「带回溯信息」的版本，记录每一步的Work快照，输出成一张过程表，报告里的分析章节可以直接引用；二是把交互层换成读脚本文件，一次跑十几个请求并打印每个请求的判定结果，这样报告里的测试部分就是一份完整的执行日志，而不是零散截图。

至于性能，is_safe每次请求都从头跑一遍，进程数上百时确实会慢，但这个算法本来就不是给大规模系统用的，优化它的意义不大。真想练手，不如把「进程可以动态加入、Max可以事后上调」这套约束加进去，那时候你才会真正体会到为什么真实系统不敢用银行家算法——Max一旦可以随便改，所有的安全性证明都成了空话。

我现在每次交这类课设前，都会强制走一遍「随机对拍 + sanitizer 编译 + 换个规模的用例」这三步，不管代码看起来多简单。银行家算法的坑不在算法本身，全在数组下标和回滚那句for循环里，肉眼是看不出来的。希望帮到你。

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