为何调用System.Drawing和System.Windows.Forms会导致ASP.NET请求阻塞？

核心原因在于这些组件的设计目标与ASP.NET服务器环境不兼容，具体分为三点： #

1. 桌面组件依赖UI线程上下文
   System.Drawing（底层基于GDI+）和System.Windows.Forms系列组件（包括你用到的Chart控件）都是为桌面GUI应用设计的。它们的初始化和运行依赖Windows UI线程的消息循环机制，但ASP.NET的请求处理线程是无UI上下文的后台工作线程，没有桌面应用的消息循环环境。直接在请求线程中创建这些控件时，组件内部会尝试绑定不存在的UI线程上下文，进而引发线程阻塞、资源死锁。

2. 线程模型冲突
   WinForms控件要求在**单线程单元（STA）线程中执行，但ASP.NET的请求处理线程默认是多线程单元（MTA）**模式。这种线程模型不匹配会导致控件初始化失败、资源泄漏，最终阻塞请求处理流程。你将图表生成逻辑放到新线程后问题解决，本质是避开了请求线程的MTA上下文冲突，让组件能在相对独立的线程环境中完成资源清理。

3. 文件资源锁定未释放
   你的代码中，Chart.SaveImage执行后，控件依赖的GDI+资源在服务器环境下可能没有被正确释放，导致目标文件句柄被持续占用。后续你用FileShare.None打开文件流时，会因为文件被锁定而无法正常读取或触发DeleteOnClose逻辑，请求线程因此无法完成响应发送，最终陷入阻塞状态。

针对你的代码的优化建议： #

• 显式销毁Chart控件：在SaveImage后调用oCh.Dispose()，强制释放GDI+资源和文件句柄
• 替换为服务器端兼容的组件：避免使用WinForms Chart，改用OxyPlot、ScottPlot等专为服务器端设计的图表库
• 调整文件流参数：将FileShare.None改为FileShare.Read，降低文件锁定的严格程度（确保无其他写入操作的前提下）

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