哪些场景会触发FireQueuedTimerCompletion工作项？WCF等组件是否相关？

System.Threading.TimerQueue.FireQueuedTimerCompletion 工作项并非仅来自手动创建的Timer，WCF、WebAPI、SignalR的内置组件都会大量依赖这个Timer机制，是它们核心逻辑的一部分，这些组件的Timer任务堆积也可能导致服务挂起。

各组件的Timer使用场景 #

• WCF：内部用Timer处理会话超时回收、连接心跳检测、异步操作超时回调、服务实例的定期清理。如果服务存在大量未正常关闭的会话，或者超时参数配置得过长/过短，都会导致Timer任务持续堆积。
• WebAPI：旧版基于OWIN的WebAPI会用Timer处理请求超时、缓存过期清理，部分扩展的后台定期任务也依赖Timer。此外，异步控制器的异步操作完成回调也可能通过Timer队列调度。
• SignalR：属于Timer重度依赖组件，核心场景包括：
  • 客户端连接的心跳Ping/Pong检测，维持长连接活性
  • 延迟消息推送、离线消息的重试调度
  • 长时间无响应客户端的连接清理
  • 后台的集群状态同步任务

任务堆积引发挂起的原因 #

当FireQueuedTimerCompletion工作项大量堆积时，通常是因为：

• Timer回调逻辑执行过慢、阻塞甚至死锁，导致线程池线程被占用无法释放
• Timer被频繁创建但未正确调用Dispose释放，导致Timer实例持续存在并不断触发任务
• 组件配置不合理（比如SignalR心跳间隔过短、WCF会话超时过长），导致Timer任务的生成速度远大于处理速度

排查方向 #

1. 分析内存转储中这些Timer任务的关联对象，定位具体是哪个组件（或手动代码）创建的Timer
2. 核对WCF、SignalR、WebAPI的超时/心跳配置，调整到合理范围
3. 检查Timer回调逻辑是否存在阻塞、IO等待未异步化、死锁等问题
4. 确认手动创建的Timer都已在生命周期结束时调用Dispose释放资源

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