Windows服务Timer回调致ThreadPoolWaitCallback高CPU问题排查

你对同步执行的认知确实存在偏差，但高CPU问题和你有没有给事件处理方法加async关键字没有直接关系。

• 首先明确：System.Timers.Timer的Elapsed事件本身就是由线程池调度触发的，回调执行天然走_ThreadPoolWaitCallback调度路径，这就是你性能报告里看到mscorlib.ni模块下该函数占比极高的原因，和方法加不加async无关。
• 核心问题99%出在你三个工作线程方法的重入校验逻辑有线程安全漏洞，这也是这类"跑一段时间CPU打满、重启恢复、空负载也高占用"现象的最常见诱因。
  绝大多数开发者写的重入校验都是用普通bool字段做标记，既没有加锁，也没有做原子访问保护，存在典型的竞态条件：当Timer回调在线程池上执行时，多个并发的回调可能同时读到"线程未运行"的标记值，同时启动新的工作线程。虽然你说大部分场景下工作线程启动后会立即退出，但随着服务运行时间拉长，线程池里会堆积越来越多的待调度工作项、产生巨量的线程上下文切换和调度开销，最终CPU占用会冲到90%以上。
  典型的错误重入实现如下，你可以对照自己的代码排查：

  // 线程不安全的重入校验，必然出现漏判
  private bool _bulkThreadRunning = false;
  private void StartBulkThread()
  {
      if (_bulkThreadRunning) return; // 多线程并发下，多个线程会同时判断为false
      _bulkThreadRunning = true;
      ThreadPool.QueueUserWorkItem(_ =>
      {
          // 业务逻辑，多数场景直接退出
          _bulkThreadRunning = false;
      });
  }
  

  这种实现下，Timer每60秒触发一次，每次都可能多启动数个冗余工作线程，跑几小时后堆积的线程池工作项足够把CPU资源吃满，和你现在靠6小时重启临时规避的现象完全吻合。

验证与修复方案 #

• 先做快速验证：在三个Start*方法的入口、工作线程逻辑的起始位置加调试日志，打印当前线程ID和触发时间，运行10到20分钟统计日志，就能看到实际启动的工作线程数量远大于你预期的1个/每类线程。
• 把重入校验替换为原子操作实现，彻底消除竞态，参考代码如下：

  // 用int做状态标记，0=未运行，1=运行中
  private int _bulkThreadRunning = 0;
  private void StartBulkThread()
  {
      // 原子操作：仅当标记为0时，将其改为1，返回修改前的值，全程无线程安全问题
      if (Interlocked.CompareExchange(ref _bulkThreadRunning, 1, 0) != 0)
      {
          return;
      }
      ThreadPool.QueueUserWorkItem(_ =>
      {
          try
          {
              // 写入实际业务逻辑
          }
          finally
          {
              // 无论业务逻辑是否抛异常，都要重置运行标记，避免死锁
              Interlocked.Exchange(ref _bulkThreadRunning, 0);
          }
      });
  }
  

• 额外防护：将Timer的AutoReset属性设为false，等本次Elapsed回调里的所有逻辑（包括三个工作线程的启动逻辑）全部执行完成后，再手动调用Timer.Start()触发下一轮计时，从Timer调度层面彻底杜绝回调排队重入的可能。

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