企业官网建设流程全解析

如果把编译器比作翻译官，那 Runtime 就是现场总指挥。CPU、GPU、NPU、FPGA 混在一起跑任务的异构计算场景里，“程序能编译过”只是第一步，真正决定吞吐和延迟的，是任务到了 Runtime 之后怎么被排队、怎么被分发、怎么塞进不同设备。这篇内容围绕 Runtime 的异构计算动态调度与执行引擎展开，适合正在自研调度模块、或者基于现成框架二次开发时总感觉“负载一上来调度就乱”的开发者。我会从资源建模讲起，把调度器主循环、任务依赖、反馈控制、事件驱动执行器这些设计点逐个拆开，最后给出一套可以直接落地的最小框架，以及我在调优过程中踩过的一些坑。

1. Runtime 到底是什么：从“运行环境”到“调度中枢”

1.1 我们平时说的 Runtime，至少有三种身份

很多开发者一听到 Runtime，第一反应是 Java 虚拟机、Python 解释器或者 C 运行时库。这类语言运行时确实很重要，但它们主要负责类型检查、内存管理、异常传播和基础 I/O，跟“任务调度”基本不沾边。只有当你接触过一些计算框架后，才会意识到还有第二层 Runtime：框架运行时。它把用户声明的高级计算图编译成底层可执行算子，再去做算子融合、内存复用、自动并行化。框架运行时管的是“图”和“算子”，它的调度粒度很粗，通常面向一个完整训练任务或推理请求。

我要展开说的其实是第三层，自定义任务运行时。这一层通常出现在底层调度组件里，接收的不是算子，而是“任务”。任务之间往往有依赖关系，执行目的地分布在 CPU 核、GPU、NPU 等多个异构设备上。它要负责把任务放进正确的队列、在正确的时间挑选正确的设备、处理设备完成通知、响应下游压力。三种 Runtime 会在一个系统里同时存在，互相之间有边界也有重叠。调试异构任务问题时，最常见的误区就是把锅甩给“框架运行时”，实际上卡住你的往往是第三层任务运行时——队列设计不合理，任务在设备之间传递时没有调度策略，队列里塞满任务，设备却在空转。

1.2 异构计算让 Runtime 的角色彻底变了

单 CPU 时代，Runtime 其实已经承担资源管理职责，但相对简单：给线程分配栈、做时间片切换、处理锁和条件变量。到了异构时代，事情变得复杂。CPU 上可以并发跑几十个线程，GPU 上一个 kernel 往往要独占设备一段时间，NPU 又有自己独立的执行队列和专用的数据搬运路径。Runtime 不能只被动等待程序来调用，它必须主动维护整个系统的实时状态：每个设备现在空闲吗？显存还够吗？设备间链路带宽是不是已经被占满？上一次提交的任务到底什么时候结束？

这里有个很直观的类比：单核时代像一个窗口的食堂，大家排队就好；异构时代像开了多个窗口的食堂，每个窗口的师傅出餐速度不同，有的窗口必须等上一道菜完全出锅才能炒下一道。如果没有总调度，就会出现某个窗口前排了三十个人、旁边窗口一个都没有的情况。调度器要做的就是在每个决策周期同时看“哪个窗口空闲”“这桌客人适合哪个窗口”“哪个窗口的师傅最近有点消极怠工”，然后综合判断把哪份菜单放进哪个窗口。

这也解释了为什么 Runtime 在异构计算里不再只是“被调用的库”，而是一个有主动行为的资源分配中枢。它要持续采集设备状态，维护一张资源可用性地图，再结合任务优先级、依赖关系和延迟预算做决策。设计重心从“怎么执行一段代码”变成了“在什么时间、用什么资源、以什么顺序去执行任务”。

1.3 “动态调度”里的“动态”到底指什么

不少人以为动态调度只是“运行时根据资源情况决定把任务放哪”，这个理解太浅了。“动态”至少包含四层含义。第一，任务到达时间不确定，上一秒还没有任务，下一秒突然爆发一千个推理请求，调度器得能接得住。第二，依赖关系可能在运行过程中动态增加，比如用户新提交的任务依赖一个还没有执行完的中间结果。第三，设备状态是动态变化的，过热降频、显存碎片化、链路拥塞、设备异常退出，这些都不是编译期能预知的。第四，策略本身会变化，某一路在线服务的优先级可能突然被调高，调度器必须立刻响应。

这四层“动态”意味着调度决策不能放到编译期或静态配置期完成。你不可能预先把每个任务分给某个固定设备，因为等任务真正到达时，设备状态可能已经完全变了。一个合格的动态调度器，必须是一个“预测-执行-测量-调整”的闭环。每次决策后要观察实际效果，再根据延迟、吞吐、排队长度这些信号修正下一轮决策。后面我会详细讲反馈控制怎么落地，这里先记住一个结论：静态任务分配表只适合离线批处理场景，一旦任务到达有波动、延迟目标有差异、设备状态有变化，静态方案一定会表现为资源不均衡——要么设备满载排队，要么设备空转等待。

2. 异构调度第一步：先把资源与任务分个类

2.1 任务按瓶颈分类：计算密集、访存密集、通信密集

很多人在设计调度器时只按“预估执行时间”给任务排队，这是个很容易掉进去的坑。执行时间只是结果，真正的决策依据应该是“瓶颈资源”是什么。任务可以大致分成三类：计算密集、访存密集、通信密集。计算密集类任务的瓶颈在算力，典型如矩阵乘、卷积、物理仿真，它们适合单设备独占式执行，并且设备核数越高收益越大。访存密集类任务的瓶颈在内存带宽或显存带宽，典型如大规模特征工程、数据预处理，这类任务并发多了以后会互相争抢带宽，理论上算力很足，但实际执行时间被带宽卡住。通信密集类任务依赖网络或设备间高速链路，典型如 AllReduce 节点、分布式采样、跨设备数据传输，执行时间主要取决于链路拥塞程度。

理解任务类型对调度策略的影响是什么？举个例子。你有一个 GPU 设备，算力非常强，但显存带宽有限。如果贪心算法把五个访存密集任务同时派上去，设备算力完全没跑满，显存带宽先被打满，每个任务都变慢。反过来，如果错开调度，把计算密集任务穿插进去，算力和带宽就都能用上。所以我建议调度器给任务打上类型标签，不仅是“预估执行时间”，而是一个描述资源需求的多维向量。

2.2 给每个设备做资源画像，而不是一把抓

所谓资源画像，就是把每个设备描述成一组带容量的向量。CPU 设备要记录核心数、可用内存、平均负载；GPU 类设备要记录显存大小、算力等级、当前排队的任务数；设备间链路要记录带宽、延迟和当前占用率。调度器做匹配时，不是问“哪个设备最快”，而是问“哪个设备现在最空闲，并且能放得下这个任务的资源需求”。这两个问题看起来像，结果差别很大。

举几个我见过的错误做法。第一种，只看时钟频率或浮点算力，不看当前负载。一块顶级计算卡上已经排了二十个任务，另一块中端卡完全空闲，调度器还是把新任务派给顶级卡，结果延迟暴涨。第二种，只管显存够不够，不管带宽是否争抢。显存足够但多个任务共用一条链路，传输时间翻了三倍。第三种，资源状态更新太慢，每次决策时还在用五秒前的设备数据，设备早就空闲了，调度器却以为它正忙。

资源画像的采集频率需要平衡。采集太频繁，采样本身的开销会吃掉一部分算力；采集太慢，决策又会基于过期数据。我在某模拟项目 X 里用的参数是每 100ms 刷新一次设备状态，对大多数在线场景足够了。任务平均执行时间很短时，可以缩短到 50ms；任务很重、执行时长到秒级时，100ms 甚至 200ms 也没问题。另外，设备状态一旦变化就要做事件通知，例如 GPU 任务提前结束、显存释放、链路降级，不能只靠周期轮询，否则调度器会错过快速变化的关键时刻。

2.3 用 DAG 把依赖关系变成调度坐标系

任务之间常有依赖：某个数据增强任务必须等上游特征计算完，某个模型推理任务必须等两个输入都就绪。这种关系最适合用 DAG（有向无环图）描述。节点是任务，边是数据或控制依赖。调度器要维护每个节点的入度、出度、依赖计数和就绪状态。当一个任务完成时，把它所有后继节点的入度减一；入度变为零的节点就可以进入就绪队列。

依赖关系是调度的“坐标系”，因为你不能只看单个任务，还要看整张图的结构。整张三 DAG 里最长的那条路径决定了最短完工时间，通常叫关键路径。给关键路径上的任务分配较低优先级会直接拖慢整个流程，所以一个有基本觉悟的调度器至少应该对“剩余深度较大”的任务给出更高优先权。工程实现上不必追求严格的动态关键路径计算，那需要频繁做全图遍历，成本很高。更现实的做法是：任务创建时向上游递归计算一个估计的剩余深度，作为静态属性存起来，调度时用这个深度加权优先级。后面我再讲增量更新怎么做。

3. 动态调度引擎的核心机制：多级队列、协作式执行与反馈控制

3.1 多级队列解决“一类任务拖累所有任务”

为什么不能只有一个大而全的队列？因为不同任务对延迟的敏感度完全不同。在线推理任务可能要求 10ms 出结果，批处理任务可以容忍几十秒。如果它们混在同一个 FIFO 队列里，一个离线批处理任务可能会占住设备几十秒，后面所有的在线推理请求全部超时。反过来，如果在线任务永远排在前面，离线任务可能永远吃不到资源，这又成了饥饿问题。

比较好的设计方案是维护多级优先级队列：紧急队列、高优先级队列、普通队列、低优先级队列。调度器每个周期从最高优先级的队列开始取任务，但同时对低优先级任务做“老化”处理——每等待一个调度周期，自动提升一个档位。这样既保证高优先级请求的实时性，又不会让后台任务被永久饿死。

多级队列还要配合批量打包策略。GPU 上每个 kernel 的启动都有固定开销，启动一个小任务可能比执行它本身还贵。如果高优先级队列里剩余任务不足以填满一个批次，可以让低优先级任务“插缝”执行，把设备占住。核心原则是：设备空转是最大的浪费，优先级再高的任务也不能弥补空转损失。

3.2 为什么异构调度大多是协作式，而不是抢占式

传统操作系统调度里，抢占式调度是常态，时间片到了就让出 CPU。但异构设备不一样。GPU 上运行中的 kernel 一般不支持被完整中断换出，强行切换上下文的代价极高；NPU 更明显，很多设备的执行模型就是“任务一旦下发，硬件内部排好队，中间不能插手”。所以异构调度器里的“抢占”通常不是中断正在执行的任务，而是“下一个调度点”——任务以 kernel 粒度执行，一旦提交到设备，中途不打断，只有等它结束后才能把设备分给下一个任务。

这个设计有点像协作式多任务：每个 kernel 都自觉不霸占设备。但带来一个新问题：如果某个任务异常超时，后续所有排队任务都会被它堵住。调度器必须加超时保护。我习惯的做法是：如果一个任务的执行时间超过预估时间的两倍，不再傻等，把设备标记为异常状态，触发现场恢复流程——捕获设备上下文、记录错误信息、把异常任务的后继节点降级或重试。

生活化地理解就是多人共用一个厨房，每个人进厨房做饭时不能中途被轰走，所以排班时要预估好每个人占用灶台的时间。如果某个人做饭做了预定时间的两倍还没出来，其他等待的人不能一直傻站着，要有人看一下厨房是不是出事了。

3.3 反馈控制：调度器要会看仪表盘

静态策略的最大问题是“不听反馈”。如果某个设备前排队任务越来越多，说明调度策略没有感知下游压力；如果队列经常为空，说明资源没有被喂饱。一个成熟的动态调度器必须像一个好司机开车，眼睛盯着仪表盘，脚根据仪表盘调整油门。

反馈控制不需要一上来就上复杂的 PID。很多场景下，一个简单的水位线控制就够了。核心逻辑是：定期统计最近 N 个任务的平均延迟、各设备就绪队列的平均深度，然后动态调整并发度或下发速率。

每 100ms 执行一次反馈控制： avg_latency = 近 N 个已完成任务的延迟均值 queue_depth = 各设备就绪队列深度的均值 if avg_latency > 延迟预算 and queue_depth > 高水位: 降低并发度，暂停部分新任务下发 elif avg_latency < 延迟预算 * 0.5 and 设备空闲率 > 阈值: 提高并发度，或加大设备任务批量

这里要注意反馈频率和任务平均执行时长的匹配。如果任务平均执行 10ms，100ms 调整一次是合理的；如果任务平均执行 1 秒，100ms 调整一次就太激进，容易造成吞吐震荡。我见过一个调度器把反馈周期设得太短，结果并发度在 8 和 64 之间来回跳，延迟反而更糟。正确思路是反馈周期取平均任务执行时长的十分之一到五分之一，一开始可以保守一些，等运行平稳后再慢慢收紧。

4. 执行引擎的关键设计：事件驱动代替线程等待

4.1 线程池的边界：为什么不能靠加线程解决问题

一个常见误区是“调度器 = 线程池”。起一堆线程，每个线程抓一个任务丢给设备，然后同步等待设备完成。表面上看很直观，但异构设备调用往往是长时间阻塞的。一个线程在等设备完成时如果干等 200ms，它占着的 CPU 核心其实什么事都没做。为了弥补等待，你可能继续加线程，线程多了以后，线程切换开始抢占 CPU，调度器自己的决策路径反而被拖慢。最后进入恶性循环：加了线程，吞吐没上去，调度延迟涨了。

更麻烦的是，同步等待还可能造成“设备 A 忙、设备 B 闲，但所有执行线程都堵在设备 A 上”的假死状态。比如设备 A 上有一个超长 kernel，线程池里 16 个线程都在等它完成，设备 B 早就空闲了，但没有线程去提交新任务。这种情况用加线程的方式完全解决不了，因为你没办法提前知道哪个设备会卡住。

正确的做法是把“提交任务”和“等待完成”拆开。提交任务的线程只负责把任务写入设备的异步队列，提交完立即返回；设备完成后再通过回调或事件通知调度器去更新状态、释放资源。线程数量应该接近 CPU 物理核心数，而不是任务数量。执行引擎里的线程越多，不代表性能越高，反而会引入更多的上下文切换和锁竞争。

4.2 事件循环：把“等设备完成”变成“收完成通知”

事件驱动是解决异构等待问题的自然选择。设备完成、任务依赖就绪、用户提交新任务，这些都可以抽象成事件。执行引擎维护一个事件循环，轮询就绪事件，调度器根据事件更新 DAG 和队列状态，然后拉取一批任务提交到设备。整个过程没有哪个线程会长时间阻塞等待设备。

while running: events = collect_ready_events(timeout=50ms) for ev in events: if ev.type == DEVICE_DONE: node.state = FINISHED for nxt in node.dependents: nxt.deps_count -= 1 if nxt.deps_count == 0: ready_queue.push(nxt) elif ev.type == TASK_SUBMIT: create_node_by_dag(ev.task) batch = ready_queue.pop_batch(max_batch) for task in batch: device = resource_manager.pick(task) device.submit(task)

这段伪代码基本就是执行引擎的核心。事件循环的 timeout 要设成可配置参数。如果完全阻塞等待事件，调度器对慢设备太敏感，一个完成事件迟迟不来，整个调度器就卡住；如果轮询间隔太短，CPU 空转严重，调度器自己变成性能瓶颈。经验初始值 1ms 左右，跑测试时再根据任务平均执行时长调整。

餐厅服务员的类比在这里也成立：服务员不用站在每桌旁边等客人招手，而是站在门口，哪个桌有人举手就过去服务。这样服务员数量不需要等于桌数，几个服务员就能覆盖几十桌客人。事件循环里的 timeout 就像是服务员偶尔环顾一下全场，避免漏掉客人举手。

4.3 无锁队列：只在合适的地方用合适的结构

事件驱动结构搭好之后，调度线程和任务提交线程之间会高频传递任务指针。如果每次都用互斥锁保护队列，当任务又小又密时，锁竞争可能成为主要开销。无锁队列是一个选择，但我要强调：不要一上来就全盘无锁化。无锁队列里面真正稳定、值得优先使用的是 SPSC（单生产者单消费者）队列，因为内存序约束简单，实现稳定，出问题概率低。

template <typename T> class SPSCQueue { public: void push(T* item); // 只能在 producer 线程调用 T* pop(); // 只能在 consumer 线程调用 private: // push 时使用 release 语义，pop 时使用 acquire 语义 // 读写索引做 cache line padding，避免伪共享 };

这里最大的坑是把 SPSC 队列直接当 MPMC 队列用。如果两个线程同时 push，索引更新就会互相覆盖，轻则丢任务，重则内存损坏。多生产者多消费者场景要么换真正的 MPMC 无锁队列，要么用多个 SPSC 队列组合成扇形拓扑。另外要注意，无锁队列并不能消除 CPU 缓存一致性开销，它只是减少了锁等待和系统调用，只有在临界区极短、并发冲突明显的场景才有明显收益。

我在某模拟项目 X 里实测过一组数据：任务指针流转 100 万次，用 mutex 保护队列大约是 8ms，用 SPSC 版本大概 1.2ms。这只是单对单场景。一旦变成多对多，SPSC 的收益立刻消失，还要处理内存顺序带来的各种诡异问题。所以我的建议是：先明确队列的读写模型，再决定用什么结构。读写着集中在两个固定线程时，SPSC 是神器；读写模式混乱时，老老实实加锁，后面再优化。

5. 最小异构调度框架落地实录

5.1 模块划分：让策略和底层设备解耦

真正落地一个调度器时，模块边界比代码量重要得多。我推荐至少分五个模块：Scheduler 负责调度决策、DAG 维护、优先级管理；Executor 负责执行器线程池和事件循环；ResourceManager 负责设备资源画像、设备选择和设备状态监控；Monitor 负责延迟统计和反馈控制；Storage 负责任务输入输出数据的管理。

按这个划分，Scheduler 完全不需要知道设备 API 的细节，Executor 不负责资源选择。将来要调整调度策略，只需要改 Scheduler 和 Monitor，不会碰到底层设备适配代码。反过来，如果换了一种新型设备，只需要扩展 ResourceManager 和 Executor 的设备适配层，调度策略完全不用动。这个解耦对长期维护非常重要。

5.2 任务状态机是调度的地基

调度器本质上是一个大的状态机驱动器。每个任务至少应该有五个状态：PENDING（已注册，但依赖未满足）、READY（依赖满足，等待调度）、RUNNING（已提交到设备执行）、FINISHED（正常完成）、FAILED（失败）。还有一些场景需要 BLOCKED 状态，比如依赖的任务失败后，当前任务不能直接判定失败，要等上层策略决定重试、跳过还是取消。

enum TaskState { PENDING, // 注册但依赖未满足 READY, // 依赖满足，等待调度 RUNNING, // 已提交到设备 FINISHED, // 正常完成 FAILED, // 执行失败 BLOCKED // 依赖异常，等待策略决定 };

状态机的实现有个容易被忽视的细节：每个状态变更都要带全局自增的版本号或 generation 字段。异步回调可能乱序，旧事件的回调晚到时会把新任务的状态覆盖掉。我实际遇到过一个 bug：两个任务共用一个任务对象，旧回调返回时把状态改成了 FINISHED，但新任务其实还在运行，调度器读到的状态却是完成，于是以为设备空闲，提前派发了下一个任务，情况非常危险。给任务对象加上版本号后，回调更新前先比较版本号，旧版本直接丢弃，这个问题就消失了。

5.3 主循环：撑起整个调度器的骨架代码

调度器主循环的骨架其实很短，核心就是“收任务、扫 DAG、选任务、提设备”四步。完整工程两三千行甚至更多是正常的，但骨架就这么点。

while scheduler.is_running: # 1. 处理外部新任务 new_tasks = intake_queue.drain() for t in new_tasks: dag.register(t) # 2. 扫描 DAG，找出所有就绪任务 ready = dag.ready_set # 3. 按策略挑选一个批次 chosen = policy.select(ready, resource_summary) # 4. 给每个任务选设备并提交 for task in chosen: dev = resources.best_fit(task) dev.submit(task) task.state = RUNNING # 控制主循环频率，默认 1ms sleep(bleed_sleep)

这段代码看起来简单，但真正要跑稳，还需要监控线程采集设备完成事件、Monitor 调整队列优先级和并发度、ResourceManager 刷新设备状态。主循环里的每个步骤都要保证是无阻塞的。任何一步做了耗时的同步操作，都会把整个调度周期拉长。我习惯在代码里给四步分别打点计耗时，如果发现某一步长时间超过 1ms，就要往这一步深挖。

5.4 一组初始参数与实测调优方向

参数调优没有一刀切的值，但有一组合理的起点，能让你避免从零开始试错。

我见过很多团队把精力花在写炫酷的调度算法上，忽略了这些基础参数。实际上，在大多数系统里，把主循环 sleep 调准、把批量大小调合适的收益，比换一个高级启发式算法大得多。参数调优的前提是有监控数据，不然就是盲人摸象。先把 Monitor 模块的统计数据落库，再动手调参。

5.5 一次调优过程：3.6 万任务/秒到 7.8 万任务/秒

我在模拟压测环境里做过一次调优，环境是纯 CPU 与 GPU 混合任务，平均单个任务约 0.5ms。初始版本吞吐稳定在 3.6 万任务/秒，但 CPU 利用率不到一半，明显不是计算瓶颈。

第一轮用性能剖析工具看了一眼，调度器线程里等待锁的时间占总耗时将近 30%。多个线程都在抢同一个任务队列的 mutex，优化方向很明确：把全局任务队列按优先级拆成多个队列，每个队列独立加锁；再把 DAG 更新操作挪到事件循环专用线程上，避免和提交线程争同一把锁。改完后吞吐升到 5.4 万任务/秒。

第二轮发现 GPU 单次 kernel 启动开销占比过高。任务太小，启动成本几乎超过了执行成本。于是把同设备上的同类小任务打包成 batch，一次提交带上 8 个任务。打包之后吞吐到了 7.8 万任务/秒。最后把主循环 sleep 从 5ms 调到 1ms，高水位下的延迟才稳定下来。

这轮调优没有用任何高深算法，全是先量化瓶颈再拆结构。结论也简单：调度器优化的优先顺序是，先消除锁竞争，再减少启动开销，最后才是调整算法。顺序反了，效果会大打折扣。

6. 真实项目里踩过的坑与排错思路

6.1 低优先级任务一直饿死：老化机制怎么设计

我遇到过的最典型问题，是多级优先级队列上线后，高优先级流量持续饱满，低优先级任务几乎推进不了。从指标看，高优先级任务延迟很漂亮，但低优先级队列里的任务等待时间以小时计，业务方天天来找。

表面上是“高优先级任务太多了”，根子在于调度策略没有防止饥饿。只按优先级取任务，低优先级任务永远排不上。解决办法有两个。一是老化提升：给每个任务记录等待时长，等待每超过一个阈值，任务优先级自动上一档。比如普通队列任务等待 5 秒后进入高优先级队列，高优先级队列任务等待 30 秒后进入紧急队列。二是批次配额：每个调度周期，高优先级队列最多取 N 批，多出来的配额强制分给低优先级。这两种机制配合使用，饥饿问题基本能解决。

另外要注意，高优先级队列空窗时一定要立刻插执行低优先级任务，千万不要让设备空转等任务。很多团队宁让 GPU 闲着等下一个高优先级请求，也不去执行低优先级批处理，这是很大的资源浪费。

6.2 同步等待把执行器线程全部堵死：完整排查链路

在一次压测里，我遇到一个特别诡异的现象：任务提交速率一旦超过某个阈值，吞吐曲线突然掉到谷底，但 CPU 利用率只有 60% 不到，看起来不像计算资源耗尽。

先看日志，发现任务从提交到完成之间的平均延迟抖动非常剧烈，部分任务延迟从 2ms 跳到 400ms。再看监控面板，发现执行器线程全部处于阻塞状态。用火焰图采样后发现，几乎所有线程都阻塞在设备 API 的 wait 调用上。根因找到了：执行器线程在调用某厂商设备 API 时用了同步等待模式，设备 A 上有一个超长 kernel 占住不放，线程池里所有线程都在等它，设备 B 早就空闲了，但没有线程能去提交新任务。

修复方案是做两件事：第一，设备调用全部改成异步提交，完成时通过回调进入事件循环；第二，完成事件的设备状态更新集中到一个线程处理，避免多线程同时响应。改动后同样负载下吞吐稳定，CPU 利用率反而升高了，因为线程不再空等。

这个坑给我们的教训是：调度器的执行引擎必须设计成事件驱动，任何阻塞的同步等待都可能在关键时刻成为系统短板。而且排查时不要只看平均延迟，要同时看分位数、线程状态和火焰图，才能准确定位等待点。

6.3 DAG 扫描成为瓶颈：增量更新与节点池化

当任务数量从几千涨到十万级以后，新的瓶颈出现了：主循环里扫描 DAG 找出就绪集合的耗时越来越长。一开始没注意，后来发现调度循环里有相当一部分时间都花在遍历所有节点上，实际上很多节点根本还没就绪，扫描是白做的。

优化分为两步。第一步，把全图扫描改成增量更新。任务完成时，只更新受影响的后继节点入度，把入度变为零的节点放入就绪位图。跨图依赖单独维护一张表，不放进主 DAG 扫描范围。第二步，DAG 节点对象池化，避免频繁创建销毁节点对象。节点对象多了以后，内存分配和 GC 会成为隐藏的周期性问题，调度延迟会周期性飙升。

在某模拟项目 X 里，这两步优化把百万节点规模的 DAG 主循环扫描开销压到了微秒级。还有一个值得注意的细节：节点对象池要预先估算容量，不能等任务量上来后再动态扩容，否则扩容瞬间会引发一大波内存分配风暴。

6.4 关闭与故障恢复：调度器最后的体面

调度器不像普通 Web 服务，关停时需要仔细决定正在 RUNNING 的任务怎么办。我推荐两阶段退出。第一阶段：停止接收新任务，把 READY 队列里还没开始的任务落盘或标记为 pending。第二阶段：等待正在执行的任务运行完，宽限期可以设置成任务预估最大时长的两倍；超时后强制回收设备上下文。这样能尽可能保证不丢任务，也不会因为强行中断设备导致上下文损坏。

设备故障处理同样不能忽视。ResourceManager 一旦检测到设备异常，要先把故障设备从候选列表里摘除，再把依赖该设备的任务重新排队。重新排队时不能直接连续重试，否则设备恢复的那一瞬间会被突发重试流量冲垮。我习惯用指数退避策略，第一次重试等 200ms，第二次等 400ms，依次翻倍，最高上限 5 秒。

如果只让我留下一个设计原则，我会选任务状态机。调度器里几乎所有疑难问题，最后都能追溯回到“某一刻状态定义不清”。只要每个任务的状态定义清楚、状态迁移都由事件驱动、版本号控制好乱序，大部分调度 bug 会自己消失。先把状态机写对，再谈优化。