ASP.NET后台长运行线程在IIS中被终止的原因及解决方案

问题确认 #

是IIS导致的线程终止。IIS的应用程序池回收机制会定期终止整个应用进程（默认固定间隔1740分钟，也可能因空闲超时、资源阈值触发），进程终止时所有线程都会被强制中止，就会出现Thread was being aborted错误。你的后台线程标记为Background=true，进程终止时会直接被销毁，无法存活。

解决方案 #

方案1：调整IIS应用程序池配置，减少回收触发

• 关闭固定时间回收：打开IIS管理器，找到对应应用程序池→高级设置→回收，取消勾选「固定时间间隔（分钟）」。
• 延长空闲超时：在高级设置→进程模型中，将「空闲超时（分钟）」设为极大值（如14400，即10天），或设为0表示永不因空闲回收。
• 设置启动模式为「AlwaysRunning」：同样在进程模型中，将「启动模式」改为AlwaysRunning，IIS会保持进程持续运行，即使没有HTTP请求。
• 禁用资源触发回收：如果是内存/CPU阈值触发的回收，可在回收选项中取消对应阈值的勾选，或调高阈值。

方案2：将Socket监听逻辑迁移至独立服务（推荐）

ASP.NET应用的设计目标是处理HTTP请求，不适合长期运行的后台任务。最可靠的方式是把Socket监听部分做成Windows服务（.NET Framework可直接创建Windows Service项目）：

• Windows服务是独立于IIS的系统进程，不受IIS回收机制影响，能稳定运行数年。
• 服务与ASP.NET MVC应用间可通过SignalR、数据库或本地消息队列通信，实现数据同步和进程监控。

方案3：使用后台任务框架（次选）

如果暂时不想迁移到Windows服务，可使用Hangfire（支持.NET Framework）管理后台任务：

• Hangfire能在应用程序池回收后自动重启任务，一定程度上保证监听逻辑的持续性。
• 但Hangfire仍依赖ASP.NET进程，若IIS强制回收，任务仍会短暂中断，可靠性不如独立服务。

额外注意事项 #

• 不要在ASP.NET中手动创建后台线程：ASP.NET运行时会管理线程池，手动线程不受控制，易引发资源泄漏或意外终止。
• 即使调整IIS配置，仍可能因服务器重启、应用崩溃等原因导致进程终止，因此独立服务是长时任务的最优选择。

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