1. 项目概述从理论到代码的跨越如果你写过一些C程序处理过一些简单的循环和函数调用可能会觉得任务调度听起来像是操作系统或者大型分布式系统里才有的高级概念。但事实上任务调度的思想无处不在。从你电脑里同时运行的几个程序到一个游戏引擎里要处理渲染、物理、音效等多个逻辑再到一个网络服务器要响应成千上万个并发请求背后都离不开任务调度。这个项目就是要把这个听起来高大上的“任务调度算法”用我们最熟悉的C从零开始实现一遍。为什么是C因为它足够“底层”又足够“高效”。用C来实现你能清晰地看到内存如何分配、线程如何切换、队列如何管理每一个延迟、每一个锁竞争都暴露无遗。这不像用一些高级语言封装的调度库调个API就完事了知其然不知其所以然。通过亲手实现你会对“并发”、“同步”、“资源竞争”这些概念有刻骨铭心的理解。这个实战过程能帮你把数据结构、算法、操作系统和并发编程的知识点全部串起来无论是为了应对那些深入的C面试题还是为了未来开发高性能中间件或游戏引擎打下基础都价值巨大。简单说这个项目就是用C造一个属于自己的、简易但核心功能完整的“任务调度器”。我们会设计几种经典的调度策略比如先来先服务、时间片轮转并用多线程模拟任务执行环境最后你会得到一个可以运行、可以观察对比调度效果的程序。这不仅是算法实现更是一个综合性的系统编程练习。2. 核心调度算法原理与选型在动手写代码之前我们必须搞清楚要调度什么以及有哪些经典的调度方法。这里的“任务”可以抽象为一个结构体至少包含任务ID、预计执行时间用于模拟、优先级等属性。而“调度器”的核心就是一个决策引擎当有多个任务在等待时下一个该执行谁2.1 先来先服务调度算法这是最简单、最直观的算法其核心思想就是维护一个先进先出的队列。所有新到达的任务都被放到队列尾部调度器总是从队列头部取出任务来执行。只有当当前任务完全执行完毕后才会取下一个。算法特点与实现考量非抢占式一个任务一旦开始就会一直运行到完成。这会导致一个长任务阻塞后面所有短任务平均等待时间可能很长也就是著名的“护航效应”。实现简单在C中直接使用std::queueTask就能完美模拟。入队用push()出队用front()加pop()。适用场景实际上纯粹的FCFS在现代交互式系统中很少用作主要调度器因为它响应性差。但在一些批处理系统或者作为其他复杂调度算法中的某个子队列时它仍有价值。对于我们项目它是理解调度概念的绝佳起点。为什么从这里开始因为它剥离了所有复杂因素让我们专注于调度器最基础的框架任务队列、任务取出、执行循环。把这个框架搭稳了后续增加更复杂的调度逻辑就是“锦上添花”。2.2 最短作业优先调度算法为了解决FCFS中长任务阻塞的问题SJF算法选择了另一种策略总是选择预计运行时间最短的那个任务先执行。这能显著降低平均等待时间。算法变种与实现关键非抢占式SJF同样是非抢占但选择任务时不是看谁先来而是看谁最短。这意味着我们需要在所有已到达的任务中动态地找出执行时间最短的那个。抢占式SJF也叫最短剩余时间优先。当一个新任务到达时它会与当前正在执行的任务的剩余时间比较。如果新任务更短当前任务会被暂停放回就绪队列新任务开始执行。这需要维护任务的剩余时间信息。实现难点关键在于如何高效地“动态获取最短任务”。使用一个简单的数组或链表每次选择都需要O(n)的遍历在任务很多时效率低。因此优先队列是更优的数据结构。在C中std::priority_queue默认是大顶堆我们需要通过自定义比较器将其改为小顶堆以快速获取执行时间最短的任务。// 自定义比较器用于构建最小堆执行时间短的优先级高 struct CompareTaskByTime { bool operator()(const Task a, const Task b) { // 注意priority_queue默认是大顶堆比较器返回true意味着a的优先级低于b // 我们希望时间短的优先级高所以当a的执行时间大于b时a的优先级低 return a.estimatedTime b.estimatedTime; } }; std::priority_queueTask, std::vectorTask, CompareTaskByTime readyQueue;注意SJF算法有一个理想化的前提——必须预知每个任务的执行时间。这在现实中往往很难做到通常只能根据历史信息或类型进行预测。我们的模拟程序会直接使用预设的估计时间。2.3 时间片轮转调度算法这是现代分时操作系统的基石算法旨在实现公平性和响应性。它给每个任务分配一个固定的CPU时间单元称为“时间片”。任务轮流执行每次只运行一个时间片。如果任务在一个时间片内没完成它会被暂停并放回就绪队列的末尾等待下一轮。算法核心参数与影响时间片大小这是RR算法的灵魂。时间片太大退化成FCFS响应性变差时间片太小上下文切换开销保存和恢复任务状态占比过高系统吞吐量下降。选择一个合适的时间片是艺术也是科学通常需要在响应时间和切换开销之间取得平衡。实现结构和FCFS一样使用队列但过程不同。任务执行一个时间片后如果未完成需要重新入队。这要求我们的任务结构体需要记录“剩余执行时间”。抢占式RR是典型的基于时间的抢占式调度。时钟中断在我们的模拟中可以用一个计时线程或简单循环计数来模拟是触发调度的关键。在模拟中如何实现“时间片”由于我们是在单机用多线程模拟没有真正的硬件时钟中断。一个实用的方法是让执行任务的线程每次只“工作”一小段模拟时间比如循环减任务剩余时间然后检查是否用完了本次分配的时间片。如果用完了就主动让出执行权由调度器决定下一个任务。这需要任务执行线程与调度器之间有良好的协作。3. 项目架构设计与核心组件一个清晰的项目架构能让编码过程事半功倍也便于后续扩展。我们的调度器模拟程序可以划分为以下几个核心模块。3.1 任务抽象与生成器任务是调度的对象首先需要将其抽象成数据结构。struct Task { int id; // 任务唯一标识 int arrivalTime; // 到达时间用于模拟任务不是同时到达 int estimatedTime; // 预计总执行时间 int remainingTime; // 剩余执行时间用于RR和抢占式算法 int priority; // 优先级可用于扩展优先级调度 // 还可以添加状态等待、运行、完成等 Task(int _id, int arr, int est, int pri0) : id(_id), arrivalTime(arr), estimatedTime(est), remainingTime(est), priority(pri) {} };任务生成器负责在模拟过程中动态创建任务。我们可以设计一个独立的线程按照一定的随机分布如泊松分布或固定间隔生成任务并放入一个“新任务缓冲队列”。调度器的主循环会定期从这个缓冲队列中取出任务根据其到达时间加入到真正的就绪队列中。这样能更真实地模拟任务随机到达的场景。3.2 调度器核心引擎这是项目的心脏一个管理所有就绪任务并做出调度决策的类。class Scheduler { public: Scheduler(SchedulerType type, int timeQuantum 1); // timeQuantum用于RR virtual ~Scheduler() default; // 添加新任务到就绪队列 virtual void addTask(const Task task) 0; // 从就绪队列中取出下一个要执行的任务 virtual std::optionalTask getNextTask() 0; // 当任务未执行完被抢占时将其重新放回队列用于RR virtual void reAddTask(const Task task) 0; // 判断就绪队列是否为空 virtual bool isEmpty() const 0; SchedulerType getType() const { return type_; } protected: SchedulerType type_; int timeQuantum_; // 时间片长度 };Scheduler是一个抽象基类为不同的调度算法定义统一接口。然后我们派生出FCFSScheduler、SJFScheduler、RRScheduler等具体类。每个具体类内部维护自己的数据结构std::queue,std::priority_queue等并以不同的逻辑实现addTask和getNextTask。使用std::optional的考量getNextTask返回std::optionalTask是一种现代C的优雅做法。当队列为空时可以返回std::nullopt避免了使用特殊值如ID为-1或输出参数让调用方代码更清晰安全。3.3 执行器与模拟循环执行器负责“执行”任务。在真实系统中这是CPU。在我们的模拟中它可以是一个或多个工作线程。模拟循环是主控逻辑它协调时间推进、从调度器获取任务、交给执行器、并更新任务状态。单线程模拟 vs 多线程模拟单线程模拟在一个循环中递增模拟的“当前时间”检查是否有新任务到达调用调度器然后处理当前任务简单地将任务剩余时间减1。逻辑简单易于理解和调试但不能真实体现多任务并发和上下文切换。多线程模拟更贴近现实。我们可以有一个调度器线程或主线程充当一个或多个工作线程池。工作线程从调度器获取任务并“执行”例如通过睡眠std::this_thread::sleep_for来模拟执行时间。这引入了真实的并发、线程同步问题复杂度陡增但练习价值也更大。对于初次实现我建议采用单线程模拟先把调度算法的逻辑跑通。之后可以将其升级为多线程版本作为一个挑战。模拟循环的核心伪代码当前时间 currentTime 0 当前运行任务 currentTask 空 当前任务已运行时间 runningTime 0 while (还有未完成的任务 或 还有任务未到达) { 1. 检查并处理在currentTime到达的新任务加入调度器。 2. 如果当前没有任务在运行 a. 从调度器获取下一个任务 nextTask。 b. 如果获取成功将其设为当前任务runningTime置0。 3. 如果当前有任务在运行 a. 执行该任务一个单位时间remainingTime--, runningTime。 b. 检查任务是否完成remainingTime 0完成则记录统计信息。 c. 如果是RR调度检查runningTime是否达到时间片。如果达到则 i. 如果任务未完成调用 scheduler.reAddTask(currentTask)。 ii. 将currentTask置空以便下一循环获取新任务。 4. currentTime。 }3.4 数据统计与可视化输出调度算法的优劣需要量化指标来衡量。在模拟过程中我们需要为每个任务记录完成时间任务执行完毕的时间点。周转时间完成时间 - 到达时间。衡量任务从提交到完成的总延迟。带权周转时间周转时间 / 执行时间。这个指标更重要它消除了任务本身长度的影响更能体现调度对用户的公平性。带权周转时间越接近1说明任务等待时间相对其执行时间越短用户体验越好。模拟结束后计算所有任务的平均周转时间和平均带权周转时间并输出对比表格。用控制台打印清晰的ASCII表格或者生成简单的日志文件都能直观地展示不同调度算法的性能差异。4. 关键实现细节与C技巧有了架构我们来深入几个实现时必然会遇到的关键技术点这些地方用对C特性能让代码更健壮、高效。4.1 线程安全的数据结构如果你选择多线程模拟那么调度器内部的队列就是共享资源。调度器线程在添加任务工作线程在获取任务这必须同步。直接使用std::mutex保护这是最直接的方法。在Scheduler基类中添加一个std::mutex在每个具体调度器的addTask、getNextTask等方法中用std::lock_guard加锁。class ThreadSafeScheduler : public Scheduler { public: void addTask(const Task task) override { std::lock_guardstd::mutex lock(mutex_); // ... 实际添加逻辑 } // ... 其他方法类似 private: std::queueTask queue_; // 或其他数据结构 mutable std::mutex mutex_; // mutable允许在const成员函数中加锁 };注意锁的粒度要小心。锁住整个方法有时是合理的但如果你在getNextTask里进行了复杂的查找如SJF持锁时间过长会影响并发性能。这时需要考虑更细粒度的锁或使用无锁数据结构但对于我们这个学习项目简单粗粒度的锁足以。使用std::condition_variable进行线程间通信当工作线程发现调度器队列为空时它不应该忙等待不断循环检查这会浪费CPU。更好的方式是让它等待直到有新任务被添加进来。这就需要条件变量。// 在调度器类中 std::condition_variable cv_; // 在 addTask 中添加任务后 cv_.notify_one(); // 通知一个等待的线程 // 在 getNextTask 中如果队列为空 std::unique_lockstd::mutex lock(mutex_); cv_.wait(lock, [this](){ return !queue_.empty(); }); // 等待直到队列非空4.2 优雅的任务执行模拟在工作线程中我们如何模拟一个任务执行了estimatedTime毫秒的工作直接调用std::this_thread::sleep_for是最简单的但这会阻塞线程这个线程就无法处理其他任务了不符合“一个CPU核心”的模拟场景。更合理的模拟方式是让工作线程成为“CPU”本身它循环执行“取任务 - 工作一个时间片 - 更新状态 - 归还或取新任务”。这里的“工作”不是真睡眠而是进行一个消耗CPU时间的循环比如空循环或者更简单地在我们的单线程模拟中就是让剩余时间减1。在多线程版本中可以让工作线程每次从调度器获取一个任务后计算应该“工作”多久取时间片和剩余时间的最小值然后通过std::chrono的高精度时钟来模拟忙碌。auto start std::chrono::steady_clock::now(); auto work_duration std::chrono::milliseconds(timeToWork); // timeToWork是计算出的本次工作时间 while (std::chrono::steady_clock::now() - start work_duration) { // 忙等待或者执行一些无意义的计算来消耗真实CPU时间 // 注意忙等待会真的占满一个CPU核心仅用于演示实际项目慎用 volatile int i 0; // 使用volatile防止被优化掉 for (int j 0; j 1000; j) { i j; } } // 时间到模拟本次执行结束4.3 调度算法的可扩展性设计我们可能想随时切换不同的调度算法进行比较。好的设计应该遵循开闭原则对扩展开放对修改封闭。我们可以定义一个SchedulerFactory工厂类根据传入的枚举类型或字符串创建对应的调度器实例。std::unique_ptrScheduler createScheduler(const std::string type, int timeQuantum) { if (type FCFS) return std::make_uniqueFCFSScheduler(); if (type SJF) return std::make_uniqueSJFScheduler(); if (type RR) return std::make_uniqueRRScheduler(timeQuantum); // ... 其他算法 throw std::invalid_argument(Unknown scheduler type); }在主函数中我们可以通过命令行参数来指定使用哪种调度器。./scheduler_sim --algorithm RR --quantum 20 --tasks 100这种设计使得添加一个新的调度算法如优先级调度变得非常容易只需要新写一个PriorityScheduler类并在工厂函数中加一个判断即可主模拟循环完全不用改动。5. 从零开始的实战步骤让我们抛开理论一步步把代码敲出来。我假设你使用Linux/Mac环境或Windows下的WSL/MinGW并且已经配置好了C编译环境如g。5.1 基础框架搭建首先创建项目目录和基本文件。scheduler_sim/ ├── include/ │ ├── Task.h │ ├── Scheduler.h │ └── common.h ├── src/ │ ├── Task.cpp │ ├── Scheduler.cpp │ ├── FCFSScheduler.cpp │ ├── SJFScheduler.cpp │ ├── RRScheduler.cpp │ └── main.cpp └── CMakeLists.txt (或直接使用Makefile)在Task.h中定义任务结构体。在Scheduler.h中定义抽象基类和枚举。在common.h中定义一些全局配置和类型别名。一个常见的坑循环依赖。如果Task.h需要引用Scheduler而Scheduler.h又需要引用Task就会形成循环包含。解决方法是使用前向声明并在头文件中尽量只包含必要的头文件将具体实现放到.cpp文件中。5.2 实现FCFS调度器从最简单的开始建立信心。在FCFSScheduler.cpp中#include FCFSScheduler.h #include iostream void FCFSScheduler::addTask(const Task task) { queue_.push(task); std::cout [FCFS] Task task.id added. Queue size: queue_.size() std::endl; } std::optionalTask FCFSScheduler::getNextTask() { if (queue_.empty()) { return std::nullopt; } Task task queue_.front(); queue_.pop(); std::cout [FCFS] Dispatching task task.id std::endl; return task; } void FCFSScheduler::reAddTask(const Task task) { // FCFS是非抢占的理论上不会被重新添加。但为接口统一可以简单实现为addTask。 // 或者如果实现了抢占比如按优先级抢占这里就需要处理。 // 我们先抛出一个异常或打印警告表明此操作对本调度器不适用。 std::cerr Warning: reAddTask() called on non-preemptive FCFS scheduler.\n; addTask(task); // 或者直接忽略 } bool FCFSScheduler::isEmpty() const { return queue_.empty(); }在main.cpp中写一个简单的测试创建几个任务按顺序加入FCFS调度器然后循环取出并打印确认顺序是先进先出。5.3 实现SJF调度器这里的关键是std::priority_queue的使用。注意我们之前定义的小顶堆比较器。addTask直接pushgetNextTask就是top()加pop()。一个易错点priority_queue的top()返回的是常量引用你不能直接修改它。如果需要修改任务属性比如在抢占式SJF中更新剩余时间你需要先取出副本修改后再放回去或者使用指针/智能指针存储任务。5.4 实现RR调度器RR调度器内部也是一个队列但getNextTask的逻辑不同它取出队头任务后这个任务不会立即从队列中“消失”因为可能还要回来。所以我们需要一个“当前任务”的概念。或者在getNextTask中取出任务后先不pop等执行完一个时间片后在reAddTask中再决定是pop掉如果完成了还是移动到队尾如果未完成。更清晰的实现是getNextTask总是从就绪队列头部取任务并pop。当任务执行一个时间片后未完成由reAddTask将其重新push到队尾。这样就绪队列里永远都是等待执行的任务。时间片耗尽的判断在模拟循环中需要维护一个变量记录当前任务在本轮中已执行的时间。当该变量等于timeQuantum时触发reAddTask。5.5 构建模拟循环与统计在main.cpp中实现单线程模拟循环。你需要初始化一个任务列表可以随机生成或从文件读取。按任务到达时间排序如果模拟任务不是同时到达。进入主循环循环变量是当前模拟时间。在每个时间点将到达的任务加入调度器。如果CPU空闲无当前任务从调度器取任务。执行当前任务一个单位时间更新其剩余时间和已执行时间。检查任务完成或时间片耗尽条件进行相应处理记录完成、重新入队等。时间步进。循环直到所有任务完成。输出统计报表。生成随机任务使用random库。例如任务到达间隔可以用指数分布模拟执行时间可以用均匀分布或正态分布。std::random_device rd; std::mt19937 gen(rd()); std::exponential_distribution arrival_dist(0.5); // 平均每秒到达0.5个任务 std::uniform_int_distribution exec_dist(1, 10); // 执行时间1-10个单位 int next_arrival_time static_castint(arrival_dist(gen)); int task_id 0; while (/* 条件 */) { if (current_time next_arrival_time) { int exec_time exec_dist(gen); Task new_task(task_id, current_time, exec_time); scheduler.addTask(new_task); next_arrival_time current_time static_castint(arrival_dist(gen)); } // ... 其他模拟逻辑 }6. 常见问题、调试技巧与性能考量即使思路清晰动手实现时也一定会遇到各种问题。这里记录一些我踩过的坑和解决方法。6.1 多线程环境下的数据竞争与死锁问题现象程序偶尔崩溃或统计结果莫名其妙不对或者直接卡死。数据竞争多个线程同时读写同一个任务队列没有加锁或锁的范围不对。比如一个线程在遍历队列另一个线程在修改队列结构push/pop会导致未定义行为。死锁线程A锁定了互斥量M1试图锁定M2线程B锁定了M2试图锁定M1。两人都在等对方释放程序永久挂起。排查与解决最小化锁范围只在对共享数据操作的代码段加锁尽快释放。避免在持锁时进行IO操作或调用可能很慢的函数。固定锁顺序如果必须获取多个锁确保所有线程都以相同的顺序获取它们例如总是先锁M1再锁M2。这是避免死锁的黄金法则。使用RAII管理锁始终使用std::lock_guard或std::unique_lock避免手动lock()和unlock()防止因异常导致锁无法释放。工具辅助在Linux下可以使用helgrind或tsanThreadSanitizer来检测数据竞争。在编译时添加-fsanitizethread选项。6.2 优先级队列的比较器陷阱问题现象SJF调度出来的顺序不对或者程序在插入任务时崩溃。原因std::priority_queue需要严格弱序的比较器。如果你的比较器对两个相等的元素estimatedTime相同返回true可能会破坏堆的内部结构。另一个坑如果Task对象在优先队列中存储而你在任务执行过程中修改了它的remainingTime堆的性质可能被破坏因为优先队列不会因为你修改了元素而自动重新调整堆。解决确保比较器逻辑正确。对于SJF如果执行时间相同可以再按任务ID或到达时间排序以定义唯一的顺序。return a.estimatedTime b.estimatedTime || (a.estimatedTime b.estimatedTime a.id b.id);如果任务属性需要动态更新如剩余时间考虑在调度器队列中存储std::shared_ptrTask或Task*。但修改后如果这个修改影响了排序关键字比如从抢占式SJF队列中修改了剩余时间你必须手动重新建堆。一个更简单的做法是不修改队列中的任务而是将任务取出后在一个独立的“正在运行”区域维护其状态。当任务被抢占时用新的状态创建一个新的任务对象或更新旧对象再放回队列。6.3 模拟时间与真实时间的不同步问题现象在单线程模拟中一切可控。但在多线程模拟中工作线程用sleep_for模拟任务执行而调度器线程或主线程用另一个时钟推进模拟时间两者可能脱节。解决思路全局模拟时钟定义一个全局的、线程安全的模拟时钟变量。所有线程都依据这个时钟来判断“当前模拟时间”。工作线程在执行任务时不是真实睡眠而是循环检查全局时钟直到它推进了任务所需的执行时间。这需要工作线程主动“让出”CPU例如用std::this_thread::yield()避免忙等待拖慢整个模拟。离散事件模拟更高级的建模方式。将任务到达、任务开始、任务完成、时间片到期等都视为“事件”放入一个按时间排序的全局优先队列事件队列。模拟引擎不断处理最早发生的事件并直接跳到该事件的时间点。这种方式效率高且逻辑清晰但实现起来更复杂。6.4 性能瓶颈分析与优化当模拟任务数达到上万甚至更多时你可能会发现程序变慢。瓶颈1调度器选择算法。FCFS和RR的队列操作是O(1)很快。但SJF的优先队列插入和删除是O(log n)当n很大时如果每个时间单位都频繁调用可能成为瓶颈。考虑是否需要每个时间点都调度在事件驱动的模拟中只在任务到达和完成时触发调度效率更高。瓶颈2统计信息记录。如果每个任务完成时都同步写入文件或进行复杂的统计计算会拖慢主循环。可以考虑将统计信息先缓存在内存中模拟结束后一次性写入。瓶颈3控制台输出。大量的std::cout是极其昂贵的操作会严重拖慢程序。在性能测试时务必关闭或减少调试输出。一个简单的性能测试生成10万个任务分别用三种算法模拟记录程序运行的真实时间。你会发现在关闭所有调试输出后主要的运行时间可能花在随机数生成和容器操作上。这时可以尝试更换更快的随机数生成器如std::mt19937已经很快或者检查是否有不必要的容器拷贝使用移动语义或指针。7. 扩展思路让项目更上一层楼完成基础版本后你可以尝试以下扩展让这个项目从“作业”升级为“作品”。7.1 实现多级反馈队列调度这是实际操作系统如Linux中使用的综合型调度算法的简化版。它设计多个优先级不同的就绪队列每个队列可以使用不同的调度算法如高优先级队列用RR低优先级队列用FCFS和不同的时间片大小高优先级时间片短响应快低优先级时间长吞吐量高。新任务进入最高优先级队列。如果它用完了该队列的时间片还没执行完就会被降级到下一级队列。这样可以保证短任务快速完成而长任务也不会饿死但可能需要等待更久。实现MLFQ是对你面向对象设计和数据结构能力的绝佳考验。你需要管理多个队列并制定任务在队列间升降级的规则。7.2 可视化调度过程用文字输出时间线不够直观。可以集成一个简单的图形库如ASCII图形库ncurses或轻量级的SFML、raylib实时绘制时间轴。横轴是时间。不同颜色的条形块代表不同任务。可以看到任务何时开始、何时被抢占、何时完成。实时显示当前的平均周转时间等指标。这不仅能让你更直观地理解调度过程也是一个很好的C项目履历亮点。7.3 与真实系统交互一个更硬核的方向不模拟任务而是调度真实的计算任务。例如写一个线程池池中的工作线程等待调度器分配函数对象std::function来执行。你的调度器需要管理这些函数对象任务并根据算法决定哪个工作线程执行哪个函数。这更接近一个轻量级的用户态任务调度库。在这个过程中你会深入接触到C的并发编程、函数对象、移动语义、完美转发等高级特性对语言的理解会更深一层。实现一个任务调度器就像在微观世界里扮演一次操作系统的设计者。从最初简单的FCFS到考虑任务特性的SJF再到追求公平的RR每一个算法都在权衡着吞吐量、响应时间、公平性和开销。用C亲手实现它们你会对“程序是如何被执行的”产生前所未有的具体认知。那些书本上枯燥的概念——上下文切换、就绪队列、抢占——都变成了你代码里活生生的变量和逻辑判断。当最后看到不同算法下那组截然不同的平均周转时间数据时你会真切感受到算法设计对系统性能那实实在在的、可量化的影响。这或许就是系统编程最迷人的地方用代码构建秩序在约束中寻求最优解。