报表QR码间歇性显示异常（GDI+错误、内存不足）求排查协助

1. GDI+资源泄漏排查 #

GDI+通用错误大多源于未正确释放图像资源。生产环境并发量高时，未释放的Bitmap、Graphics等对象会耗尽系统GDI句柄，触发这类错误。

• 检查QR码生成代码，确保所有实现IDisposable的对象都用using语句包裹，或手动调用Dispose()：

using (var qrBitmap = new Bitmap(width, height))
using (var gfx = Graphics.FromImage(qrBitmap))
{
    // QR码生成逻辑
    // ...
    return qrBitmap;
}

• 在生产环境监控进程的GDI对象计数（任务管理器中查看），若计数持续增长不回落，可确认存在资源泄漏。

2. 内存不足异常的核心原因 #

结合间歇性出现的特征，问题大概率是大对象堆（LOH）碎片化或QR码图像尺寸过大：

• 检查QR码生成的尺寸设置，若分辨率过高（如超过4000x4000），单张图片会占用大量内存，并发场景下快速耗尽资源。建议根据实际需求压缩尺寸至1000x1000以内。
• 避免频繁创建大尺寸Bitmap，可尝试复用对象池（业务允许的前提下），减少LOH分配。
• 确认报表生成后是否及时销毁PDF/Excel等报表对象，避免内存长期占用。

3. 生产环境并发场景问题 #

本地无法复现，说明是并发下的资源竞争或线程安全问题：

• 检查QR码生成逻辑是否依赖静态共享对象（如全局QRCodeGenerator实例），若实例非线程安全，并发调用会导致内部状态混乱，触发GDI+错误和内存异常。确保每个请求使用独立实例，或采用线程安全的实现。
• 监控服务器资源瓶颈：高峰期内存、CPU是否接近饱和，资源不足会放大GDI+和内存问题。可通过性能计数器追踪内存使用率、CPU负载、GDI句柄数等指标。

4. 临时缓解与长期修复 #

• 临时方案：除重启服务，可配置服务自动回收机制（如IIS应用池定期回收），但仅为治标手段。
• 长期修复：
  • 全面审计所有GDI+相关代码，确保资源释放逻辑无遗漏。
  • 对QR码生成模块做压力测试，模拟生产环境并发量，复现问题后调试定位。
  • 考虑替换QR码生成库，选用更轻量、线程安全的实现（部分库直接生成字节流，无需依赖Bitmap）。

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