React 内部调度器的优先级过期阈值模型：探究过期时间计算公式在处理长任务时的数学收敛性

各位同学，大家好！

今天我们不聊怎么用 useState，也不聊 useEffect 的执行顺序，我们要聊聊 React 的“心脏”——也就是那个藏在 scheduler 包里的调度器。它是 React 的幕后黑手，是那个在浏览器疯狂抖动、还要保证你界面不卡顿的幕后操盘手。

如果把 React 的渲染比作一场盛大的交响乐，那调度器就是那个拿着指挥棒的指挥家。他不仅要决定哪个音符（任务）该先响，还要决定什么时候该停下来喘口气，别把听众（用户）给憋死了。

今天，我们要深入解剖这个调度器的核心机密：优先级过期阈值模型。我们要用数学的眼光去审视它，特别是当那个叫“长任务”的捣乱鬼出现时，这个系统是如何在数学上保证“收敛”的——也就是它不会崩溃，不会无限死循环，最终总能把活干完。

准备好了吗？让我们把键盘敲得像打碟机一样响。

第一部分：调度器里的“等级森严”

首先，我们得搞清楚调度器手里握着什么牌。React Scheduler 定义了五个优先级，这简直就是好莱坞片场的等级制度。

1. ImmediatePriority (立即执行)： 也就是最高优先级。就像你在悬崖边上，必须马上跳下去。通常用于 flushSync 或者 useTransition 的初始阶段。
2. UserBlockingPriority (用户阻塞)： 当你疯狂点击按钮、输入文字时，React 就得给你开绿灯。这就像是你闯红灯，交警（浏览器）也得给你让路，不然你的键盘要被砸烂了。
3. NormalPriority (普通优先级)： 默认。也就是你点击一个按钮，React 去算一下那个按钮对应的逻辑，没完没了的那种。
4. LowPriority (低优先级)： 比如 getDerivedStateFromProps 或者一些不需要马上看的计算。
5. IdlePriority (空闲优先级)： 最低。只有在浏览器完全没事干的时候，React 才会去干这些杂活，比如收集性能数据。

这五个等级不是摆设，它们直接决定了你的任务能活多久。而决定任务寿命的，就是我们要讲的过期时间。

第二部分：过期时间的数学公式

想象一下，调度器是一个严格的考官。他手里有个时钟，叫 currentTime。每个任务被分配到一个“截止时间”，也就是 expirationTime。

这个过期时间是怎么算出来的？React 给了一个公式，虽然看起来简单，但蕴含深意：

$$ text{ExpirationTime} = text{currentTime} + text{timeout}(text{priority}) $$

这里的 timeout(priority) 是个函数。不同优先级，这个 timeout 的值不一样：

• ImmediatePriority: timeout = 1 (毫秒)。基本上是立刻执行，别废话。
• UserBlockingPriority: timeout = 300 (毫秒)。给用户一点缓冲，但别太久。
• NormalPriority: timeout = 5000 (毫秒)。给 5 秒钟的时间去处理，要是 5 秒钟没干完，那就强制执行。
• LowPriority: timeout = 25000 (毫秒)。给 25 秒。

数学陷阱来了：

如果 currentTime 是 1000ms，NormalPriority 的 timeout 是 5000ms，那么这个任务的 ExpirationTime 就是 6000ms。

这意味着什么？意味着调度器在 6000ms 之前，都会把其他低优先级的任务（比如收集日志）扔到一边，优先把这个任务干完。

但是，如果这个任务是个“长任务”呢？比如它要跑 10000ms 才能跑完。

这时候，数学模型就开始打架了。

第三部分：长任务的“暴走”与调度器的“止损”

当一个长任务开始执行，比如 NormalPriority 的任务，它耗时很长。调度器在旁边看着。

• 时刻 T=0: 任务开始，currentTime=0，expirationTime=5000。任务信心满满：“我有 5 秒钟的时间！”
• 时刻 T=2000: 任务还在跑。此时 currentTime=2000。任务心想：“嘿，我还没到 5000 呢，继续跑！”
• 时刻 T=5000: 调度器一看表：“哎哟，时间到了！”这就是所谓的过期。

这时候，如果任务还没跑完，会发生什么？

这就是 React 调度器的“数学收敛”核心：

1. 强制执行： 如果任务过期了，React 会觉得：“这任务太慢了，不能再让它跑了，必须马上切回来给它个痛快（或者把它打断）。”
2. 降级处理： 如果任务特别特别慢，比如跑满了 5000ms 还没完，React 不会傻傻地继续给它 NormalPriority，而是会把它降级，甚至强行中断。

让我们看看代码是怎么写的（这是简化版的 scheduler 逻辑）：

function scheduleWork() {
  // ... 省略中间的优先级判断逻辑 ...

  // 计算过期时间
  const expirationTime = currentTime + timeout(priority);

  // 启动任务
  workLoop(expirationTime);
}

function workLoop(expirationTime) {
  let didTimeout = false;

  // 核心循环：只要没超时，或者超时了但还没完全死透，就一直跑
  while (nextTask !== null && !shouldYield()) {
    const currentTask = nextTask;

    // 执行任务的一小部分
    const remainingTime = expirationTime - currentTime;
    const exitReason = currentTask.fn(remainingTime);

    if (exitReason === 'didTimeout') {
      // 任务说：我还没跑完，但是时间到了！
      didTimeout = true;
      break;
    }

    // 任务跑完了
    nextTask = nextTask.next;
  }

  if (didTimeout) {
    // 这里的数学逻辑是：如果超时了，我们可能需要调整策略
    // 比如把优先级降级，或者把任务重新推入队列
    // 这里体现了一种“自我修正”的数学收敛

    if (nextTask !== null) {
      // 如果还有任务，且当前任务超时了，说明系统过载
      // React 会尝试降低当前任务的优先级，防止它再次阻塞
      decreasePriorityLevel();
    }

    // 重新调度
    scheduleWork();
  } else {
    // 没超时，继续等待下一帧
    requestIdleCallback(workLoop);
  }
}

第四部分：数学收敛性的深度剖析

为什么说这个模型具有“数学收敛性”？因为这是一个反馈控制系统。

在控制理论里，如果输入信号（长任务）超过了系统的处理能力，系统不会崩溃，而是会通过反馈机制（shouldYield），自动调整输出参数（降低优先级、切出主线程），直到输入和输出达到一个新的平衡点。

场景模拟：地狱模式

假设你有一个极其复杂的计算任务，耗时 10 秒，优先级是 NormalPriority。

1. T=0s: 任务开始。过期时间设为 5s。
2. T=1s: 浏览器刷新，调度器检查。时间没到，继续跑。
3. T=5s: 任务过期了！调度器介入。
   • 策略 A: 强制打断任务，执行 requestIdleCallback，让浏览器渲染这一帧。
   • 策略 B: 任务被标记为“过期状态”。
4. T=5.1s: 下一次调度。React 发现任务还没做完。此时，React 会把当前任务的 timeout 值调小，或者把优先级降级。
   • 为什么？因为如果一直给 5s 的 timeout，任务永远跑不完，系统就会死锁。
   • React 会调整公式：newTimeout = Math.max(0, oldTimeout - 1000)。
5. T=6s: 任务再次被调度。这次过期时间变成了 4s。
6. T=10s: 任务终于跑完了。

收敛的证明（伪数学）：

设 $T$ 为任务总耗时，$t$ 为当前运行时间，$E$ 为当前过期阈值。

在 $t < E$ 时，系统处于 稳定态，任务正常执行。
在 $t ge E$ 时，系统进入 动态调整态。

收敛的关键在于回退机制。当任务超时，系统会执行以下操作：

1. 中断任务。
2. 降低任务的预期完成时间（即缩短 timeout）。
3. 重新调度。

只要任务的执行时间 $T$ 是有限的（这是现实世界的假设），无论 $T$ 多大，无论过期阈值 $E$ 怎么变，系统最终都会在 $T$ 时刻完成任务。

这就好比你在跑步，鞋带松了（超时了），你停下来系鞋带（中断并调整策略），然后继续跑。只要你没放弃跑，你就一定会到达终点。

第五部分：实战代码——破解 shouldYield

光说不练假把式。React 调度器最核心的数学魔法，在于 shouldYield 函数。它决定了任务什么时候该“停手”。

// scheduler 包中的简化逻辑
let isPerformingWork = false;
let deadline = 0;
let timeRemaining = 0;

function shouldYield() {
  // 获取浏览器的剩余时间
  // 这是浏览器通过 requestIdleCallback 传进来的
  const now = performance.now();

  // 如果时间不够了，必须 yield
  if (now >= deadline) {
    // 这里有一个数学上的“软阈值”
    // React 并不是精确到毫秒，而是有一个缓冲
    // 比如 deadline 是 16ms，React 可能会在 10ms 就 yield
    // 为了保证 UI 不卡顿，宁可少跑点，也不能阻塞
    return true;
  }

  return false;
}

这里有一个非常有趣的数学细节：

React 为了保证帧率（60fps），它假设每一帧有 5ms 的工作时间（16ms 的帧间隔减去开销）。

如果 timeRemaining 小于 5ms，React 会强制 shouldYield() 返回 true。

这意味着，即使你的任务还没“过期”（ExpirationTime 还没到），只要时间不够了，调度器也会强制让它停下来。

这就形成了一个双重保险：

1. 硬约束： 到了 expirationTime，必须干完。
2. 软约束： 剩余时间不够了，先歇会儿。

长任务处理中的收敛性体现：

当一个长任务（比如 50ms 的计算）正在执行时：

• 帧 1 (0-16ms): timeRemaining 足够，任务执行。
• 帧 2 (16-32ms): timeRemaining 不足，shouldYield 触发。任务挂起。浏览器绘制 UI。
• 帧 3 (32-48ms): 浏览器空闲，React 重新调度任务。任务继续。
• 帧 4 (48-64ms): 任务完成。

你看，这个 50ms 的长任务被“切碎”了。虽然它总耗时没变，但它不再是一个阻塞整个线程的“巨石”，而是一系列快速、可中断的“小石子”。

这种切片机制，就是数学收敛性的另一种体现：通过增加系统的“分辨率”（更频繁的调度），将一个不可解的“长任务”问题，转化为无数个可解的“短任务”问题。

第六部分：优先级反转与饥饿

在调度理论中，有一个著名的“饥饿”问题。如果高优先级任务永远得不到执行，系统就废了。

React 的过期阈值模型巧妙地解决了这个问题。

假设你有两个任务：

1. 任务 A (High Priority): expirationTime = 100ms。
2. 任务 B (Low Priority): expirationTime = 10000ms。

如果任务 B 非常慢，占满了 CPU，任务 A 会怎么样？

数学告诉我们，当 currentTime 超过 100ms 时，任务 A 就过期了。此时，调度器会强制将任务 A 插入到任务队列的最前面，打断任务 B。

这就是所谓的过期即中断。它保证了高优先级任务永远不会被饿死。无论任务 B 有多慢，只要时间到了，系统就会把资源抢过来给任务 A。

第七部分：代码重构——模拟一个简易版 React 调度器

为了真正理解这个数学模型，我们手写一个“迷你版 React Scheduler”。别怕，代码不长，但逻辑很硬核。

// 1. 定义优先级枚举
const Priorities = {
  Immediate: 5,
  UserBlocking: 4,
  Normal: 3,
  Low: 2,
  Idle: 1
};

// 2. 定义任务结构
let taskIdCounter = 0;
let currentTask = null;

const tasks = [];

// 3. 核心调度器
function schedule(priorityLevel, callback) {
  const taskId = taskIdCounter++;
  const currentTime = performance.now();

  // 计算过期时间
  // 优先级越高，timeout 越小
  const timeoutMap = {
    5: 1,    // Immediate: 1ms
    4: 300,  // UserBlocking: 300ms
    3: 5000, // Normal: 5s
    2: 25000,// Low: 25s
    1: Infinity
  };

  const timeout = timeoutMap[priorityLevel];
  const expirationTime = currentTime + timeout;

  const task = {
    id: taskId,
    callback: callback,
    priorityLevel: priorityLevel,
    expirationTime: expirationTime,
    startTime: currentTime
  };

  // 简单的优先级队列插入
  tasks.push(task);
  tasks.sort((a, b) => b.priorityLevel - a.priorityLevel); // 简单的排序，实际 React 用堆

  if (!isRunning) {
    isRunning = true;
    requestAnimationFrame(workLoop);
  }
}

let isRunning = false;

// 4. 工作循环——这是数学收敛发生的地方
function workLoop() {
  const currentTime = performance.now();

  // 遍历任务队列
  while (currentTask || tasks.length > 0) {
    // 如果当前没有任务在跑，取下一个
    if (!currentTask) {
      currentTask = tasks.shift();
    }

    // 如果任务过期了，或者时间到了，强制执行
    if (currentTime >= currentTask.expirationTime) {
      console.log(`任务 ${currentTask.id} 过期了！执行中...`);
      // 降级处理：如果过期，我们降低它的优先级，模拟 React 的收敛策略
      currentTask.priorityLevel = Math.max(1, currentTask.priorityLevel - 1);
      // 更新过期时间，给它新的机会
      currentTask.expirationTime = currentTime + 1000; 
    }

    // 执行任务
    console.log(`执行任务 ${currentTask.id}，耗时 2ms`);
    currentTask.callback();

    // 模拟任务耗时
    const taskDuration = 2; 
    currentTime += taskDuration;

    // 检查是否应该暂停
    // 这里我们简化：如果任务还没跑完，就暂停
    if (currentTime - currentTask.startTime > 5) {
      // 这是一个长任务！
      console.log("检测到长任务，暂停以让出主线程。");
      currentTask = null; // 暂停当前任务
      break;
    }
  }

  if (tasks.length > 0) {
    requestAnimationFrame(workLoop);
  } else {
    isRunning = false;
    console.log("所有任务完成。");
  }
}

// 5. 测试
console.time("总耗时");
schedule(Priorities.Normal, () => {
  console.log("开始执行长任务...");
  setTimeout(() => {
    console.log("长任务结束");
    console.timeEnd("总耗时");
  }, 5000);
});

在这个微型代码中，你可以看到：

1. ExpirationTime 限制了任务的生存时间。
2. Long Task Detection（长任务检测）通过比较 startTime 和 currentTime 来实现。
3. Yield 通过 break 和 requestAnimationFrame 实现。

第八部分：关于“数学收敛性”的终极思考

回到我们最初的主题：数学收敛性。

在 React 的调度器中，这种收敛体现在两个层面：

1. 宏观收敛： 无论任务多么复杂，无论优先级多么混乱，最终所有的任务都会被执行完毕。这是一个全有或全无的系统。它不会留下半截任务，也不会永远卡在某个状态。这是系统稳定性的基石。
2. 微观收敛（响应性）： 当用户进行高优先级交互时，系统会迅速收敛到“响应模式”。低优先级的后台任务会被挤出时间片，系统资源会自动向高优先级倾斜。这种动态平衡是靠 expirationTime 作为杠杆撬动的。

结论：

React 的调度器不仅仅是一个时间管理工具，它是一个精心设计的数学系统。它利用离散时间和优先级队列，在有限的浏览器时间片内，通过过期阈值作为触发器，实现了对长任务的优雅处理。

它告诉我们一个道理：在计算机科学里，没有什么是不能被打断的。只要你的数学模型（过期时间）和反馈机制（中断与重调度）设计得当，即使是世界上最长的任务，也能被切成无数个可爱的碎片，完美地呈现在用户面前。

好了，今天的讲座就到这里。下课！