React useState 状态更新的环形链表逻辑：源码分析 dispatchAction 如何在不导致内存泄漏的前提下管理 pending 更新队列

（敲击黑板，清了清嗓子）

各位下午好！欢迎来到今天的“React 源码探险之旅”。我是你们的领航员。

今天我们不谈 Hello World，也不谈那些把组件拆得像俄罗斯套娃一样花哨的模式。我们要聊的是 React useState 最底层、最硬核，甚至有点“脏活累活”的地方。你们有没有想过，当你在这个 React 函数里写下 setCount(c => c + 1) 时，到底发生了什么？

如果你的脑子里只有“状态变了，重绘了”，那你可能错过了一个精彩的世界。今天，我们要深入那个神秘的后台，去看看那个叫做 dispatchAction 的家伙是如何像指挥家一样，操控着一根看不见的线——环形链表。我们要重点探讨的是：为什么这根链表不会变成内存泄漏的坟墓？

别担心，今天我会用最通俗的语言，配合大量的代码示例，带你把 React 的内核摸个底朝天。

---

第一章：DispatchAction——那个跑堂的

想象一下，你在一家高档餐厅点菜。你举起手喊了一声“服务员！加一份牛排！”。

这个“喊一声”的动作，就是你的 setCount。

而在 React 的世界里，这个“喊一声”会被翻译成一个极其严肃的函数调用：dispatchAction。

首先，我们要找到 dispatchAction 的入口。它通常长这样：

// 这是我们为了方便理解，重写的简化版 React 核心逻辑
function dispatchAction(fiber, queue, action) {
  // 1. 创建一个新的更新对象
  // 这个对象里包含了你想要执行的动作
  const update = {
    action: action,
    expirationTime: getCurrentTime(), // 什么时候要？也就是优先级
    next: null,
    queue: queue // 它属于哪个队列？这是关键
  };

  // 2. 将这个更新扔进队列里
  // 这里就开始体现环形链表的威力了
  if (queue.pending === null) {
    // 如果队列是空的，那就简单了，这是一个新队列
    // update.next 指向自己，形成闭环
    update.next = update;
    // queue.last 也就是队尾，指向这个新节点
    queue.pending = update;
  } else {
    // 如果队列不空...
    // 这是一个 O(1) 的操作！不需要遍历数组，不需要 splice！
    // 这就是 React 为什么用链表而不是数组的原因。
    const last = queue.pending;
    // 新节点放在队尾
    last.next = update;
    // update 的 next 指向队首（也就是环形）
    update.next = queue.pending;
    // 更新队尾指针
    queue.pending = update;
  }

  // 3. 发出调度信号
  // 告诉 React："嘿，我有活儿干了，你安排个时间给我渲染一下！"
  scheduleForNextTime(update.expirationTime);
}

看到了吗？这就是 dispatchAction 的核心逻辑。它非常简单，甚至有点粗暴：拿来，挂上，走人。

但是，这个“挂上”的过程，是用一个环形链表完成的。你可能会问：“老哥，数组不行吗？push 一下不行吗？”

当然行，但是慢！

数组 push 虽然是 O(1)，但在 React 这种高频调用的场景下，React 更在乎的是性能。如果你用数组，为了追踪最新的更新，你还需要维护一个 index。每次你 setCount，你不仅要 push，可能还要 shift，甚至还要处理所有的索引变动。

而在链表里，我们只需要移动两个指针：last（队尾）和 head（队首）。React 把它玩成了环，因为“首尾相连”让它极难被破坏，也极快地被访问。

---

第二章：环形链表——它为什么是圆的？

好了，我们来看看这个环形链表到底长什么样。为了方便大家脑补，我画个图：

       [Update A] ---> [Update B] ---> [Update C]
                 ^                           |
                 |___________________________|

初始状态：
pending = A, last = A。
A.next 指向 A。

当你调用 setCount，dispatchAction 进来，创建 Update D：

1. last (A) 看见 D，把 A.next 指向 D。
2. D.next 指向 A (队列开头)。
3. pending 指向 D (新的队尾)。

现在队列变成了：D -> A -> B -> C -> D。

这就像是你在转圈圈跑步。pending 指针就像是一个在跑道上跑的人，他跑得很快，每次都跑到最前面去。旧的节点被甩在身后，变成了“垃圾”，等待被清理。

这就是 React 的高效之处！ 每次更新，我们只需要做一次指针移动。这就是所谓的 O(1) Time Complexity。

---

第三章：内存泄漏——那个潜伏的杀手

现在，我们要聊点吓人的东西了。内存泄漏。

在 React 早期（甚至现在），有一个著名的坑，叫做“未处理的更新”。

假设你的组件渲染了，React 根据最新的状态生成了新的 DOM。但是，如果在这个过程中，因为某些原因（比如网络卡顿、计算太重），React 没有完成渲染，或者仅仅是用户频繁点击了按钮，大量的 Update 对象被挂在了链表上。

如果这些更新对象永远不会被“消费”，它们就会一直留在内存里。

举个栗子：

function Counter() {
  const [count, setCount] = useState(0);

  // 用户疯狂点击，一秒钟点了 100 次
  // 100 个 Update 对象被挂到了链表上

  // 但是！此时页面卡死了，React 根本没来得及处理这 100 个更新
  // 这 100 个 Update 对象的 action、expirationTime、还有它们自身引用的其他闭包变量
  // 就全都被锁死了，死死地贴在内存里的这个环形链表上！

  return <div>{count}</div>;
}

这就好比你去吃自助餐，点了一桌子菜（100个更新），然后你不吃，只是把菜单一直叠在桌上，叠了三年。三年后，这堆菜单不仅占地方，上面的油渍（闭包变量）还弄脏了你的冰箱。

这就是内存泄漏。而在 React Fiber 架构中，React 必须保证这个环形链表最终是空的，或者至少不再包含那些“过时”的更新。

---

第四章：调度器——浏览器休息的时候

React 怎么解决这个问题的？它不能强行把更新“吃掉”然后假装没看见，那样状态就错了。

React 必须诚实地执行这些更新。但是，如果用户疯狂点击，React 如果真的每一毫秒都去处理更新，那页面肯定就崩了，变成“白屏怪兽”。

所以，React 引入了调度器。

当你调用 dispatchAction 时，你会看到那个 scheduleForNextTime。这个函数会告诉调度器：“嘿，我有个活，我需要在这个时间点（expirationTime）之前被处理。”

调度器是个聪明的家伙。它会问浏览器：“嘿，你现在忙吗？浏览器说：‘忙着呢，正在重绘背景呢。’ 调度器说：‘行，那我等会儿再来问你。’”

当浏览器终于空闲下来（空闲的时候就会触发 requestIdleCallback），调度器才会开始干活。

这时候，神奇的事情发生了。

React 开始从那个环形链表里“拉”更新出来。它拿到一个 Update，执行它的 action，计算出新的状态，生成新的 Fiber 节点，尝试渲染。

关键点来了：

如果渲染成功了，这个 Update 就被“消费”掉了。它的任务完成了。

但是，React 怎么知道这个更新已经完成了呢？

React 不能一直盯着链表看。它必须有一个机制，在渲染完之后，把已经处理过的节点从链表里剔除。

---

第五章：从链表里“拔”出垃圾

在 React 17 之前，这个问题比较棘手。你需要手动维护一个“已处理”的指针。但在 React 18 以及现代 Fiber 架构中，这个逻辑被封装在 createWorkInProgress 和 markUpdateQueueAsCompleted 等函数里。

为了让你看懂，我们手动模拟一下这个过程。

假设链表是：Pending -> A -> B -> C -> Pending。

现在，React 决定处理这些更新。它创建了一个工作单元 workInProgress。

1. 拉取：
   workInProgress.pendingQueue 开始指向链表。它从 Pending（第一个更新）开始。
   React 执行了 Pending 的 action。假设 Pending 是把 count 加 1。workInProgress 现在有了新的状态。

2. 提交：
   React 把 workInProgress 提交给了浏览器，浏览器显示了新的数字。此时，Pending 这个更新已经完成了它的使命。

3. 清理：
   这是最精彩的一步！React 需要把它从链表里摘下来。
   React 会遍历链表吗？不，那太慢了。React 会更新队列的指针。

   在源码中，你会看到类似这样的逻辑（伪代码）：

   function commitUpdate(workInProgress) {
       // 1. 获取队列
       const queue = workInProgress.memoizedState.queue;
   
       // 2. 标记队列为已完成
       // 这一步告诉 React：接下来从队列里拿出来的都是新活儿了，旧活儿别管了。
       queue.expirationTime = 0; // 或者更高级的标记，表示这是最高优先级的最新状态
   
       // 3. 重新组织链表
       // 我们把链表“切断”，只保留从 workInProgress 指针开始之后的内容。
       // 但因为它是环形的，所以我们不需要真的切断，只需要移动指针。
   
       // 假设 workInProgress 刚刚消费了链表里的第一个节点（Pending）
       // React 会把 queue.pending 指向 workInProgress.next
       // 而 workInProgress.next 会再次指向 workInProgress，形成新的环。
   
       // 这样，旧的那些“未处理”或者“已处理”的节点，就被甩在了队列之外，
       // 变成了不可达的垃圾对象，等待垃圾回收器（GC）来收尸。
   }

   这就是防止内存泄漏的核心！

   通过移动 queue.pending 指针，React 实际上是在“丢弃”旧的工作单元。每次渲染后，React 都会把链表“剪断”一截。

   这就好比你读一本书，读完一页，你就把这一页撕下来扔进垃圾桶，只读下一页。书永远不会因为读得太多而变得厚重无比。

---

第六章：深度源码剖析——DispatchAction 的完整表演

好了，铺垫了这么多，我们来看看真实的 React 源码是怎么写的。为了代码的可读性，我去除了一些宏定义和极其晦涩的类型转换，保留核心逻辑。

让我们聚焦在 ReactFiberHooks.js 中的 mountWorkInProgressHook 和 updateWorkInProgressHook，以及核心的 dispatchAction。

1. 队列的初始化

当你第一次 useState(0) 时，React 会执行 mountWorkInProgressHook。它会创建一个 updateQueue 对象。

function mountWorkInProgressHook() {
  const update = { queue: null, memoizedState: null, next: null };

  // 队列本身也是一个环形链表
  // 初始化时，pending 指向一个特殊的空节点或者自己
  const queue = { 
    pending: null, 
    baseState: null, 
    baseQueue: null, 
    interleaved: null, 
    lanes: 0, 
    dispatch: null,
    lastRenderedLane: 0,
    lastRenderedReducer: null,
    lastRenderedState: null
  };

  update.queue = queue;
  hook.queue = queue;

  return update;
}

2. 执行 DispatchAction（深潜）

现在，我们再看看 dispatchAction 的完整版本。这可是 React 的重头戏。

// 这里的函数名可能略有不同，但在源码中逻辑是相通的
function dispatchAction(fiber, queue, action) {
  // 这是一个非常经典的技巧：保留最新的 action。
  // 当 React 还没来得及处理这个更新时，如果又被新的更新打断，
  // 或者处于某种“并发”状态，React 需要知道最新的动作是什么。
  const update = {
    action: action,
    expirationTime: getCurrentTime(), // 获取当前时间戳作为优先级依据
    next: null,
    queue: queue,
    // 下面这两个是关键，用于快速定位
    lane: ... 
  };

  // === 核心逻辑：环形链表追加 ===
  if (queue.pending === null) {
    // 情况 A：空队列
    update.next = update;
    queue.pending = update;
  } else {
    // 情况 B：非空队列
    // 找到当前的最后一个节点
    const last = queue.pending;
    // 将最后一个节点的 next 指向新节点
    last.next = update;
    // 将新节点的 next 指向队首（形成环）
    update.next = queue.pending;
    // 更新队尾指针
    queue.pending = update;
  }

  // === 核心逻辑：调度 ===
  // 通知调度器：我要干活了！给我分配时间！
  scheduleUpdateOnFiber(fiber, update.expirationTime);
}

3. 处理更新（The Magic）

当调度器告诉 React 可以干活了，React 会进入 updateReducer。

function updateReducer(reducer, initialArg, lastArg) {
  // 1. 获取当前的 hook
  // ...

  // 2. 获取 pending 队列
  const pendingQueue = hook.queue;
  const pending = pendingQueue.pending;

  if (pending === null) {
      // 理论上不应该发生，除非没有人调用 dispatchAction
      return;
  }

  // === 这里是防止内存泄漏的关键步骤 ===
  // React 18 之前，这个逻辑比较复杂，涉及到 baseState 和 baseQueue 的合并。
  // 简单来说，React 会把 pending 链表里的所有节点取出来，按顺序执行 reducer。

  // 为了不造成内存泄漏，当 React 完成处理这些 pending 更新后，
  // 它必须把 pendingQueue.pending 指针移到下一个位置。
  // 这样，旧的处理过的节点就从 pending 链表里消失了。

  // 源码中的简化模拟：
  // 我们需要把 pending 链表“剪开”
  let first = pending.next;
  pendingQueue.pending = first;

  // 执行所有的 reducer
  let newState = pendingQueue.baseState;

  let update = first;
  do {
    // 执行 reducer(state, action)
    newState = reducer(newState, update.action);
    update = update.next;
  } while (update !== null);

  // 3. 恢复状态
  hook.memoizedState = newState;
}

等等，这里有个疑点！

我上面的代码把 pendingQueue.pending 指向了 first（原来的第二个节点）。
如果 first 是 null（只有一个节点），那么 pendingQueue.pending 就变成 null 了。
这就是结束！ 链表清空了！垃圾对象被释放了！

这就解释了为什么 React 不会内存泄漏：每次渲染周期结束时，React 都会清空 pending 队列，只保留“未处理”的更新。

---

第七章：并发模式下的内存管理

到了 React 18，事情变得更有趣了。引入了“并发模式”和“自动批处理”。

以前，你点击按钮，React 只能串行处理。现在，React 可以暂停当前的渲染，去处理高优先级的任务，回来后再继续。

这给内存管理带来了更大的挑战。如果我在处理高优先级任务时，又来了一个低优先级的更新怎么办？

React 使用了 Lane（车道） 机制。

dispatchAction 中的 update 对象不仅仅包含 action 和 expirationTime，还包含一个 lane（车道 ID）。

const update = {
  action: action,
  lane: ..., // 比如 lane = 1 (高优先级), lane = 2 (低优先级)
  expirationTime: ...,
  next: null,
  queue: queue
};

环形链表现在变成了一个复杂的混合体，但它依然是基于链表的。React 会在 updateReducer 中遍历链表时，使用 getHighestPriorityLane 等函数来决定先处理谁。

内存管理在这里的体现：

即使 React 处于并发状态，它的清理机制依然是强大的。React 会在 Fiber 节点的工作循环中，不断地检查哪些更新已经处理完了，然后通过修改 queue.pending 指针的方式，把不再需要的更新从待处理列表中剔除。

这就像是在一个繁忙的十字路口，红绿灯（调度器）不断地指挥车辆（更新）通过。当一辆车（更新）通过了路口，它就会被清理出当前的车流（链表）。

---

第八章：实战演练——如何防止你的 React 应用爆炸？

理论讲得再多，不如写代码来得实在。作为一个资深开发者，当你看到 useState 导致内存泄漏时，你应该怎么做？

1. 避免在闭包中保存大量状态：
   这是导致内存泄漏的头号杀手。

   // 危险！
   function BadComponent() {
     const [data, setData] = useState(bigObject); // 假设这是一个 10MB 的对象
   
     const handleClick = () => {
       // 如果你不解构 setData，或者不把 setData 传进去
       // 这里的闭包会一直保存 data
       // 即使组件卸载，因为 handleClick 还在某个地方被引用（比如事件监听器），data 也不会被释放！
       setTimeout(() => {
          console.log(data); // 这里引用了闭包
       }, 10000);
     }
   
     return <button onClick={handleClick}>Click</button>
   }

   修正方案：
   使用 function 组件的形式，或者在闭包里使用 useCallback，确保回调函数能获取最新的状态，而不是旧的。

2. 理解 queue.pending 的清理时机：
   不要试图手动去清理 React 的状态队列。React 的调度器已经帮你做过了。如果你发现内存占用过高，通常是因为你的 reducer 函数本身太重，或者你在 useEffect 里创建了无限循环，导致 dispatchAction 被疯狂调用，而 React 的调度器因为某些原因（比如正在处理更高优先级的任务）暂时无法清理这些队列。

3. 使用 Profiler：
   如果你怀疑有内存泄漏，打开 React DevTools 的 Profiler。点击一次按钮，然后看看内存占用曲线。如果曲线没有随着组件卸载而下降，那就是泄漏。

---

第九章：总结与展望

好了，各位，我们的讲座也接近尾声了。

我们今天从 dispatchAction 入手，深入到了 React 那看不见的内部世界。

我们看到了：

1. 环形链表：为什么 React 不用数组？因为链表的指针移动（O(1)）比数组的索引追踪更高效、更纯粹。
2. 内存管理：为什么不会泄漏？因为 React 有一套精密的调度机制。每当渲染完成，它就会像切香肠一样，切断链表，剔除已完成的节点，把垃圾交给 GC。
3. 并发模式：这不仅仅是快，更是为了在多任务环境下，依然能保持内存的整洁和高效。

React 的作者们就像是舞台导演，而 dispatchAction 和那个环形链表就是他们手中的道具。这些道具设计得极其巧妙，既满足了“快”的需求，又照顾了“稳”的需求。

记住，作为一名前端工程师，理解这些底层逻辑，不是为了让你去手写一个 React，而是为了让你在遇到 Uncaught Error: Maximum update depth exceeded 或者 Memory leak 这种鬼东西时，能一眼看穿它的本质。

当你下次再点击那个按钮，看着状态数字欢快跳动的时候，希望你能想起这个环形的、流转的、永远在奔跑的链表。

谢谢大家！下课！