.NET Core 3.1 API XmlSerializers.dll内存泄漏问题求助

核心问题定位 #

通过内存dump已确认问题根源是XmlSerializers.dll重复加载，结合场景（仅高流量API触发、未直接调用XmlSerializer(Type)构造函数、配置了AddXmlSerializerFormatters），大概率是ASP.NET Core在XML响应序列化环节的动态生成序列化器逻辑触发的问题，与你怀疑的runtime问题匹配。

排查思路 #

• 跟踪序列化器创建路径：用dotMemory、PerfView等工具，确认XmlSerializerOutputFormatter在高并发请求下是否重复触发动态编译生成XmlSerializers.dll的逻辑。
• 检查ResponseDto结构：确认带XML特性（如[XmlRoot]、[XmlElement]）的Dto类是否存在结构不稳定情况（比如动态生成的类型、属性频繁变更），这类情况会导致序列化器无法被缓存，进而重复生成。
• 对比同代码低流量API差异：检查高流量API的部署配置（Azure App Service缩放模式、应用池回收策略）、请求特征（如Accept头是否大量包含application/xml），确认是否是高并发下缓存失效触发重复加载。

可行解决方案 #

1. 预生成XmlSerializers.dll #

手动为ResponseDto类预生成序列化器dll，避免runtime动态生成：

• 使用Sgen.exe（.NET Framework工具）或dotnet-sgen（第三方工具）针对类库生成对应的*.XmlSerializers.dll，将生成的dll部署到应用bin目录。
• 部署后通过内存dump验证，确认不再出现动态生成的*.Progress.Lib.XmlSerializers.dll。

2. 替换XML序列化方式 #

若预生成序列化器无法彻底解决，可替换默认XML序列化逻辑：

• 改用DataContractSerializer替代XmlSerializer，在Startup中配置AddXmlDataContractSerializerFormatters()，同时将Dto上的XML特性替换为[DataContract]、[DataMember]。
• 或使用第三方XML序列化库，避免依赖runtime的动态生成逻辑。

3. 调整Azure App Service配置 #

• 配置应用池定期回收：在Azure App Service的「配置-常规设置」中设置固定时间间隔的应用回收，避免内存持续累积到影响性能的程度（临时缓解方案）。
• 启用内存监控警报：在Azure门户配置内存阈值警报，达到阈值时自动重启应用，减少人工干预成本。

4. 升级.NET版本（若业务允许） #

你怀疑的runtime问题在.NET 5及后续版本中已被修复，若业务无限制，可将API升级到更高版本的.NET，从根源解决动态序列化器的缓存问题。

内容的提问来源于stack exchange，提问作者cah1r