深度解析 React 并发调度：当“时间戳”成为防止任务饥饿的救命稻草
大家好，欢迎来到今天的“React 内核深度解剖课”。
我是你们的讲师，一个在 React 调度器里摸爬滚打多年的老司机。今天我们不聊怎么用 useEffect 或者 useMemo，那些只是花拳绣腿。今天我们要聊的是 React 的内功心法——并发模式下的调度器。
你们有没有遇到过这种情况：你的 React 应用正在渲染一个复杂的列表，然后用户突然点击了一个按钮。结果呢？那个按钮的点击事件响应慢得像是在用拨号上网，而那个复杂的列表还在那儿死死地占着 CPU 不放。这就是传说中的任务饥饿。
如果调度器是个不负责任的保姆，低优先级的任务（比如渲染列表）就会把高优先级的任务（比如处理点击）活活饿死。那用户体验就完蛋了，用户会以为电脑死机了。
那么，React 是怎么防止这种“饿死”现象的呢？今天我们就来扒一扒 React 调度器如何利用时间戳这一神奇的小工具，来维持任务世界的公平与正义。
第一讲：厨房里的“饿死”惨案
为了讲清楚调度器，我们得先建立一个世界观。想象一下，React 的渲染过程就是一个繁忙的餐厅后厨。
所有的任务都是厨师（或者传菜员）。有些任务是大厨，比如“处理用户点击”或者“更新状态”，这是 VIP 顾客，优先级极高，得马上办。有些任务是洗碗工，比如“渲染几万条列表”或者“计算复杂的数学公式”，这些是慢活，优先级很低。
在非并发模式下，也就是 React 的老版本里，厨房有个规矩：谁先来谁先做。大厨正在炒菜（渲染列表），这时候传菜员端来了 VIP 的菜单（用户点击）。大厨一看，说：“我正忙着呢，你先等着。”结果 VIP 顾客等得不耐烦了，掀桌子了。这就是任务饥饿。
并发模式的目的，就是为了解决这个问题。React 希望厨房能有多条流水线，或者至少，大厨在炒菜的时候，如果听到有 VIP 来了，得能停下来，先去服务 VIP，然后再回来继续炒菜。
但是，停下来再继续，这就涉及到了一个核心问题：怎么控制什么时候停下来？
这就轮到我们的主角——调度器 登场了。
第二讲：时间戳——给任务贴上“死亡倒计时”的标签
在调度器眼里，所有的任务都不是永恒的。每个任务在进队列的时候，调度器都会给它发一张时间戳，这张票上写着它的截止时间。
这个截止时间是怎么来的？它不是随机的，它是由任务的优先级决定的。
React 的调度器里有一个核心公式，用来计算这个截止时间。为了方便理解，我们假设系统的基准时间 currentTime 是 0，且所有任务都有 5000 毫秒的缓冲期（实际 React 会根据优先级动态调整）。
// 简单的伪代码逻辑
function scheduleCallback(priorityLevel) {
// 1. 获取当前时间（注意：这是调度器内部维护的时间，不是系统时间）
const currentTime = getCurrentTime();
// 2. 根据优先级计算过期时间
// 优先级越高，过期时间越短（越急）
// 优先级越低，过期时间越长（越从容）
const expirationTime = currentTime + getExpirationTime(priorityLevel);
// 3. 创建任务对象
const task = {
id: timestamp++,
callback: null, // 具体的执行函数
priorityLevel: priorityLevel,
expirationTime: expirationTime, // 关键！
startTime: currentTime,
timeout: 0,
};
// 4. 把任务扔进调度器的“锅”里
push(taskQueue, task);
// 5. 开始调度
requestHostCallback(flushWork);
}看，这就是时间戳的由来。它本质上是一个截止时间。
调度器为什么要给任务贴这个标签？因为只有知道了截止时间，调度器才能判断：“哎呀，这个低优先级的任务已经堆积了太久，它马上就要过期了！如果我现在不把它执行完，它就要被当成垃圾扔掉了！为了防止任务消失，我必须赶紧把它叫起来干活！”
这个逻辑有点反直觉，对吧？通常我们认为“时间戳”是用来记录“开始时间”的。但在 React 的调度器里，时间戳是用来标记“如果不做，就会出事”的紧急程度的。
第三讲：代码实战——模拟一个饥饿的调度器
光说不练假把式。我们手写一个超级简化的调度器，来演示一下时间戳是如何防止饥饿的。
假设我们有一个 SimpleScheduler 类。
class SimpleScheduler {
constructor() {
this.taskQueue = [];
this.currentTime = 0;
this.isRunning = false;
}
// 模拟系统时钟滴答
tick() {
this.currentTime += 10; // 每次滴答增加 10ms
}
// 添加任务
// priority: 1 (最高) -> 5 (最低)
schedule(task, priority) {
const startTime = this.currentTime;
// 核心逻辑：根据优先级计算过期时间
// 优先级 1 (高): 剩余时间 500ms
// 优先级 5 (低): 剩余时间 5000ms (给低优先级任务更多“生存时间”)
let timeout;
if (priority === 1) timeout = 500;
else if (priority === 2) timeout = 1000;
else if (priority === 3) timeout = 2000;
else if (priority === 4) timeout = 4000;
else timeout = 8000;
const expirationTime = startTime + timeout;
console.log(`[调度器] 接收任务: 优先级=${priority}, 截止时间=${expirationTime}, 当前时间=${startTime}`);
const taskObj = {
task,
priority,
startTime,
expirationTime,
id: Math.random().toString(36).substr(2, 9)
};
this.taskQueue.push(taskObj);
// 按照截止时间排序（越早过期的越靠前）
this.taskQueue.sort((a, b) => a.expirationTime - b.expirationTime);
if (!this.isRunning) {
this.isRunning = true;
this.run();
}
}
async run() {
while (this.taskQueue.length > 0) {
this.tick(); // 模拟时间流逝
const currentTask = this.taskQueue[0]; // 查看队首任务
// 关键判断：时间到了没？
if (this.currentTime >= currentTask.expirationTime) {
console.log(`[调度器] 警告：任务 ${currentTask.id} 已过期！必须执行！`);
// 执行任务
await currentTask.task();
// 移除任务
this.taskQueue.shift();
// 检查是否有高优先级任务插队（虽然这里简单实现了，但真实 React 会更复杂）
// 在这里，我们假设执行完当前任务，继续循环
} else {
// 任务还没过期，调度器可以休息一下，或者让出 CPU
console.log(`[调度器] 任务 ${currentTask.id} 还没过期，先歇会儿 (当前: ${this.currentTime}, 截止: ${currentTask.expirationTime})`);
break; // 让出控制权
}
}
this.isRunning = false;
console.log(`[调度器] 所有任务处理完毕`);
}
}场景演示：高优先级“插队”
现在我们来跑一下这个模拟器，看看它是如何工作的。
const scheduler = new SimpleScheduler();
// 1. 首先来了一个低优先级任务（比如渲染列表），它有很长的截止时间
scheduler.schedule(() => {
console.log(">>> 执行低优先级任务：渲染 10000 条数据...");
// 模拟耗时操作
return new Promise(resolve => setTimeout(resolve, 5000));
}, 5); // 优先级 5，截止时间 = 0 + 8000 = 8000
// 2. 仅仅过了 100ms，来了一个高优先级任务（比如点击事件）
setTimeout(() => {
console.log("n>>> 用户点击了按钮！高优先级任务来了！");
scheduler.schedule(() => {
console.log(">>> 执行高优先级任务：处理点击逻辑...");
return Promise.resolve();
}, 1); // 优先级 1，截止时间 = 10 + 500 = 510
}, 100);运行结果分析：
- t=0ms: 低优先级任务进队，截止时间 8000ms。
- t=10ms: 高优先级任务进队，截止时间 510ms。
- t=10ms: 调度器开始运行。检查队首（低优先级）。
- 当前时间 10，截止时间 8000。没过期。
- 调度器输出：“任务还没过期，先歇会儿”。
- 调度器停止，把 CPU 权交还给浏览器。
- t=100ms: 用户点击，高优先级任务进队。
- 此时任务队列里有：[高优先级(截止510), 低优先级(截止8000)]。
- 调度器醒来，再次运行。
- 注意排序！ 调度器会按照截止时间排序。高优先级任务（510ms）排到了队首。
- 调度器检查队首：当前时间 100，截止时间 510。还没过期。
- 关键点来了： 如果调度器继续执行低优先级任务，它会在 10ms 后（t=110ms）把低优先级任务跑完，再回过头来跑高优先级任务。这时候高优先级任务的截止时间就到了（510ms）。
- 但是！ 在这个简化的模拟里，我们的
run()函数是单线程顺序执行的。为了演示“防止饥饿”，我们需要一个机制，让高优先级任务在低优先级任务执行之前就能获得执行机会。
在真实的 React 中，flushWork 函数会执行一个循环，但在每次循环开始时，它会先检查当前最高优先级任务是否已经过期。
让我们修正一下模拟器的逻辑，加入“抢占”机制：
async run() {
while (this.taskQueue.length > 0) {
this.tick();
// 找出所有还没过期的任务中，截止时间最早的（最高优先级）
// 过滤掉已经过期的任务
const validTasks = this.taskQueue.filter(t => t.expirationTime > this.currentTime);
if (validTasks.length === 0) {
break; // 队列空了
}
// 取出截止时间最早的（也就是最高优先级）
const currentTask = validTasks[0];
// 核心判断：是否过期？
if (this.currentTime >= currentTask.expirationTime) {
console.log(`[调度器] 警告：任务 ${currentTask.id} 已过期！强制执行！`);
await currentTask.task();
this.taskQueue.shift(); // 移除已过期任务
} else {
console.log(`[调度器] 执行任务 ${currentTask.id} (优先级 ${currentTask.priority})`);
// 执行任务，模拟耗时
await currentTask.task();
// 执行完一个，把它从队列里移除
this.taskQueue.shift();
}
}
}现在再运行刚才的代码，你会看到：
- t=0ms: 低优先级进队（截止 8000）。
- t=10ms: 高优先级进队（截止 510）。调度器醒来，发现队首是高优先级（截止 510），没过期，开始执行高优先级任务。
- t=100ms: 高优先级任务还在执行中…
- t=510ms: 高优先级任务还没跑完，但它的截止时间到了！调度器会抛出异常或者标记任务过期，强制中断当前高优先级任务的执行（在真实 React 中这叫 yield），然后执行下一个任务。
通过这种方式，时间戳（截止时间）迫使调度器优先处理那些“快来不及”的任务。
第四讲：为什么是“时间切片”而不是“时间戳”？
你可能会问：“既然有了截止时间，为什么还要切片？直接把任务跑完不行吗？”
这就是 React 的精妙之处。如果任务跑完，浏览器主线程就会阻塞，导致页面卡死，连滚动条都动不了。用户感觉不到并发，只感觉到卡顿。
时间戳的作用是宏观调度，而时间切片的作用是微观执行。
React 的调度器在执行一个任务时，会记录一个 startTime。当它执行到一定程度，或者时间接近任务的 expirationTime 时，它会主动停下来，调用 requestHostCallback 把控制权交还给浏览器。
function workLoop() {
while (deadlineSuspendedTime === null && currentTask !== null) {
const nextTask = peek(taskQueue);
// 检查是否应该暂停
if (nextTask.expirationTime > currentTime) {
// 如果下一个任务的截止时间还没到，我们还可以再跑一会儿
// 但为了不卡顿 UI，我们通常会在每一帧（16ms）左右暂停
if (shouldYield(currentTime)) break;
}
// 执行任务的一小部分
currentTask = advanceTimers(currentTime, currentTask);
}
}这里的时间戳 nextTask.expirationTime 就像是一个哨兵。它告诉调度器：“嘿，兄弟，你虽然现在没事干，但那个低优先级任务虽然还没过期，但它排在后面。如果那个高优先级任务（截止时间很近）进来了，你必须得让路！”
第五讲：优先级的映射——时间戳的刻度
React 的调度器定义了 5 个优先级级别。这些级别直接决定了时间戳的长短。
让我们看看 React 源码里那个著名的 Scheduler 包里的映射逻辑（简化版）：
// 优先级从高到低
const ImmediatePriority = 99;
const UserBlockingPriority = 98;
const NormalPriority = 97;
const LowPriority = 96;
const IdlePriority = 95;
// 这里的逻辑大致是：
// expirationTime = currentTime + timeout
// timeout 的值取决于优先级
function getExpirationTime(priorityLevel) {
const currentTime = getCurrentTime();
// 这是一个硬编码的基准延迟，实际上 React 会根据当前帧的负载动态调整
const baseTimeout = 1;
switch (priorityLevel) {
case ImmediatePriority:
return currentTime + baseTimeout;
case UserBlockingPriority:
// 用户交互通常给 300ms - 500ms 的缓冲
return currentTime + 250;
case NormalPriority:
return currentTime + 5000; // 普通渲染给 5 秒
case LowPriority:
return currentTime + 10000; // 低优先级给 10 秒
case IdlePriority:
// Idle 优先级几乎没有截止时间，或者很久之后
return currentTime + 30000;
default:
console.assert(false, 'Invalid priority level');
return currentTime + 5000;
}
}看到这个表，是不是觉得很亲切？
- ImmediatePriority (99)：比如
flushSync，或者componentDidCatch。一旦进入这个队列，它必须在几毫秒内执行完，否则就过期了。 - UserBlockingPriority (98)：比如点击、滚动、输入。这是用户最关心的。如果这个任务过期了，用户体验会非常差（页面卡死）。
- NormalPriority (97)：普通的 React 渲染。如果这个任务过期了，页面可能会稍微卡顿一下，但通常不会导致用户无法操作，因为它是渐进式的。
第六讲：MessageChannel 与 真实的“时间戳”魔法
React 调度器是怎么在浏览器里真正“偷”时间的呢？它不能一直霸占 CPU。
React 使用了 MessageChannel（消息通道）机制。这就像是浏览器和 JS 引擎之间的一条秘密通道。
当调度器决定让出 CPU（shouldYield）时，它不会直接停止，而是会把控制权推给浏览器的事件循环。然后，它会设置一个定时器，在下一帧（大约 16ms 后）再次检查队列。
// 简化的 requestHostCallback
function requestHostCallback(callback) {
// 1. 如果浏览器支持 requestIdleCallback，就用那个（这是现代浏览器的特性，用于后台任务）
// 2. 否则，使用 MessageChannel
if (typeof window !== 'undefined' && window.postMessage) {
if (!isScheduled) {
isScheduled = true;
channel.port2.onmessage = event => {
// 当浏览器处理完其他所有宏任务（比如你的点击事件）后，
// 这里会被触发。
// 此时，调度器会再次检查 currentTime 和 expirationTime。
callback();
};
channel.port1.postMessage(null);
}
}
}这个循环是：
- 检查时间：
currentTime是否已经超过了某个任务的expirationTime？ - 检查负载：当前帧已经用了 16ms 吗？
- 执行切片：如果有任务要跑，就跑一小段。
- 让步：如果没任务了，或者时间到了，就
postMessage唤醒浏览器，让浏览器先处理用户输入（比如响应那个高优先级的点击事件）。
这就是为什么你在 React 里点击按钮，按钮能立刻响应，而下面的列表还在慢慢渲染。因为调度器在渲染列表（低优先级）的时候，时刻盯着那个点击事件（高优先级）的截止时间。一旦点击事件的截止时间到了，或者浏览器给了机会，调度器就会立刻把 CPU 切换给点击事件处理程序。
第七讲：任务过期——饥饿的终极解决方案
前面我们一直在说“防止饥饿”，也就是让低优先级任务有机会跑。但时间戳还有一个更狠的功能：如果低优先级任务太懒，一直不跑，它就会被干掉。
这在 React 中被称为“任务过期”。
如果调度器发现当前时间已经超过了某个任务的 expirationTime，它通常会采取以下措施之一：
- 降级执行：把这个任务标记为
lowPriority，然后继续执行。这就像是把一个急事变成了小事。 - 丢弃任务：直接从队列中移除。这通常发生在用户离开页面或者组件卸载的时候。
function advanceTimers(currentTime, task) {
// 查找所有比当前时间更早过期的任务
let earliestExpiredTime = -1;
// ... 遍历队列逻辑 ...
if (earliestExpiredTime !== -1) {
// 找到了过期任务
const expiredTask = taskQueue[earliestExpiredTime];
// 如果过期时间非常久远，或者当前是 Idle 级别，直接丢弃
if (expiredTask.expirationTime < currentTime) {
console.warn(`[调度器] 任务 ${expiredTask.id} 已过期且未被处理，已丢弃。`);
taskQueue.splice(earliestExpiredTime, 1);
return task; // 继续处理下一个
}
}
return task;
}防止饥饿有两种方式：
- 喂饱它：高优先级任务来了，低优先级任务主动让路。（抢占）
- 饿死它：低优先级任务一直不动，最后被系统扔掉。（淘汰）
React 的调度器巧妙地结合了这两种方式。对于低优先级任务，它给足了时间窗口（时间戳很长），只要你肯干活，你就能跑完。但如果高优先级任务太多，导致你一直拿不到 CPU，你的时间窗口就会慢慢变小，直到你过期被扔掉。
第八讲：总结——时间戳的哲学
回到我们最初的问题：调度器如何利用时间戳防止低优先级任务永不执行？
答案其实非常简单，却又充满智慧：
时间戳不仅仅是一个标记，它是一个倒计时器。
它告诉调度器：“嘿，这个任务虽然现在看起来不重要，但我给你留了 5 秒钟。如果你不快点把它干完，5 秒钟后我就不管了。”
这种机制创造了一种动态的平衡：
- 如果系统很空闲，低优先级任务可以慢慢跑，时间戳永远不会到期。
- 如果系统很繁忙（高优先级任务堆积），调度器会根据时间戳，不断地唤醒低优先级任务，甚至打断它，把 CPU 让给高优先级任务。
最终，如果低优先级任务真的“懒”到连时间戳都没过就消失了，那说明它本身就不重要，或者系统已经不堪重负了。这就是一种自我保护的机制。
React 的调度器就像一个精明的管家。他手里拿着每个人的截止时间表。当大厨（高优先级）喊饿的时候，管家会立刻把洗碗工（低优先级）赶到一边，甚至把洗碗工没洗完的盘子直接扔进垃圾桶，只为了确保大厨能吃饱。
这就是并发模式下的任务饥饿问题，以及时间戳的解决方案。希望今天这堂课，能让你在面对 useEffect 卡顿或者 React 报错时，能从更深层的逻辑去理解它。
好了，今天的课就到这里。下课！记得把电脑关了，出去走走，别让你的 CPU 也“饥饿”了！