C# Timer定时器的使用方法与常见示例详解

首页

编程语言

热心网友

转载

2026-05-06

选错 Timer 类型是 C# 定时任务出问题的最常见原因

c#如何使用Timer定时器_c#Timer定时器的几种常见方法

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在 C# 中实现定时任务，代码本身可能没错，但问题往往出在第一步：用错了 Timer 类。这就像用螺丝刀去敲钉子，工具不对，活儿自然干不好。比如，在控制台程序里误用 System.Windows.Forms.Timer，定时器压根不会触发；反过来，在 UI 线程里用 System.Threading.Timer 直接更新控件，等待你的就是一个跨线程异常；如果想用 await 等待定时任务，却选了老式的同步回调模型，主线程被阻塞也就不奇怪了。

说到底，C# 提供了多种 Timer，各有其明确的适用场景。选对类型，问题就解决了一半。

System.Threading.Timer：后台任务、无 UI 场景的首选

这是最轻量级的选手，纯粹基于线程池执行回调，不依赖任何 UI 框架。因此，它是控制台应用、后台服务或 Worker Service 的理想选择。不过，它的回调执行在非 UI 线程上，这意味着你不能直接在其中操作像 TextBox.Text 这样的控件。

构造与异常处理：构造时需要传入一个 TimerCallback 委托。这里有个关键细节：务必在委托内部捕获并处理异常。否则，一旦回调抛出未捕获的异常，定时器就会“静默”停止工作，不报错也不继续执行，排查起来相当棘手。
```
var timer = new Timer(_ => {
    try
    {
        DoWork();
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Error: {ex}");
    }
}, null, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(5));
```
动态调整：通过 Change() 方法可以动态改变触发间隔。需要注意的是，第一个参数 dueTime 指的是下一次触发距离现在的延迟时间，而不是一个绝对的起始偏移量。将其设为 TimeSpan.Zero 则表示立即触发下一次。
资源释放：必须手动调用 Dispose() 来释放其占用的线程池资源。推荐使用 using 语句块或在适当生命周期内显式释放，以避免资源泄漏。

System.Timers.Timer：需要事件模型 + 自动重置的后台服务

这个类可以看作是 System.Threading.Timer 的一个封装，提供了更清晰的 Elapsed 事件模型，并且支持 AutoReset（自动重置）和 Enabled 等属性，语义上更直观。但本质上，它的回调仍然在线程池线程上触发。

UI 线程访问：在 Elapsed 事件处理器中，同样不能直接访问 WinForms 或 WPF 的控件。更新 UI 必须通过 Control.Invoke 或 Dispatcher.Invoke 进行封送。
间隔设置：其 Interval 属性单位是毫秒（double 类型），而不是 TimeSpan。将其设置为 0 是无效的，通常最小有效值为 1。
停止与销毁：调用 Stop() 方法和设置 Enabled = false 效果相同，但前者意图更明确。一旦调用了 Dispose()，这个定时器实例就不能再调用 Start() 了。

System.Windows.Forms.Timer：WinForms UI 更新唯一安全的选择

这是为 WinForms 量身定制的定时器。它的 Tick 事件严格在创建它的 UI 线程上触发，因此所有控件操作都是天然线程安全的。不过，它的精度较低，实际间隔可能比设定值多出 10 到 30 毫秒，并且仅适用于 WinForms 应用程序。

使用限制：它必须在窗体线程的上下文中创建和使用。在控制台程序或 WPF 应用中实例化它，它是不会工作的。
间隔的合理设置：Interval 单位也是毫秒。设置过小的值（比如 1 毫秒）没有意义，因为系统的消息泵处理不过来。
避免耗时操作：切勿在 Tick 事件处理器中执行耗时操作，否则会导致 UI 界面卡顿。如果确实需要执行异步任务，应该在 Task.Run 中启动，并在任务完成后通过 Invoke 回到 UI 线程更新界面。

.NET 6+ 推荐：PeriodicTimer 配合 await

如果你的项目基于 .NET 6 或更高版本，并且定时任务逻辑本身是支持异步的（例如发起 HTTP 请求、读写文件），那么 PeriodicTimer 是目前最简洁、最现代的方案。它不绑定任何特定线程，也不强制使用回调，而是设计为与 await foreach 配合使用。

定位与替代：它并非用来直接替代旧的 Timer 类型，而是专门为 async/await 异步流场景设计的。不能用它直接替换同步的回调逻辑。

使用模式：必须搭配 async 方法和 IAsyncEnumerable 模式来使用：

var timer = new PeriodicTimer(TimeSpan.FromSeconds(2));
while (await timer.WaitForNextTickAsync())
{
    await DoWorkAsync(); // 这里可以安全地使用 await
}

间隔调整：它没有提供 Change() 方法。如果需要改变触发间隔，只能将现有实例释放（Dispose），然后重新创建一个新的 PeriodicTimer。

最后，有一个容易被忽略但至关重要的点：所有基于线程池的 Timer（包括 System.Threading.Timer 和 System.Timers.Timer）在回调中如果发生未捕获的异常，整个定时器就会停摆。它不会自动重试，也不会将错误抛到控制台，只会静默终止。这种“故障静默”的特性，比 UI Timer 导致的“界面卡顿”更加隐蔽，也更难调试。因此，在回调内部进行完善的异常处理，不是最佳实践，而是必须遵守的生存法则。

来源:https://www.php.cn/faq/2324968.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：Debian系统下Java项目依赖管理最佳实践下一篇：C# EF Core实现数据库读写分离配置与架构策略