企业官网建设流程全解析

System.Threading.Timer，一看这个类名，很多人第一反应是“又一个定时器”，然后就开始往项目里复制粘贴代码。但实际开发里，我见过太多人因为它踩了坑——回调不执行、UI卡死、内存泄漏、定时不准。这玩意儿和WinForms里的Timer完全是两回事，用错了轻则功能异常，重则直接把进程拖垮。

这篇文章我就把这几年用System.Threading.Timer做上位机、工业通讯、后台轮询任务的实战经验整理出来，把它的原理、用法、坑点一次说清楚。适合刚接触C#的新手，也适合写过几个定时器但一直没搞明白为什么“有时灵有时不灵”的开发者。

1. 先搞清楚System.Threading.Timer到底是什么

1.1 它不是“定时执行”，而是“在线程池里排队执行”

这是理解System.Threading.Timer最关键的一点。它和我们熟悉的WinForms里的Timer（System.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：传给回调方法的状态参数，可以传null
• dueTime：延迟多久后开始第一次执行，单位毫秒，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.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 List<double> _history = new List<double>(); 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. 精度问题：能不能精确到1ms

4.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 = xxx，WinForms里会抛InvalidOperationException，WPF也类似。

标准做法是用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 常见异常速查

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，用好了它是项目的骨架和节拍器，用不好就是在系统里埋雷。希望这篇文章能帮你少走一些弯路。