再记一次MemoryLeak分析

　　性能是优化出来的，不管是在上生产前，还是在上生产后。大部分性能在性能测试阶段就能发现问题，但也有一些性能问题，结合生产的环境，生产数据才能表现出来，成为一个显著的瓶颈。
　　这次是生成pdf造成的内存泄露，大体代码如下，具体表现是内存缓慢增长，在docker中比windows增长速度要快，但都有只增不回收的特点。usingSystem。Data；usingSystem。Reflection。Metadata；usingQuestPDF。Helpers；usingQuestPDF。Infrastructure；usingQuestPDF。Fluent；usingQRCoder；usingMicrosoft。AspNetCore。Mvc；usingQuestPDF。Drawing；usingQuestPDF；varbuilderWebApplication。CreateBuilder（args）；varappbuilder。Build（）；app。MapGet（getpdf，（）｛vartablenewDataTable（）；for（vari0；i10；i）｛table。Columns。Add（i。ToString（））；｝for（varrow0；row1000；row）｛table。Rows。Add（row。ToString（），row。ToString（），row。ToString（），row。ToString（），row。ToString（），row。ToString（），row。ToString（），DateTime。Nowwwewrwerewfdsfdswefwefewfwefwefewrow，row。ToString（），row。ToString（））；｝returnTypedResults。File（GetPDF（table），contentType：applicationpdf，fileDownloadName：a。pdf）；｝）；app。Run（）；staticIContainerCellStyle（IContainercontainer）｛returncontainer。DefaultTextStyle（xx。SemiBold（）。FontSize（11））。PaddingVertical（5）。BorderBottom（1）。BorderColor（Colors。Black）；｝staticbyte〔〕GetPDF（DataTabledt）｛vardocQuestPDF。Fluent。Document。Create（container｛usingvarstreamFile。OpenRead（Path。Combine（AppDomain。CurrentDomain。BaseDirectory，fonts，MEIRYO。TTC））；FontManager。RegisterFont（stream）；Settings。EnableCachingtrue；Settings。EnableDebuggingfalse；container。Page（page｛page。Size（PageSizes。A4）；page。Margin（2，Unit。Centimetre）；page。PageColor（Colors。White）；page。DefaultTextStyle（xx。FontSize（14）。FontFamily（Meiryo））；page。Content（）。PaddingVertical（1，Unit。Centimetre）。Column（x｛x。Item（）。Table（table｛table。ColumnsDefinition（columns｛for（vari0；idt。Columns。Count；i）｛columns。RelativeColumn（）；｝｝）；table。Header（header｛foreach（DataColumncolindt。Columns）｛header。Cell（）。Element（CellStyle）。Text（col。ColumnName）；｝｝）；foreach（DataRowrowindt。Rows）｛for（vari0；idt。Columns。Count；i）｛if（i7）｛byte〔〕qrCodeAsBitmapByteArrPngByteQRCodeHelper。GetQRCode（row〔i〕。ToString（），QRCodeGenerator。ECCLevel。Q，20，false）；usingvarmsnewMemoryStream（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（）；｝）；｝）；｝）；returndoc。GeneratePdf（）；｝
　　各种。net的调试工具用上，都只能证明内存只增不减，连pmap都用上了，发现下面的一个大文件的内存占用，并且很多，大体都是在65M左右。AddressKbytesRSSDirtyModeMapping00007f4d54000000655366553665536rw〔anon〕
　　经过一天的测试，找不到具体的问，最后推测是生成Pdf后，生成的内存是非托管内存，GC回收不掉，每当有用户下载PDF时，就会积累内存，直到Pod崩掉。
　　干不掉bug，就干掉需求吧，因为经过统计这个下载pdf的使用量很低，可以下掉功能。同时把这个问题给QuestPDF提了个issues。就准备躺平。QuestPDF回应很快，说注册字体只用注册一次就行，多次注册会重复累加字体，37到40行代码，只在服务启动时加载一次即可，经过测试果然有效果。
　　在复盘时，总结，常规的思维在win下注册字体，多次注册不会让相同的字体保存多份，从而认知QuestPDF注册也是同理，造成下载一次就注册一次，造成内存积加，这也是为什么65M左右的内存一起在累加的原因。
　　后来，我又思考了一下，如果做一个支持高并发，高性能的web服务，像下载Excel，PDF这些操作，是不能在后台生成的，因为用户的一个文件的体积和用户的数据是有关系的，大小很难控件，如果耦合在web服务端来做这件事，肯定是个雷。也有的建议是用其他服务或cli异步生成，然后放在云存储上让用户下载，这也是一种解决方案。
　　我觉还是让web服务做自己擅长的事，提供数据，把文件生成组装操作转嫁给客户的浏览器来完成，这样既能减轻web服务的负载，又能充分利用客户端的资源，一举两得。