.NET 8 WPF应用突发CPU内存飙升，大量TimerQueueTimer对象堆积求助

以下是针对WPF场景下TimerQueueTimer大量堆积导致内存/CPU飙升的具体排查方案：

• 定位Timer创建的代码路径
  使用Visual Studio性能分析器的「.NET对象分配追踪」功能，启动应用后持续追踪到问题出现，筛选TimerQueueTimer的分配记录，查看其调用堆栈，直接定位到创建Timer的代码位置。也可以用dotTrace、PerfView等工具收集ETW事件，聚焦Timer相关的创建/销毁事件，明确泄漏来源。

• 排查WPF Timer的误用场景

  • 检查DispatcherTimer：页面/窗口关闭时是否调用了Stop()并解除了事件绑定？若未清理，Timer会持有窗口/ViewModel引用，导致两者都无法被GC回收。
  • 检查System.Threading.Timer：是否存在创建后未调用Dispose()的情况？尤其是后台任务中创建的Timer，若未正确释放，会持续存在于Timer队列中。
  • 排查第三方依赖：确认所用MVVM框架、日志库、网络组件等是否存在内部Timer泄漏的情况，可临时禁用第三方组件测试问题是否消失。

• 验证.NET 8框架的已知问题
  查看.NET官方GitHub Issues和.NET 8补丁版本说明，确认是否存在WPF场景下TimerQueueTimer无法被回收的已知Bug。若有对应补丁，升级到最新的.NET 8 patch版本；也可临时降级到.NET 7测试，判断问题是否为.NET 8特定引入。

• 手动审计代码中的Timer生命周期
  全局搜索代码中创建Timer的逻辑（new DispatcherTimer()、new Timer()等），逐一检查：

  • Timer是否在不再需要时被Dispose()？
  • 是否存在静态Timer被长期持有，导致无法回收？
  • Timer回调是否捕获了长生命周期对象（如Window、ViewModel实例），形成循环引用？

• 深度分析内存快照的引用链
  在内存快照中选中TimerQueueTimer实例，查看其引用链（右键选择「显示引用」），找到持有Timer的根对象（如静态集合、未销毁的ViewModel），顺着引用链即可定位到泄漏的根源。

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