当前位置：首页 > news >正文

React 任务过期逻辑：调度器中的 expirationTime 是如何防止低优先级任务产生“饥饿（Starvation）”现象的？

news 2026/4/22 22:05:52

React 调度器深度解析：如何用 expirationTime 告别“任务饥饿”

各位老铁，各位前端界的“架构师”们，大家好！

我是你们的老朋友，一个整天在代码堆里刨食的资深编程专家。今天咱们不聊那些虚头巴脑的架构图，也不扯什么微前端架构，咱们来聊点“接地气”的，甚至可以说是“发际线保护”的话题——React 调度器。

你可能会说：“调度器？不就是 React 帮我渲染页面吗？这有什么好聊的？”

嘿，别急。如果你觉得调度器就是“按顺序执行代码”，那你可就太小看它了。在现代前端开发中，尤其是涉及到复杂交互、长列表渲染、动画以及后台数据同步时，调度器就是整个 React 世界的“交通指挥官”。而在这个指挥官手里，握着一张最重要的“王牌”——expirationTime（过期时间）。

这张王牌，直接决定了低优先级任务会不会在浩如烟海的高优先级任务面前被活活“饿死”。

今天，咱们就扒开 React 的底层逻辑，用最通俗的大白话，配合最硬核的代码，来聊聊这张王牌是如何防止“饥饿”现象的。

第一幕：调度器的“食堂”模型

要理解 expirationTime，咱们得先建立一个世界观。

想象一下，React 的调度器就是一个超级繁忙的食堂。这个食堂里有各种各样的顾客，他们手里拿着不同的订单（也就是我们的 React 任务）。

顾客 A（高优先级）：是个急脾气的大老板，他点的菜（比如点击按钮的响应）必须在 10 分钟内端上来，不然就要掀桌子。
顾客 B（低优先级）：是个慢性子的老奶奶，她点的菜（比如更新一下页面底部的版权信息）不急，晚点吃也行。
厨师（主线程）：只有一个，手速再快也有限度。

如果食堂里只有这一个厨师，老奶奶点的菜，如果大老板一直没来，老奶奶的菜可能永远在锅里煮不熟。这就是饥饿。

在 React 里，如果所有的更新都是高优先级（比如用户疯狂点击、滚动页面），那么那些低优先级的更新（比如在后台计算数据、做一些不影响视觉的优化）就会被无限期推迟，直到用户把手机刷没电。这就是前端界的“饥饿现象”。

那么，React 怎么解决这个问题呢？它给每个订单贴了一个“保质期”。

这个“保质期”，就是我们今天的主角——expirationTime。

第二幕：expirationTime 是什么鬼？

在 React 源码的Scheduler模块中，每个任务对象里都有一个属性叫expirationTime。这不仅仅是一个数字，它是任务的生命倒计时。

1. 时间的计算逻辑

当你在 React 组件里调用setState时，React 并不是马上执行更新，而是把这个任务扔进调度器的队列里。此时，调度器会根据你当前的优先级，算出一个expirationTime。

这个计算逻辑有点意思，咱们看代码：

// 这是一个简化的 React Scheduler 逻辑 function computeExpirationForPriority(priorityLevel) { switch (priorityLevel) { case ImmediatePriority: // 立即执行，几乎不等待 return NoTimeout; case UserBlockingPriority: // 用户交互优先级，比如正在输入，通常给 300ms 左右的过期时间 return 300; case NormalPriority: // 普通优先级，比如数据加载完成后的更新 return 5000; case LowPriority: // 低优先级，比如离屏渲染、统计上报 return 10000; case IdlePriority: // 空闲优先级，几乎不执行，只在浏览器真的空闲时 return MaxPriority; default: return NoTimeout; } }

你看，高优先级的任务，过期时间很短（比如 300ms）。这意味着：“嘿，你只有 300ms 的时间来干活，如果 300ms 后还没干完，你就得让路！”

而低优先级的任务，过期时间很长（比如 10000ms）。这意味着：“你有 10 秒钟的时间，慢慢来，不着急。”

2. 时间的流逝

React 的调度器会不断地运行，每一帧（大约 16ms 或 1000ms）都会检查当前时间（currentTime）。

如果currentTime > task.expirationTime，恭喜你，这个任务过期了。

这时候，React 就会面临一个严峻的抉择：是继续让这个过期的任务运行，还是把它踢出去，去执行别的任务？

这就是防止饥饿的关键时刻！

第三幕：饥饿是如何发生的？（没有 expirationTime 的悲剧）

在 React 还没有引入精细的调度器（或者在没有 expirationTime 逻辑的旧版逻辑）之前，或者如果我们将expirationTime设为无限大，会发生什么？

让我们写个模拟代码看看：

// 假设没有 expirationTime 限制的简单队列 let taskQueue = [ { name: "高优先级任务：点击响应", priority: 10, work: () => console.log("处理点击") }, { name: "低优先级任务：后台数据同步", priority: 1, work: () => console.log("同步数据...") }, { name: "中优先级任务：更新列表", priority: 5, work: () => console.log("更新列表...") } ]; function simulateOldScheduler() { // 简单的 FIFO（先进先出）执行 while (taskQueue.length > 0) { const task = taskQueue.shift(); // 取出任务 console.log(`开始执行: ${task.name}`); task.work(); // 执行任务 // 模拟耗时操作 console.log(`${task.name} 执行完毕`); console.log("---n"); } } simulateOldScheduler();

输出结果：

开始执行: 高优先级任务：点击响应
处理点击
高优先级任务：点击响应执行完毕
开始执行: 低优先级任务：后台数据同步
同步数据…
低优先级任务：后台数据同步执行完毕
开始执行: 中优先级任务：更新列表
更新列表…
中优先级任务：更新列表执行完毕

在这个简单的例子里，低优先级任务也能跑完。但现实生活比代码复杂多了。

现实场景：

高优先级任务（点击响应）开始执行，它非常耗时，要 2 秒钟。
低优先级任务（数据同步）排在后面，它在排队。
高优先级任务（点击响应）一秒后还没结束，这时候来了一个紧急的高优先级任务（比如用户按下了 ESC 键取消操作）。
新的高优先级任务把低优先级任务挤出了队列。

结果：低优先级任务永远在队列末尾，永远在等，直到用户关闭浏览器。这就是饥饿。

第四幕：expirationTime 的“绝地反击”

现在，咱们引入expirationTime。调度器不再只是按顺序执行，而是变成了一个动态调度系统。

核心逻辑是这样的：

时间切片：任务不能一口气干完。如果任务很重，React 会把它切成小块，每干 5ms 就停下来，看看有没有更高优先级的任务插队。
过期检查：如果任务太慢，超过了它的expirationTime，它就会降级。

代码实战：实现一个防饥饿的调度器

来，咱们自己动手写一个简单的调度器，看看它是怎么防止饥饿的。

class Scheduler { constructor() { this.taskQueue = []; this.currentTask = null; this.currentPriority = 0; this.isPerformingWork = false; } // 添加任务 scheduleTask(name, priority, work) { // 1. 根据 priority 计算过期时间 (简化版) const expirationTime = this.computeExpiration(priority); const task = { id: Math.random().toString(36).substr(2, 9), name, priority, expirationTime, work, startTime: null // 记录开始时间 }; this.taskQueue.push(task); this.sortQueue(); // 按优先级排序，高优先级在前 this.performWork(); // 尝试执行 } // 计算过期时间 computeExpiration(priority) { if (priority === 'high') return 10; // 10ms 后过期 if (priority === 'medium') return 50; if (priority === 'low') return 500; // 500ms 后过期 return Infinity; // 默认不过期 } // 排序：优先级高的在前，如果优先级相同，过期时间早的在前 sortQueue() { this.taskQueue.sort((a, b) => { // 优先级降序 if (a.priority !== b.priority) { return b.priority - a.priority; } // 优先级相同，expirationTime 升序（早过期的先跑） return a.expirationTime - b.expirationTime; }); } // 执行工作 performWork() { if (this.isPerformingWork) return; this.isPerformingWork = true; while (this.taskQueue.length > 0) { // 2. 取出队首任务 this.currentTask = this.taskQueue[0]; // 3. 关键检查：任务是否过期？ const now = Date.now(); if (now > this.currentTask.expirationTime) { console.log(`⚠️ 任务 [${this.currentTask.name}] 已过期！`); // 4. 防止饥饿的核心逻辑：降级！ // 如果任务过期了，它的优先级必须降低，否则它永远跑不完 this.lowerPriority(this.currentTask); // 重新排序队列，确保低优先级的任务不会永远堵在高优先级后面 this.sortQueue(); // 继续循环，看看有没有新进来的任务，或者重新排好序的任务 continue; } // 5. 模拟时间切片：执行任务 console.log(`🚀 开始执行: ${this.currentTask.name} (过期于: ${this.currentTask.expirationTime}ms)`); // 模拟执行时间 const workDuration = Math.floor(Math.random() * 20) + 1; // 1-20ms console.log(` 执行了 ${workDuration}ms...`); // 执行工作函数 this.currentTask.work(); // 如果任务还没跑完（比如它很大），我们把它放回队列头部，继续切片 // 但这里为了演示，假设执行一次就算完成了 this.taskQueue.shift(); console.log(` 完成!n`); } this.isPerformingWork = false; } // 降级逻辑 lowerPriority(task) { console.log(` 👉 ${task.name} 优先级降低！`); if (task.priority === 'high') task.priority = 'medium'; else if (task.priority === 'medium') task.priority = 'low'; // low 降到 idle，或者直接丢弃，这里我们保持 low } } // --- 测试场景 --- const scheduler = new Scheduler(); // 场景：高优先级任务先来，然后来了个超长耗时任务，最后又来了紧急任务 console.log("=== 场景开始 ===n"); // 1. 紧急的高优先级任务 scheduler.scheduleTask("紧急点击响应", "high", () => { console.log(" 👆 处理紧急点击！"); // 模拟耗时 5ms setTimeout(() => console.log(" 👆 点击响应完成"), 5); }); // 2. 低优先级任务（耗时很长） scheduler.scheduleTask("后台数据同步", "low", () => { console.log(" 📡 开始同步 5GB 数据..."); // 模拟耗时 100ms setTimeout(() => console.log(" 📡 数据同步完成"), 100); }); // 3. 又来一个紧急的高优先级任务（打断） setTimeout(() => { console.log("=== 50ms 后，新任务插队 ===n"); scheduler.scheduleTask("键盘输入响应", "high", () => { console.log(" ⌨️ 处理键盘输入！"); console.log(" ⌨️ 键盘输入完成"); }); }, 50);

运行结果分析：

0ms: 紧急点击响应开始执行（高优先级，10ms过期）。
50ms: 键盘输入响应插队（高优先级）。此时“后台数据同步”在队列里。
50ms: 键盘输入响应开始执行，抢占了 CPU。
60ms: 键盘输入响应完成。
60ms: 回到调度循环。此时，队列里只有“后台数据同步”。
60ms: 检查“后台数据同步”的过期时间（500ms）。当前时间 60 < 500，没过期，开始执行。
执行中…
100ms: “后台数据同步”执行了一半（模拟耗时）。
110ms: 110 > 10（紧急点击响应的过期时间）。注意！紧急点击响应已经过期了！
关键点：调度器发现“紧急点击响应”过期了，执行lowerPriority，把它降级为 medium。
重新排序：队列里现在有“后台数据同步”（low）和“紧急点击响应”（medium）。
执行结果：“后台数据同步”（low）继续执行，因为它现在优先级比刚降级的“紧急点击响应”（medium）还高（因为 low < medium）。
最终结局：低优先级任务并没有被饿死，它成功跑完了。

这就是 expirationTime 的魔力：它通过“过期即降级”的机制，打破了高优先级任务对 CPU 的永久霸占。

第五幕：requestIdleCallback 与浏览器的配合

React 的调度器不仅仅是自己玩，它还必须和浏览器这位“房东”打交道。React 早期大量使用了浏览器原生的requestIdleCallbackAPI。

requestIdleCallback是浏览器提供的接口，它会在主线程空闲的时候（比如渲染完一帧，没有用户输入，没有动画），回调一个函数。

React 利用这个接口，把低优先级任务塞进浏览器的“空闲时间”里。

逻辑流程：

React 调度器告诉浏览器：“嘿，我这有个低优先级任务，你空闲的时候帮我跑一下。”
浏览器说：“好嘞，我现在没活干，你发过来吧。”
React 把任务扔给requestIdleCallback。
浏览器在下一帧渲染前执行这个任务。

这如何防止饥饿？

因为requestIdleCallback是异步的。它不会阻塞主线程。即使高优先级任务来了，浏览器也会先处理高优先级，等高优先级处理完了（比如渲染完 DOM），浏览器会再次调用requestIdleCallback。

这就给低优先级任务留出了呼吸的空间。

但是，如果低优先级任务一直没跑完怎么办？浏览器可能会觉得你太慢了，或者用户已经离开页面了，它可能会取消这个回调。

这时候，React 的expirationTime再次发挥作用。如果任务过期了，React 会把它标记为“过时”，并可能用setTimeout（降级为普通优先级）重新投递。

代码示例：浏览器空闲回调的模拟

// 模拟 React 的 requestIdleCallback 行为 let idleQueue = []; let isIdle = true; function requestIdleCallback(callback) { // 实际上浏览器会检查当前是否有空闲时间 // 这里我们简单模拟：立即调用，或者由主线程调度 setTimeout(() => { if (isIdle) { callback(); } else { // 如果主线程忙，浏览器可能会重试，或者忽略 // React 的做法通常是重试 requestIdleCallback(callback); } }, 0); } // React 内部逻辑 function scheduleLowPriorityWork() { // 这是一个低优先级任务，过期时间很长 const task = { work: () => console.log("我在浏览器空闲时偷偷运行！"), expirationTime: 5000 // 5秒后才过期 }; requestIdleCallback(() => { const now = Date.now(); if (now > task.expirationTime) { console.log("任务已过期，放弃执行或降级执行"); return; } task.work(); }); } // 模拟高优先级任务打断 function simulateHighPriority() { isIdle = false; console.log("高优先级任务来了，主线程繁忙！"); setTimeout(() => { isIdle = true; console.log("高优先级任务结束，主线程空闲了！"); scheduleLowPriorityWork(); // 此时才真正触发低优先级任务 }, 100); } simulateHighPriority();

第六幕：降级与重排（Scheduler 的核心算法）

咱们刚才的例子比较简单，实际 React 源码中的逻辑要复杂得多。React 的调度器维护了一个任务队列，并且有一个当前时间指针。

当任务过期时，React 会调用lowerPriority函数。这个函数不仅仅是改个数字，它还会重新计算expirationTime。

// React 源码中的逻辑片段 function lowerPriority(task) { // 1. 降低优先级 switch (task.priorityLevel) { case ImmediatePriority: task.priorityLevel = UserBlockingPriority; break; case UserBlockingPriority: task.priorityLevel = NormalPriority; break; case NormalPriority: task.priorityLevel = LowPriority; break; // ... } // 2. 重新计算过期时间 // 如果任务变成了低优先级，它的过期时间会变得非常长 // 这意味着：即使它过期了，它也拥有了“长期生存权” task.expirationTime = computeExpirationForPriority(task.priorityLevel); }

为什么要这么做？

你可能会问：“如果任务过期了，为什么不让它直接滚蛋？”

因为 React 想要最终一致性。即使低优先级任务跑得慢，它也必须跑完。如果直接扔掉，页面可能就永远缺了一块内容。

但是，如果它一直跑不完，就会一直占用 CPU（或者占用requestIdleCallback的槽位）。

所以，React 的策略是：给过期任务一个“终身监禁”的缓刑。它会一直降级，直到变成最低优先级（IdlePriority），然后乖乖地在浏览器空闲时跑。

这就像监狱里的囚犯：

罪犯 A（高优先级）：必须马上判刑。
罪犯 B（低优先级）：被判了死刑缓期执行。
如果 A 一直不执行死刑，B 就会一直待在监狱里，但刑期会越来越长（降级）。
只要监狱里没别的事，B 总有放出来的那一天。

第七幕：时间切片与 shouldYield

防止饥饿的另一个重要手段是时间切片。

如果 React 一个接一个地执行任务，哪怕任务很小，也会因为函数调用栈的开销导致主线程阻塞。浏览器一旦阻塞，就会失去对requestIdleCallback的控制权。

React 会在执行任务的过程中，不断检查shouldYield()。

function workLoop() { while (nextUnitOfWork !== null && !shouldYield()) { nextUnitOfWork = performUnitOfWork(nextUnitOfWork); } } function shouldYield() { // 检查是否超过了 deadline // deadline 是 requestIdleCallback 传进来的 const currentTime = getCurrentTime(); // 如果当前时间超过了 deadline，说明浏览器要渲染下一帧了 // React 必须停下来，把控制权还给浏览器 return currentTime >= deadline.timeRemaining(); }

这如何防止饥饿？

如果 React 不切分任务，高优先级任务会一直占用主线程，导致requestIdleCallback根本不会被浏览器调用。低优先级任务就真的饿死了。

通过切片，React 允许高优先级任务在每一帧跑一点点，然后主动让出控制权。

// 伪代码演示切片 function executeLongTask() { let i = 0; while (i < 1000000) { // 做点工作 i++; // 检查是否该让步了 if (i % 100 === 0) { // 每做 100 步检查一次 if (shouldYield()) { // 停下来！ // 此时浏览器空闲了，我们可以去执行低优先级任务了！ scheduleLowPriorityTasks(); return; // 返回，等待下一帧 } } } }

第八幕：实战中的 expirationTime

让我们看看在真实的 React 组件中，expirationTime是如何影响渲染的。

假设你在开发一个电商 App。

用户点击“立即购买”按钮：触发高优先级更新。expirationTime被设为NoTimeout（几乎立即执行）。
此时，后台正在计算一个复杂的推荐算法：触发低优先级更新。expirationTime被设为LowPriority（比如 100ms 或 500ms）。
点击事件处理函数执行：它里面有一个同步的、耗时的JSON.parse操作（这是个坏习惯，但假设发生了）。
React 调度器：
- 它检测到点击任务正在执行。
- 它看到后台任务过期了（或者快过期了）。
- 关键点：React 不会让后台任务在点击任务的同步代码执行期间运行（因为主线程被占用了）。它会等待点击任务的同步代码执行完毕。
- 点击任务完成后，React 开始渲染。
- 此时，后台任务可能已经过期了。React 会把它降级为LowPriority。
- React 开始渲染。它先渲染高优先级部分（按钮状态）。
- 然后它检查requestIdleCallback。如果浏览器空闲，它会把后台任务扔进去执行。
- 结果：用户点击按钮有反馈（高优先级任务完成），页面底部的推荐列表也在不卡顿的情况下慢慢更新了（低优先级任务完成，没饿死）。

代码示例：实际场景模拟

import React, { useState, useEffect } from 'react'; const ExpiredTaskDemo = () => { const [count, setCount] = useState(0); const [status, setStatus] = useState('idle'); // 模拟一个低优先级任务：每秒更新一次状态，但不影响主线程 useEffect(() => { const timer = setInterval(() => { // 这是一个低优先级更新 // React 会给它分配一个较长的 expirationTime setCount(prev => prev + 1); }, 1000); return () => clearInterval(timer); }, []); const handleClick = () => { setStatus('loading'); // 这是一个高优先级更新 // React 会给它分配一个极短的 expirationTime (ImmediatePriority) // 模拟耗时操作（阻塞主线程） console.log("开始处理点击..."); setTimeout(() => { console.log("处理完毕！"); setStatus('idle'); }, 500); // 假设这个操作耗时 500ms }; return ( <div style={{ padding: 20, fontFamily: 'monospace' }}> <h1>点击计数器</h1> <p>当前状态: <strong>{status}</strong></p> <p>后台计数: <strong>{count}</strong></p> <button onClick={handleClick} disabled={status === 'loading'}> {status === 'loading' ? '处理中...' : '点击我'} </button> <div style={{ marginTop: 20, color: 'red' }}> 注意观察：当点击按钮处理时，后台计数器虽然慢，但从未停止！ </div> </div> ); }; export default ExpiredTaskDemo;

在这个例子中，虽然点击按钮的操作（高优先级）会阻塞主线程 500ms，但 React 的调度器知道后台的setInterval是低优先级的。它不会因为主线程忙就取消后台任务，也不会让后台任务在主线程阻塞期间试图抢占 CPU（那是违规的）。

一旦主线程空闲，React 就会渲染最新的状态。低优先级任务通过setInterval这种机制，配合 React 的调度逻辑，完美地避免了饥饿。