.net - itgenclr007 : Fix OutOfMemory in 32-bit Excel with VSTO add-in

Question

使用 Invantive Control(带有 Microsoft .NET 4.7 的 VSTO 加载项)的复杂查询从 Exact Online 检索大约 200.000 行。这在 64 位版本的 Microsoft Excel 2010 及更高版本中运行良好。

在查询结束时进行强制 .NET 垃圾回收后，报告大约有 250 MB 的内存正在使用中。在此过程中，使用的内存有所不同，但峰值为 750 MB。

但是，在 32 位版本上，用户在下载数据期间经常会遇到 OutOfMemory 异常。即使在重构查询以尽早删除未使用的列和行之后，它仍然不适合可用内存。

如何在 Excel 32 位版本中运行如此复杂的查询？

Answer 1

尽管至少从 Excel 2007 起就有了 64 位版本的 Excel，但主要的安装仍然是 32 位版本的 Microsoft Excel。

大多数外接程序开发人员从未找到支持 64 位 Microsoft Office 的业务案例，并且在 2010 年左右，Microsoft 将其使用 64 位版本 Office 的建议更改为 32 位版本。

VSTO 加载项的可用内存因版本而异，但随着 Excel 本身复杂性的增加而不断减少。

目前，在加载了 Excel 和 .NET CLR 的情况下，可寻址内存空间为 1.75 GB，您最多可以为 .NET 代码和数据使用大约 250-300 MB 的空间。垃圾收集器在将所有内容放入可寻址内存空间方面做得很好，但这通常是不够的。

使用 64 位 Windows 版本(现在的常见版本)并向 Windows 添加更多物理或虚拟内存通常不会改善可用和可寻址内存量。这是 32 位地址空间设计的限制。

从 2016 年 5 月的版本开始，Microsoft 已设置 LARGEADDRESSAWARE Excel.exe header 中的位。这使得 32 位版本的 Excel 就像旧的 32 位版本的 Oracle 和其他版本一样，可以寻址超过 2 GB 的内存。

knowledge base进一步记录了哪些版本提供了此功能。鉴于 Excel 2013 已停产，本质上您应该使用新版本的 32 位 Excel 2016 以避免出现 OutOfMemory 异常。

对于 Office365 订阅者，建议切换到包含足够新版本的 Excel 2016 的 channel 。

虽然对于 Excel，这会将可寻址内存空间增加到仅 3 GB，但它会将 .NET 代码和 VSTO 数据的可用内存量从 250-300 MB 增加到 1250-1300 MB。可用内存空间惊人地增加了 4-5 倍。

Invantive Control 在帮助 -> 诊断窗口中显示可寻址内存空间。

对于非 LARGEADDRESSAWARE 版本的 Excel，它显示:

但对于 LARGEADDRESSAWARE 版本，它显示:

分配超过 2 GB 的操作: