Csharp .NET HttpClient、JsonSerializer或误用的Stream中的内存泄漏

任何时候分配一个连续的内存块&>=85,000字节，它都会进入large object heap字节.与常规堆不同，它不是压缩的，除非您这样做manually^[1]，因此它可能会因为碎片而增长，看起来像是内存泄漏.请参见102.

由于您的responseString和contentBytes通常在2MB左右，我建议重写您的代码以消除它们.取而代之的是，使用相关的内置API直接从您的服务器异步传输到JSON文件，如下所示:

const int BufferSize = 16384;
const bool UseAsyncFileStreams = true; //https://learn.microsoft.com/en-us/dotnet/api/system.io.filestream.-ctor?view=net-5.0#System_IO_FileStream__ctor_System_String_System_IO_FileMode_System_IO_FileAccess_System_IO_FileShare_System_Int32_System_Boolean_

protected async Task DumpAppList()
{
    try
    {
        var httpClient = _httpClientFactory.CreateClient();
        var appList = new List<SteamApiGetAppListApp>();
        int? lastAppId = null;
        do
        {
            // Get the SteamApiGetAppListOuterResponse directly from JSON using HttpClientJsonExtensions.GetFromJsonAsync() without the intermediate string.
            // https://learn.microsoft.com/en-us/dotnet/api/system.net.http.json.httpclientjsonextensions.getfromjsonasync
            // If you need customized error handling see 
            // https://stackoverflow.com/questions/65383186/using-httpclient-getfromjsonasync-how-to-handle-httprequestexception-based-on
            var responseObject = (await httpClient.GetFromJsonAsync<SteamApiGetAppListOuterResponse>(GetAppListUrl(lastAppId)))
                !.response;
            appList.AddRange(responseObject.apps);
            lastAppId = responseObject.have_more_results ? responseObject.last_appid : null;

        } while (lastAppId != null);

        await using var output = new FileStream(Path.Combine(Config.DumpDataPath, DateTime.UtcNow.ToString("yyyy-MM-dd__HH-mm-ss") + ".json.gz"),
                                                FileMode.Create, FileAccess.Write, FileShare.None, bufferSize: BufferSize, useAsync: UseAsyncFileStreams);
        await using var gz = new GZipStream(output, CompressionMode.Compress);
        // See https://faithlife.codes/blog/2012/06/always-wrap-gzipstream-with-bufferedstream/ for a discussion of buffer sizes vs compression ratios.
        await using var buffer = new BufferedStream(gz, BufferSize);
        // Serialize directly to the buffered, compressed output stream without the intermediate in-memory array.
        await JsonSerializer.SerializeAsync(buffer, appList);
    }
    catch (Exception ex)
    {
        Trace.TraceError("skipped...");
    }
}

备注:

• GZipStream不会缓冲其输入，因此以增量方式向其传输数据可能会导致更差的压缩比.然而，正如Bradley Grainger在Always wrap GZipStream with BufferedStream中所讨论的，使用8K或更大的缓冲区来缓冲增量写入可以有效地消除该问题.

• 根据docs，将useAsync参数传递给FileStream构造函数

  指定是使用异步I/O还是使用同步I/O.但是，请注意，基础操作系统可能不支持异步I/O，因此当指定为TRUE时，句柄可能会根据平台而同步打开.当以异步方式打开时，BeginRead(Byte[], Int32, Int32, AsyncCallback, Object)和BeginWrite(Byte[], Int32, Int32, AsyncCallback, Object)方法在大型读取或写入时执行得更好，但在小型读取或写入时可能会慢得多.如果应用程序设计为利用异步I/O，请将useAsync参数设置为True.正确使用异步I/O可以将应用程序的速度提高10倍，但是使用它而不为异步I/O重新设计应用程序可能会使性能降低10倍.

  因此，您可能需要进行测试，看看在实践中，UseAsyncFileStreams等于true还是false会获得更好的性能.您可能还需要调整缓冲区大小以获得最佳性能和压缩比--始终确保缓冲区小于85,000字节.

• 如果您认为大对象堆碎片可能是一个问题，请参阅MSFT文章The large object heap on Windows systems: A debugger以获取有关如何进一步调查的建议.

• 因为您的DumpAppList()方法只每半小时运行一次，所以您可以try 在每次运行后手动压缩大对象堆，看看这是否有帮助:

   protected override async Task ExecuteAsync(CancellationToken stoppingToken)
   {
       while (!stoppingToken.IsCancellationRequested)
       {
           await DumpAppList();
           GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
           GC.Collect();           
  
           await Task.Delay(RepeatDelay, stoppingToken);
       }
   }
  

• 你可能想把CancellationToken stoppingToken改成DumpAppList().

^[1]请注意，在Memory management and garbage collection (GC) in ASP.NET Core: Large object heap年中，MSFT写道:

在使用.NET Core 3.0及更高版本的容器中，会自动压缩LOH.

因此，我关于LOH压缩何时发生的声明在某些平台上可能会过时.