Electron 和 V8 内存笼
Electron 21 及更高版本将启用 V8 内存笼，这对某些原生模块有影响。
要跟踪关于 Electron 21+ 中原生模块使用的持续讨论，请参阅 electron/electron#35801。
在 Electron 21 中，我们将启用 Electron 中的 V8 沙盒指针，继 Chrome 在 Chrome 103 中做出同样的决定之后。这对原生模块有一些影响。此外，我们之前在 Electron 14 中启用了一项相关技术，指针压缩。我们当时没有过多谈论它，但指针压缩对最大 V8 堆大小有影响。
当启用这两项技术时，对安全性、性能和内存使用都有显著的好处。然而，启用它们也有一些缺点。
启用沙盒指针的主要缺点是不再允许指向外部 (“堆外”) 内存的 ArrayBuffer。这意味着依赖 V8 中此功能的原生模块需要重构才能继续在 Electron 20 及更高版本中工作。
启用指针压缩的主要缺点是V8 堆的最大大小限制为 4GB。这方面的确切细节有点复杂，例如，ArrayBuffer 与 V8 堆的其余部分分开计数，但有其自己的限制。
Electron 升级工作组认为，指针压缩和 V8 内存笼的好处大于缺点。这样做的主要原因有三个
- 它使 Electron 更接近 Chromium。Electron 在诸如 V8 配置之类的复杂内部细节中与 Chromium 的差异越小，我们意外引入错误或安全漏洞的可能性就越小。Chromium 的安全团队非常强大，我们希望确保我们正在利用他们的工作。此外，如果某个错误仅影响 Chromium 中未使用的配置，那么修复该错误不太可能是 Chromium 团队的优先事项。
- 它的性能更好。指针压缩将 V8 堆大小减少高达 40%，并将 CPU 和 GC 性能提高 5%–10%。对于绝大多数不会遇到 4GB 堆大小限制且不使用需要外部缓冲区的原生模块的 Electron 应用程序来说，这些是显著的性能提升。
- 它更安全。某些 Electron 应用程序运行不受信任的 JavaScript（希望遵循我们的安全建议！），对于这些应用程序，启用 V8 内存笼可以保护它们免受大量有害的 V8 漏洞的侵害。
最后，对于确实需要更大堆大小的应用程序，有一些解决方法。例如，可以在应用程序中包含一个禁用了指针压缩的 Node.js 副本，并将内存密集型工作移动到子进程。虽然有点复杂，但如果您决定希望为您的特定用例做出不同的权衡，也可以构建一个禁用指针压缩的 Electron 自定义版本。最后，在不久的将来，wasm64 将允许在 Web 和 Electron 上使用 WebAssembly 构建的应用程序使用远大于 4GB 的内存。
常见问题解答
我如何知道我的应用程序是否受此更改的影响？
在 Electron 20+ 中，尝试使用 ArrayBuffer 包装外部内存会在运行时崩溃。
如果您的应用程序中未使用任何原生 Node 模块，则您是安全的——无法从纯 JS 中触发此崩溃。此更改仅影响在 V8 堆外部分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存的原生 Node 模块。这是一个相当罕见的用例，但某些模块确实使用了这种技术，并且此类模块需要重构才能与 Electron 20+ 兼容。
我如何测量我的应用正在使用的 V8 堆内存量，以了解是否接近 4GB 的限制？
在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，它将返回以字节为单位的 V8 堆使用量。在主进程中，您可以使用 process.memoryUsage().heapUsed，它们是可比较的。
什么是 V8 内存笼？
有些文档将其称为 “V8 沙箱”，但该术语很容易与 Chromium 中发生的其他类型的沙箱混淆，因此我将坚持使用“内存笼”这个术语。
有一种相当常见的 V8 漏洞利用方式，大致如下：
- 在 V8 的 JIT 引擎中找到一个错误。JIT 引擎分析代码，以便能够省略缓慢的运行时类型检查并生成快速的机器代码。有时，逻辑错误意味着它的分析是错误的，并且省略了实际需要的类型检查——例如，它认为 x 是一个字符串，但实际上它是一个对象。
- 滥用这种混淆来覆盖 V8 堆中的某些内存位，例如，指向 ArrayBuffer 开头的指针。
- 现在您有了一个指向您喜欢的任何位置的 ArrayBuffer，因此您可以读取和写入进程中的任何内存，甚至是 V8 通常无法访问的内存。
V8 内存笼是一种旨在明确防止此类攻击的技术。实现这一目标的方式是不在 V8 堆中存储任何指针。相反，所有对 V8 堆内部其他内存的引用都存储为相对于某个保留区域开头的偏移量。然后，即使攻击者设法破坏了 ArrayBuffer 的基地址，例如通过利用 V8 中的类型混淆错误，他们最坏的情况也只能读取和写入笼子内的内存，而他们可能已经可以做到这一点。关于 V8 内存笼如何工作还有很多资料可以阅读，因此我不会在此处进一步详细介绍——最好的阅读起点可能是 Chromium 团队的高级设计文档。
我想重构一个 Node 原生模块以支持 Electron 21+。我该怎么做？
有两种方法可以重构原生模块以使其与 V8 内存笼兼容。第一种方法是，在将外部创建的缓冲区传递给 JavaScript 之前，将其复制到 V8 内存笼中。这通常是一个简单的重构，但当缓冲区很大时，它可能会很慢。另一种方法是使用 V8 的内存分配器来分配您打算最终传递给 JavaScript 的内存。这稍微复杂一些，但可以让您避免复制，这意味着对于大型缓冲区具有更好的性能。
为了使这一点更具体，这是一个使用外部数组缓冲区的 N-API 模块示例：
// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);
当启用内存笼时，这将崩溃，因为数据是在笼子外部分配的。重构为将数据复制到笼子内部，我们得到：
size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!
这会将数据复制到 V8 内存笼内部新分配的内存区域。可选地，N-API 还可以提供一个指向新复制数据的指针，以防您需要在事后修改或引用它。
重构为使用 V8 的内存分配器有点复杂，因为它需要修改 create_external_resource 函数以使用 V8 分配的内存，而不是使用 malloc。这可能或多或少是可行的，具体取决于您是否控制 create_external_resource 的定义。其思想是首先使用 V8 创建缓冲区，例如使用 napi_create_buffer，然后将资源初始化到 V8 分配的内存中。重要的是要保留对 Buffer 对象的 napi_ref，以确保资源的生命周期，否则 V8 可能会垃圾回收 Buffer，并可能导致使用后释放错误。
