Web服务循环执行任务时触发线程中止异常，寻求排查方案

首先，"Thread was being aborted"异常几乎都是线程被外部强制终止的信号，结合你的IIS托管场景，最可能的原因有这几个：

1. IIS应用池回收 #

IIS默认会定期回收应用池（默认29小时），或者在内存占用过高、请求队列过长等条件触发时自动回收。回收过程中，IIS会中止应用池内所有正在运行的线程，如果你刚好在回收时机执行任务，就会抛出这个异常。

2. ASP.NET请求超时 #

如果你的ExecuteTasks方法是通过Web请求（比如Web API接口）触发的，ASP.NET有默认的请求超时时间（默认110秒）。如果任务执行总时间超过这个值，ASP.NET会强制中止请求线程，即使你手动创建了子线程，也可能被波及（尤其是子线程依赖请求上下文的情况下）。

3. Windows服务调用的超时或中断 #

虽然概率较低，但如果Windows服务调用Web服务时设置了超时，超时后强制终止请求，也可能导致Web服务端的线程被中止。

排查步骤 #

• 检查IIS应用池回收日志：在IIS管理器中找到你的应用池，进入「高级设置」，启用「生成回收事件日志」，然后查看日志路径（默认是%SystemDrive%\inetpub\logs\LogFiles\W3SVC<站点ID>），对比异常发生的时间和回收日志的时间，看是否吻合。
• 查看Windows事件日志：打开事件查看器，定位到「Windows日志 -> 应用程序」，搜索IIS或ASP.NET相关的警告/错误，比如应用池回收的记录、进程终止的原因。
• 添加异常捕获与日志：修改你的代码，给任务执行逻辑添加异常捕获，记录详细信息（时间、任务ID、堆栈），方便定位问题：

  public void ExecuteTasks() 
  { 
      var tf = new TasksFactory(); 
      var tasks = tf.GetPlaningTasks(); 
      foreach (var t in tasks) 
      { 
          var job = new ThreadStart(() => {
              try
              {
                  t.Execute();
              }
              catch (ThreadAbortException ex)
              {
                  // 替换成你的日志组件，比如Serilog、NLog
                  LogHelper.WriteError($"任务[{t.TaskId}]执行时线程被中止，时间：{DateTime.Now}", ex);
                  // 注意：尽量不要用Thread.ResetAbort()，这会取消中止信号，但可能导致资源泄漏
              }
              catch (Exception ex)
              {
                  LogHelper.WriteError($"任务[{t.TaskId}]执行失败", ex);
              }
          }); 
          var thread = new Thread(job); 
          thread.Start(); 
          Thread.Sleep(1000); 
      } 
  }
  

结合你的场景（每分钟执行定时任务），最推荐的方案是避免用IIS托管长时间/定时任务，因为IIS的设计目标是处理短周期的Web请求，不是后台任务引擎。下面分情况给出方案：

方案1：将任务执行逻辑迁移到Windows服务 #

既然已经有一个Windows服务在每分钟调用Web服务，不如直接把ExecuteTasks的逻辑移到这个Windows服务里：

• 移除Web服务中的任务执行代码，Windows服务直接调用TasksFactory获取任务并执行。
• 这样完全避开IIS应用池回收、请求超时等问题，定时任务的稳定性会大幅提升。

方案2：如果必须保留Web服务触发 #

如果因为某些原因不能迁移，可通过以下方式优化：

• 使用异步任务替代手动创建Thread：用Task.Run代替Thread，并确保任务脱离ASP.NET请求上下文（避免被请求超时影响）：

  public async Task ExecuteTasks() 
  { 
      var tf = new TasksFactory(); 
      var tasks = tf.GetPlaningTasks(); 
      foreach (var t in tasks) 
      {
          // 用Task.Run执行，脱离请求上下文
          _ = Task.Run(() => {
              try
              {
                  t.Execute();
              }
              catch (Exception ex)
              {
                  LogHelper.WriteError($"任务[{t.TaskId}]执行失败", ex);
              }
          });
          await Task.Delay(1000); // 用异步延迟替代Thread.Sleep
      } 
  }
  

• 调整IIS应用池配置：
  • 修改应用池的回收时间，避开任务执行的时间段（比如设置在凌晨2点回收，而任务是每分钟执行，避免冲突）。
  • 增加应用池的「关闭超时时间」（默认90秒），给线程足够的时间完成任务再回收。
• 引入消息队列解耦：Web服务只负责向消息队列发送任务触发消息，Windows服务监听队列并执行任务。这样即使Web服务的线程被中止，任务还是会在Windows服务中正常执行，完全解耦触发和执行逻辑。

方案3：优雅处理线程中止 #

当捕获到ThreadAbortException时，不要强行阻止中止，而是在异常处理中清理任务占用的资源（比如关闭数据库连接、释放文件句柄），让线程优雅退出。因为这个异常通常是进程要终止的信号，强行用Thread.ResetAbort()取消中止可能导致资源泄漏或数据不一致。

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