React 调度器深度剖析：TimerQueue 与 TaskQueue 的“相爱相杀”与状态迁移
各位同学，大家好！
今天我们要聊的东西，听起来有点枯燥，甚至有点反直觉。在 React 的世界里，我们习惯了“组件渲染”、“状态更新”、“虚拟 DOM Diff”。这些都是大家耳熟能详的“前端三大件”。
但是，如果 React 没有一个极其精密的时间管理器，如果它不知道什么时候该干活，什么时候该偷懒，那它就像是一个只会瞎忙活的搬砖工，虽然勤劳，但效率低下，甚至会把主线程（UI 线程）堵死，导致页面卡顿。
这个时间管理器，就是我们的主角——Scheduler（调度器）。而在 Scheduler 内部，有两支“特种部队”：一支负责即时作战的 TaskQueue，另一支负责远程支援的 TimerQueue。
今天，我就要带大家钻进 React 的调度器内部，看看这两支队伍是如何通过复杂的逻辑，完成从“等待”到“执行”的状态迁移的。
第一部分：场景模拟——为什么我们需要两个队列？
想象一下，你现在是一家繁忙餐厅的大厨（React 应用）。
厨房里有两种任务：
- 顾客催单了（TaskQueue）： 比如用户点击了按钮，或者父组件更新了数据。这就像是刚端上来的菜，必须立刻做，不能等！
- 预点单（TimerQueue）： 比如用户点击了“5秒后提醒我”，或者组件挂载时有一个延时加载的动画。这就像是预订了明天的早餐，现在不用急着做，但必须得安排个闹钟。
如果只有一个队列，大厨就得把所有预点单都堆在案板上，结果顾客催单的时候，大厨还在那儿慢悠悠地切洋葱（处理延时任务）。这显然不行。
所以，React 采用了双队列机制：
- TaskQueue（任务队列）： 存放那些必须立即执行或者高优先级的任务。
- TimerQueue（计时器队列）： 存放那些有延时要求的任务，并且它是按时间排序的（谁先到期谁在前面）。
调度器的核心工作，就是不断比较当前时间，决定是把 TimerQueue 里的任务“踢”进 TaskQueue，还是直接把 TaskQueue 里的任务扔给执行器。
第二部分：TaskQueue —— 紧急通道
我们先来看看 TaskQueue。这是 React 调度器的“VIP 休息室”。
在这个队列里的任务，要么是同步任务，要么是优先级极高的任务。它们的共同特点是：不需要等待时间。
代码示例：Task 的结构
首先，我们得定义一个“任务”长什么样。在 React 源码中，一个任务对象大致长这样：
// 简化版的 Task 结构
const task = {
id: 1,
callback: function() {
console.log("这是任务回调，我要执行了！");
},
priorityLevel: 'High', // 优先级
startTime: 0, // 任务开始时间
expirationTime: 0 // 任务过期时间
};代码示例：runTask（执行任务）
当调度器决定要干活了，它会从 TaskQueue 的头部取出一个任务并执行。这就像大厨从案板上拿走第一个菜。
// 简化版的 runTask 逻辑
function runTask(task) {
const callback = task.callback;
// 执行任务
const didTimeout = callback();
// React 源码中这里还有非常复杂的错误捕获和重试逻辑
// 但为了理解状态迁移，我们只看核心：
if (didTimeout) {
// 如果任务执行完毕后，发现它自己也是一个延时任务（比如 setTimeout 的回调）
// 那么它会被重新推回 TimerQueue 等待下次执行
pushTimer(task);
} else {
// 如果任务正常结束，它就从 TaskQueue 中消失了
// React 会继续取下一个任务，直到队列空了
}
}注意： TaskQueue 是一个先进先出（FIFO）或者最小堆（Min-Heap）结构。不管任务是谁加进来的，只要它是高优先级的，它就得先执行。
第三部分：TimerQueue —— 候车室
接下来是 TimerQueue。这是 React 的“候车室”。
这里面的任务都有一个共同的属性：expirationTime（过期时间）。React 需要一个高效的方式来找到“谁最早到期”。
代码示例：scheduleCallback（调度任务）
当你调用 setTimeout 或者 React 内部的 scheduleCallback 时，调度器会根据你的需求决定把任务扔进哪个队列。
function scheduleCallback(priorityLevel, callback, options) {
// 1. 计算任务的时间
const currentTime = getCurrentTime();
// 2. 计算过期时间
// 如果 options.delay 是 1000ms，那过期时间就是 当前时间 + 1000ms
let expirationTime = currentTime + options.delay || 0;
const task = {
id: Math.random(),
callback: callback,
priorityLevel: priorityLevel,
startTime: currentTime + options.delay, // 真正开始的时间
expirationTime: expirationTime // 必须执行的时间点
};
// 3. 决策：是进 TaskQueue 还是 TimerQueue？
// 逻辑：如果 startTime <= currentTime
// 说明这个任务不需要等，现在就可以做。
if (task.startTime <= currentTime) {
// 进 TaskQueue！
push(task, taskQueue);
} else {
// 否则，进 TimerQueue！
// TimerQueue 会根据 expirationTime 排序，保证最早到的任务在前面
push(task, timerQueue);
}
// 4. 触发调度
requestHostCallback();
}这里有个重点： push(task, timerQueue) 这一步，并没有立即执行任务。它只是把任务“挂”起来了。React 现在会去检查 TimerQueue，看看有没有任务到期了。
第四部分：状态迁移的核心 —— handleTimeout
现在，我们要进入最精彩的部分了。TimerQueue 里的任务是怎么变成 TaskQueue 里的任务的？
这中间的桥梁，就是 handleTimeout 函数。
React 使用浏览器原生的 setTimeout 来模拟“时间流逝”。当时间到了，浏览器会调用 handleTimeout。
代码示例：handleTimeout（迁移逻辑）
这是整个调度器逻辑最核心的代码段。请仔细阅读，因为这就是你要的“状态迁移逻辑”。
// 伪代码实现
function handleTimeout(currentTime) {
// 1. 检查 TimerQueue 是否为空
while (timerQueue.length > 0) {
const firstTask = timerQueue.peek(); // 查看队头（最早到期的任务）
// 2. 核心判断：这个任务真的过期了吗？
// 如果 firstTask.expirationTime > currentTime
// 说明时间还没到，这个任务还得再等等，直接退出循环
if (firstTask.expirationTime > currentTime) {
break;
}
// 3. 状态迁移！
// 任务从 TimerQueue 被移除
const task = timerQueue.shift();
// 关键点：我们将任务推入 TaskQueue
// 这意味着，它从“延时等待区”变成了“立即执行区”
push(task, taskQueue);
}
// 4. 触发下一帧
// 这一步非常重要！
// 我们把控制权交还给 requestHostCallback
requestHostCallback();
}这段代码说明了什么？
- 扫描： 调度器像个守门员，每隔一段时间（由 setTimeout 决定），就会看一眼 TimerQueue。
- 筛选： 它只看队头的任务。如果队头还没到时间，说明后面那些任务更晚，它就不看了，直接睡觉去了。这叫“懒惰的调度”，非常节省性能。
- 迁移： 一旦队头任务
expirationTime <= currentTime，说明时间到了！此时，React 会把这个任务从TimerQueue移到TaskQueue。 - 重启： 调用
requestHostCallback()。这会告诉浏览器：“嘿，我有新任务要处理了，请把主线程交给我。”
第五部分：requestHostCallback 与 requestHostTimeout
光有队列还不够，React 还需要知道什么时候触发 handleTimeout。这就涉及到浏览器 API 的调用。
1. requestHostTimeout（启动定时器）
当调度器往 TimerQueue 里塞了一个任务时，它知道这个任务需要等待。于是，它得告诉浏览器：“你帮我设个闹钟吧。”
function requestHostTimeout(callback, delay) {
// 使用 setTimeout 模拟
// 注意：React 在源码中会根据环境做很多兼容性处理（比如在 node.js 环境下）
setTimeout(() => {
callback(getCurrentTime());
}, delay);
}2. requestHostCallback（执行任务）
当 handleTimeout 迁移完任务后，React 需要开始干活了。它不能直接同步执行，因为那样会阻塞 UI。它需要利用浏览器渲染一帧的时间。
// requestHostCallback 的简化逻辑
function requestHostCallback() {
// 如果已经在运行中，就不重复调度了
if (isFlushing) {
return;
}
isFlushing = true;
// 这里的 requestAnimationFrame 是关键
// 它比 setTimeout 更精准，能保证在浏览器重绘前执行
requestAnimationFrame(() => {
// 执行工作
workLoop();
// 工作结束后，恢复标志位
isFlushing = false;
});
}为什么是 requestAnimationFrame？
因为 React 想把任务安排在浏览器的下一帧（Vsync 信号）之前执行。这样，任务执行完后，浏览器刚好有空隙去渲染 UI，用户看到的就是流畅的动画，而不是卡顿。
第六部分：深度剖析——为什么会有“优先级”介入？
你可能会问：“TimerQueue 里的任务什么时候到期，难道不是由用户决定的吗？”
错！React 的调度器非常霸道。它有自己的优先级体系（比如 NoPriority, Low, Normal, High, Immediate）。
让我们重新审视 scheduleCallback 中的逻辑，加入优先级的干扰。
场景模拟：VIP 闯入
假设现在 TimerQueue 里有一个延时 5000ms 的低优先级任务（比如统计上报）。此时，用户点击了一个按钮，触发了一个高优先级任务。
// 用户点击按钮，触发高优先级任务
scheduleCallback(ImmediatePriority, () => {
console.log("救命！用户点击了！");
});
// 执行 scheduleCallback 逻辑
function scheduleCallback(priorityLevel, callback, options) {
const currentTime = getCurrentTime();
let expirationTime = currentTime + options.delay || 0;
const task = {
id: Math.random(),
priorityLevel: priorityLevel,
startTime: currentTime + options.delay,
expirationTime: expirationTime
};
// 重点来了！
// React 的 push 函数不是简单的 push，而是根据优先级排序的！
// 即使这个任务先加入 TimerQueue，如果它优先级极高，它可能会直接跳到 TaskQueue！
if (task.startTime <= currentTime) {
// 即时任务，直接进 TaskQueue
push(task, taskQueue);
} else {
// 延时任务，进 TimerQueue
push(task, timerQueue);
}
requestHostCallback();
}这里有一个隐藏的逻辑陷阱：
如果在 TimerQueue 中，有一个任务已经等待了很久（比如 4990ms 了），马上就要到期了。这时候，一个高优先级的即时任务进来了。
React 会怎么处理？
- 这个高优先级任务会直接进
TaskQueue。 - 调用
requestHostCallback。 requestHostCallback会先执行TaskQueue里的任务。- 高优先级任务抢占了 CPU！
状态迁移的变体：
如果在 handleTimeout 执行过程中，发现 TimerQueue 队头虽然过期了，但是它的优先级非常低，而 TaskQueue 里还有一堆高优先级任务没跑完。
React 的逻辑是：
- 先把过期的任务从
TimerQueue移到TaskQueue。 - 立即执行
TaskQueue里的高优先级任务。 - 高优先级任务执行完后，才会回来继续处理刚才那个过期的低优先级任务。
这就是 React 的优先级抢占机制。它保证了用户体验永远是第一位的。
第七部分：时间漂移与 requestHostCallback 的递归
在真实的 React 源码中，还有一个非常精妙的点：时间漂移。
假设：
TimerQueue里有一个任务，需要在100ms后执行。requestHostTimeout被调用，设置了setTimeout(handleTimeout, 100)。- 但是！浏览器卡顿了，或者系统负载很高，
100ms实际上过去了200ms才执行handleTimeout。
这时候，handleTimeout 里的逻辑会变成什么样？
function handleTimeout(currentTime) {
while (timerQueue.length > 0) {
const firstTask = timerQueue.peek();
// 此时 currentTime = 200ms
// firstTask.expirationTime = 100ms
// 判断：200 > 100，任务过期了！
if (firstTask.expirationTime > currentTime) {
break;
}
// 迁移任务...
const task = timerQueue.shift();
push(task, taskQueue);
}
// 关键：再次调用 requestHostCallback
// 注意，这里没有再次设置 setTimeout，而是直接把控制权交还给 RAF
requestHostCallback();
}为什么这么做？
因为 handleTimeout 本身就是由 requestHostTimeout 触发的，而 requestHostTimeout 又是 requestHostCallback 的一部分。
如果我们在 handleTimeout 里再次设置 setTimeout，那就会产生无限循环的定时器。
正确的流程是：
handleTimeout发现任务过期 -> 移动到TaskQueue。requestHostCallback被调用 -> 开始执行TaskQueue。- 在执行
TaskQueue的过程中，如果发现TaskQueue没任务了，或者执行完了，它会检查TimerQueue。 - 如果
TimerQueue还有任务没过期，它会再次调用requestHostTimeout，设置下一个延时。
这形成了一个闭环：
TimerQueue -> requestHostTimeout -> handleTimeout -> TaskQueue -> requestHostCallback -> workLoop -> 检查 TimerQueue…
第八部分：实战演练——一个完整的调度周期
为了让大家彻底搞懂，我们来模拟一次完整的 React 渲染周期。
场景：
- 用户进入页面，有一个延时 2000ms 的弹窗。
- 1000ms 后，用户点击了“提交”按钮。
阶段 1：初始化
// 用户进入页面，React 开始调度
scheduleCallback(IdlePriority, showPopup, { delay: 2000 });
// 内部逻辑：
// currentTime = 0
// task.expirationTime = 2000
// task.startTime = 2000
// push(task, timerQueue); // 进 TimerQueue
// requestHostTimeout(handleTimeout, 2000); // 设置 2000ms 后的回调此时，TimerQueue 里有任务 A，TaskQueue 是空的。浏览器在等待 2000ms。
阶段 2：用户点击（时间点 1000ms）
// 用户点击按钮
scheduleCallback(ImmediatePriority, handleSubmit);
// 内部逻辑：
// currentTime = 1000
// task.expirationTime = 1000
// task.startTime = 1000
// push(task, taskQueue); // 进 TaskQueue (因为 startTime <= currentTime)
// requestHostCallback();此时，TaskQueue 里有任务 B（高优先级），TimerQueue 里有任务 A。
阶段 3：执行
requestHostCallback 被触发。
function workLoop() {
// 1. 先看 TaskQueue
if (taskQueue.length > 0) {
const task = taskQueue.shift();
runTask(task); // 执行 handleSubmit
} else {
// 2. TaskQueue 空，再看 TimerQueue
// 调用 requestHostTimeout
const firstTask = timerQueue.peek();
// 设置 handleTimeout 在 currentTime + 1000ms 后触发
requestHostTimeout(handleTimeout, firstTask.expirationTime - currentTime);
}
}React 先执行了任务 B（提交按钮），UI 瞬间响应。
阶段 4：时间到了（时间点 2000ms）
setTimeout 触发了 handleTimeout(currentTime = 2000)。
function handleTimeout(currentTime) {
// 1. 检查 TimerQueue
while (timerQueue.length > 0) {
const firstTask = timerQueue.peek();
// 此时 currentTime = 2000
// firstTask.expirationTime = 2000
// 2000 > 2000? 不成立！任务过期！
const task = timerQueue.shift(); // 取出任务 A
push(task, taskQueue); // 迁移到 TaskQueue！
}
// 2. 再次触发 requestHostCallback
requestHostCallback();
}现在，任务 A 被迁移到了 TaskQueue。
阶段 5：弹窗出现
requestHostCallback 再次被调用。
function workLoop() {
if (taskQueue.length > 0) {
const task = taskQueue.shift();
runTask(task); // 执行 showPopup
}
}弹窗出现。任务 A 执行完毕，TaskQueue 空了。如果 TimerQueue 也没任务了，React 就彻底休息了。
第九部分：总结——TimerQueue 与 TaskQueue 的爱恨情仇
回顾一下，我们今天把 React 调度器的核心逻辑扒了个底朝天。
-
分工明确：
- TaskQueue 是前线指挥部，负责处理那些不需要等待、或者高优先级的紧急任务。
- TimerQueue 是后勤仓库，负责管理那些有延时要求、低优先级的任务。
-
状态迁移（核心）：
- 迁移的触发点是
handleTimeout。 - 迁移的条件是
expirationTime <= currentTime。 - 迁移的动作是
shift(从 TimerQueue) ->push(到 TaskQueue)。 - 迁移的目的是为了让过期的任务有机会被
requestHostCallback抓取并执行。
- 迁移的触发点是
-
优先级为王：
- 即使是 TimerQueue 里的任务，如果优先级极高，也可以直接跳过 TimerQueue，进入 TaskQueue。
- 一旦进入 TaskQueue，就会打断 TimerQueue 的等待，立即执行。
-
时间管理：
- React 使用
requestAnimationFrame来保证任务在渲染帧之前执行。 - 它使用
setTimeout来模拟“时间流逝”并触发handleTimeout。 - 它通过检查
currentTime来处理“时间漂移”，确保不会漏掉过期的任务。
- React 使用
最后，我想说：
React 的调度器就像是一个极其精明的交通指挥官。TimerQueue 和 TaskQueue 就是两条不同的车道。调度员时刻盯着时钟（getCurrentTime），一旦 TimerQueue 里有人要迟到了，他就立刻挥旗，把人从慢车道（TimerQueue）赶到快车道（TaskQueue），然后吹响哨子（requestHostCallback），让汽车（任务）全速前进。
理解了这一点，你就理解了 React 为什么能在一个复杂的单页应用中，依然保持 UI 的流畅和响应。当你下次看到 setTimeout 在 React 代码里出现时，别再以为它只是个简单的延时器了，它可是调度器里身经百战的“特使”！
好了，今天的讲座就到这里。大家回去可以试着在控制台打印一下 Scheduler 的相关日志，看看你的应用里，这两个队列都在忙些什么。下课！