64位进程的进程内存限制答案

【问题标题】：Process Memory limit of 64-bit process64位进程的进程内存限制
【发布时间】：2011-01-24 20:15:34
【问题描述】：

我目前有一个需要大量内存的 32 位 .Net 应用程序（在 x86 Windows 上）。最近它开始抛出 System.OutOfMemoryException。

因此，我计划将其作为 64 位进程移至 x64 平台。因此，这将有助于解决内存不足异常。我正在从 MSDN 阅读这篇文章 Memory limits for Windows

所以，我的问题是，如果我编译一个 64 位的 .Net 应用程序，它是否会将 IMAGE_FILE_LARGE_ADDRESS_AWARE 设置为默认值（如文章所示）？即我能否利用 8GB 用户模式虚拟地址空间？

【问题讨论】：

【解决方案1】：

x64 进程的最大内存限制为 8 TB，但实际限制要小得多，因为它取决于系统上的物理内存量和页面文件大小。有关更多详细信息，请参阅this post。

IMAGE_FILE_LARGE_ADDRESS_AWARE 会影响在 x64 操作系统（或带有 /3GB 指令的 x86 操作系统）上运行的 x86 进程。您的 x64 应用程序不需要设置大地址感知标志，它将能够使用您系统上所有可用的虚拟内存。

【讨论】：

【解决方案2】：

IMAGE_FILE_LARGE_ADDRESS_AWARE 仅与 32 位进程相关。原因是 32 位 Windows 上的地址空间分为两部分：2 GB 用于内核空间，2 GB 用于用户空间。要寻址 2 GB，您需要 31 位。 IE。 32 位应用程序中的指针不需要最后一位来寻址。

某些应用程序可能已将此额外位用于自定义目的，因此如果 Windows 内存管理器突然向它们提供一个真正的 32 位地址，它们将无法处理。通过启用IMAGE_FILE_LARGE_ADDRESS_AWARE 标志，应用程序基本上告诉操作系统它可以处理整个32 位可寻址空间。

如果您在 32 位 Windows 上运行 IMAGE_FILE_LARGE_ADDRESS_AWARE 应用程序，您可以访问 3 GB。如果您在 64 位 Windows 上运行相同的 32 位应用程序，则该进程实际上会获得整个 4 GB 地址空间。

如果您在 64 位 Windows 上运行 64 位应用程序，则用户地址空间为 8 TB（另外留出 8 TB 用于内核地址空间）。设置为 AnyCPU 的 .NET 应用程序将自动成为 x64 上的 64 位应用程序，因此您无需执行任何操作来处理额外的内存。

但是请记住，CLR 对任何单个对象施加了 2 GB 的限制，因此虽然您的应用程序可能会使用大量内存，但您不能创建一个 2 TB 的数组。此问题的更多信息：Single objects still limited to 2 GB in size in CLR 4.0?

【讨论】：

对于 32 位寻址方案（总共 4 GB 地址），windows 将整个空间分成两部分，即 2 GB 用于 OS 内核，2 GB 用于用户进程。对于 64 位寻址方案，他们似乎没有采取这种方法将整个地址空间分成两个相等的部分。 64 位寻址方案总计为 16777216 TB，但它们将内核和用户进程空间都限制为 8 TB。

【解决方案3】：

实际上在 x64 操作系统上，如果您的应用程序是为 AnyCPU 编译的，那么您不需要做任何特别的事情。 JIT 将在运行时创建 x64 映像，或在 32 位系统上运行时创建 x86 映像。

【讨论】：

【解决方案4】：

实际上，该文章指出您将可以访问 8 TB 的虚拟地址空间（是的，这是真的）。

【讨论】：

这就是不需要做任何额外的事情来设置 IMAGE_FILE_LARGE_ADDRESS_AWARE。即默认情况下64位进程具有该开关。我说的对吗？
如果我们将自己限制在 Windows x64：我认为您的意思是说您_可以_可以访问 8TB，因为您受到可用物理内存和页面文件位置的限制正在被存储。我们还没有 8TB 硬盘。

【解决方案5】：

迁移到 64 位肯定有助于减少 OutOfMemoryExceptions，但您可能需要专注于您的系统架构和编码机制以避免这些，因为它们在 64 位机器上也出现只是时间问题.
迁移到 64 位机器的另一个优势是，有了 8 TB 的虚拟地址空间，.NET 的垃圾收集很少发生。这确实通过增加程序的可用虚拟空间来提高应用程序性能。

【讨论】：