C++实现操作系统进程与线程模拟：从理论到实践的并发编程指南

1. 项目概述：从理论到实践的跨越

“操作系统实验：C++实现进程与线程”，这个标题对于计算机专业的学生和初入行的开发者来说，既熟悉又充满挑战。熟悉，是因为进程与线程是操作系统课程中绕不开的核心概念；充满挑战，则在于从书本上的流程图、状态转换图，到亲手用代码构建出可以运行的“进程”和“线程”，中间隔着一条巨大的鸿沟。很多人学完了理论，面对“如何用代码模拟一个进程调度”这样的实验要求时，依然会感到无从下手。这个项目的核心价值，就在于弥合这道鸿沟，它不是一个简单的“Hello World”程序，而是一个微型的、可运行的“操作系统内核”模拟器，让你能亲手触摸到并发世界的底层逻辑。

简单来说，这个项目要求你用C++这门贴近系统底层的语言，去模拟操作系统最核心的并发管理功能。你需要设计数据结构来表示进程和线程的“身份证”（PCB/TCB），实现让它们“活起来”的创建、切换、等待与唤醒机制，并处理好它们之间对共享资源的争夺。最终，你的程序将能够演示多个“任务”如何在一颗CPU上（通过时间片轮转等策略）交替执行，如何通过同步机制（如互斥锁、信号量）有序协作，而不是陷入混乱的竞争。这不仅仅是完成一次作业，更是对计算机系统如何运作的一次深刻洞察。无论你是为了巩固课程知识、准备面试中高频的操作系统八股文，还是为日后从事系统级开发（如数据库、中间件、游戏引擎）打下坚实基础，这个项目都是一块极佳的敲门砖。

2. 核心概念与设计思路拆解

在动手写代码之前，我们必须把核心概念和整体设计思路理清楚。很多人一上来就埋头写struct PCB，写着写着就乱了，根本原因在于对模拟的“尺度”和“目标”不清晰。

2.1 进程与线程的本质区别与我们的模拟尺度

教科书上说，进程是资源分配的单位，线程是CPU调度的单位。在我们的模拟项目中，这句话需要被翻译成具体的数据结构和行为。

• 进程：在我们的C++模拟程序中，一个“进程”更像是一个资源的容器和执行的沙箱。它需要拥有：

  • 模拟的进程控制块（PCB）：这是进程的“户口本”，至少包含进程ID（PID）、状态（就绪、运行、阻塞等）、程序计数器（PC，指向下一条要执行的指令地址，这里可能是我们模拟的指令数组索引）、寄存器集合（模拟的上下文）、以及指向其地址空间（模拟）的指针。
  • 模拟的地址空间：我们不可能在用户态真的去划分物理内存。通常，我们用一个大数组或一个结构体来模拟进程的“内存”，里面存放该进程的“代码”（用函数指针或一个任务函数表示）和“数据”（一些全局或堆变量）。
  • 资源所有权：进程是资源分配的单位。在我们的模拟中，“资源”可以简化为一些互斥访问的全局变量、文件句柄（用整数ID模拟）或信号量。进程创建时，可能会“持有”某些资源。

• 线程：线程是进程内部的执行流。在我们的模拟中，一个进程下可以有多个线程。

  • 模拟的线程控制块（TCB）：包含线程ID（TID）、状态、独立的模拟寄存器集（尤其是栈指针SP，因为每个线程要有自己独立的栈）、所属进程的PID，以及指向其私有栈空间（模拟）的指针。
  • 共享与私有：同一个进程下的所有线程共享进程的“地址空间”（即那些全局变量和代码），但每个线程有自己私有的栈空间（用于存放局部变量、函数调用链）。这是实现模拟的关键，也是线程间通信（通过共享变量）和线程同步问题（竞争共享变量）的来源。
  • 我们的模拟重点：由于是在单一的用户进程内模拟，我们实现的“线程”通常指的是用户级线程。它们的调度由我们的模拟程序（即“运行时库”）自己管理，而不是由操作系统内核直接调度。这简化了实现，但核心的同步、互斥问题依然存在且必须解决。

设计思路的核心：我们将构建一个用户态的线程库和进程管理器。主程序（main函数）就像是我们的“内核初始化代码”。我们会有一个全局的调度器（Scheduler），它维护着就绪队列、阻塞队列。我们会实现一套函数（如create_process,create_thread,yield,sleep,lock,unlock），这些函数被我们的“模拟任务”调用，从而触发状态的改变和调度。CPU的执行时间流，我们用主循环（while）来模拟，每次循环，调度器从就绪队列中选出一个线程执行它的一小段“任务代码”。

2.2 模拟方案选型：为何是C++与用户级线程

为什么用C++而不是Java或Python？首先，C++提供了对内存和底层操作的精细控制（指针、内存布局），这与操作系统管理资源的理念吻合。其次，C++标准库中的<thread>虽然能直接创建系统线程，但为了学习原理，我们通常选择自己模拟，或者使用更底层的pthread（POSIX线程）库作为基础来封装我们自己的逻辑。但在这个纯教学模拟项目中，我们甚至可以不用任何系统线程库，完全用一个“协作式”或“抢占式”的循环来模拟多任务。这能让你最清晰地看到上下文切换的每一步。

方案选择：

1. 完全模拟（协作式）：所有“线程”函数都是普通函数，它们必须主动调用yield()来放弃CPU。调度器只是一个简单的队列管理器。这种方式最简单，能清晰展示状态切换，但无法模拟真正的抢占。
2. 基于定时器中断的模拟（抢占式）：利用setitimer或alarm函数设置一个定时信号（如SIGALRM），在信号处理函数中强制进行上下文切换。这更贴近真实操作系统，但实现复杂，涉及信号安全和异步上下文保存。
3. 基于系统线程库的封装：使用pthread_create创建真实的系统线程，但在此基础上封装我们自己的TCB、调度策略和同步原语。这样，线程是真正并发的（在多核上可能并行），我们的调度器可能演变为一个“工作队列”模式。这种方式更“真实”，但可能会掩盖单调度循环的简洁性。

对于初学者，我强烈推荐从方案1（协作式）开始。它剥离了硬件中断和系统调用的复杂性，让你专注于进程/线程模型、状态机、调度算法和同步机制这些核心概念的本质实现。理解了这些，再去研究方案2或3，会豁然开朗。

注意：在协作式模拟中，一个“恶意”线程（不调用yield的死循环）会阻塞整个模拟程序，这与真实操作系统中的线程行为不同。但这正是教学意义所在——让你理解抢占的必要性。

3. 核心数据结构与关键函数设计

有了清晰的思路，我们就可以开始设计支撑整个模拟系统的基石：数据结构和关键函数接口。

3.1 进程控制块（PCB）与线程控制块（TCB）的设计

这是整个系统的灵魂。设计的好坏直接决定了代码的清晰度和扩展性。

// 进程状态枚举 enum ProcessState { READY, RUNNING, BLOCKED, TERMINATED }; // 线程状态枚举 enum ThreadState { T_READY, T_RUNNING, T_BLOCKED, T_TERMINATED }; // 模拟的上下文结构体（用于保存/恢复“现场”） // 在完全模拟方案中，这组数据可能比较简单 struct Context { // 对于模拟线程，我们可能只需要保存程序计数器（PC）和栈指针（SP） // PC可以用一个函数指针或任务编号表示 void (*pc)(); // 下一条要执行的指令（函数） void* stack_pointer; // 模拟的栈指针，指向该线程私有栈的当前位置 // 可以添加更多通用寄存器模拟，如 int eax, ebx, ecx... }; // 线程控制块（TCB） struct ThreadControlBlock { int tid; // 线程ID ThreadState state; // 线程状态 Context context; // 线程上下文 int pid; // 所属进程ID void* stack_base; // 线程栈起始地址（我们动态分配的内存块） size_t stack_size; // 栈大小 // 用于链接到调度队列 TCB* next; // 可以添加优先级、等待时间等字段 int priority; int wait_until; // 用于模拟睡眠，直到某个模拟时间点 }; // 进程控制块（PCB） struct ProcessControlBlock { int pid; // 进程ID ProcessState state; // 进程状态（宏观状态，通常由其主线程或所有线程状态推导） // 进程资源列表（模拟），例如持有的文件描述符、信号量ID等 std::vector<int> resources; // 指向该进程的第一个线程（主线程）或线程链表 TCB* main_thread; // 进程的“地址空间”模拟（例如，一个结构体，包含共享数据） struct { int shared_counter; // 其他共享变量... } address_space; // 用于链接到进程链表 PCB* next; };

设计要点：

• TCB是调度的基本单位：在我们的模拟中，调度器操作的是TCB队列。进程状态更多是管理意义上的。
• 栈的管理：每个线程必须有自己独立的栈空间。我们使用malloc或new在堆上分配一块内存作为线程栈。当切换线程时，我们需要切换stack_pointer。在协作式模拟中，栈切换可能通过setjmp/longjmp来实现（需谨慎使用），或者通过我们手动的上下文保存/恢复逻辑。
• 上下文（Context）：在真实CPU中，上下文切换需要保存几十个寄存器。我们这里做了极大简化，只保存最关键的PC和SP。在基于ucontext或汇编的深入实现中，这个结构会复杂得多。

3.2 调度器（Scheduler）的设计与实现

调度器是模拟系统的“大脑”，它决定接下来该谁运行。

class Scheduler { private: TCB* ready_queue; // 就绪队列（链表实现） TCB* blocked_queue; // 阻塞队列 TCB* current_thread; // 当前正在运行的线程 int next_tid; // 用于分配下一个线程ID int simulated_time; // 模拟的全局时间 public: Scheduler() : ready_queue(nullptr), blocked_queue(nullptr), current_thread(nullptr), next_tid(1), simulated_time(0) {} // 创建一个新线程，并将其放入就绪队列 int create_thread(void (*start_routine)(void*), void* arg, int priority = 0) { TCB* new_tcb = new TCB(); new_tcb->tid = next_tid++; new_tcb->state = T_READY; new_tcb->priority = priority; // 为线程分配栈空间（例如 64KB） new_tcb->stack_size = 64 * 1024; new_tcb->stack_base = malloc(new_tcb->stack_size); // 初始化上下文：PC指向线程入口函数，SP指向栈顶（栈通常从高地址向低地址增长） new_tcb->context.pc = (void (*)())start_routine; new_tcb->context.stack_pointer = (char*)new_tcb->stack_base + new_tcb->stack_size - sizeof(void*); // 将参数压入模拟栈（这里简化处理，实际可能需要内联汇编或特定函数设置） // ... 参数传递的模拟比较复杂，是难点之一 // 将新线程加入就绪队列尾部 enqueue_ready(new_tcb); return new_tcb->tid; } // 将线程放入就绪队列 void enqueue_ready(TCB* tcb) { tcb->state = T_READY; tcb->next = nullptr; if (!ready_queue) { ready_queue = tcb; } else { TCB* p = ready_queue; while (p->next) p = p->next; p->next = tcb; } } // 调度函数：从就绪队列中选择下一个要运行的线程 void schedule() { if (!current_thread || current_thread->state == T_TERMINATED) { // 当前线程结束或不存在，直接选择下一个 } else if (current_thread->state == T_RUNNING) { // 协作式调度：当前线程主动yield，状态变回READY current_thread->state = T_READY; enqueue_ready(current_thread); } // 从就绪队列头部取出一个线程（先来先服务，FCFS） if (!ready_queue) { // 没有就绪线程，可能是所有线程都阻塞或结束了 return; } TCB* next = ready_queue; ready_queue = ready_queue->next; next->next = nullptr; next->state = T_RUNNING; current_thread = next; // 执行上下文切换（在协作式模拟中，这可能只是一个函数调用） // 在更真实的模拟中，这里会调用 context_switch(&old_context, &new_context) switch_to_thread(next); } // 线程主动让出CPU void yield() { schedule(); } // 模拟时间流逝并检查阻塞队列 void tick() { simulated_time++; // 检查阻塞队列，是否有线程等待的条件满足了（如睡眠时间到） TCB** pp = &blocked_queue; while (*pp) { TCB* t = *pp; // 假设线程在等待某个模拟时间点 if (t->wait_until <= simulated_time) { // 从阻塞队列中移除 *pp = t->next; // 放入就绪队列 enqueue_ready(t); // 继续检查当前节点的下一个（因为pp已经指向了新的next） } else { pp = &((*pp)->next); } } } // 线程睡眠（模拟） void sleep(int ticks) { if (current_thread) { current_thread->state = T_BLOCKED; current_thread->wait_until = simulated_time + ticks; // 将当前线程从就绪/运行状态转移到阻塞队列 enqueue_blocked(current_thread); schedule(); // 立即触发调度 } } private: void enqueue_blocked(TCB* tcb) { /* 类似enqueue_ready */ } void switch_to_thread(TCB* next) { // 协作式模拟的简化版本：直接调用线程函数 // 注意：这只是一个示意，真正的上下文切换需要保存当前状态 void (*func)() = (void (*)())next->context.pc; func(); // 这里无法传递参数，且函数不会返回，因为我们的线程函数是死循环或最终调用thread_exit // 真正的实现需要使用 setjmp/longjmp 或 ucontext 系列函数 } };

关键点解析：

• 队列管理：我们使用简单的单链表管理就绪和阻塞队列。工业级调度器会使用更高效的数据结构，如多级优先队列、红黑树等。
• schedule()函数：这是核心。它处理当前线程的状态转移（从RUNNING到READY或BLOCKED），然后从就绪队列中选择下一个线程。选择策略（如FCFS、优先级）就在这里体现。
• switch_to_thread()：这是最复杂的部分，在协作式模拟中我们极大地简化了它。真实的上下文切换需要：
  1. 保存当前线程的所有寄存器到其context中。
  2. 将current_thread指向下一个线程。
  3. 从下一个线程的context中恢复所有寄存器。
  4. 跳转到恢复的PC地址继续执行。 在Linux中，setjmp/longjmp可以保存/恢复部分上下文，但不够完整（例如信号掩码）。ucontext系列函数（makecontext,swapcontext）是更好的选择，但它们在一些平台上已被标记为废弃。最正统但最复杂的方式是使用汇编语言编写上下文切换代码。
• 模拟时间：simulated_time和tick()函数用于模拟时间的流逝，是实现sleep、时间片轮转等与时间相关功能的基础。

4. 同步与互斥机制的实现

多个线程并发访问共享资源（比如我们PCB里的address_space.shared_counter），如果不加控制，就会导致数据竞争，结果不可预测。实现同步互斥机制是本项目的另一个核心难点和亮点。

4.1 互斥锁（Mutex）的实现

互斥锁保证同一时刻只有一个线程能进入临界区。

class Mutex { private: int locked; // 锁状态：0-未锁，1-已锁 TCB* waiting_queue; // 等待该锁的线程队列 public: Mutex() : locked(0), waiting_queue(nullptr) {} void lock() { // 这是一个非原子操作，在真实多线程环境下会有问题！ // 但在我们的协作式单线程模拟器中，由于`lock()`和`unlock()`之间不会发生调度（除非主动yield），所以暂时安全。 // 如果模拟抢占，则需要更严格的保护，例如禁用中断（模拟）或使用原子操作。 if (locked) { // 锁已被占用，当前线程阻塞 if (current_thread) { current_thread->state = T_BLOCKED; // 将当前线程加入该锁的等待队列 enqueue_waiting(current_thread); scheduler->schedule(); // 主动放弃CPU } } else { locked = 1; } } void unlock() { locked = 0; // 检查等待队列，唤醒一个线程 if (waiting_queue) { TCB* t = waiting_queue; waiting_queue = waiting_queue->next; t->next = nullptr; scheduler->enqueue_ready(t); // 唤醒，放入就绪队列 } } private: void enqueue_waiting(TCB* tcb) { tcb->next = nullptr; if (!waiting_queue) { waiting_queue = tcb; } else { TCB* p = waiting_queue; while (p->next) p = p->next; p->next = tcb; } } }; // 使用示例 Mutex counter_mutex; int shared_counter = 0; void thread_func() { for (int i = 0; i < 100000; ++i) { counter_mutex.lock(); shared_counter++; // 临界区 counter_mutex.unlock(); scheduler->yield(); // 模拟线程切换，增加竞争机会 } }

问题与思考：上面的lock()实现有一个致命缺陷：判断if (locked)和设置locked = 1不是原子操作。在真正的并发环境下，两个线程可能同时看到locked == 0，然后都去加锁，导致互斥失效。这就是著名的竞态条件。在真实的操作系统中，硬件会提供原子指令（如Test-and-Set, Compare-and-Swap）来实现锁的原子获取。在我们的模拟中，如果是在协作式环境下（线程只在yield或lock内主动放弃CPU），这个简单实现可以工作。但为了教学完整性，我们应该意识到这一点，并可以尝试用std::atomic（如果使用C++11及以上）来模拟原子操作，或者在我们的模拟“内核”中约定，检查锁和加锁的过程是不可分割的“原语”。

4.2 信号量（Semaphore）的实现

信号量是一种更通用的同步机制，可以用来实现互斥、条件同步等多种模式。

class Semaphore { private: int value; // 信号量值 TCB* waiting_queue; // 等待队列 public: Semaphore(int init_val) : value(init_val), waiting_queue(nullptr) {} void wait() { // P操作 value--; if (value < 0) { // 资源不足，阻塞当前线程 if (current_thread) { current_thread->state = T_BLOCKED; enqueue_waiting(current_thread); scheduler->schedule(); } } } void signal() { // V操作 value++; if (value <= 0) { // 有线程在等待，唤醒一个 if (waiting_queue) { TCB* t = waiting_queue; waiting_queue = waiting_queue->next; t->next = nullptr; scheduler->enqueue_ready(t); } } } private: void enqueue_waiting(TCB* tcb) { /* 同Mutex */ } }; // 使用示例1：用信号量实现互斥（初始值设为1） Semaphore mutex(1); void critical_section() { mutex.wait(); // ... 访问共享资源 mutex.signal(); } // 使用示例2：生产者-消费者问题（有限缓冲区） const int BUFFER_SIZE = 10; int buffer[BUFFER_SIZE]; int in = 0, out = 0; Semaphore empty(BUFFER_SIZE); // 空槽位数量 Semaphore full(0); // 满槽位数量 Semaphore mutex(1); // 缓冲区互斥访问 void producer() { int item; while (true) { item = produce_item(); empty.wait(); // 等待空槽位 mutex.wait(); buffer[in] = item; in = (in + 1) % BUFFER_SIZE; mutex.signal(); full.signal(); // 增加一个满槽位 } } void consumer() { int item; while (true) { full.wait(); // 等待满槽位 mutex.wait(); item = buffer[out]; out = (out + 1) % BUFFER_SIZE; mutex.signal(); empty.signal(); // 增加一个空槽位 consume_item(item); } }

信号量的精妙之处：value可以大于1，这使得信号量能管理多个同类资源。wait和signal操作的原子性同样是实现的关键。生产者-消费者问题是检验同步机制是否正确的经典试金石，务必亲手实现并测试。

5. 完整模拟流程与核心环节实现

现在，我们将所有模块组合起来，形成一个可以运行的模拟程序。这里以协作式线程为例，展示一个最小化的可运行框架。

5.1 模拟程序主循环与线程示例

#include <iostream> #include <cstdlib> // 假设Scheduler, Mutex等类已定义 Scheduler* scheduler = nullptr; // 全局调度器 // 模拟的线程函数1 void worker_thread_1(void* arg) { int id = *(int*)arg; for (int i = 0; i < 5; ++i) { std::cout << "Thread " << id << ": Loop " << i << std::endl; scheduler->yield(); // 主动让出CPU // 模拟一些工作 scheduler->sleep(id); // 睡眠id个时间单位 } std::cout << "Thread " << id << ": Exiting." << std::endl; // 这里应该调用 thread_exit，简化处理，我们直接让函数返回，调度器需要处理线程终止状态 } // 模拟的线程函数2，演示共享资源竞争 int shared_value = 0; Mutex shared_mutex; void competing_thread(void* arg) { int id = *(int*)arg; for (int i = 0; i < 1000; ++i) { shared_mutex.lock(); int temp = shared_value; scheduler->yield(); // 故意在这里切换，放大竞争问题 shared_value = temp + 1; shared_mutex.unlock(); } std::cout << "Thread " << id << " finished. Shared value should be 2000, is: " << shared_value << std::endl; } int main() { scheduler = new Scheduler(); // 创建几个工作线程 int id1 = 1, id2 = 2, id3 = 3; scheduler->create_thread(worker_thread_1, &id1); scheduler->create_thread(worker_thread_1, &id2); scheduler->create_thread(worker_thread_1, &id3); // 创建竞争线程 int cid1 = 101, cid2 = 102; scheduler->create_thread(competing_thread, &cid1); scheduler->create_thread(competing_thread, &cid2); // 主模拟循环 bool all_done = false; while (!all_done) { // 1. 驱动调度器运行一个时间片 scheduler->schedule(); // 2. 模拟时间流逝，处理超时唤醒等 scheduler->tick(); // 3. 检查是否所有线程都结束了（简化：这里需要维护活动线程计数） // 在实际实现中，线程结束时应该通知调度器，调度器减少活动计数。 // 这里我们用一个简单的循环次数限制来模拟程序结束。 static int loop_count = 0; loop_count++; if (loop_count > 10000) { // 防止无限循环 std::cout << "Simulation loop limit reached." << std::endl; break; } // 4. 可以在这里打印一些状态信息，方便调试 // print_system_status(); } std::cout << "Final shared value (without proper mutex would be wrong): " << shared_value << std::endl; delete scheduler; return 0; }

主循环逻辑：这个while循环就是我们的“CPU”。每次迭代，我们让调度器选一个线程执行（schedule()），然后时间前进一格（tick()），处理可能发生的超时唤醒。线程函数内部通过调用yield(),sleep(),lock()等接口与调度器交互，从而改变系统状态。

5.2 线程的创建与终结处理

上面的示例简化了线程的创建和终结。一个更完整的实现需要考虑：

• 线程入口包装：我们传递给create_thread的函数是void (*)(void*)，但如何让这个函数在“自己的栈”上运行，并且在结束时能清理资源？通常需要一个启动桩（stub）函数。这个stub函数先设置好栈帧，然后调用用户提供的函数，用户函数返回后，stub再调用thread_exit()。
• thread_exit()的实现：

  void thread_exit() { if (current_thread) { current_thread->state = T_TERMINATED; // 释放线程栈内存 free(current_thread->stack_base); // 从所有调度队列中移除（可能存在于就绪、阻塞队列） // ... // 通知调度器，活动线程数减一 // ... // 立即触发调度，选择下一个线程 scheduler->schedule(); // 注意：此函数不应返回，因为当前线程已经“死了” } }

• 参数传递：如何将参数arg放到新线程的栈上，并让线程函数能取到？这需要一些技巧，通常stub函数会从TCB中或约定的栈位置获取参数。

6. 常见问题、调试技巧与扩展方向

实现这样一个模拟系统，你会遇到无数个“为什么结果不对”的时刻。下面是一些常见坑点和调试心得。

6.1 典型问题与排查清单

6.2 调试技巧实录

• 日志是王道：在schedule、lock、unlock、create_thread、thread_exit等关键函数入口处添加详细的日志输出，打印线程ID、状态、队列长度等信息。这比调试器单步跟踪并发程序有时更有效。
• 确定性重现：并发bug难以重现。可以尝试在每次调用yield()或schedule()时，固定线程切换的顺序（例如，总是按线程ID顺序调度），或者使用一个随机种子来控制yield的调用，使得bug可以确定性地重现，方便调试。
• 简化测试用例：不要一开始就跑复杂的生产者-消费者。先测试两个线程交替打印，再测试一个简单的共享计数器加锁。逐步增加复杂度。
• 使用assert：在数据结构中增加不变式断言，例如“当前运行线程的状态必须是T_RUNNING”、“一个线程不能同时存在于就绪队列和阻塞队列”等，可以在错误发生时立刻崩溃并定位，而不是让错误状态传播。

6.3 项目扩展方向

完成基础版本后，你可以尝试以下扩展，让项目更具深度和挑战性：

1. 实现抢占式调度：使用setitimer和SIGALRM信号。在信号处理函数中，保存当前线程上下文，并强制调用scheduler->schedule()。注意信号处理函数中能调用的函数是受限的（异步信号安全）。
2. 实现多级反馈队列（MLFQ）：设计多个不同优先级的就绪队列。新线程进入最高优先级队列。用完一个时间片还未结束的线程会被降级。这能模拟交互式进程（短任务）获得更好响应的场景。
3. 实现进程间通信（IPC）：模拟管道、消息队列或共享内存。例如，共享内存可以通过让两个进程的PCB中的“地址空间”指针指向同一个全局数据结构来模拟。
4. 实现内存管理模拟：为每个进程维护一个模拟的页表，实现简单的按需调页或页面置换算法（如FIFO、LRU）。
5. 可视化界面：使用ncurses库或简单的图形库（如SFML），实时绘制出进程/线程的状态、队列情况、CPU利用率等，让调度过程一目了然。

这个项目就像一把钥匙，帮你打开了操作系统并发世界的大门。从纸上谈兵到动手实现，你会对课本上那些晦涩的概念产生前所未有的具象理解。过程中遇到的每一个bug，都是对操作系统设计精妙之处的一次致敬。当你看到自己编写的调度器有条不紊地切换着线程，互斥锁完美地保护着共享数据时，那种成就感是无可替代的。这不仅仅是完成了一个实验，更是为自己构建了一套理解复杂系统的思维模型。