React 内存碎片整理与 Fiber 节点回收

各位同学，大家好！

欢迎来到今天的“React 深度解剖室”。我是你们的主讲人，一个在代码堆里摸爬滚打多年，头发比 React Hooks 稳定性还要差的资深架构师。

今天我们要聊的话题有点硬核，有点“烧脑”，甚至有点“费内存”。我们不讲 useEffect 的依赖数组陷阱，也不讲 Context 传递地狱，我们要聊的是 React 的底层呼吸机制——内存碎片整理与 Fiber 节点回收。

听起来是不是有点像在说装修房子？别急，我们先把 React 想象成一个巨大的、极其复杂的乐高城堡建造现场。当你添加一个组件，它就搭一块砖；当你删除一个组件，它就拆一块砖。但是，如果你拆得太快，或者搭得太乱，这个城堡的“内存空间”就会变得像早高峰的地铁一样拥挤。

那么，React 是如何在这个拥挤的地铁里，优雅地穿梭，确保老组件“死得透透的”，新组件“活得蹦蹦跳跳”的呢？这就是我们今天要讲的故事。

---

第一章：Fiber 架构——React 的骨架与神经系统

在深入内存之前，我们得先搞清楚 Fiber 是个啥。很多同学背过 Fiber 的定义：“Fiber 是 React 的内部调度单元，它是一个链表结构。” 好的，背得很熟。但如果只背定义，那你就是只会背字典的哑巴。

想象一下，React 以前的渲染机制（React 15 时代）就像是一个只会做加法的笨重巨人。你让他渲染一个列表，他必须把整个列表从头算到尾，算完了再画在屏幕上。如果列表有 10,000 个元素，那这巨人就得憋气憋 10 秒钟，屏幕会卡顿 10 秒钟，用户体验极其糟糕。

为了解决这个问题，React 16 引入了 Fiber。Fiber 本质上是一个 JavaScript 对象，它就像是巨人身体里的一根根“神经纤维”。

每个 Fiber 节点都长得像这样（为了方便理解，我简化了代码）：

interface FiberNode {
  // 身份证号：唯一标识这个节点
  memoizedProps: any; 
  memoizedState: any;

  // 亲戚关系：这是 React 树（DOM 树）的链表结构
  // child: 第一个孩子
  // sibling: 下一个兄弟
  // return: 父亲（指向回去的路）
  child: FiberNode | null;
  sibling: FiberNode | null;
  return: FiberNode | null;

  // 状态标记：这是它现在的状态
  tag: number; // FunctionComponent, ClassComponent, HostComponent...
  flags: number; // Placement, Update, Deletion...

  // 重要：双缓冲技术
  // current: 当前屏幕上显示的树
  // alternate: 正在计算中的树（下一帧的树）
  alternate: FiberNode | null;
}

你可以把 child, sibling, return 理解成 React 渲染树的一条链子。React 通过修改这些指针，来决定是“新增节点”、“更新节点”还是“删除节点”。

但是，这跟内存回收有什么关系？

关系大了去了！每一次 React 的渲染，本质上都是在创建新的 Fiber 节点，或者修改旧的 Fiber 节点。如果你的页面一直渲染，这些 Fiber 节点就会像垃圾一样堆积。如果 React 不能及时清理这些不再使用的节点，内存就会爆表。

---

第二章：垃圾回收的“幽灵”——React 16 的烦恼

在 React 16 之前，内存管理主要依赖浏览器的垃圾回收器（GC）。浏览器里的 V8 引擎是个很勤快的清洁工，它遵循“标记-清除”算法。当你把一个变量赋值为 null，或者组件卸载了，V8 就会标记这些内存为“可回收”，并在后台找个空闲时间把它们擦掉。

但是，React 16 引入的并发模式和 Fiber 架构，给 V8 引擎出了一道难题。

React 16 为了实现“时间切片”，它会中断当前的渲染任务，去处理高优先级的任务（比如用户点击了“提交”按钮）。这就意味着，在渲染过程中，React 可能会创建大量的中间状态。

举个栗子，你有一个父组件 App，里面有个 List，List 里有 100 个 Item。

1. React 开始渲染 App，创建 App 的 Fiber 节点。
2. React 发现 App 下面有个 List，创建 List 的 Fiber 节点。
3. React 开始遍历 List，创建 100 个 Item 的 Fiber 节点。
4. 咔嚓！ 突然，用户点击了“刷新”按钮（这是一个高优先级任务）。
5. React 停止当前的渲染，把正在构建的那棵树（workInProgress 树）扔一边。
6. React 开始处理“刷新”任务。
7. 关键点来了！ 当“刷新”任务完成后，React 需要重新开始渲染。这时候，之前那 100 个 Item 的 Fiber 节点怎么办？

在 React 16 的早期版本中，这些节点并没有被立即回收。它们被保留在内存里，等待着下一次渲染被复用。这就导致了一个现象：随着页面使用时间的增加，内存占用会像心电图一样波动，而不是一条直线。

为什么？因为 React 试图“复用”节点。它认为：“嘿，这 100 个 Item 我刚创建过，属性好像也没变，是不是直接拿来用就行？”

这种策略叫 Fiber 节点复用。它确实提高了性能，减少了 GC 的压力。但是，如果复用策略失效了呢？或者组件被卸载了怎么办？

---

第三章：Fiber 节点回收的艺术——当“复用”变成“清理”

这是 React 18 乃至更深层级最核心的技术。React 18 引入了自动批处理和更精细的调度，但这还不够。真正的“回收”发生在 Commit 阶段。

当 React 确定某个组件需要被卸载（比如你从详情页返回了列表页），它并不会直接把这个 Fiber 节点变成垃圾。相反，它会执行一套复杂的“告别仪式”。

1. 标记删除

首先，React 会在 Fiber 树上打上一个标记。比如 flags 字段里的 Placement | Deletion。这就像是给这个节点发了一张“退房通知单”。

2. 执行卸载副作用

这是最关键的一步。React 会调用组件的 componentWillUnmount 生命周期（或者 useEffect 的清理函数）。

class MyComponent extends React.Component {
  componentWillUnmount() {
    console.log('我要走了，记得把我的房间打扫干净！');
    // 这里是清理事件监听器、清除定时器、取消网络请求的好地方
    this.timer = null; 
    window.removeEventListener('resize', this.handleResize);
  }

  // ... 其他代码
}

为什么要强调这一点？ 很多新手在这里会犯大错！如果你在 componentWillUnmount 里没有清理事件监听器，或者没有取消订阅，这些引用就会一直挂在 Fiber 节点上。而 Fiber 节点此时还没被回收，所以这些引用也就跟着“赖着不走”。

3. 清理状态与属性

React 会把 Fiber 节点上的 memoizedProps 和 memoizedState 重置为 null。这就像是把桌上的文件扫进垃圾桶，把椅子翻过来。

// React 内部伪代码
function resetFiberNode(fiber: FiberNode) {
  fiber.memoizedProps = null;
  fiber.memoizedState = null;
  fiber.updateQueue = null;
  // ... 重置其他属性
}

4. 双缓冲机制下的回收

React 18 依然依赖 current 和 alternate 两个指针。

• current 指针指向当前渲染在屏幕上的那棵树。
• alternate 指针指向正在构建的那棵树（下一帧）。

当组件卸载时，React 会把 current 指针指向 alternate，把 alternate 指向 current（或者直接销毁旧的 current）。这就完成了 Fiber 树的切换。

在这个过程中，旧的 current 树中的 Fiber 节点就失去了引用。此时，如果 V8 的垃圾回收器（GC）启动了，这些节点就会被回收。

---

第四章：内存碎片整理——不仅仅是“删”

你可能会问：“React 把节点设为 null，V8 就能回收吗？”

别天真了！内存回收不仅仅是“删除对象”。它还涉及内存碎片整理。

想象一下你的内存是一个抽屉。

1. React 创建了 100 个 Fiber 节点，占据了抽屉的前 100 个格子。
2. React 删除了 50 个节点，但这 50 个格子依然是满的。
3. React 又创建了 50 个新节点，占据了新的格子。

这时候，抽屉里虽然只有 100 个节点，但是格子乱七八糟，中间有空隙，两边是满的。这就是内存碎片。

React 是如何缓解这个问题的？

A. 对象池

在 React 的源码深处，其实并没有一个全局的“Fiber 节点池”供所有组件共用。但是，React 会利用 GC 的分代回收机制。

V8 引擎通常会将堆分为“新生代”和“老生代”。

• 大部分 React 的 Fiber 节点生命周期都很短（从创建到卸载，可能只有几毫秒到几秒）。
• 这些节点会被频繁地创建和销毁，它们主要集中在新生代。
• 新生代通常使用“复制算法”，也就是把存活的对象复制到另一块区域。这个过程天然就带有整理内存碎片的功能！

所以，React 的高频创建和销毁，其实是在帮 V8 引擎维持新生代的整洁。只要你能保证组件卸载及时，V8 就能快速地把这些碎片清理掉。

B. 避免闭包陷阱

这是开发者最容易造成内存碎片的地方，而不是 React 本身。

请看这个经典的反模式：

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

  // 危险！这个函数被记住了！
  const handleClick = () => {
    console.log(count);
  };

  useEffect(() => {
    // 即使组件卸载了，这个闭包里的 handleClick 依然持有 count 的引用！
    // 而且，如果这里把 handleClick 赋值给 DOM 事件，那这个闭包就永远不会释放。
    document.addEventListener('click', handleClick);
  }, []); // 依赖数组是空的，以为不会变？大错特错！

  return <button onClick={handleClick}>Click me</button>;
}

在这个例子中，handleClick 闭包捕获了 count。如果组件卸载了，但 DOM 事件还在监听，这个闭包就会一直占用内存，导致 count 的值被“卡”在内存里，无法被 GC 回收。这就是典型的内存泄漏，也是导致内存碎片堆积的元凶。

React 的解决方案：
React 18 引入了 flushSync 和 startTransition，目的是为了控制渲染的时机。虽然它们不直接清理内存，但它们通过减少不必要的重新渲染，减少了 Fiber 节点的创建数量，从而间接减少了内存碎片的产生。

---

第五章：实战演练——如何让你的 React 应用“断舍离”

理论讲多了容易犯困。现在，我们用代码来实战一下。假设我们要构建一个高性能的无限滚动列表组件。

这个组件是内存杀手的重灾区。为什么？因为它一直在创建 DOM 节点，也一直在创建 Fiber 节点。

场景：一个“吃内存”的列表组件

import React, { useState, useEffect, useRef } from 'react';

// 模拟一个重型组件
const HeavyItem = ({ id, data }) => {
  // 假设这个组件有一个巨大的定时器，或者一个巨大的对象
  const hugeObject = new Array(10000).fill('data');

  // 如果我们不清理，这个 hugeObject 会一直存在
  const timerRef = useRef(null);

  useEffect(() => {
    console.log(`Item ${id} mounted`);
    // 启动定时器
    timerRef.current = setInterval(() => {
      console.log(`Item ${id} is alive`);
    }, 1000);

    // 返回清理函数，这是回收的关键！
    return () => {
      console.log(`Item ${id} unmounting...`);
      clearInterval(timerRef.current);
      timerRef.current = null;
      // hugeObject 会被 GC 回收，因为组件已经卸载，没人引用它了
    };
  }, [id]);

  return (
    <div style={{ border: '1px solid #ccc', padding: '10px', margin: '10px' }}>
      <h3>Item {id}</h3>
      <p>Data: {data}</p>
    </div>
  );
};

export const MemoryHog = () => {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);
  const [loading, setLoading] = useState(false);

  const loadMore = () => {
    setLoading(true);
    // 模拟网络请求，加载 20 个新数据
    setTimeout(() => {
      const newItems = Array.from({ length: 20 }, (_, i) => ({
        id: (page - 1) * 20 + i,
        data: `Data ${i}`,
      }));
      setItems((prev) => [...prev, ...newItems]);
      setPage((prev) => prev + 1);
      setLoading(false);
    }, 1000);
  };

  // 模拟滚动到底部加载更多
  useEffect(() => {
    const handleScroll = () => {
      if (window.innerHeight + document.documentElement.scrollTop !== document.documentElement.offsetHeight) return;
      if (loading) return;
      loadMore();
    };

    window.addEventListener('scroll', handleScroll);

    return () => {
      // 1. 移除事件监听！这是防止内存泄漏的第一步。
      window.removeEventListener('scroll', handleScroll);
      // 2. 组件卸载时，React 会自动调用所有子组件的 cleanup 函数。
      //    HeavyItem 的 useEffect return 会被执行。
      console.log("MemoryHog unmounted. All resources should be freed.");
    };
  }, [loading]);

  return (
    <div>
      {items.map((item) => (
        <HeavyItem key={item.id} {...item} />
      ))}
      {loading && <div>Loading more ghosts...</div>}
    </div>
  );
};

这段代码里藏着什么玄机？

1. useRef 的妙用：我们用 timerRef 来持有定时器 ID。为什么不用 useState？因为 useState 会触发重新渲染。用 ref，只有在组件卸载时我们才关心它，这样不会干扰渲染循环。
2. 清理函数：注意 HeavyItem 里的 useEffect。当这个组件被 React 从 Fiber 树中移除（alternate 指针不再指向它，或者被标记为 Deletion）时，React 会执行这个清理函数。它拔掉了定时器的插头，把内存交还给了 V8。
3. 事件监听器：在 MemoryHog 的 useEffect 返回值里，我们移除了 scroll 监听器。如果不移除，即使 MemoryHog 卸载了，浏览器依然会每隔几毫秒调用一次 handleScroll，而这个函数里可能还引用了 items 状态。这会导致 items 即使在组件卸载后依然无法被 GC。

---

第六章：React 18 的“自动批处理”与内存

React 18 带来了一个很酷的功能叫 Automatic Batching（自动批处理）。

在以前，如果你在 useEffect 里调用了两个 setState，它们会被合并成一个渲染周期，性能很好。

但在事件处理函数（比如 onClick）里，React 以前会把它们拆分成多次渲染。

// 以前
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => f + true); // 这里会触发一次单独的渲染！
  // 这意味着 DOM 操作次数增加了，Fiber 节点的创建和销毁次数也增加了。
  // 内存压力变大。
}

// 现在 (React 18)
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => f + true); // 自动批处理，只渲染一次！
  // Fiber 树只需要构建一次，内存占用更平滑。
}

这对内存回收意味着什么？
它意味着 React 不需要在短时间内疯狂地创建和销毁 Fiber 节点。这极大地降低了 GC 的压力。你可以把它想象成：以前你是一笔一笔地写作业，写完一张纸扔一张；现在你是一张一张地写，写完一摞纸再扔一摞。虽然总量没变，但中间过程的混乱程度（内存碎片）大大降低了。

---

第七章：React 团队是如何“作弊”的？

作为资深专家，我必须告诉你们一些 React 源码里的“作弊”手段。React 并不是真的把每个节点都存起来等 GC 来捡。React 有自己的策略。

1. Fiber 节点复用池

在 React 源码的 ReactFiber.new.js 文件中，你会看到大量的 createFiber 调用。React 并不是每次都 new FiberNode()。它会在内部维护一个“空闲节点池”。

当组件卸载时，React 会把这个 Fiber 节点放回池子里，而不是直接销毁它。

// React 源码极简模拟
const pool: Array<FiberNode> = [];

function recycleFiberNode(node: FiberNode) {
  // 重置所有属性
  node.memoizedProps = null;
  node.memoizedState = null;
  node.return = null;
  node.child = null;
  node.sibling = null;
  node.index = 0;
  node.ref = null;

  // 放回池子
  pool.push(node);
}

function createFiberNode() {
  if (pool.length > 0) {
    return pool.pop()!; // 从池子里拿一个
  }
  return new FiberNode(); // 没了就新建
}

这招高明在哪里？
它避免了频繁的内存分配和垃圾回收。虽然这不能完全消除内存碎片，但它能保证内存分配的连续性。这就像是你装修房子，你不会把拆下来的砖头全扔到垃圾场，而是把它们堆在院子里，下次装修直接拿来用。

2. 状态持久化

React 还有一个特性，叫做 state 持久化（在 Concurrent Mode 下）。如果你在组件卸载时修改了 state，React 会抛出警告。

这是为了防止开发者犯傻。如果你在 useEffect 里修改 state，而这个组件被卸载了，那这个 state 的更新就没人接收了，但 React 为了保持一致性，必须把这个更新“处理”完。这会导致额外的内存开销。

所以，React 通过限制这种行为，间接地帮你管理了内存。

---

第八章：深度剖析——React 如何处理“Fiber 树的切换”

最后，我们来看看 React 是如何处理 Fiber 树切换的。这是内存回收中最复杂的部分。

想象一下，React 正在渲染一棵树，突然用户切换了路由，或者父组件卸载了。

1. 标记删除：React 会遍历当前树，把所有需要卸载的子树的根节点标记为 Deletion。
2. 遍历删除：React 会开始遍历这些标记的节点。对于每一个节点，它都会调用 unmountComponentAtNode。
3. 执行清理：如前所述，它会调用 componentWillUnmount。
4. 断开连接：React 会切断 return 指针，切断 child 和 sibling 指针。这就像是把断肢从身体上切下来。
5. 回收：此时，这棵旧的树已经没有任何指针指向它了。V8 引擎的 GC 就可以放心地回收这些节点了。

但是，React 还有一个“杀手锏”——React.memo。

如果你把一个组件用 React.memo 包裹，React 会比较新旧 props。如果 props 没变，React 就不会重新创建这个 Fiber 节点，而是复用旧的。

const MemoizedItem = React.memo(function HeavyItem({ id, data }) {
  console.log('Rendering Item', id);
  // ... 复杂逻辑
});

这看起来是好事，对吧？
坏事！
如果你在 HeavyItem 里使用了 useState 或 useRef，并且这些状态在组件卸载后依然被某些闭包引用，那么 React.memo 会阻止你清理这些状态，因为你“复用”了节点，而不是“销毁”了节点。

结论： React.memo 是一把双刃剑。它能提升性能，但如果不小心，它就是内存泄漏的温床。

---

第九章：调试与监控——如何发现你的 React 在“吃内存”

光说不练假把式。作为专家，我教大家几招如何用 Chrome 开发者工具来诊断 React 的内存问题。

1. Performance 面板

打开 Chrome DevTools，进入 Performance 面板。勾选 Memory。
录制你的操作（比如在列表页来回滚动）。
停止录制后，查看内存堆快照。

• 红点：代表未释放的对象。
• Search by object ID：如果你发现某个组件的实例数量在不断增加，你可以搜索它的类名，看看有没有“僵尸”实例。

2. 查看堆快照中的 Retainers（保留者）

这是最强大的功能。当你发现某个对象没有被释放时，点击它，查看 Retainers。

你会看到一条链路：
Window -> MyComponent -> handleClick -> count。

这就告诉你：“你的组件虽然卸载了，但你的事件监听器还抓着它的手不松开，导致它的 count 状态没法被 GC 回收！”

找到这个链路，把事件监听器移到 useEffect 的清理函数里，问题就解决了。

---

第十章：终极指南——写出“内存友好”的 React 代码

好了，理论讲完了，我们来总结一下，如何写出那种“优雅、干净、不占内存”的 React 代码。

1. 永远、永远、永远要在 useEffect 的清理函数里清理东西！

   • 定时器？clearInterval。
   • 订阅？unsubscribe。
   • 事件监听器？removeEventListener。
   • 全局变量引用？设为 null。

2. 警惕闭包。

   • 尽量不要在事件处理函数里直接引用 useState 的值。虽然 React 18 帮你做了很多批处理，但在极端情况下，闭包依然是内存泄漏的源头。

3. 合理使用 React.memo。

   • 不要滥用。如果你组件内部使用了 useState，React.memo 可能会害了你。只有当你的组件 props 变化极不频繁，且计算成本极高时，才考虑使用。

4. 理解 Fiber 的生命周期。

   • 想象每一个组件都是一个生命。useEffect 是它的墓志铭。你要确保墓志铭里写的是“清理完毕”，而不是“未清理”。

5. 利用 V8 的特性。

   • 不要担心小对象的频繁创建。V8 处理新生代对象非常快。真正需要担心的是大对象的堆积和循环引用。

---

结语：再见，内存碎片

React 的 Fiber 架构，不仅仅是为了让页面不卡顿，它更是为了解决 JavaScript 在处理复杂 UI 时的内存管理难题。

通过双缓冲机制、节点复用池、以及精细的卸载流程，React 建立了一套严密的内存回收体系。作为开发者，我们不需要知道 React 内部是如何回收 Fiber 节点的（除非你想做 React 源码贡献），但我们需要知道如何配合它。

当我们写下的代码能正确地清理副作用，当我们理解了闭包的陷阱，当我们不再盲目地使用 React.memo，我们就成为了内存管理的大师。

记住，最好的内存优化，是写出可预测的代码。让 React 能在合适的时间，把不需要的节点干净利落地送进垃圾回收器的怀抱。

好了，今天的讲座就到这里。希望大家回去后，都能检查一下自己的 useEffect，看看有没有哪个“幽灵”还赖在你的内存里不走。

下课！