我正在编写在 Windows Server 2016 上运行的 .NET 应用程序，该应用程序对大文件的许多块进行 http 获取。这样可以大大加快下载过程，因为您可以并行下载它们。不幸的是，一旦它们被下载，将它们全部拼接在一起需要相当长的时间。
需要组合的文件数量在 2 到 4k 之间。这个服务器具有充足的内存，接近800GB。我认为使用MemoryStream来存储已下载的分片，直到它们可以按顺序写入磁盘，是有意义的但在我使用约2.5GB的内存后，就会出现System.OutOfMemoryException错误。该服务器有数百 GB 的可用空间，但我无法找出如何使用它们。
MemoryStreams是基于字节数组构建的。 目前，数组大小不能超过2GB。
System.Array的当前实现对其所有内部计数器等均使用Int32，因此理论上元素的最大数量为
Int32.MaxValue。Microsoft CLR还强制规定了每个对象的最大大小为2GB。
当你试图将内容放入单个MemoryStream时，底层数组变得太大，因此会出现异常。
尝试分别存储这些部分，并在准备好时直接将它们写入FileStream（或您使用的任何其他方式），而不是先尝试将它们全部连接成一个对象。
new long[2_000_000_000]成功创建了一个16 GB的数组，但new byte[3_000_000_000]抛出了OverflowException异常。 - ckuristatic void Main(string[] args)
{
MemoryStream ms1 = new MemoryStream((int)Math.Pow(1024, 3));
MemoryStream ms2 = new MemoryStream((int)Math.Pow(1024, 3));
MemoryStream ms3 = new MemoryStream((int)(Math.Pow(1024, 3)*.95));
MemoryStream ms4 = new MemoryStream((int)Math.Pow(1024, 3)); //这个会出现内存不足的错误
} - Josh DayberryInt32.MaxValue，而数组的最大索引被设置为0x0x7FFFFFC7，即2.147.783.591十进制（= 2 GB）。private const int MemStreamMaxLength = Int32.MaxValue;
片段数组
// We impose limits on maximum array lenght in each dimension to allow efficient
// implementation of advanced range check elimination in future.
// Keep in sync with vm\gcscan.cpp and HashHelpers.MaxPrimeArrayLength.
// The constants are defined in this method: inline SIZE_T MaxArrayLength(SIZE_T componentSize) from gcscan
// We have different max sizes for arrays with elements of size 1 for backwards compatibility
internal const int MaxArrayLength = 0X7FEFFFFF;
internal const int MaxByteArrayLength = 0x7FFFFFC7;
更新
我建议使用以下代码，在x64构建中应该能够分配超过4GB，但在x86构建中<4GB将失败。
private static void Main(string[] args)
{
List<byte[]> data = new List<byte[]>();
Random random = new Random();
while (true)
{
try
{
var tmpArray = new byte[1024 * 1024];
random.NextBytes(tmpArray);
data.Add(tmpArray);
Console.WriteLine($"{data.Count} MB allocated");
}
catch
{
Console.WriteLine("Further allocation failed.");
}
}
}
MemoryStream 的本质是由一个固定上限大小的 byte[] 所支持。Stream 实现的选项已经被注意到。另一个选择是查看新的 IO API 中的 "pipelines"。"Pipeline" 基于不连续的内存，这意味着它不需要使用单个连续缓冲区；pipelines 库将根据需要分配多个物理块，您的代码可以处理这些块。我已经详细地写过这个话题；第一部分 在这里。第三部分可能具有最多的代码关注点。确认我理解你的问题：你正在使用多个并行块下载单个非常大的文件，并且你知道最终文件的大小？如果不知道，那么这会变得更加复杂，但仍然可以完成。
最好的选择可能是使用MemoryMappedFile（MMF）。你需要通过MMF创建目标文件。每个线程将为该文件创建一个视图访问器，并以并行方式写入它。最后，关闭MMF。这基本上给了你想要的MemoryStreams的行为，但Windows通过磁盘支持文件。这种方法的好处之一是Windows在后台管理将数据存储到磁盘中（刷新），因此你不必担心，应该会获得出色的性能。
ConcatenatedStream可以满足你的需求，只要你不需要随机寻址。它来自于 How do I concatenate two System.Io.Stream instances into one?。 - dbc