.NET再记一次Memory Leak分析

性能是优化出来的，不管是在上生产前，还是在上生产后。大部分性能在性能测试阶段就能发现问题，但也有一些性能问题，结合生产的环境，生产数据才能表现出来，成为一个显著的瓶颈。

这次是生成pdf造成的内存泄露，大体代码如下，具体表现是内存缓慢增长，在docker中比windows增长速度要快，但都有只增不回收的特点。.

using System.Data;using System.Reflection.Metadata;using QuestPDF.Helpers;using QuestPDF.Infrastructure;using QuestPDF.Fluent;using QRCoder;using Microsoft.AspNetCore.Mvc;using QuestPDF.Drawing;using QuestPDF;
var builder = WebApplication.CreateBuilder(args);var app = builder.Build();
app.MapGet("/getpdf", () =>{    var table = new DataTable();    for (var i = 0; i < 10; i++)    {        table.Columns.Add(i.ToString());    }    for (var row = 0; row < 1000; row++)    {        table.Rows.Add(row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), DateTime.Now + "wwewrwerewfdsfdswefwefewfwefwefew" + row, row.ToString(), row.ToString());    }     return TypedResults.File(GetPDF(table), contentType: "application/pdf", fileDownloadName: "a.pdf");});
app.Run();static IContainer CellStyle(IContainer container){    return container.DefaultTextStyle(x => x.SemiBold().FontSize(11)).PaddingVertical(5).BorderBottom(1).BorderColor(Colors.Black);}static byte[] GetPDF(DataTable dt){    var doc = QuestPDF.Fluent.Document.Create(container =>    {        using var stream = File.OpenRead(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "fonts", "MEIRYO.TTC"));        FontManager.RegisterFont(stream);        Settings.EnableCaching = true;        Settings.EnableDebugging = false;        container.Page(page =>        {            page.Size(PageSizes.A4);            page.Margin(2, Unit.Centimetre);            page.PageColor(Colors.White);            page.DefaultTextStyle(x => x.FontSize(14).FontFamily("Meiryo"));            page.Content()                .PaddingVertical(1, Unit.Centimetre)                .Column(x =>                {                    x.Item().Table(table =>                    {                        table.ColumnsDefinition(columns =>                        {                            for (var i = 0; i < dt.Columns.Count; i++)                            {                                columns.RelativeColumn();                            }                        });                        table.Header(header =>                        {                            foreach (DataColumn col in dt.Columns)                            {                                header.Cell().Element(CellStyle).Text(col.ColumnName);                            }
                        });                        foreach (DataRow row in dt.Rows)                        {                            for (var i = 0; i < dt.Columns.Count; i++)                            {                                if (i == 7)                                {                                    byte[] qrCodeAsBitmapByteArr = PngByteQRCodeHelper.GetQRCode(row[i].ToString(), QRCodeGenerator.ECCLevel.Q, 20, false);                                    using var ms = new MemoryStream(qrCodeAsBitmapByteArr);                                    table.Cell().Image(qrCodeAsBitmapByteArr);                                }                                else                                {                                    table.Cell().Element(CellStyle).Text(row[i].ToString());                                }                            }                        }                    });                });            page.Footer()                .AlignCenter()                .Text(x =>                {                    x.Span("Page ");                    x.CurrentPageNumber();                    x.Span("/ ");                    x.TotalPages();                });        });    });    return doc.GeneratePdf();}

各种.net的调试工具用上，都只能证明内存只增不减，连pmap都用上了，发现下面的一个大文件的内存占用，并且很多，大体都是在65M左右。

Address           Kbytes     RSS   Dirty Mode  Mapping00007f4d54000000   65536   65536   65536 rw---   [ anon ]

经过一天的测试，找不到具体的问，最后推测是生成Pdf后，生成的内存是非托管内存，GC回收不掉，每当有用户下载PDF时，就会积累内存，直到Pod崩掉。

干不掉bug，就干掉需求吧，因为经过统计这个下载pdf的使用量很低，可以下掉功能。同时把这个问题给QuestPDF提了个issues。就准备躺平。QuestPDF回应很快，说注册字体只用注册一次就行，多次注册会重复累加字体，37到40行代码，只在服务启动时加载一次即可，经过测试果然有效果。

在复盘时，总结，常规的思维在win下注册字体，多次注册不会让相同的字体保存多份，从而认知QuestPDF注册也是同理，造成下载一次就注册一次，造成内存积加，这也是为什么65M左右的内存一起在累加的原因。

后来，我又思考了一下，如果做一个支持高并发，高性能的web服务，像下载Excel，PDF这些操作，是不能在后台生成的，因为用户的一个文件的体积和用户的数据是有关系的，大小很难控件，如果耦合在web服务端来做这件事，肯定是个“雷”。也有的建议是用其他服务或cli异步生成，然后放在云存储上让用户下载，这也是一种解决方案。

我觉还是让web服务做自己擅长的事，提供数据，把文件生成组装操作转嫁给客户的浏览器来完成，这样既能减轻web服务的负载，又能充分利用客户端的资源，一举两得。

董川民