1. 为什么“定时器”这件事值得单独拎出来聊C#里做定时任务很多人第一反应就是System.Timers.Timer或者System.Threading.Timer再老一点的项目里还能见到System.Windows.Forms.Timer。表面上看它们都叫Timer都带Interval和Tick/Elapsed好像随便挑一个就能跑。但我自己踩过的坑是同一个逻辑换一个Timer实现程序行为可能完全不一样——有的回调在UI线程上跑有的在线程池线程上跑有的会重入有的不会有的在Dispose之后还会再触发一次。这篇文章我想把C#里常见的几种定时器彻底掰开讲清楚它们分别是什么、底层靠什么驱动、回调跑在哪个线程、什么场景该用哪个、哪些坑是文档里不会写但实际项目一定会遇到的。内容会覆盖System.Windows.Forms.Timer、System.Timers.Timer、System.Threading.Timer、System.Threading.PeriodicTimer以及顺带提一下DispatcherTimer和Observable.Timer这类在特定框架里常见的实现。适合已经写过一点C#、但被定时器线程模型和重入问题折腾过的开发者也适合刚开始接触异步编程、想搞清楚“为什么我的定时任务会卡住界面”的朋友。我尽量不写成API手册而是按“我实际会怎么选、怎么用、怎么排错”的顺序来讲。每个结论我都会说清楚背后的原因涉及参数的地方会把计算过程写出来方便你直接抄作业。2. 先把“定时器”这件事的本质说透2.1 定时器到底在做什么很多人以为定时器是“每隔N毫秒执行一次代码”这个理解只对了一半。更准确的说法是定时器负责在时间到达时把一个“通知”投递到某个执行上下文里至于这个通知由谁处理、在哪个线程处理、处理期间下一次通知会不会来完全取决于具体实现。这就像你设了一个闹钟。闹钟本身只负责响响完之后你是立刻起床、还是按掉再睡五分钟、还是让闹钟响着同时去刷牙是你自己的事。C#里不同Timer的差别本质上就是“闹钟响在哪个房间”和“响的时候你手上正忙着怎么办”。理解这一点之后很多看似奇怪的现象就说得通了。比如System.Windows.Forms.Timer的Tick为什么能直接改控件因为它的通知是通过Windows消息队列投递的天然就在UI线程上。而System.Threading.Timer的回调为什么不能碰控件因为它在ThreadPool线程上跨线程访问UI会抛异常。2.2 三个核心维度线程、重入、生命周期判断一个定时器适不适合你的场景我一般只看三个维度。第一个是回调线程。回调跑在UI线程、ThreadPool线程还是专用线程决定了你能在里面做什么。碰UI的必须回UI线程做纯计算的放ThreadPool更合适需要长时间阻塞的则要考虑专用线程。第二个是是否允许重入。所谓重入就是上一次回调还没执行完下一次定时又到了于是同一个回调被并发执行。System.Threading.Timer默认是允许重入的这一点坑了无数人。System.Timers.Timer通过AutoReset和内部同步机制在一定程度上缓解但也不是绝对安全。第三个是生命周期管理。Timer什么时候开始、什么时候停、Dispose之后还会不会触发、被GC回收后会不会突然不工作了这些都需要明确。尤其是System.Threading.Timer如果只创建不持有引用它可能被垃圾回收导致定时任务莫名其妙停掉。把这三个维度想清楚选型基本就不会错。3. 四种主流定时器逐一拆解3.1 System.Windows.Forms.TimerUI场景的专用工具这个Timer是WinForms时代的产物特点是简单、安全、但精度差。它的Interval单位是毫秒底层依赖Windows的SetTimer和WM_TIMER消息。消息进入UI消息队列后由消息循环分发所以Tick回调天然在UI线程上执行。它的优点很明确在Tick里直接改Label、改ProgressBar、刷新DataGridView都不需要Invoke写起来非常顺手。对于做进度条动画、定时刷新界面状态这类需求它是最省心的选择。但它的缺点同样明显。第一精度低Interval设成100毫秒实际间隔可能是100到200毫秒之间波动因为WM_TIMER消息的优先级很低UI忙的时候会被压后。第二Tick是同步执行的如果Tick里的代码耗时超过Interval界面会直接卡住因为UI线程被占用了。第三它只能在有消息循环的线程上工作控制台程序里用不了。我一般这样用它只在WinForms项目里做界面相关的轻量刷新Tick里的逻辑控制在几毫秒内完成绝不在这里做IO或复杂计算。如果确实需要做重活就在Tick里发一个异步任务出去让ThreadPool去处理。// WinForms场景下的典型用法 private System.Windows.Forms.Timer uiTimer; private void InitTimer() { uiTimer new System.Windows.Forms.Timer(); uiTimer.Interval 500; // 500毫秒刷新一次 uiTimer.Tick (s, e) { // 这里在UI线程可以直接操作控件 lblStatus.Text $当前时间{DateTime.Now:HH:mm:ss}; }; uiTimer.Start(); } private void Form_FormClosing(object sender, FormClosingEventArgs e) { uiTimer.Stop(); uiTimer.Dispose(); }注意System.Windows.Forms.Timer的Tick事件如果执行时间超过Interval下一次Tick不会排队等待而是直接跳过或延后具体行为取决于消息队列状态。所以不要指望它做精确的周期控制。3.2 System.Timers.Timer服务端和后台任务的常客System.Timers.Timer是我在写Windows服务、后台守护任务时用得最多的一个。它默认使用ThreadPool线程执行Elapsed回调AutoReset默认为true也就是会自动重复触发。它比System.Threading.Timer多了一层封装有SynchronizingObject属性可以把回调marshal到指定线程有AutoReset控制是否重复有Enabled属性控制启停。这些封装让它在很多场景下比System.Threading.Timer更好用。但它也有自己的坑。最典型的是Elapsed回调如果执行时间超过Interval下一次回调会在另一个ThreadPool线程上并发执行导致重入。很多人以为设置了AutoReset true就万事大吉其实不是。要避免重入要么在回调里加锁要么把AutoReset设为false在回调结束时手动再Start一次。// 避免重入的写法AutoReset false 手动重启 private System.Timers.Timer safeTimer; private readonly object timerLock new object(); private void InitSafeTimer() { safeTimer new System.Timers.Timer(1000); safeTimer.AutoReset false; // 关键不自动重复 safeTimer.Elapsed OnElapsed; safeTimer.Start(); } private void OnElapsed(object sender, System.Timers.ElapsedEventArgs e) { lock (timerLock) { try { // 执行你的业务逻辑 DoWork(); } finally { // 无论成功失败都重新启动保证下一次触发 safeTimer.Start(); } } }这种写法的好处是上一次没执行完下一次绝对不会进来因为Timer根本没在跑。缺点是如果DoWork耗时很长实际周期会变成“执行时间 Interval”而不是固定Interval。这一点在做心跳、轮询这类任务时要特别注意。3.3 System.Threading.Timer最底层也最灵活System.Threading.Timer是所有Timer里最轻量的直接基于ThreadPool没有事件模型构造时就要传入回调委托。它的Change方法可以动态调整首次触发时间和周期非常灵活。它的回调默认在ThreadPool线程上执行允许重入而且如果回调抛异常异常会直接终止进程在.NET Framework里尤其明显。这一点非常危险所以我在用它的时侯回调里一定包一层try-catch。另一个大坑是生命周期。如果你这样写// 危险写法Timer可能被GC回收 private void StartBadTimer() { var timer new System.Threading.Timer( callback: _ Console.WriteLine(tick), state: null, dueTime: 0, period: 1000); // timer是局部变量方法结束后没有引用可能被GC回收 }这个Timer可能在某个时刻被垃圾回收导致定时任务无声无息地停掉。正确做法是把Timer保存为字段或者在回调里保持对它的引用。// 正确写法持有引用 private System.Threading.Timer threadTimer; private void StartGoodTimer() { threadTimer new System.Threading.Timer( callback: OnThreadTimerTick, state: null, dueTime: 0, period: 1000); } private void OnThreadTimerTick(object state) { try { // 业务逻辑 } catch (Exception ex) { // 必须捕获异常否则可能终止进程 Console.WriteLine($Timer异常{ex.Message}); } } private void StopTimer() { threadTimer?.Change(Timeout.Infinite, Timeout.Infinite); threadTimer?.Dispose(); threadTimer null; }Change(Timeout.Infinite, Timeout.Infinite)是停止Timer的标准做法比直接Dispose更安全因为它会等待当前回调执行完。3.4 System.Threading.PeriodicTimer异步时代的正确姿势PeriodicTimer是.NET 6引入的专门为异步场景设计。它的用法和前面几个完全不同通过WaitForNextTickAsync异步等待下一次触发天然支持async/await而且不会重入——因为你要等上一次循环处理完才会进入下一次等待。// PeriodicTimer的典型用法 private async Task RunPeriodicTaskAsync(CancellationToken cancellationToken) { using var timer new PeriodicTimer(TimeSpan.FromSeconds(1)); while (await timer.WaitForNextTickAsync(cancellationToken)) { try { await DoWorkAsync(); } catch (Exception ex) { Console.WriteLine($任务异常{ex.Message}); } } }它的优势非常明显代码是线性的没有回调地狱没有重入问题异常处理自然取消通过CancellationToken统一管理。如果项目用的是.NET 6及以上我强烈建议新代码优先考虑它。但它也有局限。第一它需要异步上下文纯同步场景用起来反而别扭。第二它的精度依赖系统时钟和前面几个一样不是硬实时。第三如果DoWorkAsync耗时超过周期下一次Tick会立即触发因为等待已经完成实际周期会变成“执行时间”这一点和System.Timers.Timer的AutoResetfalse行为类似。4. 横向对比一张表看清差异光讲单个实现容易记混我把关键维度整理成表格方便你对照。特性WinForms.TimerSystem.Timers.TimerSystem.Threading.TimerPeriodicTimer回调线程UI线程ThreadPool可同步到指定线程ThreadPool调用WaitForNextTickAsync的上下文是否重入否UI线程串行默认可能重入默认可能重入否精度低约15ms起中等中等中等异常处理抛到UI线程可能终止进程可能终止进程由await处捕获生命周期需手动Stop/Dispose需手动Stop/Dispose需持有引用并Disposeusing或手动Dispose适用场景WinForms界面刷新后台服务、轮询底层定时、轻量任务.NET 6异步任务动态调整周期改Interval改IntervalChange方法不支持需重建这张表里我特别想强调“异常处理”这一行。System.Timers.Timer和System.Threading.Timer的回调如果抛出未捕获异常在.NET Framework下会直接导致进程崩溃在.NET Core/.NET 5下行为有所改善但仍然非常危险。我见过生产环境因为一个定时器回调里的空引用异常导致整个服务挂掉的情况排查了半天才发现是Timer没包try-catch。5. 选型思路我实际项目里怎么选5.1 按场景选而不是按喜好选我的选型逻辑很简单按场景走。如果是WinForms界面刷新无脑选System.Windows.Forms.Timer因为跨线程更新控件太麻烦用它最省事。如果是WPF对应的是DispatcherTimer逻辑一样。如果是后台服务里的周期性任务比如每分钟检查一次队列、每30秒发一次心跳优先考虑PeriodicTimer如果框架版本允许否则用System.Timers.Timer配合AutoReset false手动重启。如果是在类库底层做轻量定时不想引入事件模型用System.Threading.Timer但一定要持有引用、包异常、正确Dispose。如果是在控制台程序里做简单轮询System.Threading.Timer或PeriodicTimer都可以看是否需要异步。5.2 精度这件事别抱太大期望很多人问“哪个Timer最准”。我的答案是都不准至少不是硬实时级别的准。Windows不是实时操作系统ThreadPool调度、GC、系统负载都会影响实际触发时间。System.Threading.Timer和PeriodicTimer的精度大概在15毫秒左右System.Timers.Timer类似WinForms.Timer更差。如果你的业务需要毫秒级精度比如高频交易、音频处理那就不该用这些通用Timer而应该考虑专用线程加自旋等待或者依赖更底层的多媒体定时器。但绝大多数业务场景几十毫秒的抖动完全可以接受。5.3 关于Interval的计算Interval的单位是毫秒但实际周期不等于Interval。以System.Timers.Timer为例如果AutoReset true且回调执行时间为T那么实际周期约等于max(Interval, T)。如果回调执行时间小于Interval周期接近Interval如果大于周期就是T加上一些调度开销。举个例子Interval设为1000毫秒回调执行需要300毫秒那么实际周期大约是1000毫秒因为回调在1000毫秒内的前300毫秒完成剩下700毫秒空闲。但如果回调需要1500毫秒那么下一次触发会在回调完成后立即进行实际周期约1500毫秒。这个计算在设置心跳间隔时很重要。比如你想每5秒发一次心跳但心跳处理本身需要2秒那Interval设5000是合理的。但如果处理需要6秒那实际间隔会变成6秒以上可能导致服务端判定超时。6. 实操中一定会遇到的坑和排查方法6.1 定时器不触发或触发几次就停这是最常见的问题原因通常有三个。第一个是Timer被GC回收。System.Threading.Timer如果只被局部变量引用方法结束后就可能被回收。排查方法是把Timer改成字段或者用GC.KeepAlive临时验证。第二个是回调抛异常导致Timer停止。System.Timers.Timer在AutoReset true时如果回调抛异常Timer可能停止触发。排查方法是在回调入口加try-catch把异常打出来。第三个是Enabled或AutoReset设置错误。比如设了AutoReset false却忘了手动Start那就只会触发一次。6.2 回调重入导致数据错乱重入的典型表现是日志里同一个任务出现并发执行或者共享集合被同时修改抛异常。排查方法是在回调入口打印线程ID和时间戳看是否有重叠。解决方法有三种加锁、用AutoReset false手动重启、改用PeriodicTimer。加锁最简单但会阻塞ThreadPool线程手动重启最可控PeriodicTimer最优雅但需要异步改造。6.3 Dispose之后还在触发System.Threading.Timer的Dispose不会等待正在执行的回调完成所以可能出现Dispose之后回调还在跑的情况。正确做法是先用Change(Timeout.Infinite, Timeout.Infinite)停止再Dispose并且在回调里检查一个取消标志。private volatile bool _stopped false; private void OnTick(object state) { if (_stopped) return; // 业务逻辑 } private void Stop() { _stopped true; threadTimer?.Change(Timeout.Infinite, Timeout.Infinite); threadTimer?.Dispose(); }6.4 常见问题速查表现象可能原因排查方法解决方向完全不触发Timer被GC、未Start、Interval为0检查引用、Enabled、Interval持有引用、正确Start触发几次后停止回调异常、AutoReset错误加try-catch、检查AutoReset捕获异常、手动重启回调并发执行重入打印线程ID和时间加锁或改PeriodicTimerDispose后仍触发Dispose不等待回调加停止标志Change标志Dispose界面卡顿UI线程Timer回调耗时检查Tick内逻辑异步化或换Timer周期不准系统负载、GC记录实际间隔降低精度预期或换方案7. 几个容易被忽略的细节7.1 Timer的线程安全System.Timers.Timer的Enabled属性是线程安全的但Interval不是。如果在回调执行期间修改Interval行为未定义。我一般只在启动前设置Interval运行期间不改。System.Threading.Timer的Change方法是线程安全的可以在回调里调用这也是它比System.Timers.Timer灵活的地方。7.2 在回调里更新UI的正确姿势如果用的是System.Timers.Timer或System.Threading.Timer回调在非UI线程更新控件必须Invoke。WinForms用Control.Invoke或BeginInvokeWPF用Dispatcher.Invoke。// WinForms跨线程更新UI private void OnElapsed(object sender, ElapsedEventArgs e) { if (this.InvokeRequired) { this.BeginInvoke(new Action(() UpdateUi())); } else { UpdateUi(); } }BeginInvoke是异步的不会阻塞Timer回调Invoke是同步的会等UI线程处理完。我一般用BeginInvoke避免Timer回调被UI阻塞。7.3 多个Timer的协调一个项目里往往有多个定时任务如果都用独立的Timer线程数会膨胀。更好的做法是用一个调度器统一管理或者用PeriodicTimer配合Task.WhenAll。如果任务之间有依赖关系比如A完成后才能跑B那就该用Task链而不是多个Timer。7.4 测试定时器逻辑定时器逻辑很难测因为依赖真实时间。我的做法是把业务逻辑抽成一个纯方法Timer只负责调用它。这样测试时直接调方法不用等Timer。对于需要验证周期行为的场景可以用Microsoft.Extensions.TimeProvider.Testing里的FakeTimeProvider把时间控制住。8. 我个人的使用习惯和最后几点建议新项目如果框架版本允许我一律优先用PeriodicTimer代码干净、没有重入、异常处理自然。维护老项目时遇到System.Timers.Timer我会检查AutoReset和异常捕获遇到System.Threading.Timer我会检查引用持有和Dispose逻辑。WinForms界面刷新继续用System.Windows.Forms.Timer不折腾。最后分享一个小技巧不管用哪个Timer我都会在回调入口和出口各打一条日志带上线程ID和时间戳。这样一旦出现重入、卡顿、不触发日志一看就清楚。这个习惯帮我省了无数次排查时间。另外Timer的Interval不要设得太小。小于50毫秒的间隔在通用Timer上意义不大反而增加调度负担。如果确实需要高频考虑用循环加Task.Delay或者专用线程而不是硬压Timer的Interval。