今天我的申请提出了OutOfMemoryException。对我来说，这几乎几乎是不可能的，因为我也有4GB RAM和很多虚拟内存。当我尝试将现有集合添加到新列表时发生了错误。
List<Vehicle> vList = new List<Vehicle>(selectedVehicles);
据我了解，这里没有分配多少内存，因为我的新列表中应该包含的车辆已经存在于内存中。我不得不承认这Vehicle是一个非常复杂的类，我试图一次将大约50.000个项目添加到新列表中。但是，由于Vehicle应用程序中的所有内容都来自大小仅为200MB的数据库，因此我不知道这可能导致什么OutOfMemoryException。
OutOfMemoryException被抛出，你附加到进程使用调试器，看看问题可能是什么？多大了对象？.NET Framework的对象大小硬限制为2 GB，减去框架本身消耗的开销。
Answers:
两点：
List是一个数组。如果您的内存非常分散，则List即使您总共有足够的可用内存，也可能没有足够的连续空间来分配您的。gcAllowVeryLargeObjects配置设置克服它。此处有更多详细信息-msdn.microsoft.com/en-us/library/…–
3岁的话题，但我找到了另一个可行的解决方案。如果您确定有足够的可用内存，正在运行64位操作系统并且仍然出现异常，请转到Project properties->Build选项卡，并确保将其设置x64为Platform target。
Project properties- >Build标签- >变化Platform target，以x64
.Net4.5对对象不再有2GB的限制。将此行添加到App.config
<runtime>
<gcAllowVeryLargeObjects enabled="true" />
</runtime>
并且可以创建非常大的对象而不会出现OutOfMemoryException
请注意，它仅适用于x64 OS！
与应用程序中的内存相比，数据库中存储的数据有很大的不同。
无法获得对象的确切大小，但是您可以这样做：
GC.GetTotalMemory()
装入一定数量的对象后，查看加载列表时内存的变化量。
如果是导致过多内存使用的列表，那么我们可以考虑将其最小化的方法。例如，为什么首先要一次将50,000个对象全部加载到内存中。按照您的要求调用数据库不是最好吗？
如果您在此处查看：http : //www.dotnetperls.com/array-memory，您还将看到.NET中的对象大于其实际数据。通用列表甚至比数组更像是内存消耗。如果您的对象中有一个通用列表，则它将更快地增长。
（在32位计算机上）OutOfMemoryException与碎片实际发生在内存上的实际硬限制一样多-您会发现很多有关此的信息，但这是我第一次在Google上进行的简短讨论：http : //blogs.msdn.com/b /joshwil/archive/2005/08/10/450202.aspx。（@Anthony Pegram在上面的评论中提到了相同的问题）。
就是说，上面的代码还有另外一种可能性：当您对列表使用“ IEnumerable”构造函数时，您可能不会给对象任何有关所传递集合大小的提示。到List构造函数。如果要传递的对象不是集合（未实现该ICollection接口），那么在幕后，List实现将需要增长几次（或多次），每次都留下一个很小的数组需要被垃圾收集。垃圾收集器可能不会足够快地到达那些被丢弃的数组，并且您会得到错误。
最简单的解决方法是使用List(int capacity)构造函数告诉框架要分配的后备数组大小（即使您估计并仅猜测为“ 50000”），然后使用该AddRange(IEnumerable collection)方法实际填充列表。
所以，如果我是对的话，最简单的“修复”：替换
List<Vehicle> vList = new List<Vehicle>(selectedVehicles);
与
List<Vehicle> vList = new List<Vehicle>(50000);
vList.AddRange(selectedVehicles);
其他所有评论和答案仍适用于总体设计决策-但这 可能是一个快速解决方案。
注意（如下面的@Alex所述），这仅selectedVehicles是不是ICollection的问题。
我的开发团队解决了这种情况：
我们将以下构建后脚本添加到.exe项目中，然后再次编译，将目标设置为x86并增加1.5 gb，并且将x64 Platform目标设置为使用3.2 gb增加内存。我们的应用程序是32位。
相关网址：
脚本：
if exist "$(DevEnvDir)..\tools\vsvars32.bat" (
call "$(DevEnvDir)..\tools\vsvars32.bat"
editbin /largeaddressaware "$(TargetPath)"
)
随着.Net的发展，他们添加新的32位配置的能力也在不断提高，这似乎使每个人都感到困惑。
如果您使用的是.Net Framework 4.7.2，请执行以下操作：
转到项目属性
建立
取消选中“首选32位”
干杯!
我知道这是一个老问题，但是由于没有答案提到大对象堆，因此这可能对发现此问题的其他人有用...
.NET中任何超过85,000字节的内存分配都来自大对象堆（LOH），而不是普通的小对象堆。为什么这么重要？因为没有压缩大对象堆。这意味着大对象堆变得碎片化，根据我的经验，这不可避免地导致内存不足错误。
在原始问题中，列表中包含50,000个项目。在内部，列表使用数组，并假设需要50,000 x 4bytes的32位= 200,000字节（如果是64位，则为两倍）。因此，内存分配来自大型对象堆。
所以你对此能做些什么？
如果您使用的是4.5.1之前的.net版本，那么您所能做的就是意识到这一问题并设法避免它。因此，在这种情况下，如果没有列表中包含的车辆不超过18,000个元素，则可以使用车辆列表的清单。这可能会导致一些难看的代码，但这是可行的解决方法。
如果使用的是.net 4.5.1或更高版本，则垃圾收集器的行为已发生了细微变化。如果在要进行大内存分配的位置添加以下行：
System.Runtime.GCSettings.LargeObjectHeapCompactionMode = System.Runtime.GCLargeObjectHeapCompactionMode.CompactOnce;
它将迫使垃圾收集器压缩大对象堆-仅在下一次。
它可能不是最佳解决方案，但以下方法对我有用：
int tries = 0;
while (tries++ < 2)
{
try
{
. . some large allocation . .
return;
}
catch (System.OutOfMemoryException)
{
System.Runtime.GCSettings.LargeObjectHeapCompactionMode = System.Runtime.GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();
}
}
当然，这仅在您具有可用的物理（或虚拟）内存时才有用。
selectedVehicles？