System.Threading.Timer一看这个类名很多人第一反应是“又一个定时器”然后就开始往项目里复制粘贴代码。但实际开发里我见过太多人因为它踩了坑——回调不执行、UI卡死、内存泄漏、定时不准。这玩意儿和WinForms里的Timer完全是两回事用错了轻则功能异常重则直接把进程拖垮。这篇文章我就把这几年用System.Threading.Timer做上位机、工业通讯、后台轮询任务的实战经验整理出来把它的原理、用法、坑点一次说清楚。适合刚接触C#的新手也适合写过几个定时器但一直没搞明白为什么“有时灵有时不灵”的开发者。1. 先搞清楚System.Threading.Timer到底是什么1.1 它不是“定时执行”而是“在线程池里排队执行”这是理解System.Threading.Timer最关键的一点。它和我们熟悉的WinForms里的TimerSystem.Windows.Forms.Timer有着本质区别。WinForms的Timer是跑在UI线程上的它的Tick事件会在界面消息循环里触发所以你可以在Tick事件里直接操作控件。但System.Threading.Timer完全不同——它跑在线程池ThreadPool上。每次时间到了它会从线程池里抓一个线程来执行你的回调方法。这意味着三件事第一回调方法不跑在UI线程直接操作控件会抛异常或者界面假死第二回调方法的执行时机由线程池调度决定理论上有延迟第三回调方法的执行不会阻塞主线程UI照常响应。看它的构造函数就明白了Timer(TimerCallback callback, object state, int dueTime, int period)callback时间到了要执行的方法state传给回调方法的状态参数可以传nulldueTime延迟多久后开始第一次执行单位毫秒0表示立即period周期单位毫秒每次执行完再过period毫秒执行下一次一个典型的用法是这样var timer new System.Threading.Timer( state Console.WriteLine($线程池线程执行: {DateTime.Now:HH:mm:ss.fff}线程ID: {Thread.CurrentThread.ManagedThreadId}), null, TimeSpan.FromSeconds(2), TimeSpan.FromSeconds(1) ); Console.ReadLine();这里dueTime是2秒——等2秒才第一次回调之后每隔1秒执行一次。1.2 为什么要用线程池的定时器有人会问我用Thread.Sleep加死循环不行吗或者用Task.Delay不行吗用Thread.Sleep的方式每条线程在等待期间都是占用状态的——它不干活但资源牢牢占着不放。如果你有10个定时任务就要维护10条线程在那干等。System.Threading.Timer所依赖的线程池就是为了解决“大量短小任务不能占用太多线程”的问题。时间到之前池里的线程都回去待命真正该干活的时候才被唤醒。这和现实中请临时工干活一个道理活来了叫人过来活干完让人回去而不是雇十个人在公司原地待命。1.3 和另外两个“Timer”的区别我写C#这几年最大的困惑之一就是“怎么这么多Timer”。实际上.NET里有三套常用定时器用途完全不同定时器类型运行线程适用场景注意点System.Windows.Forms.TimerUI线程控件更新、界面轮询时间到但UI忙时事件会延后甚至丢System.Timers.Timer线程池服务端后台任务、日志写入有AutoReset属性可以只触发一次但默认陷阱是异常会中断System.Threading.Timer线程池高精度周期任务、回调形式需要自己处理异常最灵活也最底层System.Threading.Timer是所有定时器里最“轻”的——它对线程的使用是池化的本身也不依赖任何消息循环。对于纯计算、数据采集、状态轮询这类不涉及界面的场景它是最合适的选择。2. 真正用起来之前先搞懂回调的运作机制2.1 state参数是传数据的关键TimerCallback委托有个object类型的state参数这个设计很多新手看不懂。它的意义是回调方法执行时所需要的上下文数据可以通过state传进去省得写一个成员变量到处改。比如你要定时采集某个串口设备的数据设备名称就在回调里用var timer new System.Threading.Timer( DevicePolling, COM3, 0, 1000 ); static void DevicePolling(object state) { var portName state as string; Console.WriteLine($正在轮询设备: {portName}); }比闭包捕获变量更省事也避免了闭包内变量被GC误回收的潜在问题。state参数理论上可以是任意类型但建议只传纯数据对象不要传IDisposable资源进去否则回调里要负责释放很容易造成资源泄漏。2.2 Change方法动态调整下一次执行时间Period是构造时定的但实际项目里经常遇到“定时器的频率要动态变化”的需求——比如程序启动时轮询频率快状态稳定后调低。Change方法就是干这个的timer.Change(Timeout.Infinite, Timeout.Infinite); // 暂停 timer.Change(0, 500); // 立即重启每500ms一次第一个参数是dueTime第二个是period。Change方法的名字很形象——修改下一次执行的到期时间。我做过一个设备状态监测程序要求连接正常时每2秒上报一次状态断开重连期间每500毫秒快速探测一次。当时就是在回调里检测到连接状态变化后调用Change调整周期实现的。但要注意一个细节Change方法执行后正在执行中的回调不会被中断。如果回调刚开跑你调了Change这次回调还是会把剩余代码跑完只有下一次触发才能按新周期走。2.3 回调默认不重入但你挡不住它堆积周期设为1000ms回调本身执行了3秒会发生什么——第二次回调并不会在下一个周期点强制执行。.NET的底层设计是当上一个回调还在执行时下一次触发会跳过不会并发执行同一个Timer的回调。听起来很安全对吧但实际有个坑如果你把period设成1000回调耗时3000那这个定时器会变成“每3秒多执行一次”而不是“每1秒一次”。如果你的业务逻辑要求“无论如何每1秒必须触发一次”用这个定时器就不合适了它只保证“不重叠”不保证“准时”。更隐蔽的问题是回调排队。如果线程池很忙回调也可能延迟执行或者发生回调堆积。这个后面第五节详说。2.4 回调里的异常必须自己消化这是新手最容易忽视的一点。WinForms的Timer出异常会弹到界面上还能看到。但System.Threading.Timer的回调发生在线程池线程默认情况下异常不会抛到主线程你根本察觉不到可怕的是Timer会“安静死”——异常发生后回调被终止之后的回调不再执行进程不崩溃看起来一切正常定时器还在但已经变成废的所以回调方法里必须用try-catch把所有可能异常包住这是我的铁律。static void RepeatingTask(object state) { try { // 实际业务逻辑 DoSomething(); } catch (Exception ex) { // 记录日志至少不能让它静默死掉 Logger.Error(ex, 定时任务执行异常); } }3. 从零写一个标准定时采集任务3.1 需求定义我拿一个真实案例来串整个流程。之前做的一个上位机系统需要每秒读取一次仪表的温度数据写入日志并且每60秒统计一次历史平均值。看起来很简单但有几个问题必须在设计阶段就确定定时器持有的对象何时释放回调里读数据失败怎么处理时间不准怎么办3.2 完整实现先定义采集任务的核心逻辑public class TemperatureMonitor : IDisposable { private System.Threading.Timer _timer; private readonly object _syncRoot new object(); private readonly Listdouble _history new Listdouble(); private volatile bool _isRunning; public void Start() { if (_isRunning) return; _isRunning true; _timer new System.Threading.Timer( Callback, null, TimeSpan.Zero, // 立即执行一次 TimeSpan.FromSeconds(1) // 然后每1秒一次 ); } private void Callback(object state) { try { var temperature ReadTemperature(); lock (_syncRoot) { _history.Add(temperature); } Console.WriteLine($[采集] {DateTime.Now:HH:mm:ss.fff} 温度 {temperature:F2}℃); // 每60个点统计一次平均值 if (_history.Count % 60 0) { var avg CalculateAverage(); Console.WriteLine($[统计] 近60秒平均温度 {avg:F2}℃); } } catch (Exception ex) { Console.WriteLine($[错误] {ex.Message}); } } private double ReadTemperature() { // 实际项目里这里是读Modbus寄存器或串口 Thread.Sleep(80); // 模拟读取耗时 return 20 Random.Shared.NextDouble() * 10; } private double CalculateAverage() { lock (_syncRoot) { return _history.TakeLast(60).Average(); } } public void Dispose() { _isRunning false; _timer?.Dispose(); _timer null; } }有人会问回调里加了Thread.Sleep(80)间隔1秒的定时器不会乱吗——不会。上面说过回调不重叠下一个回调会等这个ReadTemperature返回后再开始计时。所以实际周期变成了1080ms左右但如果你对周期绝对准时没有要求这个误差完全可以接受。3.3 state对象和闭包哪个更好用上面代码里state直接传了null回调里用的是捕获的实例状态。实际项目里如果回调逻辑依赖很多外部变量用启动时创建的Context对象作为state更清晰var context new DeviceContext(deviceId: 1, threshold: 30.0); var timer new System.Threading.Timer( context { var ctx context as DeviceContext; // ... }, context, 0, 1000 );当你的定时器要在多个地方复用同一个回调方法时state的优势会非常明显它让回调方法成为一个“传入什么就处理什么”的纯逻辑单元也更方便做单元测试。3.4 什么时候真正开始计时构造函数里的dueTime如果是Timeout.Infinite那定时器创建后不会启动等待。只有调用Change才会激活。创建后立即调用timer.Change(0, 1000)和构造函数直接传0效果一样但有一种情况你必须用Change——定时器要等某个条件满足后才开始比如等待配置文件加载成功再启动轮询。还有一点Timer构造函数创建的实例不会被GC回收只要它还在运行。因为它在线程池里有根引用。这个很多人以为“创建了但没存引用就能被回收”完全错了。定时器只会因为Dispose停止不会因为没人引用它就不跑了。4. 精度问题能不能精确到1ms4.1 默认情况下别奢望1ms网上有人问“C# 定时器精准到 1ms 做什么方案好”。我直接说结论System.Threading.Timer在普通Windows系统默认环境下精度根本到不了1ms。它的底层计时精度取决于操作系统的时钟粒度而Windows的默认时钟中断周期是15.6ms。也就是说理想情况下它最准也就15毫秒左右。测试表现就是这样明明设了10ms周期实际触发间隔可能在15-16ms附近波动。这不是.NET的问题是操作系统级别的精度限制。4.2 硬实时要求怎么处理如果你真的需要稳定到1ms级别的调度路子主要是调用Windows的timeBeginPeriod(1)把系统时钟周期降到1ms。很多用NAudio处理音频的程序就是这么做的。但要注意这会增加系统整体功耗和中断频率工业现场没什么问题笔记本上你要掂量一下。改用多媒体定时器Windows Multimedia Timer或Stopwatch自旋等待的组合。后者精度能到微秒级但它会占满一个CPU核而且代码写得不好会有严重的功耗问题。C#侧启用高精度的典型代码是[DllImport(winmm.dll)] private static extern uint timeBeginPeriod(int period); [DllImport(winmm.dll)] private static extern uint timeEndPeriod(int period); // 启动时 timeBeginPeriod(1); // 程序退出时 timeEndPeriod(1);调完timeBeginPeriod(1)之后System.Threading.Timer的触发间隔会明显更接近设定的值。我自己实测下来1ms周期的抖动大概在±1ms左右作为上位机轮询可以接受做PLC运动控制还是老老实实走实时系统吧。4.3 简化的精度测试方法想知道你当前环境的实际可用精度写个简单的测试就行var sw new System.Diagnostics.Stopwatch(); var timer null as System.Threading.Timer; var lastTick 0L; timer new System.Threading.Timer(_ { if (lastTick 0) { sw.Start(); lastTick sw.Elapsed.Ticks; return; } var now sw.Elapsed.Ticks; var intervalMs (now - lastTick) / 10000.0; Console.WriteLine($实际间隔: {intervalMs:F3} ms); lastTick now; }, null, 0, 1); Console.ReadLine(); timer.Dispose();把这个测试在你的目标机器上跑一遍再决定你到底该不该用这个类的默认精度。能用就省事不能用就趁早换方案。5. 实战场景上位机、扫码枪、UI交互5.1 要更新UI先回到UI线程System.Threading.Timer的回调跑在线程池。如果你直接在回调里写textBox.Text xxxWinForms里会抛InvalidOperationExceptionWPF也类似。标准做法是用Control.BeginInvoke把更新动作丢回UI线程TimerCallback callback state { // 耗时的采集逻辑跑在线程池里 var value ReadFromDevice(); // 更新UI必须回UI线程 textBox.BeginInvoke(new Action(() { textBox.Text value.ToString(); })); };这个模式的核心思想是脏活累活在线程池干碰UI那一刻才回主线程。如果你反过来在UI事件里搞耗时操作界面马上卡给你看。5.2 上位机数据采集的经典模式在我的上位机项目里常用做法是“System.Threading.Timer做后台采样UI定时器做界面刷新”。后台采集线程把数据放进并发队列UI界面每100ms拉一次队列渲染。这样的好处是后台采集频率和界面刷新频率解耦了界面卡顿不会影响数据采集数据采集的节奏也不会被界面拖累。// 后台采集 var samplingTimer new System.Threading.Timer(_ { var data ReadAllSensors(); _dataQueue.Enqueue(data); }, null, 0, 50); // 20Hz采样 // UI刷新用System.Windows.Forms.Timer var uiTimer new System.Windows.Forms.Timer { Interval 100 }; uiTimer.Tick (s, e) { while (_dataQueue.TryDequeue(out var data)) { RenderChart(data); } }; uiTimer.Start();这种组合我用了很多年稳定、清晰几乎不会出线程问题。5.3 扫码枪触发事件的定时超时组合还有朋友问“C# 扫码枪触发事件怎么做”。扫码枪本质是个键盘输入设备靠硬件的字符事件很难判断“一次完整扫完了没”。更可靠的方案是在串口或HID事件里累积字符每次字符到达时重置一个超时定时器——超过300ms没有新字符进来就认为一帧扫完了。这里System.Threading.Timer派上用场了。每次收到字符调用timer.Change(300, Timeout.Infinite)——300ms内没新字符回调执行表示一帧扫码完成。private System.Threading.Timer _scanTimer; public void Init() { _scanTimer new System.Threading.Timer(ScanTimeoutCallback, null, Timeout.Infinite, Timeout.Infinite); } private void OnScannerDataReceived(string chunk) { _inputBuffer.Append(chunk); // 重置为300ms后触发一次period设为Infinite _scanTimer.Change(300, Timeout.Infinite); } private void ScanTimeoutCallback(object state) { var fullCode _inputBuffer.ToString(); _inputBuffer.Clear(); BeginInvoke(new Action(() { textBoxCode.Text fullCode; })); }这里用到了Timeout.Infinite作period意思就是“只触发一次”每次靠Change重新激活。这个模式在串口分包、扫码拼接、键盘组合键识别里都挺好使。5.4 事件驱动与定时轮询的取舍有些场景更适合用事件而不是定时器。比如某个变量的数值变化你用定时器每100ms去检查一次也不是不行但平白无故多了100ms延迟而且大量创建定时器轮询变量会拉低CPU效率。C# 里检测变量数值变化最优雅的是事件驱动public class ValueNotifier : INotifyPropertyChanged { private int _value; public int Value { get _value; set { if (_value ! value) { _value value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Value))); } } } public event PropertyChangedEventHandler PropertyChanged; }事件通知做不到的是外部设备没有通知机制的情况——硬件寄存器变了它可不会发个事件给你。这时候定时器轮询依然是唯一选择。我一般遵循的原则是系统内部状态变化用事件外部世界未知变化用定时器。6. 常见问题与排查技巧实录6.1 定时器不执行或只执行一次新手常犯的一个错误是定时器对象作为局部变量方法执行完就被GC回收了。上面提过运行中的Timer有线程池根引用一般不会被回收但如果你在调试器里看到定时器“好像失效了”先检查是不是忘了保存引用或者哪个地方调用了Dispose。另外dueTime和period别混了。看过不少代码把1000填到dueTime把0填到period——结果定时器“马上执行了一次就再也不触发”。period为0的话表示只执行一次。6.2 为什么锁屏之后定时器就不准了有朋友遇到“Windows锁屏定时器失效”。这很正常系统为了省电锁屏后会让CPU进入低功耗模式很多定时任务被合并或延后。如果你的程序在锁屏后仍然需要保持精确计时必须调用一些控制电源状态的API或者告诉系统你的程序需要保持完全运行状态。普通应用无解涉及工控场景的话建议在设备管理器电源设置里把相关设备的“允许计算机关闭此设备以节约电源”关掉。6.3 性能排查回调耗时不能太长我不能太强调这一点回调里的代码应该短而快。System.Threading.Timer的回调一旦耗时太长带来的问题不只是延迟线程池线程可能被占满其他Timer回调也开始排队如果发生回调堆积系统内存占用会飙升日志文件可能被频繁写入撑爆磁盘排查方法很传统——在回调第一行和最后一行业务结束时打印耗时或者用性能计数器监控。我习惯在生产代码里加一个简单的耗时统计private void Callback(object state) { var sw System.Diagnostics.Stopwatch.StartNew(); try { // ... } finally { if (sw.ElapsedMilliseconds 500) { Logger.Warn($定时回调执行超过500ms实际耗时: {sw.ElapsedMilliseconds}ms); } } }6.4 高频定时器下的线程池饥饿线程池默认最小线程数和CPU核数相关。如果你有大量的Timer同时运行比如上百个线程池可能会来不及创建足够线程。写高频周期的定时任务时务必先回调里做个简单的负载检查该并发就并发不该并发就排队。6.5 常见异常速查症状可能原因解决方案回调从未触发dueTime设成Infinite没调用Change确认构造函数参数或者调timer.Change(0, period)只触发一次period设成了Timeout.Infinite确认period不为Infinite界面卡死回调里操作了UI控件改用BeginInvoke或者用UI线程的定时器UI更新抛异常回调线程不是UI线程用Control.Invoke/BeginInvoke切换线程程序退出后进程还在跑Timer没Dispose实现IDisposable退出时调用Dispose频率明显偏低回调耗时长于period重写回调逻辑或改用异步方式7. 写在最后的几个实用拾遗托管资源的释放顺序有讲究。Dispose定时器之后要等正在执行的回调跑完再释放它依赖的资源。否则回调还在用串口你把串口关掉了就会出现随机异常。稳妥的写法是先调用_timer.Dispose(new ManualResetEvent(false))等回调全部结束再往下走。Dispose有个重载可以等待回调结束。timer.Dispose(WaitHandle notifyObject)回调结束后通知对应的WaitHandle。用它能让你的资源释放顺序非常可控。state传值尽量只用只读对象。回调可能并发执行不同的Timer或者同一个回调挂在多个Timer上改共享状态要加锁。System.Threading.Timer没有Start/Stop方法。它通过Change来控制启停忘了这一点的开发者很容易把WinForms.Timer的用法套过来写编译错误。日志别在回调里写太多。曾有段时间日志文件在回调里每毫秒写一条直接把SSD的IO打满了。我用System.Threading.Timer做上位机、做数据采集、做超时控制前前后后踩了很多坑上面这些内容基本都是实战中总结出来的。定时器这个东西看起来是个简单的API用好了它是项目的骨架和节拍器用不好就是在系统里埋雷。希望这篇文章能帮你少走一些弯路。