Qt写的生产者消费者可视化模拟工具，用Windows原生信号量做线程同步

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

简介：这是一个能在Windows上直接运行的Qt图形界面程序，专门用来演示生产者-消费者模型的线程同步过程。程序调用Windows系统级API（比如CreateSemaphore、WaitForSingleObject）实现精确的信号量控制，不是用Qt自带的同步机制，而是真实还原操作系统底层同步逻辑。界面上能实时看到缓冲区内容变化、每个生产者和消费者的运行状态、当前资源占用情况，还支持手动调整线程数量、缓冲区大小、执行速度等参数。启动、暂停、重置功能齐全，所有操作都通过UI按钮完成，不需要改代码。核心逻辑拆分清晰：producer.h封装生产者行为，consumer逻辑在主线程调度中协调，共享缓冲区全程线程安全，能稳定复现空缓冲区时生产者等待、满缓冲区时消费者阻塞的典型场景，也规避了死锁。工程结构完整，包含.pro项目文件、UI设计文件（mainwindow.ui）、头文件和源码，用Qt Creator打开就能编译运行，适合教学演示、课程实验或学生作业参考。

1. 这不是玩具程序，是能放进操作系统课实验报告里的生产者-消费者“显微镜”

你有没有试过给学生讲信号量时，他们眼睛里那种“老师您说的我好像懂了，但又好像没懂”的表情？我带过三年操作系统实验课，每年都有至少三分之一的学生，在写完POSIX信号量作业后，依然分不清sem_wait()阻塞时到底发生了什么——是线程被挂起？还是CPU在轮询？调度器怎么知道该唤醒谁？课本上那个经典的“缓冲区大小为n，有m个生产者、k个消费者”的伪代码，写在纸上很干净，一跑起来就全是竞态、死锁、输出错乱。直到我把这个Qt程序往实验室投影仪上一放，学生围过来盯着屏幕里那个实时跳动的缓冲区格子，看着红色的“P1”图标卡在“等待空位”状态、绿色的“C2”图标在“等待数据”上停住，然后突然一起动起来——那一刻，信号量不再是抽象符号，而是看得见摸得着的系统资源。

这个工具的核心关键词就是生产者消费者、Qt界面、Windows信号量、线程同步、缓冲区模拟。它不依赖Qt的QMutex或QSemaphore，而是直接调用CreateSemaphore、WaitForSingleObject、ReleaseSemaphore这些Windows原生API，把教科书上的PV操作，一比一还原成Windows内核调度的真实行为。你看到的每一个“等待”和“释放”，背后都是一个真实的内核对象句柄在起作用，不是Qt封装层的模拟。界面不是花架子：缓冲区用网格实时渲染，每个格子显示当前数据（数字ID），生产者/消费者用不同颜色图标+状态标签（运行中/等待空位/等待数据/已终止），资源占用栏动态显示信号量当前计数值——这相当于把sem_getvalue()的结果可视化了。参数全由UI控制：你可以拖动滑块把缓冲区从3格改成20格，把生产者数量从1个拉到8个，把执行速度从“慢动作”调到“飞驰模式”，所有改动点下“应用”就生效，不用改一行代码、不用重新编译。它不是一个演示动画，而是一个可交互的同步机制沙盒。如果你是学生，它能帮你拿下课程设计高分；如果你是老师，它能让课堂提问从“信号量初值设多少？”变成“现在P3卡住了，你猜是哪个信号量的值变成了0？为什么不是别的？”——这才是教学该有的样子。

2. 整体架构设计：为什么坚持用Windows原生信号量，而不是Qt封装？

2.1 核心设计哲学：向下穿透，拒绝黑盒

很多Qt教程教生产者-消费者，直接甩出QSemaphore和QMutex，几行代码搞定。这没错，但对学生理解操作系统底层毫无帮助。QSemaphore::acquire()内部到底做了什么？它调用的是POSIX sem_wait()，还是Windows WaitForSingleObject()？它的等待队列由谁管理？超时机制怎么实现？这些问题，Qt文档不会告诉你，因为它的使命是跨平台抽象，不是教学解剖。而这个项目的设计起点就很明确：必须让每一行同步代码，都能在Windows SDK文档里找到对应解释，让学生能顺着代码，一路查到MSDN，看到函数原型、参数含义、返回值说明、错误码列表。所以，CreateSemaphore(NULL, 3, 3, NULL)这行代码，学生可以立刻去查MSDN，明白第一个NULL是安全描述符（我们不需要），第二个3是初始计数（空缓冲区有3个空位），第三个3是最大计数（缓冲区容量），第四个NULL是名字（我们用匿名信号量）。这种一一映射，是建立底层直觉的基石。

2.2 线程模型：主线程调度 + 工作线程纯逻辑

整个程序采用“主线程掌控全局，工作线程专注业务”的分工。主线程（也就是QApplication所在的线程）负责三件事：一是构建和响应UI（按钮点击、滑块拖动）；二是维护一个全局的QTimer，以固定间隔（比如50ms）触发一次“调度检查”；三是作为唯一的协调者，决定何时启动、暂停、重置所有工作线程。而真正的生产者和消费者逻辑，全部封装在独立的ProducerThread和ConsumerThread类中（注意，它们继承自QThread，但核心同步逻辑完全绕开Qt的QMutex）。每个工作线程的run()函数里，只做两件事：一是执行自己的业务逻辑（生产者生成数据、消费者消费数据），二是在关键临界区入口和出口，调用Windows API进行PV操作。这种设计的好处是：UI响应永远不卡顿（因为耗时的WaitForSingleObject不在主线程里），同时又能保证主线程对所有线程生命周期的绝对控制权——点“暂停”，主线程发指令，所有工作线程在下一个PV点检查标志位就停下来；点“重置”，主线程直接Terminate()所有线程并重建，干净利落。

2.3 同步对象布局：三个信号量，各司其职

教科书里常说“需要两个信号量”，但真实系统里，互斥访问缓冲区本身就需要第三个同步原语。这个程序严格遵循经典解决方案，创建了三个Windows信号量：

• hEmptySemaphore：空缓冲区信号量。初始值等于缓冲区大小n。生产者每次想放入数据前，先WaitForSingleObject(hEmptySemaphore, INFINITE)；成功后，空位减一。消费者每次取出数据后，ReleaseSemaphore(hEmptySemaphore, 1, NULL)，空位加一。
• hFullSemaphore：满缓冲区信号量。初始值为0。消费者每次想取数据前，先WaitForSingleObject(hFullSemaphore, INFINITE)；成功后，满位减一。生产者每次放入数据后，ReleaseSemaphore(hFullSemaphore, 1, NULL)，满位加一。
• hMutexSemaphore：互斥信号量。初始值为1。用于保护对共享缓冲区数组buffer[]的读写操作。这是最容易被忽略，却最致命的一环。没有它，即使hEmpty和hFull工作正常，多个生产者同时往同一个buffer[index]写，或者多个消费者同时从同一个buffer[index]读，照样会数据错乱。所有对buffer[]的访问，都必须被WaitForSingleObject(hMutexSemaphore, INFINITE)和ReleaseSemaphore(hMutexSemaphore, 1, NULL)包裹。

提示：这三个信号量的创建顺序和初始值，是程序稳定运行的铁律。hMutex必须是二元信号量（初始=1，最大=1），hEmpty初始=n，hFull初始=0。任何初始化错误，都会导致后续所有等待行为不可预测。

2.4 UI与逻辑解耦：状态驱动，而非事件驱动

界面不是被动接收“生产完成”、“消费完成”的事件，而是主动轮询。主线程的QTimer每50ms触发一次updateDisplay()槽函数。这个函数会：
1. 读取所有工作线程的当前状态枚举（Running, WaitingForEmpty, WaitingForFull, Terminated）；
2. 读取共享缓冲区数组buffer[]的当前内容；
3. 读取三个信号量的当前计数值（通过ReleaseSemaphore的反向技巧或专用查询函数）；
4. 将这些原始数据，转换成UI元素的属性（网格格子文本、图标颜色、状态标签文字、进度条位置）。

这种“状态驱动”模式，让UI成为系统当前快照的忠实反映，而不是一堆离散事件的拼凑。学生看到的，永远是某一时刻系统的真实全貌，而不是“刚看到P1放入，下一帧就看到C1取出”的跳跃感。这也为后续扩展（比如添加“单步执行”、“断点暂停”）打下了坚实基础——你随时可以冻结这个状态快照。

3. 核心细节解析：从Windows API调用到Qt UI渲染的完整链条

3.1 Windows信号量的创建与生命周期管理

信号量对象不是凭空出现的，它是一个内核对象，有严格的创建、使用、销毁流程。在MainWindow的构造函数里，你会看到这样的代码：

// 初始化信号量
hEmptySemaphore = CreateSemaphore(NULL, bufferSize, bufferSize, NULL);
hFullSemaphore = CreateSemaphore(NULL, 0, bufferSize, NULL);
hMutexSemaphore = CreateSemaphore(NULL, 1, 1, NULL);

if (hEmptySemaphore == NULL || hFullSemaphore == NULL || hMutexSemaphore == NULL) {
    QMessageBox::critical(this, "Error", "Failed to create semaphores! Error: " + QString::number(GetLastError()));
    // 程序无法继续，弹窗提示并退出
}

这里的关键细节在于CreateSemaphore的参数。第一个NULL表示不继承句柄，这是安全的默认选择。第二个参数是初始计数，hEmptySemaphore设为bufferSize，意味着一开始有bufferSize个空位可用；hFullSemaphore设为0，意味着一开始没有数据可取；hMutexSemaphore设为1，表示互斥锁初始是“未锁定”状态。第三个参数是最大计数，它限定了信号量计数的上限。对于hEmptySemaphore和hFullSemaphore，这个值必须等于bufferSize，否则ReleaseSemaphore调用超过上限会失败。对于hMutexSemaphore，最大值必须是1，否则它就不是互斥锁了。

信号量的销毁放在MainWindow的析构函数里，使用CloseHandle()：

// 在MainWindow::~MainWindow()中
if (hEmptySemaphore) CloseHandle(hEmptySemaphore);
if (hFullSemaphore) CloseHandle(hFullSemaphore);
if (hMutexSemaphore) CloseHandle(hMutexSemaphore);

注意：CloseHandle()只是关闭当前进程对该内核对象的引用，当所有引用都被关闭后，内核对象才会被真正销毁。这里没有用DeleteSemaphore（Windows根本没有这个API），因为CloseHandle()就是正确的销毁方式。很多初学者会误以为需要专门删除，这是对Windows对象模型的误解。

3.2 生产者线程的完整PV循环：一次放入的七步法

让我们拆解一个生产者线程ProducerThread::run()中最核心的一次“生产-放入”循环。这不是简单的两行代码，而是一个包含七个明确步骤的原子操作：

1. 生成数据：int data = ++m_nextId; （生成一个递增的唯一ID）
2. 等待空位：WaitForSingleObject(m_hEmptySemaphore, INFINITE); —— 这是P(empty)操作。如果此时hEmptySemaphore计数为0（缓冲区满了），线程在此处被内核挂起，进入等待队列，CPU时间片让给其他线程。这是阻塞发生的精确位置。
3. 获取互斥锁：WaitForSingleObject(m_hMutexSemaphore, INFINITE); —— 这是P(mutex)操作。确保接下来对缓冲区的写入是独占的。
4. 计算索引：int index = m_writeIndex % m_bufferSize; （使用模运算实现循环缓冲区）
5. 写入数据：m_buffer[index] = data; （这才是真正修改共享内存的地方）
6. 更新写指针：m_writeIndex++; （指针前进）
7. 释放锁并通知：ReleaseSemaphore(m_hMutexSemaphore, 1, NULL); ReleaseSemaphore(m_hFullSemaphore, 1, NULL); —— 这是V(mutex)和V(full)操作。先释放互斥锁，再增加满位计数，通知可能正在等待的消费者。

这个七步法，清晰地展示了PV操作的顺序依赖。如果把第2步和第3步颠倒，先抢锁再等空位，就会造成“持锁等待”，极易引发死锁（想象所有生产者都拿到了锁，但都在等空位，而消费者因为拿不到锁，永远无法消费）。如果把第6步和第7步颠倒，先通知再更新指针，就会导致消费者读到一个未写入的垃圾值。顺序，就是同步的全部意义。

3.3 UI缓冲区网格的实时渲染：从数组到像素的映射

mainwindow.ui里定义了一个QGridLayout，里面放置了bufferSize个QLabel，每个QLabel代表缓冲区的一个格子。在updateDisplay()函数里，渲染逻辑如下：

for (int i = 0; i < m_bufferSize; ++i) {
    QLabel* label = qobject_cast<QLabel*>(ui->gridLayout->itemAt(i)->widget());
    if (label) {
        int value = m_buffer[i];
        if (value == -1) { // -1 表示空位
            label->setText("");
            label->setStyleSheet("background-color: #f0f0f0; border: 1px solid #ccc;");
        } else {
            label->setText(QString::number(value));
            // 根据数值大小设置颜色渐变，让数据流动更直观
            int hue = (value % 256); // 简单的色相映射
            label->setStyleSheet(QString("background-color: hsl(%1, 70%, 85%); border: 1px solid #aaa; color: black; font-weight: bold;").arg(hue));
        }
    }
}

这里的关键是，m_buffer[i]是一个受hMutexSemaphore保护的共享变量，updateDisplay()在主线程里读取它时，必须确保没有工作线程正在写入。解决方案是：updateDisplay()本身不加锁，但它只在工作线程处于“等待”或“终止”状态时才读取；而工作线程只有在持有hMutexSemaphore时才写入，且写入时间极短（纳秒级）。这是一种“乐观读取”策略，依赖于UI刷新频率（50ms）远大于单次写入时间，实践中几乎不会读到中间状态。如果追求绝对安全，可以在updateDisplay()开始时也尝试WaitForSingleObject(hMutexSemaphore, 10)，超时即放弃本次更新，但这会引入不必要的复杂性，对于教学演示，当前方案足够稳健。

3.4 状态标签的语义化设计：让“等待”看得见

UI上每个生产者/消费者图标旁边，都有一个状态标签，文字不是简单的“Running”或“Blocked”，而是精确描述其阻塞原因：

• P1: Waiting for empty slot （生产者1：等待空缓冲区）
• C2: Waiting for data （消费者2：等待数据）
• P3: Running （生产者3：运行中）

这个状态信息，不是靠猜测，而是由工作线程自己在run()函数中实时更新的一个QAtomicInt状态变量。例如，在生产者线程里：

// 在等待空位前
m_state.store(ProducerState::WaitingForEmpty);
WaitForSingleObject(m_hEmptySemaphore, INFINITE);

// 成功获得空位后
m_state.store(ProducerState::Running);
// ... 执行写入 ...

主线程的updateDisplay()函数，会定期读取这个QAtomicInt，并将其转换为对应的中文字符串。这种设计，让学生一眼就能看出“为什么卡在这里”，而不是笼统地认为“线程卡死了”。它把抽象的“阻塞”概念，具象成了“我在等什么”。

4. 实操过程详解：从Qt Creator打开到参数调优的完整指南

4.1 环境准备与工程导入：零配置起步

这个项目对环境的要求极其宽松，这也是它能走进课堂的关键。你只需要：

• 操作系统：Windows 7 或更高版本（64位推荐，但32位也完全支持）。
• 开发工具：Qt Creator 4.15 或更高版本（推荐使用Qt 5.15.2，因为它对Windows API的支持最成熟，且是LTS长期支持版本）。
• 编译器：MinGW 7.3.0_64bit（随Qt Creator安装包自带）或 MSVC 2019（如果你习惯用Visual Studio工具链）。

导入步骤简单到不可思议：
1. 解压下载的ZIP包，得到EWa2HPQZnaRFNh7bKtF9-master-32beba0c375b07b1f399101413dae6144c1c2206文件夹。
2. 打开Qt Creator，选择 File -> Open File or Project...，然后导航到该文件夹，选中ProductorConsumer.pro文件。
3. Qt Creator会自动识别这是一个Qt项目，加载.pro文件，并解析mainwindow.ui。无需手动配置Kit，Creator会自动匹配你电脑上已安装的Qt版本和编译器。
4. 点击左下角的绿色三角形“运行”按钮，或者按Ctrl+R。几秒钟后，一个标题为“Producer-Consumer Simulator”的窗口就会弹出。

注意：第一次运行时，Qt Creator可能会提示“找不到Qt版本”，这时点击提示框里的“Auto-detect”按钮，它会扫描你电脑上已安装的Qt路径并自动添加。如果扫描不到，你可能需要先去qt.io下载并安装Qt Online Installer，选择安装Qt 5.15.2 for Desktop MinGW。

4.2 参数面板实战：用三分钟理解缓冲区大小的影响

参数面板是教学的利器。我们来做个快速实验：

1. 初始状态：缓冲区大小=3，生产者=1，消费者=1，速度=中速。
2. 启动：点击“Start”按钮。观察：P1图标开始闪烁，很快在缓冲区第一个格子填入“1”，然后是“2”、“3”。当第三个格子填满后，P1图标状态变为“Waiting for empty slot”，停止不动。与此同时，C1图标开始工作，依次取出“1”、“2”、“3”，缓冲区格子变为空白。这是一个完美的、节奏分明的流水线。
3. 放大缓冲区：将“Buffer Size”滑块拖到10，点击“Apply”。你会发现，P1可以连续生产10个数据才停下，而C1需要更长时间才能清空。这直观地展示了增大缓冲区如何缓解生产者和消费者的速率不匹配问题。
4. 增加竞争：将“Producer Count”改为3，“Consumer Count”改为2，再次点击“Apply”和“Reset”。现在，你会看到三个红色P图标在争抢空位，两个绿色C图标在争抢数据。有时P1刚写完，P2就立刻抢到锁写入下一个；有时C1取走一个，C2马上跟上。这生动地演示了多线程并发访问共享资源时，信号量如何公平地调度等待队列（Windows的WaitForSingleObject默认是FIFO队列）。

4.3 “暂停”与“重置”功能的底层实现

这两个按钮看似简单，但其实现体现了对线程生命周期的精细控制。

• “Pause”按钮：它并不直接调用QThread::terminate()（那是危险的）。相反，它设置一个全局的QAtomicBool m_isPaused标志位。所有工作线程的run()函数里，都有一个循环：

cpp while (m_isRunning.load()) { if (m_isPaused.load()) { QThread::msleep(10); // 短暂休眠，避免空转 continue; } // 执行一次完整的PV循环... }

点击“Pause”，m_isPaused.store(true)，所有线程立刻在下一轮循环中检测到标志，进入休眠。点击“Resume”，m_isPaused.store(false)，线程立刻醒来继续工作。这是一种安全、可控的暂停方式。

• “Reset”按钮：这是最彻底的清理。它首先调用m_isRunning.store(false)，通知所有线程准备退出。然后，对每个工作线程对象，调用wait()方法，强制主线程等待，直到该工作线程的run()函数自然结束。最后，delete掉所有旧的线程对象，并根据新的参数，重新new一批全新的线程对象。这样做的好处是，所有Windows信号量句柄、缓冲区内存、线程栈，都得到了彻底的释放和重建，杜绝了任何残留状态导致的诡异bug。

4.4 死锁规避的现场验证：故意制造，然后化解

教学中，让学生亲手制造一次死锁，再亲手解开它，印象最深刻。我们可以这样做：

1. 制造死锁：在代码里，临时注释掉生产者线程中ReleaseSemaphore(m_hFullSemaphore, 1, NULL);这一行。重新编译运行。
2. 观察现象：程序启动后，P1会顺利生产3个数据（缓冲区满），然后卡在Waiting for empty slot。C1尝试WaitForSingleObject(hFullSemaphore, INFINITE)，但hFullSemaphore的计数始终是0（因为没人释放它），所以C1也卡住。两个线程互相等待，形成经典死锁。UI上，P1和C1的状态标签会一直显示“Waiting…”，永远不会改变。
3. 恢复并讲解：把那行ReleaseSemaphore代码取消注释，重新编译。这次，P1每放入一个数据，就立刻释放一个hFullSemaphore，C1就能及时被唤醒。这个对比实验，让学生亲眼看到：V(full)操作不是可有可无的，它是打破等待循环、维持系统活性的生命线。

5. 常见问题与排查技巧实录：那些年踩过的坑，都给你记下来了

5.1 问题速查表：高频故障与一键定位

5.2 独家避坑心得：来自三年教学一线的血泪总结

• “INFINITE”不是万能的，但它是教学的最佳选择：WaitForSingleObject(h, INFINITE)会让线程无限期等待，直到信号量可用。有些同学会想用WaitForSingleObject(h, 1000)加1秒超时，认为这样“更安全”。但在教学演示中，这反而会制造混乱：线程超时返回WAIT_TIMEOUT，你得额外处理这个错误码，还要决定是重试还是放弃。而INFINITE则让逻辑无比清晰——“我就是要等到，直到条件满足”。对于理解同步本质，这是最干净的模型。等学生真正理解了，再教他们超时处理也不迟。

• 不要迷信“Qt线程安全”的神话：Qt文档说QString、QList等容器是线程安全的，但这仅指它们自身的内存管理，绝不意味着你可以把一个QList<int>当作共享缓冲区，在多个线程里随意读写。QList::append()内部可能涉及内存重分配，QList::at()在多线程下读取，依然可能读到部分写入的中间状态。这个项目里，共享缓冲区必须是原始C风格数组int buffer[1024]，配合hMutexSemaphore保护，这才是教科书级别的正解。

• UI刷新频率是个甜蜜的陷阱：QTimer设成10ms刷新一次，UI看起来更“丝滑”，但会极大增加主线程负担，可能导致updateDisplay()来不及执行完，下一个定时器又来了，最终UI卡顿。实测下来，50ms是一个完美的平衡点：人眼无法分辨50ms（20帧/秒）和100ms（10帧/秒）的差别，但50ms给了主线程充足的处理时间，确保每次刷新都是完整的、一致的状态快照。把这个值写死在代码里，比做成可调参数更稳妥。

• “Terminate()”是最后的手段，永远优先用“优雅退出”：QThread::terminate()会立即杀死线程，不执行任何清理代码，可能导致Windows信号量句柄泄漏（虽然系统会在进程退出时回收，但这是不良习惯）。正确的做法是，像前面说的那样，用QAtomicBool m_isRunning标志位，让线程自己在循环末尾检查并干净退出。terminate()只应在wait()超时（比如等了5秒线程还不退出）的极端情况下使用，而且要用try-catch包裹，并记录日志。

• 调试信号量，最好的工具是你的大脑，不是IDE：你无法在Qt Creator的调试器里，像看普通变量一样看到hEmptySemaphore的当前计数值。Windows没有提供公开的API来查询信号量值（出于安全考虑）。所以，最可靠的调试方式，是通过UI的状态标签和缓冲区显示，反向推理。如果P1卡在“Waiting for empty slot”，而缓冲区明明是空的，那一定是hEmptySemaphore的计数出了问题——要么是某个地方ReleaseSemaphore没调用，要么是CreateSemaphore初始值设错了。这种“现象->推理->验证”的闭环，恰恰是操作系统思维训练的核心。

6. 教学延伸与二次开发：让它不止于一个演示程序

这个程序的价值，远不止于课堂演示。它是一个绝佳的二次开发起点，可以无缝衔接到更高级的操作系统概念教学中。

6.1 引入“饥饿”概念：修改调度策略

当前的WaitForSingleObject使用的是默认的FIFO等待队列，公平但可能造成“饥饿”。你可以引导学生思考：如果一个消费者C1总是比C2快，C2会不会永远等不到数据？答案是肯定的。那么，如何修改，让等待时间最长的线程优先被唤醒？这就引出了优先级继承和等待超时的概念。二次开发建议：在ConsumerThread::run()里，将WaitForSingleObject(hFullSemaphore, INFINITE)改为WaitForSingleObject(hFullSemaphore, 5000)，并捕获WAIT_TIMEOUT。当超时时，让该消费者线程打印一条日志“Starving for 5 seconds!”，并主动yield()让出CPU。这能直观地展示“饥饿”现象及其初步缓解策略。

6.2 集成“银行家算法”：从同步走向死锁避免

生产者-消费者模型本身不会死锁，但它是理解死锁的完美入口。下一步，可以将这个UI框架，改造为一个“银行家算法”模拟器。保留相同的UI结构（网格、状态标签、参数面板），但把“缓冲区”变成“系统资源总览”，把“生产者/消费者”变成“进程”，把“数据ID”变成“资源请求向量”。学生可以在UI上输入每个进程的最大需求、已分配资源、当前请求，然后点击“Calculate Safe State”，程序后台运行银行家算法，UI实时显示安全序列或指出死锁进程。这个扩展，能把“死锁预防”和“死锁避免”两个章节，用同一个熟悉的界面讲透。

6.3 添加“性能统计”面板：量化并发效果

在UI右侧，增加一个“Performance Stats”标签页，实时显示：
- 吞吐量：单位时间内成功生产/消费的数据项数量（items/sec）。
- 平均等待时间：所有生产者等待空位的平均毫秒数，所有消费者等待数据的平均毫秒数。
- CPU占用率：通过GetProcessTimes() API，计算主线程和工作线程的CPU时间占比。

这些数据，能让学生从定性观察（“看起来很忙”）走向定量分析（“吞吐量提升了23%，但平均等待时间增加了40%”），理解并发优化中的经典权衡。

6.4 跨平台移植的务实路径：不是放弃Windows，而是拥抱差异

有老师问：“能不能改成Linux版？”我的建议是：不要强行跨平台，而是利用平台差异进行对比教学。保留Windows版作为“原生API”范本，再单独做一个Linux版，使用sem_init()/sem_wait()/sem_post()。两个版本UI完全一致，但核心同步代码截然不同。上课时，把两个窗口并排打开，让学生观察：同样的参数设置下，两者的行为是否一致？sem_getvalue()在Linux下能查到值，而Windows下不行，这反映了不同内核的设计哲学。这种对比，比任何理论讲解都更有说服力。

我在实际使用中发现，这个程序最大的价值，不是它有多炫酷，而是它把“看不见”的操作系统内核行为，变成了“看得见、摸得着、可操控”的实体。学生不再需要闭着眼睛想象“调度器在做什么”，他们可以直接看到，当hFullSemaphore的值变成0时，那个绿色的C图标是如何凝固在屏幕上的。这种具象化的认知，是任何PPT和板书都无法替代的。它不是一个终点，而是一把钥匙，打开了通往操作系统深处的大门。

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

简介：这是一个能在Windows上直接运行的Qt图形界面程序，专门用来演示生产者-消费者模型的线程同步过程。程序调用Windows系统级API（比如CreateSemaphore、WaitForSingleObject）实现精确的信号量控制，不是用Qt自带的同步机制，而是真实还原操作系统底层同步逻辑。界面上能实时看到缓冲区内容变化、每个生产者和消费者的运行状态、当前资源占用情况，还支持手动调整线程数量、缓冲区大小、执行速度等参数。启动、暂停、重置功能齐全，所有操作都通过UI按钮完成，不需要改代码。核心逻辑拆分清晰：producer.h封装生产者行为，consumer逻辑在主线程调度中协调，共享缓冲区全程线程安全，能稳定复现空缓冲区时生产者等待、满缓冲区时消费者阻塞的典型场景，也规避了死锁。工程结构完整，包含.pro项目文件、UI设计文件（mainwindow.ui）、头文件和源码，用Qt Creator打开就能编译运行，适合教学演示、课程实验或学生作业参考。

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