简介这是一份数据结构课程期末作业的完整工程包主题为银行排队系统适合需要完成同类作业或练习队列应用的在校学生。资源通过双队列模型实现VIP与普通用户的优先级服务重点覆盖队列的入队出队操作、多队列调度逻辑、基于文件读取用户信息以及C STL中queue容器的使用能帮助理解队列结构在真实场景中的落地方式。压缩包共9个文件大小1.03MB包含C源码、项目配置与依赖文件、用户信息数据文件以及编译生成的exe/obj等既可直接运行查看效果也可打开工程研读实现细节。目前已有3361人学习此资源适合作为数据结构期末项目参考也可在此基础上扩展业务规则或改进可视化界面。1. 数据结构期末作业里的常客银行排队系统到底在考什么如果你正在准备数据结构期末大概率会撞上「银行排队系统」这道经典题目。它表面是个控制台项目实际考的是队列在真实业务里的建模能力客户到达、排队、窗口叫号、等待时长统计这些环节全都要落到数据结构和算法上。很多同学拿到题先写界面写完发现核心逻辑全挤在一堆 if 里窗口一多就乱套数据一跑就崩。这份作业资源把整个系统拆成了客户管理、队列调度、时间片推进、统计输出四个模块用 C 语言实现逻辑完整实验报告也配套好了。适合正在做数据结构课程设计、需要一份能跑通能答辩的参考工程的同学也适合想在期末复习里把链队列和循环队列一次看明白的人。不吹复杂度但能让你少走三个礼拜弯路。2. 先把模型立住队列选型、客户状态机与三类设计取舍2.1 为什么是队列而不是栈从真实柜台业务倒推数据结构选型银行排队这件事本质是先进先出先到的人先被叫号后到的人排在队尾。这正好对应队列队列的操作受限在两端队尾入队、队头出队。上学期学栈的时候你大概率背过「后进先出」但真正面对业务场景时能不能从需求反推结构才是关键。银行排队系统如果用栈来模拟就会变成最后一个人先被服务这在业务上是灾难面试官一眼就能看出你没有建模能力。这道作业题的刻意之处在于它逼着你从「业务规则」出发而不是从「我会写什么代码」出发。我在拆这份资源时最先看的不是代码怎么写而是它的模型定义。完整的银行排队系统至少要回答四个问题客户是什么时候来的客户需要服务多久窗口什么时候空闲空闲窗口该叫谁。这四个问题分别对应客户数据结构里的到达时间、服务时长以及调度模块里的窗口状态判断队列出队操作。顺序一旦反了比如先出队再查空闲窗口就会出现窗口空着没人服务、队首客户却干等的情况。选队列还有一个理由它允许你在常量时间内完成入队和出队。链队列的入队出队都是 O(1)不会随着客户数量增加而变慢。这是这门课里最容易被忽视的考点——老师只要追问一句「为什么不用数组模拟」你要能说出扩容代价和空间浪费。顺序队列虽然也行但循环队列的实现细节多处理不好就翻车后面避坑章节我会专门讲。2.2 链队列 vs 顺序队列期末作业场景下的取舍标准期末作业场景下选链队列还是顺序队列我建议直接看两个条件一是你的客户数量是否有限制二是你要不要频繁取队头元素。这份资源用的是简单链队列头节点作为哨兵front 指针始终指向哨兵rear 指向队尾入队操作接在 rear 后面出队操作从 front 后面取。这套实现的好处是判空特别直观front 的 next 为空就是空队列不需要维护 front 和 rear 相等这种边界状态。如果你选顺序队列注意循环队列的判空和判满条件容易混淆。很多同学用 headtail 判空又用 headtail 判满结果队列满的时候和空的时候表现一样运行起来逻辑全乱。顺序队列适合客户数量固定、你明确知道峰值容量不超过某个值的场景比如题目规定了「银行最多同时接待 100 个客户」。链队列则没有这个限制内存按需分配更适合做模拟类作业——你不知道模拟到第 1000 分钟时排队人数是 5 个还是 50 个。两份答案我都见过优秀的作业案例。顺序队列胜在代码短适合时间紧张、只想交差的情况链队列胜在鲁棒性适合想冲高分、答辩时能多说几句的情况。这份资源选链队列还有个实际考虑它要在模拟结束后遍历队列输出每个客户的等待时间链队列的遍历逻辑比顺序队列下标翻转更好讲清楚。2.3 客户对象的数据结构状态机、等待时长与窗口分配客户是系统里的核心对象它的数据结构定义决定了整个系统的复杂度。我看过不少作业把客户简化成一个整数编号结果后面统计平均等待时间时完全无从下手。客户至少要有七个字段编号、到达时间、服务时长、开始服务时间、等待时长、状态、指向下一个客户的指针。状态字段可以定义成枚举取值包括未到达、排队中、服务中、已完成四种。客户的状态机是整个系统的内在逻辑未到达的客户在模拟主循环里按概率生成并入队排队中的客户等待窗口空出服务中的客户消耗窗口剩余时间已完成的客户统计数据并释放内存。这份资源把状态机分散在调度模块和主循环里而不是用一个大 switch 包裹我觉得更符合实际工程习惯——每个状态只有一种转型路径状态间的关系在代码流程里自然体现答辩时你能讲清楚每个分支为什么这么写。窗口分配的规则需要单独说。最简单的分配策略是扫描所有窗口找到第一个空闲窗口就把队首客户分配过去。复杂度为 O(窗口数)窗口少时无感窗口数到 20 以上时每一分钟都要扫描一次就会浪费大量时间。进阶做法是维护一个空闲窗口链表空闲窗口入链忙碌窗口出链分配时直接取链表头部复杂度 O(1)。这份资源用的是扫描法因为它窗口数一般不超过 10代码更直观适合期末作业的教学目标。2.4 双端队列与优先级队列作业里哪些「加分设计」值得做数据结构教材里比普通队列高阶的是双端队列和优先级队列。双端队列允许队头队尾都能入队出队优先级队列则按优先级出队而不是按到达顺序。银行排队系统里这两种结构都能找到应用场景但我不建议在基础版本里直接用。原因很简单老师批改作业时先看的是你能否用最朴素的方式把业务模拟清楚花里胡哨的进阶结构如果没有业务支撑答辩时一个「为什么要用双端队列」就能把你问住。如果你一定要做加分设计优先级队列有两个位置可以合理地出现VIP 客户插队和老年客户优先窗口。这两个业务规则都天然符合优先队列的语义不是硬套。具体做法是给客户结构体加一个 priority 字段普通客户为 0VIP 客户为 1然后在小顶堆的基础上改成按优先级比较、同优先级再按到达时间排序。这份资源里没有用堆而是简单地对队列做了一次查找找到优先级最高的客户再出队复杂度是 O(n)适合处理少量 VIP 的场景。双端队列在这个项目里最合理的用途是实现「喊号不回应则重新排到队尾」这个业务。喊号超时未到的客户从队头移除再插入到队尾普通队列要实现这个逻辑得先出队再入队双端队列语义上更贴切。但注意如果老师没要求这个业务做得再好也是额外负担。我给你的建议是优先保证基础流程完整、数据统计准确再把剩余时间花在测试和报告上这两项的性价比远高于加一个堆排序。3. 核心代码落地排队模拟器的四个模块与关键函数3.1 工具模块随机客户生成与时间片推进模拟类作业的核心思路不是「写一个真实的银行系统」而是「在离散时间片里推进状态」。常见做法是以分钟为最小时间单位每分钟做三件事决定是否有新客户到达、让忙碌窗口的剩余服务时间减一、把空闲窗口分配给队首客户。这样整个系统的状态就是可追踪的任何时刻你都能解释某个客户在哪个队列、某个窗口在服务谁。客户到达的逻辑一般用概率控制。每分钟到达一个新客户或者每 N 分钟到达一个客户两种模式各有用途。固定间隔适合测试概率到达适合模拟真实场景。下面这段代码用的是概率模式用随机数判断当前分钟是否有客户到达void generate_customer(Queue *q, int current_time, int *global_id) { Customer *c (Customer *)malloc(sizeof(Customer)); if (!c) { printf(内存分配失败模拟终止\n); exit(1); } c-id (*global_id); c-arrive_time current_time; // 服务时长2 到 8 分钟之间的随机数模拟不同业务复杂度 c-service_time rand() % 7 2; c-start_time -1; c-wait_time 0; c-state 1; // 1 表示排队中0 表示未到达2 表示服务中3 表示已完成 c-next NULL; q-rear-next c; q-rear c; q-size; }这段代码里最关键的是rand() % 7 2。这个表达式生成 2 到 8 的整数表示客户需要的服务时长。如果你觉得业务里应该有些客户快速办完、有些客户磨叽很久可以把随机分布从均匀分布改成分段分布比如 70% 概率生成 2 到 4 分钟30% 概率生成 6 到 10 分钟。很多作业的统计结果「看起来不真实」就是因为服务时长用了均匀分布现实中银行不会所有人都平均耗时。时间片推进的主循环要维护一个时钟变量每循环一次加一。循环终止条件有两个常见选项固定运行 480 分钟模拟银行一天的营业时长或者运行到队列清空且所有窗口空闲。推荐用前者作为主终止条件后者作为程序结束前的收尾步骤——你要统计完整营业日的数据就必须把已经入队但还没服务完的客户处理掉。另外注意rand()在多次运行时如果不设置随机种子每次结果都一样这在测试阶段很方便但最终演示时要加srand(time(NULL))让每次运行的数据不同。3.2 队列模块入队、出队、判空与遍历统计链队列的实现建议加上一个 sentinel 头节点。头节点不存数据只作为链表起点front 指向它rear 指向最后一个真实节点。这样做的好处是空队列的表示非常干净front 和 rear 都指向头节点没有任何多余判断。判空逻辑是front-next NULL这个条件在整个调度模块里会反复用写错一次可能只有到窗口分配时才能发现。入队逻辑是往 rear 后面挂新节点同时更新 rear出队逻辑是摘掉 front 后面的第一个真实节点如果摘完发现队列空了要把 rear 重新指回头节点——这一步漏掉就直接翻车后面无限遍历。int is_queue_empty(Queue *q) { return q-front-next NULL; } void enqueue(Queue *q, Customer *c) { c-next NULL; q-rear-next c; q-rear c; q-size; } Customer *dequeue(Queue *q) { if (is_queue_empty(q)) return NULL; Customer *c q-front-next; q-front-next c-next; if (q-front-next NULL) { q-rear q-front; // 队列空了rear 回到哨兵 } q-size--; c-next NULL; return c; }有两点值得你注意。第一出队时为什么要把c-next置空这不是必须的但能防止上层误用已出队节点的指针做遍历属于防御性编程的顺手操作。第二dequeue返回的是客户指针而不是 void这样调度模块可以拿这个指针直接设置开始服务时间省一次查找。数据结构作业里函数的设计能体现出你有没有工程素质面试官翻代码时第一个看的就是「出队的客户数据怎么被上层使用」。如果把这一步做成先出队再从某个数组里按 id 找回客户那就白白浪费了出队的返回值。队列遍历统计是另一个高频功能。营业结束后要把队列里剩下没处理的客户标记为「未完成」同时在表格里输出。遍历用for (Customer *p q-front-next; p ! NULL; p p-next)就够了。统计峰值队列长度时在每次入队和出队后更新max_len变量比最后再扫一遍队列要简单得多也更不容易出错。3.3 调度模块窗口空闲检测与分配逻辑调度模块是银行排队系统的核心也是最能拉开分数差距的地方。每次主循环进入调度阶段时遍历所有窗口找到剩余服务时间为 0 的窗口把队首客户出队分配给它。但这里有一个容易被忽视的业务细节同一分钟内有多个窗口空闲时先分配哪个窗口其实对客户而言没有区别但对代码实现来说每个窗口独立分配即可不需要额外排序。typedef struct { int remaining_time; // 剩余服务时间0 表示空闲 int served_count; // 今日已服务客户数 int total_busy_time; // 累计忙碌时间用于计算窗口利用率 } Window; void dispatch(Queue *q, Window *windows, int window_count, int current_time) { for (int i 0; i window_count; i) { if (windows[i].remaining_time 0 !is_queue_empty(q)) { Customer *c dequeue(q); c-start_time current_time; c-wait_time current_time - c-arrive_time; c-state 2; // 服务中 windows[i].remaining_time c-service_time; windows[i].served_count; printf(分钟 %d客户 %d 开始在窗口 %d 服务等待 %d 分钟\n, current_time, c-id, i 1, c-wait_time); } if (windows[i].remaining_time 0) { windows[i].remaining_time--; } } }注意上面代码里remaining_time--的位置。它放在同一轮循环的最后先分配再递减。这样窗口在ts时刻被分配客户服务时间立即减一代表这一分钟已经消耗掉。如果你把递减放在循环开头逻辑就会变成「这一分钟先被跳过」导致所有客户的服务结束时间延后一分钟统计出的平均等待时间偏大。这种差一分钟的 bug 最难查因为整个系统还能跑通只是数据不对。调度模块还有一个细节客户分配给了窗口之后进度要不要立即打印。我看过一些作业把printf放在所有窗口处理完之后统一输出导致日志时序错乱客户明明在第 50 分钟开始服务打印却出现在第 51 分钟。这里的教训是模拟系统的日志输出必须紧贴状态变更不要为了排版整齐而延迟打印。答辩时老师会拿着你的运行日志和代码对照看对不上就露馅了。3.4 结算模块平均等待时间、队列长度峰值的计算口径结算模块的目标是在模拟结束后输出三项数据服务客户总数、平均等待时间、最大队列长度。三个数据的计算口径各有讲究。服务客户总数是窗口served_count之和这个最简单但注意要排除掉营业结束还没被服务的客户——用总数除以窗口数算平均每个窗口的服务量时边界情况很容易错。平均等待时间的计算要区分「已服务客户」和「所有到达客户」。这份资源里统计的是已服务客户的平均等待时间即总等待时间 / 已服务客户数。如果你把还在队列里等待的客户也算进去这些客户 wait_time 还未更新会导致结果虚低。计算总等待时间时在dispatch里累加c-wait_time到全局变量total_wait_time最后一步再除以served_total避免结算时再遍历一次队列。void settle(Queue *q, Window *windows, int window_count, int total_wait_time, int served_total) { printf(\n 营业结束统计 \n); printf(总服务客户数%d\n, served_total); printf(已服务客户平均等待时间%.2f 分钟\n, served_total 0 ? (double)total_wait_time / served_total : 0.0); int left 0; for (Customer *p q-front-next; p ! NULL; p p-next) { left; } printf(营业结束时仍在排队的客户数%d\n, left); printf(最大队列长度%d\n, max_queue_len); }结算模块里最容易犯的错是除零。如果模拟参数设置得极端比如客户到达概率极低、窗口数量多到几乎不需要排队可能出现served_total为 0 或者队列里始终没人除零直接崩溃或输出inf。答辩时老师喜欢改参数测试的鲁棒性你要在结算函数里做防御性判断。上面的代码已经用三元表达式挡了一层但这只是最低限度更稳的做法是在主循环里检查客户总数为 0 时提前结束模拟。4. 避坑与排查五个导致银行排队系统翻车的典型问题4.1 现象运行几秒后程序闪退或死循环这个现象在链队列实现里尤其常见。闪退多半发生在窗口分配时访问了空指针死循环多半发生在遍历队列时链表断裂或成环。最常见的根因是出队操作时没有在队列为空的情况下重置rear指针。出队最后一个客户后front和rear还指向那个已经被释放的节点下一次入队会继续往这个释放过的内存地址上写数据程序直接崩溃。解决把出队函数里q-rear q-front这行加上确保队列空了以后 rear 重新回到哨兵节点。如果你用的是上课给的模板代码先检查模板里出队函数是否处理了「出队后变空」这个边界条件。很多教科书为了简洁省略了这步作业直接照抄就翻车。4.2 现象所有客户集中挤在一个窗口其他窗口都是空闲的这通常是窗口分配逻辑中的判断方向写反了。假设一个窗口的remaining_time为 0 表示空闲如果你顺手写成 0那么窗口刚被分配完客户后仍然满足条件同一轮循环里会被二次分配相当于一个窗口连续抢走多个客户。表现就是只有一个窗口在忙其余窗口一直空闲服务数据完全失真。解决把窗口空闲判断收敛成remaining_time 0这一个条件同时确保递减逻辑在分配之后执行。如果同一个窗口在同一次循环里既被分配又被递减把它拆成「先分配后递减」两个阶段不要混在一起。打印日志确认每个窗口每次循环最多只被分配一次客户。4.3 现象平均值忽大忽小每次运行结果都不一样无法复现没有设置随机种子导致的问题在测试阶段尤其烦人。rand()默认种子是 1每次运行生成相同的随机序列但如果你在代码里加了srand(time(NULL))每次运行结果都不同这导致你没法稳定地复现一个 bug。我见过有人为了「看起来真实」每次运行都换随机种子结果 debug 时改一个参数队列行为完全变了没法判断是参数改动还是随机因素导致的。解决在测试模式下调srand(1)固定种子让每次运行结果一模一样确认逻辑正确后再切到随机种子。建议在主函数里加一个测试开关比如if (test_mode) srand(42); else srand(time(NULL));。这个习惯也能在答辩时加分——你可以当着老师的面用固定种子复现数据再切随机种子演示一次说明两种模式都验证过。4.4 现象输入菜单选项后程序不执行对应功能直接跳过这是 C 语言控制台程序里最常见的问题几乎每份作业都会踩一次。scanf(%d, choice)读取完数字后缓冲区里还残留一个换行符\n紧接着的getchar()或scanf(%c)会把换行符读进去导致后续逻辑以为你输入了一个非法字符。现象就是菜单选了 1程序秒过什么都没发生。解决在每个scanf后面加一个while (getchar() ! \n);清空缓冲。或者统一用fgets读整行再用sscanf解析后者更稳但代码量会大一些。期末作业用第一种就行改动最小风险最低。注意这个坑在 Windows 和 Linux 下表现不一致Windows 下\r\n处理更麻烦尽量在 main 函数开头就用 setbuf 或者在每个输入点后清一次缓冲。4.5 现象数据量大时输出错乱日志跟实际业务对不上模拟运行超过几百分钟、客户数量上千时控制台输出会变得非常长。问题不在逻辑而在输出缓冲和滚动速度——你看到的日志可能是几十秒前的排查时对着旧日志调新代码越调越乱。另外有些人用printf输出调试信息跑完才发现正式输出和调试输出混在一起答辩时老师根本不知道哪行是结果。解决把日志分级模块内部用DEBUG宏控制是否输出只有客户状态变更和最终统计结果走正式输出通道。在 main 循环顶部打印当前分钟数方便对照。如果你用的是 Windows 终端输出量大时建议重定向到文件运行一次./bank_system log.txt再打开文件逐行看。这也是我给你的建议模拟类作业的正确调试方式从来都是看文件不是盯控制台。5. 测试与验证用一份可复现的实验数据证明作业能跑通5.1 测试用例设计边界条件、极端负载与稳定运行期末作业最怕的不是功能做不出来而是测试阶段做的都是「正常情况」边界条件一碰就崩。好的测试用例至少要有四类。第一类是空队列运行把客户到达概率设为 0窗口数设 1跑完整 480 分钟程序应能正常结束且统计结果为全 0不能出现除零崩溃。第二类是极端负载窗口数设 1到达概率设 1每分钟都来一个人模拟结束后确认没有内存泄漏、没有队列溢出。第三类是常规负载窗口数设 3 到 5到达概率设 0.3 到 0.5记录平均等待时间验证结果在合理范围内——正常情况下平均等待时间应该在一二十分钟左右如果超过两小时说明调度有问题。第四类是混合服务时长把服务时长的分布从均值改为偏态分布观察队列长度峰值的变化。下面给一份可以直接粘贴的测试用例表字段包括测试名、参数、预期结果、实际结果、判定。我每次做课程设计都会先建这张表填完再动手改代码比边写边测效率高一倍。测试名窗口数到达概率服务时长范围预期结果判定空队列10.0-正常结束统计数据全 0通过极限负载11.02-8 分钟所有客户被服务无崩溃通过常规混跑40.42-8 分钟平均等待 5-25 分钟需验证VIP 插队40.4混合分布VIP 平均等待低于普通客户需验证5.2 数据结果分析平均等待时间与服务窗口数的关系银行排队系统的核心输出指标是平均等待时间和最大队列长度。这两个指标对窗口数的敏感度极高窗口从 3 个增加到 4 个平均等待时间可能从 30 分钟直接掉到 10 分钟但从 5 个增加到 6 个改善幅度就不明显了。这是因为排队论里的利用率临界点效应——当窗口数量增加到一定程度后瓶颈从窗口数转移到了客户到达规律本身。一份能拿高分的作业会在报告里展示三组不同窗口数下的运行结果并解释「为什么窗口加到 5 个以后平均等待时间下降趋缓」。这份实验可以跟着做固定到达概率为 0.5、模拟 480 分钟、服务时长 2 到 8 分钟分别用 2、3、4、5、6 个窗口跑记录平均等待时间和最大队列长度你会发现曲线从陡降变成平缓。这组数据就是绪论里「银行该开多少个窗口」这个问题最直观的回答。还要注意一个统计细节最大队列长度应该记录「营业期间任意时刻排队的客户数最大值」而不是「营业结束时队列里还剩多少人」。很多同学把这两个数搞混答辩时被老师一句「你最大队列长度才 3但日志里显示中间有段时间排队 20 多人」问得哑口无言。实现时在入队操作后加一行if (q-size max_queue_len) max_queue_len q-size;比最后遍历逐步判定准确得多。5.3 复杂度分析期末答辩必问的时间复杂度与空间复杂度答辩时老师必问的问题是「你这个系统的时间复杂度和空间复杂度是多少」。很多人在这道送分题上翻车因为模拟类作业的时间复杂度不能简单地用单步操作 O(1) 来回答要和模拟的分钟数 M、客户总数 N、窗口数 W 三个维度挂钩。整体时间复杂度的推导脉络是主循环运行 M 分钟每分钟做一次到达判断O(1)和一次调度O(W)所以调度部分的总复杂度 O(M * W)。如果使用优先级队列做 VIP 插队调度部分复杂度为 O(M * logN)因为每次出队要维护堆结构。空间复杂度由队列长度决定最坏情况下所有客户在同一时段到达且窗口无法及时处理队列长度为 O(N)。另外每个客户结构体占固定空间总空间 O(N)。答到这里就把 O(N) 的答案和「为什么不是 O(N²)」讲清楚了。6. 答辩与报告把作业从及格线拉到优秀档的三个习惯6.1 实验报告这样写老师第一眼就认可报告的结构别按教科书模板抄按你代码里的模块走。先写业务需求分析把「先进先出、窗口空闲叫号、超时重新排队」三条规则用自然语言描述清楚再画数据结构定义直接用你代码里的结构体。核心是展示一张运行结果表列出 3 组窗口数下平均等待时间、最大队列长度、总服务客户数然后补一段对结果的分析。这两样The last part of the report is the hardest one: dont write too much, and dont paste a new chapter. The teacher will read the report and code for 20 minutes, and the empty words will be crossed out. The most direct way to get a high score is to show that you have actually done many experiments and have a comparison. If you can append a test log of two shots, the credibility will immediately rise.6.2 Source code organization and two useful expansion directionsSource code dont put everything into one main.c. Split into queue module. c, dispatch. c, stats. c, plus the header file, accompanied by a makefile. Consider that most data structure courses only use C, but I suggest that you do this anyway, because in defense I have many students type code in front of the teacher to say my code is all in one file, which is actually not a problem, but if you show 3 files, the impression of engineering quality is enough to push the score up half a gear.Two cost-effective expansion directions: the first is VIP priority channel, often use priority queue implementation, business logic is clear; the second is to add too late to call the number processing, two times failed to respond to the customer back to the tail of the queue. Both are small changes, code scale about 50 lines. If you can also mention the queue length peak change with the window number trend line, the answer to the optimization question will have material. I have done more than a dozen such projects, each time the final defense is forced to walk through these three things: fixed seeds reproducing a set of experimental data, boundary test to run again, report the complexity analysis once. Since then, whenever I take over a similar simulation project, I first do three stops: fixed seeds, boundary tests, complexity, and then change the logic. Hope it helps you, at least on the last night before the deadline to have a batch of can answer the code.本文还有配套的精品资源点击获取