Question

在添加到C＃列表时，明确检查/处理您没有达到2 ^ 31 - 1（？）最大条目数是疯狂，是真的吗？

（假设这是一个平均列表大小小于100的应用程序。）

Answer 1

<强> 1。内存限制

那么，没有任何属性的System.Object的大小是8字节（2x32位指针），或64位系统中的16字节。 [编辑：] 实际上，我刚刚检查了WinDbg，x86（32位）的大小为12bytes。

因此，在32位系统中，您需要24Gb ram（在32位系统上无法使用）。

<强> 2。程序设计

我坚信，这么大的列表不应该存储在内存中，而应该放在其他存储介质中。但在这种情况下，您始终可以选择创建一个包含List的缓存类，该类可以处理实际存储。因此，在添加之前测试大小是进行测试的错误位置，如果您有一天发现需要，List实现应该自行完成。

第3。为了安全起见

为什么不在每个方法中添加一个重入计数器以防止堆栈溢出？：）

所以，是的，测试它是疯狂的。：）

Answer 2

似乎过度。您是否首先不会达到机器的内存限制，具体取决于列表中对象的大小？（我假设这个检查是由List类的用户执行的，并不是实现中的任何检查？）

也许令人放心的是，同事们正在考虑未来？（讽刺！）

Answer 3

看起来似乎如此，我可能不会包括支票，但我对此有冲突。程序员虽然2位数足以表示日期字段中的年份，理由是它们的代码的预期寿命是正常的，但是我们发现这个假设是不正确的。

看风险，看看努力并做出判断电话（否则称为有根据的猜测！:-)）。我不会说这个有任何硬性或快速的规则。

Answer 4

正如在上面的答案中，我怀疑会出现更多问题而不是担心。但是，如果你有时间和倾向，你可以抛光代码，直到它闪耀！

Answer 5

真

（你问的是真还是假..）

Answer 6

刚试过这段代码：

List<int> list = new List<int>();
while (true) list.Add(1);

我收到了System.OutOfMemoryException。那么你会做什么来检查/处理这个？

Answer 7

如果您继续向列表中添加项目，则在达到该限制之前很久就会耗尽内存。 “长”，我的意思是“比你想象的要快得多”。

请参阅大对象堆（LOB）上的this discussion。一旦你达到21500个元素（在64位系统上的一半）（假设你正在存储对象引用），你的列表将开始成为一个大对象。由于LOB的压缩方式与正常的.NET堆不同，因此最终会将其分解得足够严重，以至于无法分配足够大的连续内存区域。

所以你根本不必检查这个限制，这不是一个真正的限制。

Answer 8

是的，这就是疯狂。

当您开始接触这些数字时，请考虑其余代码会发生什么。如果列表中有数百万个项目，该应用程序是否可用？

如果应用程序甚至可能达到该数据量，那么您应该采取措施防止列表变得那么大。也许您甚至不应该立即将所有数据保存在内存中。我无法想象任何代码可以实际利用那么多数据的情况。