Ubuntu 20.04环境下dotnet core 3.1应用独有内存泄漏问题排查

根因分析 #

• 你观测到GC堆内存无明显上涨、仅工作集暴涨，说明泄漏发生在非托管内存区域，和你使用的System.Drawing.Common库的跨平台实现直接相关：Windows下该库调用系统原生GDI+实现，稳定性较高；Linux下依赖第三方实现libgdiplus，.NET Core 3.1配套的默认版本存在多个已知的图片处理场景内存泄漏bug，符合你观测到的跨平台差异表现。
• 现有代码存在异常分支下的资源泄漏风险：scaledImage等绘图对象未用using块包裹，若处理流程中途抛出异常，会跳过后续手动调用的Dispose方法，导致非托管资源无法释放，Linux下libgdiplus对这类未正常释放的资源回收逻辑远不如Windows完善，会直接表现为内存持续上涨。

修复方案 #

1. 优先替换System.Drawing.Common（推荐） #

微软自.NET 6起已将System.Drawing.Common标记为Windows专属API，跨平台场景推荐使用纯托管实现的图像处理库ImageSharp，无libgdiplus依赖，跨平台表现完全一致，API和System.Drawing高度兼容，改造成本极低，可从根本上解决非托管内存泄漏问题。

2. 修复现有代码的资源释放逻辑 #

所有System.Drawing相关对象的创建必须包裹在using块中，无需手动调用Dispose，确保异常场景下资源也能正常释放：

• 主逻辑修改示例：

if (!string.IsNullOrEmpty(filePath) && this._fileInfoHelper.doesFileExist(filePath)) 
{
    // 用using块包裹scopedImage，作用域结束后自动释放
    using System.Drawing.Image scaledImage = size > 0 
        ? this._fileInfoHelper.scaleImage(filePath, size * size) 
        : System.Drawing.Image.FromFile(filePath);
    
    byte[] bytes = this._fileInfoHelper.imageToByteArray(scaledImage, this._fileInfoHelper.getFormatFromExtension(img.ImageType));
    string type = this._fileInfoHelper.getContentType(filePath);
    img.Base64 = "data:" + type.ToLower() + ";base64," + Convert.ToBase64String(bytes);
    returnImages.Add(img);
    // 无需手动调用scaledImage.Dispose()
}

• 移除scaleImage、imageToByteArray函数中冗余的手动Dispose调用：已经包裹using块的对象会自动释放，重复调用不会带来额外收益，反而增加出错概率。

3. 若必须继续使用System.Drawing.Common #

首先升级Linux环境的libgdiplus到最新稳定版，Ubuntu 20.04默认源中的版本过旧，存在多个已知内存泄漏问题，可通过Mono官方源安装最新版：

sudo apt install apt-transport-https dirmngr gnupg ca-certificates
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb https://download.mono-project.com/repo/ubuntu stable-focal main" | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
sudo apt update && sudo apt install -y libgdiplus

其次可在进程启动时添加环境变量DOTNET_GC_HEAPCOUNT=1，关闭服务器GC的多堆模式，部分场景下Linux服务器GC会保留大量内存不释放给操作系统，该配置可让内存回收逻辑更激进，降低工作集的常驻内存大小。

4. 泄漏验证 #

可使用valgrind工具运行目标进程，直接定位非托管内存泄漏的具体来源，确认修复效果。

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