Sneaky React Memory Leaks: How `useCallback` and closures can bite you

October 18, 2024

原文：https://www.schiener.io/2024-03-03/react-closures
原文包含一节关于闭包的简要回顾，为保持简略此处没有保留。

闭包与 React

在 React 中，我们重度依赖闭包来实现所有函数组件、hooks 和事件处理程序。
每当创建一个新函数，需要访问组件作用域内的变量（如状态或属性）时，实际上就是在创建闭包。

以下是一个示例：

jsx

import { useState, useEffect } from "react";

function App({ id }) {
    const [count, setCount] = useState(0);

    const handleClick = () => {
        setCount(count + 1); // 这是一个对 count 变量的闭包
    };

    useEffect(() => {
        console.log(id); // 这是一个对 id 属性的闭包
    }, [id]);

    return (
        <div>
            <p>{count}</p>
            <button onClick={handleClick}>Increment</button>
        </div>
    );
}

在大多数情况下，这本身并不是问题。在上面的例子中，每次 App 渲染时都会重新创建闭包，旧的闭包会被垃圾回收。
这可能意味着一些不必要的分配和释放操作，但这些操作通常都非常快。

然而，当我们的应用程序变得庞大，并开始使用 useMemo 和 useCallback 等记忆化技术来避免不必要的重新渲染时，就需要格外注意了。

闭包与 `useCallback`

使用记忆化 hooks，我们以增加内存使用量为代价来换取更好的渲染性能。只要依赖项没有改变，useCallback 就会一直持有对函数的引用。让我们来看一个例子：

tsx

import React, { useState, useCallback } from "react";

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

    const handleEvent = useCallback(() => {
        setCount(count + 1);
    }, [count]);

    return (
        <div>
            <p>{count}</p>
            <ExpensiveChildComponent onMyEvent={handleEvent} />
        </div>
    );
}

在这个例子中，我们希望避免 ExpensiveChildComponent 的重新渲染。我们可以尝试保持 handleEvent() 函数引用的稳定性来实现这一点。
我们使用 useCallback 记忆 handleEvent()，以便仅在 count 状态发生变化时才重新分配新值。
然后，我们可以将 ExpensiveChildComponent 包裹在 React.memo() 中，以避免在父组件 App 渲染时重新渲染。
到目前为止，一切顺利。

但是，让我们稍微修改一下这个例子：

tsx

import { useState, useCallback } from "react";

class BigObject {
    public readonly data = new Uint8Array(1024 * 1024 * 10); // 10MB 的数据
}

function App() {
    const [count, setCount] = useState(0);
    const bigData = new BigObject();

    const handleEvent = useCallback(() => {
        setCount(count + 1);
    }, [count]);

    const handleClick = () => {
        console.log(bigData.data.length);
    };

    return (
        <div>
            <button onClick={handleClick} />
            <ExpensiveChildComponent2 onMyEvent={handleEvent} />
        </div>
    );
}

你能猜到会发生什么吗？

由于 handleEvent() 创建了一个对 count 变量的闭包，它将持有对组件上下文对象的引用。
而且，即使我们从未在 handleEvent() 函数中访问 bigData，handleEvent() 仍然会通过组件的上下文对象持有对 bigData 的引用。

所有闭包都共享一个从创建时就存在的共同上下文对象。由于 handleClick() 闭包捕获了 bigData，因此 bigData 将被此上下文对象引用。
这意味着，只要 handleEvent() 被引用，bigData 就永远不会被垃圾回收。这个引用将一直保持到 count 发生变化并且 handleEvent() 被重新创建。

捕获大型对象

译注：组件上下文对象简单来说就是 React Fiber 对象
读者可参考 useCallback 相关源码和 React Fiber 类源码

`useCallback` + 闭包 + 大型对象的无限内存泄漏

让我们看最后一个例子，它将上述所有内容发挥到了极致。这个例子是我在我们的应用程序中遇到的一个简化版本。
因此，尽管这个例子可能看起来有些刻意，但它很好地展示了普遍存在的问题。

jsx

import { useState, useCallback } from 'react';

class BigObject {
  public readonly data = new Uint8Array(1024 * 1024 * 10);
}

export const App = () => {
  const [countA, setCountA] = useState(0);
  const [countB, setCountB] = useState(0);
  const bigData = new BigObject(); // 10MB 的数据

  const handleClickA = useCallback(() => {
    setCountA(countA + 1);
  }, [countA]);

  const handleClickB = useCallback(() => {
    setCountB(countB + 1);
  }, [countB]);

  // 这段代码仅仅是为了演示问题
  const handleClickBoth = () => {
    handleClickA();
    handleClickB();
    console.log(bigData.data.length);
  };

  return (
    <div>
      <button onClick={handleClickA}>Increment A</button>
      <button onClick={handleClickB}>Increment B</button>
      <button onClick={handleClickBoth}>Increment Both</button>
      <p>
        A: {countA}, B: {countB}
      </p>
    </div>
  );
};

在这个例子中，我们有两个记忆化的事件处理程序 handleClickA() 和 handleClickB()。
我们还有一个函数 handleClickBoth()，它调用这两个事件处理程序并记录 bigData 的长度。

你能猜到当我们交替点击“Increment A”和“Increment B”按钮时会发生什么吗？

让我们来看看在 Chrome 开发者工具中，点击每个按钮 5 次后的内存使用情况：

BigObject 泄漏

看起来 bigData 从未被垃圾回收。每次点击都会导致内存使用量持续增长。
在我们的例子中，应用程序持有对 11 个 BigObject 实例的引用，每个实例大小为 10MB。
一个用于初始渲染，其余的每次点击都会创建一个。

保留树为我们提供了一些线索。看起来我们正在创建一个不断重复的引用链。让我们一步一步地分析它。

0. 首次渲染：

当 App 首次渲染时，它会创建一个闭包作用域，该作用域持有对所有变量的引用，因为我们在至少一个闭包中使用了所有这些变量。
这包括 bigData、handleClickA() 和 handleClickB()。我们在 handleClickBoth() 中引用了它们。我们将这个闭包作用域称为 AppScope#0。

闭包链 0

1. 点击“Increment A”：

第一次点击“Increment A”会导致 handleClickA() 被重新创建，因为我们改变了 countA - 我们将新的闭包称为 handleClickA()#1。
handleClickB()#0 不会被重新创建，因为 countB 没有改变。
然而，这意味着 handleClickB()#0 仍然会持有对先前 AppScope#0 的引用。
新的 handleClickA()#1 将持有对 AppScope#1 的引用，AppScope#1 又持有对 handleClickB()#0 的引用。

闭包链 1

2. 点击“Increment B”：

第一次点击“Increment B”会导致 handleClickB() 被重新创建，因为我们改变了 countB，从而创建了 handleClickB()#1。
React 不会重新创建 handleClickA()，因为 countA 没有改变。
handleClickB()#1 将持有对 AppScope#2 的引用，AppScope#2 持有对 handleClickA()#1 的引用，handleClickA()#1 持有对 AppScope#1 的引用，AppScope#1 持有对 handleClickB()#0 的引用。

闭包链 2

3. 第二次点击“Increment A”：

以此类推，我们可以创建一个无休止的闭包链，它们相互引用并且永远不会被垃圾回收，同时还拖着一个独立的 10MB bigData 对象，因为它在每次渲染时都会被重新创建。

闭包链

问题的本质

问题的本质在于，单个组件中的不同 useCallback hooks 可能会通过闭包作用域相互引用，以及引用其它占用大量内存的数据。
然后，这些闭包会一直保存在内存中，直到 useCallback hooks 被重新创建。
在一个组件中拥有多个 useCallback hook 会使得我们很难推断出哪些内容被保存在内存中，以及何时会被释放。
拥有的回调越多，就越有可能遇到这个问题。

你是否会遇到这个问题？

以下是一些让你更容易遇到这个问题的因素：

你有一些很少被重新创建的大型组件，例如，你将很多状态提升到应用程序外壳组件中。

译注：组件存活时间越长，就越有时间从其它闭包中捕获各种变量（比如一些需要在组件树中提升的状态）。这通常是组件树顶端的问题。
你依赖 useCallback 来最小化重新渲染。
你从记忆化的函数中调用其它函数。
你处理大型对象，例如图像数据或大型数组。

如果你不需要处理任何大型对象，那么引用几个额外的字符串或数字可能不是问题。
大多数情况下，这些闭包交叉引用会在足够多的属性发生变化后被清除。
只是要注意，你的应用程序占用的内存可能会比你预期的要多。

如何避免闭包和 `useCallback` 导致的内存泄漏？

以下是我可以提供的一些避免此问题的技巧：

技巧 1：尽可能缩小闭包作用域。

JavaScript 中难以发现所有被捕获的变量。避免持有过多变量的最佳方法是减少闭包周围的函数大小。这意味着：

编写更小的组件。这将减少创建新闭包时作用域内的变量数量。
编写自定义 hooks。因为这样任何回调都只能捕获 hook 函数作用域内的变量。这通常只意味着函数参数。

技巧 2：避免捕获其它闭包，尤其是记忆化的闭包。

尽管这看起来很明显，但 React 很容易让人掉入这个陷阱。如果你编写了相互调用的较小函数，那么一旦你添加了第一个 useCallback，组件作用域内的所有被调用函数都会发生连锁反应，从而被记忆化。

技巧 3：在没有必要的情况下避免记忆化。

useCallback 和 useMemo 是避免不必要重新渲染的好工具，但它们是有代价的。只有当你注意到由于渲染而导致性能问题时才使用它们。

技巧 4（紧急出口）：对大型对象使用 useRef。

这可能意味着你需要自己处理对象的声明周期并正确地清理它。这不是最佳选择，但总比内存泄漏要好。

结论

闭包是 React 中一种常用的模式，它们允许我们的函数记住组件上次渲染时作用域内的属性和状态。
当与 useCallback 等记忆化技术结合使用时，这可能会导致意外的内存泄漏，尤其是在处理大型对象时。
为了避免这些内存泄漏，请尽可能缩小闭包作用域，在非必要情况下避免使用记忆化，并可以考虑对大型对象使用 useRef。

Big thanks to David Glasser for his 2013 article A surprising JavaScript memory leak found at Meteor that pointed me in the right direction.

Feedback?

Do you think I missed something or got something wrong? Maybe you have a better solution to the problem or never encountered it in the first place.

If you have any questions or comments, please feel free to reach out to me on LinkedIn or X/Twitter.

Happy debugging!

Follow-up article for React Query users: Sneaky React Memory Leaks II: Closures Vs. React Query.
Interested how the React compiler will handle this?: Sneaky React Memory Leaks: How the React compiler won't save you.

←Back to home

This work is licensed under CC BY-NC-SA 4.0