c# - 使用文件流写入字节通过控制台输出进度时出现Out of Memory异常

Question

我有以下代码在写入大文件时抛出内存不足异常。有什么我想念的吗？

我不确定为什么会抛出内存不足错误，因为我认为 Filestream 最多只能使用 4096 字节的缓冲区？老实说，我不完全确定 Buffer 的含义，如有任何建议，我们将不胜感激。

 public static async Task CreateRandomFile(string pathway, int size, IProgress<int> prog)
    {
        byte[] fileSize = new byte[size];
        new Random().NextBytes(fileSize);
        await Task.Run(() =>
           {
               using (FileStream fs = File.Create(pathway,4096))
               {

                   for (int i = 0; i < size; i++)
                   {
                       fs.WriteByte(fileSize[i]);
                       prog.Report(i);
                   }

               }

           }
       );
    }

    public static void p_ProgressChanged(object sender, int e)
    {
        int pos = Console.CursorTop;
        Console.WriteLine("Progress Copied: " + e);
        Console.SetCursorPosition (0, pos);
    }

    public static void Main()
    {
        Console.WriteLine("Testing CopyLearning");
        //CopyFile()
        Progress<int> p = new Progress<int>();
        p.ProgressChanged += p_ProgressChanged;
        Task ta = CreateRandomFile(@"D:\Programming\Testing\RandomFile.asd", 99999999, p);
        ta.Wait();
    }

编辑:刚刚创建了 99,999,999 以生成 99MB 的文件

注意:我已经注释掉了 prog.Report(i)，它会正常工作。似乎出于某种原因，错误发生在该行

Console.writeline("Progress Copied: " + e);

我不完全确定为什么会导致错误？那么错误可能是由于 progressEvent 引起的？

编辑 2:我按照建议更改代码，使用以下代码每 4000 字节报告一次进度:

 if (i%4000==0)
     prog.Report(i);

出于某种原因。我现在可以写入高达 900MB 的文件。

我想问题是，为什么“Edit 2”的代码允许它写入 900MB 就好了？是因为它报告进度和写入控制台的次数比以前少了 4000 倍吗？我没有意识到控制台会占用这么多内存，尤其是因为我假设它所做的只是输出“已复制进度”？

编辑 3:

出于某种原因，当我如下更改以下行时:

 for (int i = 0; i < size; i++)
      {
          fs.WriteByte(fileSize[i]);
          Console.Writeline(i)
          prog.Report(i);
      }

在 prog.Report(i) 之前有一个“Console.Writeline()”，它可以正常工作并复制文件，尽管这样做需要很长时间。这让我相信这是出于某种原因与控制台相关的问题，但我不确定是什么。

Answer 1

           fs.WriteByte(fileSize[i]);
           prog.Report(i);

您制造了一个消防水带问题。在死锁和线程竞争之后，可能是线程引起的第三大最有可能的问题。而且同样难以诊断。

使用调试器的 Debug + Windows + Threads 窗口最容易查看，并查看正在执行 CreateRandomFile() 的线程。运气好的话，您会看到它已完成 并已写入所有 99MB 字节。但是控制台上报告的进度远远落后于此，只报告了 125KB 字节写入，给予或接受。

核心问题是 Progress<>.Report() 的工作方式。它使用 SynchronizationContext.Post() 来调用 ProgressChanged 事件处理程序。在将调用 ThreadPool.QueueUserWorkItem() 的控制台模式应用程序中。这非常快，您的 CreateRandomFile() 方法不会因此而陷入困境。

但是事件处理程序本身相当慢，控制台输出不是很快。所以实际上，您正在以 巨大 的速度添加线程池工作请求，在几秒钟内就有 9900 万个。线程池调度程序无法跟上，您将同时执行大约 4 个线程池调度程序。所有竞争也写入控制台，只有其中一个可以获得底层锁。

所以是线程池调度器导致OOM，被迫存储这么多工作请求。

当然，当您调用 Report() 的频率降低时，消防水带问题就不会那么严重。虽然直接调用 Console.Write() 是一个明显的解决方法，但要确保它从不 导致问题实际上并不那么简单。最终很简单，创建一个对人类有用的可用 UI。没有人喜欢疯狂滚动的窗口或模糊的文字。报告进度不超过每秒 20 次对用户来说已经足够好了，控制台可以轻松跟上这一点。