ProcessMemoryLimitto64-bitProcess我目前有一个需要大量内存的32位.Net应用程序（在x86Windows上）。最近它开始抛出System.OutOfMemoryException。因此，我计划将其作为64位进程移至x64平台。所以这将有助于解决内存不足的异常。我正在从MSDNMemoryLimitsforWindows阅读这篇文章所以，我的问题是，如果我编译一个64位.Net应用程序，它是否将IMAGE_FILE_LARGE_ADDRESS_AWARE设置为默认值（如文章所建议的）？即我可以利用8GB用户模式虚拟地址空间吗？x64进程的最大内存限制为8TB，但实际限制要小得多，因为它取决于系统上的物理内存量和页面文件大小。有关详细信息，请参阅此帖子。IMAGE_FILE_LARGE_ADDRESS_AWARE影响在x64操作系统（或带有/3GB指令的x86操作系统）上运行的x86进程。您的x64应用程序不需要设置大地址感知标志，它将能够使用系统上所有可用的虚拟内存。IMAGE_FILE_LARGE_ADDRESS_AWARE仅与32位进程相关。原因是32位Windows上的地址空间分为两部分：2GB用于内核空间，2GB用于用户空间。要满足2GB，您需要31位。即32位应用程序中的指针不需要最后一位进行寻址。某些应用程序可能出于自定义目的使用了这个额外的位，因此如果Windows内存管理器突然给了它们真正的32位地址，它们将无法处理。通过启用IMAGE_FILE_LARGE_ADDRESS_AWARE标志，应用程序基本上告诉操作系统它可以处理整个32位可寻址空间。如果您在32位Windows上运行IMAGE_FILE_LARGE_ADDRESS_AWARE应用程序，您可以访问3GB。如果您在64位Windows上运行相同的32位应用程序，该进程实际上会获得整个4GB的地址空间。如果在64位Windows上运行64位应用程序，则用户地址空间为8TB（另外8TB用于内核地址空间）。设置为AnyCPU的.NET应用程序将自动成为x64上的64位应用程序，因此您无需执行任何操作来占用额外的内存。但请记住，CLR对任何单个对象施加了2GB的限制，因此尽管您的应用程序可能会使用大量内存，但您不能创建2个TBarray。这个问题的更多信息：Isthesizeofasingleobjectstilllimitedto2GBinCLR4.0?事实上，文章指出您可以访问8TB的虚拟地址空间（是的，这是真的）。实际上在x64操作系统上，如果您的应用程序是为AnyCPU编译的，那么您不需要做任何特殊的事情。JIT将在运行时创建x64图像，或在32位系统上运行时创建x86图像。迁移到64位肯定有助于消除OutOfMemoryExceptions，但您可能希望专注于您的系统架构和编码机制以避免这些问题，因为它们在64位机器上也只是时间问题。迁移到64位计算机的另一个优势是.NET的垃圾收集很少发生在8TB的虚拟地址空间上。这确实通过增加程序可用的虚拟空间来提高应用程序性能。以上是C#学习教程：进程内存限制为64位进程。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
