垃圾收集器为.NET进程分配的最大内存是多少？当我编译为x64时，Process.GetCurrentProcess.MaxWorkingSet返回大约1,4GB，但是当我编译到AnyCPU（x64）时，返回相同的数字。对于x64，它应该更像是任务管理器中显示的“限制”值。如何在所有情况下获得超出OutOfMemory-Exceptions的正确数字？
该方法应返回的一些示例：
1）机器配置：x64-Windows，4GB物理内存，4GB页面文件
- 作为64位进程：8GB
- 作为32位进程：1.4GB
2）机器配置：x64-Windows，1GB物理内存，2GB页面文件
- 作为64位进程：3GB
- 作为32位进程：1.4GB
3）机器配置：x32-Windows，4GB物理内存，4GB页面文件
- 作为64位进程：不会发生
- 作为32位进程：1.4GB
答案 0 :(得分：17)
Windows可以配置为按需分配更多页面文件空间，或on request Job objects可以防止消耗超过一定量的记忆 堆的碎片化和它的世代性（加上需要在大对象堆中放入大量的东西）
所有这些意味着硬限制在现实中没有多大用处，并且意味着回答“我理论上可以分配多少内存”的问题比你想象的要复杂得多。
由于复杂的任何人询问该问题可能是在尝试做一些错误的并且应该将他们的问题重定向到更有用的问题。
你想做什么似乎需要这样一个问题？
“我只想知道当前进程的内存负载何时会出现问题 所以我可以采取行动，比如释放一些自定义缓存的项目。“
右。这是一个更容易处理的问题。
按复杂程度排列的两种解决方案：
注意事项。
维护这个大容量缓存（通过它的声音进入磁盘）比重新计算/重新请求数据真的更便宜。
如果您的缓存在常用/连续请求的项目之间显示较差的位置，那么将花费很多精力来分页数据。具有有效调整的重新缓存策略的较小缓存很有可能表现得更好（并且对其他正在运行的程序的影响要小得多）
顺便说一下：在.Net中，由于内核管理的核心CLR结构的限制，没有可变大小的对象（字符串，数组）的大小可以超过2GB。 （以上任何一种解决方案都将从中受益）
答案 1 :(得分：3)
它不取决于你有多少RAM？
从理论上讲，x64进程可以分配EB的（etabytes？）RAM，我认为 - 即很多。但是，如果你这样做，你的机器应该像疯了一样开始分页并且通常会死掉。
在32位模式下有所不同，因为在Windows中的任何进程中都无法分配超过1GB的RAM（是的，有很多方法，但它并不漂亮）。实际上，这个每个.NET进程大约7-800meg，因为.NET保留了一些空间。
无论哪种方式，在32位中，你可以使用的最多是3GB - 操作系统为自己预留1GB的虚拟空间。
在64位中，它应该是2 ^ 64，这是一个很大的数字，但http://en.wikipedia.org/wiki/X86-64表示它是256TB的虚拟空间和1TB的REAL RAM。无论哪种方式，它都比您在机器中可能拥有的要多得多，所以它会打到页面文件。
使用64位操作系统和64位运行时， 基于.NET 2.0的应用程序现在可以 利用500倍的内存来存储数据 例如基于服务器的缓存。
这也有一些很好的信息http://www.theserverside.net/tt/articles/showarticle.tss?id=NET2BMNov64Bit
顺便说一句，如果您使用的是x64计算机（即x64计算机+ x64操作系统），则为AnyCPU和x64编译会做同样的事情 - 它以x64模式运行。唯一的区别是你使用AnyCPU vrs x86：x64 OS / .NET，x32：x32 app（安装了Fx的x64和x64版本的x64 .NET框架）
x32 OS / NET，AnyCPU：x32 app