定时器：.NET Framework类库中的Timer类比较（转帖）

现在的位置: 首页 > 综合 > 正文

RSS

定时器：.NET Framework类库中的Timer类比较（转帖）

2013年07月29日 ⁄ 综合 ⁄ 共 12444字 ⁄ 字号小中大 ⁄ 评论关闭

定时器：.NET Framework类库中的Timer类比较

原作者：Alex Calvo

原文：http://msdn.microsoft.com/zh-cn/magazine/cc164015(en-us).aspx

翻译：flyjimi

源代码下载地址：TimersinNet.exe (126KB)

源代码在线查看

概要

在客户端程序和服务器组件（包括windows服务）中，timer（定时器）通常扮演着一个重要角色。编写高效的timer驱动的托管代码，需要对程序流程和.net线程模型的精妙有清晰的理解。.NET Framework 类库提供了三个不同的timer类：System.Windows.Forms.Timer, System,Timers.Timer 和 System.Threading.Timer。每个Timer类被设计优化用于不同的场合。本文研究了这三个Timer类，帮组你理解如何及何时该使用哪个类。

System.Windows.Forms.Timer

System.Timers.Timer

System.Threading.Timer

定时器的线程安全编程

处理timer事件的重入

结论

Microsoft® Windows® 中的Timer对象在行为发生时允许你进行控制。Timer最常见的一些用法是有规律的定时启动一个进程，设置事件发生的间隔，在处理图像时维持一致的动画速度（不管处理器的速度如何）。在过去，对于使用Visual Basic®的开发人员来说， Timer甚至能用来模拟多任务。

如你所想，微软.NET Framework为你提供了处理这些任务所需的工具。在.NET Framework类库中有三个不同的Timer类：System.Windows.Forms.Timer, System,Timers.Timer 和 System.Threading.Timer。前两个类出现在Visual Studio® .NET 工具箱中，你可以直接把它们拖拽到Windows窗体设计器或组件设计器。如果你不小心，这时麻烦就开始了。

Visual Studio .NET 工具箱在Windows窗体页和组件页都有一个Timer控件（见图1）。很容易就用错了，或者更糟的是没有认识到它们是不同的。仅当目标是Windows窗体设计器时，使用Windows窗体页上的Timer控件。这个控件会在你的窗体上放置一个System.Windows.Forms.Timer类的实例。正如工具箱中的其它控件，你可以让Visual Studio .NET自动生成，或者也可以自己手工实例化、初始化这个类。

图1 定时器控件

组件页上的Timer控件可以安全地用于任何类。这个控件会创建System.Timers.Timer类的实例。如果你使用Visual Studio .NET 工具箱，无论是在Windows窗体设计器，还是在组件设计器，你都可以安全的使用这个Timer。当你处理一个继承自System.ComponentModel.Component的类（例如处理Windows服务）时，Visual Studio .NET会使用组件设计器。System.Threading.Timer类不在Visual Studio .NET 工具箱中。它稍微复杂些，但也提供了更高级的控制，稍后你将在本文看到。

我们首先研究一下System.Windows.Forms.Timer和System.Timers.Timer。这两个类有非常相似的对象模型。一会儿我会探究更高级的Sytem.Threading.Timer类。图2是我在这篇文章中引用的例子程序的屏幕截图。这个程序将帮助你更清晰的认识这几个类。你可以从文章上方的链接下载完整代码，并用它做试验。

图2 例子程序

System.Windows.Forms.Timer

如果你在找一个节拍器，你就找错地方了。这个Timer类触发的定时器事件与你的Windows窗体应用程序的其余代码是同步的。这就是说，正在执行的应用程序代码永远也不会被这个Timer类的实例抢占（假定你没有调用Application.DoEvents）。就像一个典型的Windows窗体应用程序的其余代码一样，这种Timer类的Timer事件处理器中的任何代码都是使用应用程序的UI线程来执行。在空闲时间，UI线程也负责处理应用程序的Windows消息队列中的所有消息，其中包括Windows API消息，也包括这种Timer类触发的Tick事件。当应用程序没有忙于做其他事时，UI线程就处理这些消息。

如果你在Visual Studio .NET之前，写过VB代码，你可能知道在基于Windows的应用程序中，允许UI线程在执行事件处理器时响应Windows消息的唯一方法，就是调用Application.DoEvents方法。正如VB中一样，在.NET Framework中调用Application.DoEvents会导致一些问题。Application.DoEvents移交控制给UI消息泵，允许对所有未处理的事件进行处理。这会改变我刚才提到的程序执行路径。如果在你代码里调用Application.DoEvents，你的程序流程会被中断，以便处理这个Timer类的实例所触发的定时器事件。这会导致不可预料的行为，使调试变得困难。

当我们执行例子程序，这个Timer类的行为就明显了。点击例子程序的Start按钮，然后点击Sleep按钮，最后点击Stop按钮，将会产生下面的输出：

System.Windows.Forms.Timer Started @ 4:09:28 PM

--> Timer Event 1 @ 4:09:29 PM on Thread: UIThread

--> Timer Event 2 @ 4:09:30 PM on Thread: UIThread

--> Timer Event 3 @ 4:09:31 PM on Thread: UIThread

Sleeping for 5000 ms...

--> Timer Event 4 @ 4:09:36 PM on Thread: UIThread

System.Windows.Forms.Timer Stopped @ 4:09:37 PM

例子程序把System.Windows.Forms.Timer类的Interval属性设置为1000毫秒。正如你看到的，如果在主UI线程休眠（5秒）时，timer事件处理器继续捕获timer事件，那么一旦UI线程再次被唤醒时，就应该显示5个timer事件——UI线程休眠时每秒钟一个。然而，在UI线程休眠时，timer处于挂起状态。

用System.Windows.Forms.Timer编程已经够简单了——它有一个非常简单直观的编程接口。Start和Stop方法提供了一个设置Enable属性（对Win32® SetTimer/ KillTimer 函数的轻量级封装）的替代方法。刚才提到的Interval属性，是不言自明的。尽管技术上，你可以把Interval属性设置得低到一毫秒，但你应该知道.NET Framework文档中说这个属性只能精确到大约55毫秒（假设UI线程可用于处理）。

捕获System.Windows.Forms.Timer类的实例触发的事件，是通过把Tick事件关联到标准的EventHandler代理来实现的，如下面例子中的代码片段所示：

System.Windows.Forms.Timer tmrWindowsFormsTimer = new

System.Windows.Forms.Timer();

tmrWindowsFormsTimer.Interval = 1000;

tmrWindowsFormsTimer.Tick += new

EventHandler(tmrWindowsFormsTimer_Tick);

tmrWindowsFormsTimer.Start();

...

private void tmrWindowsFormsTimer_Tick(object sender,

System.EventArgs e) {

//Do something on the UI thread...

}

System.Timers.Timer

.NET Framework文档之处System.Timers.Timer是一个基于服务器的定时器，是为多线程环境进行设计和优化的。这个Timer类的实例可以从多线程中安全的访问。不像System.Windows.Forms.Timer，System.Timers.Timer类默认会从公共语言运行时的线程池获取一个工作线程（worker thread）来调用你的timer事件处理器。这意味着你的Elapsed事件处理器中的代码必须遵守Win32编程的黄金规则：控件的实例绝不能被除实例化它的线程以外的任何其他线程访问。

System.Timers.Timer类提供了一个简单的方式处理这样的困境——它暴露了一个公有的SynchronizingObject属性。把这个属性设置成Windows窗体的一个实例（或Windows窗体上的一个控件），可以保证你的Elapsed事件处理器中的代码运行在SynchronizingObject 被实例化的同一个线程。

如果你使用Visual Studio .NET工具箱，Visual Studio .NET会自动把SynchronizingObject属性设置为当前窗体。起初可能看起来，使用有SynchronizingObject属性的这个Timer类，使其在功能上与使用System.Windows.Forms.Timer等同。对于大部分功能，确实是这样。当操作系统通知System.Timers.Timer类启用的定时时间已过，定时器使用SynchronizingObject.BeginInvoke方法在创建SynchronizingObject的底层handle的线程上执行Elapsed事件代理。事件处理器会被阻塞，直到UI线程能处理它。然而，不像 System.Windows.Forms.Timer，事件最终还是会被触发。就像你在图2看到的，当UI线程不能处理时， System.Windows.Forms.Timer不会触发事件。而System.Timers.Timer会把事件排到队列中，等待UI线程可用时进行处理。

图3显示了如何使用SynchronizingObject 属性。你可以使用例子程序分析这个类，选择 System.Timers.Timer 单选按钮，按照执行System.Windows.Forms.Timer同样的顺序执行这个类。这样做会产生图4所示输出。

图3 使用SynchronizingObject属性

System.Timers.Timer tmrTimersTimer = new System.Timers.Timer();

tmrTimersTimer.Interval = 1000;

tmrTimersTimer.Elapsed += new

ElapsedEventHandler(tmrTimersTimer_Elapsed);

tmrTimersTimer.SynchronizingObject = this; //Synchronize with

//the current form...

tmrTimersTimer.Start();

……

private void tmrTimersTimer_Elapsed(object sender,

System.Timers.ElapsedEventArgs e) {

// Do something on the UI thread (same thread the form was

// created on)...

// If we didn't set SynchronizingObject we would be on a

// worker thread...

}

图4 输出

System.Timers.Timer Started @ 5:15:01 PM

--> Timer Event 1 @ 5:15:02 PM on Thread: WorkerThread

--> Timer Event 2 @ 5:15:03 PM on Thread: WorkerThread

--> Timer Event 3 @ 5:15:04 PM on Thread: WorkerThread

Sleeping for 5000 ms...

--> Timer Event 4 @ 5:15:05 PM on Thread: WorkerThread

--> Timer Event 5 @ 5:15:06 PM on Thread: WorkerThread

--> Timer Event 6 @ 5:15:07 PM on Thread: WorkerThread

--> Timer Event 7 @ 5:15:08 PM on Thread: WorkerThread

--> Timer Event 8 @ 5:15:09 PM on Thread: WorkerThread

System.Timers.Timer Stopped @ 5:15:10 PM

正如你看到的，它不会跳过一个节拍——即使当UI线程休眠时。在每个事件间隔，一个Elapse事件处理器被放到队列准备执行。因为UI线程在休眠，当UI线程被唤醒并可处理这些事件处理器时，例子程序一次显示了所有5个timer事件（从4到8）。

我前面说过，System.Timers.Timer类成员与 System.Windows.Forms.Timer 类成员非常相似。最大的不同在于，System.Timers.Timer是Win32 waitable timer对象的一个封装，并在一个工作线程（worker thread）触发Elapsed事件，而不是在UI线程上触发一个Tick事件。Elapsed事件必须连接到一个符合ElapsedEventHandler 代理的事件处理器。这个事件处理器接受一个ElapsedEventArgs类型的参数。

除了标准的EventArgs成员，ElapsedEventArgs类暴露了一个SignalTime属性，其中包含了定时器消逝的精确时间。因为这个类支持从不同的线程访问，应该相信Stop方法可以被除使用Elapsed事件的线程之外的线程访问。这可能潜在地导致在调用Stop方法后Elapsed事件才触发。你可以通过比较SignalTime属性和调用Stop方法的时间，来处理这种情况。

System.Timers.Timer还提供了AutoReset属性，用来决定Elapsed事件是否应该持续触发，或只触发一次。记住，在定时器启动后重置Interval属性，会把当前的计数重置为0。例如，如果设置interval=5秒，3秒后修改interval=10秒，下一次事件跟上一次事件的时间间隔将会是13秒。

System.Threading.Timer

第三个Timer类来自System.Threading命名空间。我想说这是所有timer类中最好的，但这可能会产生误导。首先，我惊奇的发现这个类的实例天生就不是线程安全的，考虑到它存在与System.Threading命名空间。（显然，这并不是说它不能以线程安全的方式使用。）这个类的编程接口与另外两个timer类不一致，而且有点笨重。

不像我前面讨论的两个Timer类，System.Threading.Timer有4个重载的构造函数。像下面这样：

public Timer(TimerCallback callback, object state, long dueTime,

long period);

public Timer(TimerCallback callback, object state, UInt32 dueTime,

UInt32 period);

public Timer(TimerCallback callback, object state, int dueTime,

int period);

public Timer(TimerCallback callback, object state, TimeSpan dueTime,

TimeSpan period);

第一个参数callback要求一个TimerCallback代理，这个代理指向有如下签名（signature，方法的特征标）的方法：

public void TimerCallback(object state);

第二个参数state可以是null或一个包含应用程序特定信息的对象。这个state对象在每次timer事件触发时，被传递给你的timer回调函数。记住timer回调函数是在一个工作线程上执行的，所以你应该保证对state对象的访问是线程安全的。

第三个参数dueTime允许你指定首次的timer事件应该何时触发。你可以指定0，立即启动timer，或者为了阻止timer自动启动，你可以使用 System.Threading.Timeout.Infinite 常量。

第四个参数period允许你指定回调函数被调用的时间间隔。指定0或System.Threading.Timeout.Infinite将禁止后续的timer事件触发。

调用了构造函数后，你仍然可以使用Change方法修改dueTIme和period属性。这个方法有如下4个重载：

public bool Change(int dueTime, int period);

public bool Change(uint dueTime, uint period);

public bool Change(long dueTime, long period);

public bool Change(TimeSpan dueTime, TimeSpan period);

这是我在例程中用来启动和停止这个timer的代码：

//Initialize the timer to not start automatically...

System.Threading.Timer tmrThreadingTimer = new

System.Threading.Timer(new

TimerCallback(tmrThreadingTimer_TimerCallback),

null, System.Threading.Timeout.Infinite, 1000);

//Manually start the timer...

tmrThreadingTimer.Change(0, 1000);

//Manually stop the timer...

tmrThreadingTimer.Change(Timeout.Infinite, Timeout.Infinite);

如你希望的，选择System.Threading.Timer类执行例子程序，产生了与选择 System.Timers.Timer 类一样的结果。因为TimerCallback函数是在一个工作线程被调用的，所以没有被跳过的节拍（假定工作线程可用）。图5显示了例子程序的输出。

图5 例子程序输出

System.Threading.Timer Started @ 7:17:11 AM

--> Timer Event 1 @ 7:17:12 AM on Thread: WorkerThread

--> Timer Event 2 @ 7:17:13 AM on Thread: WorkerThread

--> Timer Event 3 @ 7:17:14 AM on Thread: WorkerThread

Sleeping for 5000 ms...

--> Timer Event 4 @ 7:17:15 AM on Thread: WorkerThread

--> Timer Event 5 @ 7:17:16 AM on Thread: WorkerThread

--> Timer Event 6 @ 7:17:17 AM on Thread: WorkerThread

--> Timer Event 7 @ 7:17:18 AM on Thread: WorkerThread

--> Timer Event 8 @ 7:17:19 AM on Thread: WorkerThread

System.Threading.Timer Stopped @ 7:17:20 AM

不像System.Timers.Timer，System.Threading.Timer没有提供与System.Timers.Timer的SynchronizingObject对应的属性。任何需要访问UI控件的操作，必须使用控件的Invoke或BeginInvoke方法来组织。

定时器的线程安全编程

为了最大限度的重用代码，例子程序从三种不同的timer事件中调用了相同的ShowTimerEventFired方法。下面是三个timer事件处理器：

private void tmrWindowsFormsTimer_Tick(object sender,

System.EventArgs e) {

ShowTimerEventFired(DateTime.Now, GetThreadName());

}

private void tmrTimersTimer_Elapsed(object sender,

System.Timers.ElapsedEventArgs e) {

ShowTimerEventFired(DateTime.Now, GetThreadName());

}

private void tmrThreadingTimer_TimerCallback(object state) {

ShowTimerEventFired(DateTime.Now, GetThreadName());

}

如你所见，ShowTimerEventFired方法接受当前时间和当前线程的名称作为参数。为了区分工作线程和UI线程，在例子程序的主入口把CurrentThread对象的Name属性设置为“UIThread”。GetThreadName辅助方法返回Thread.CurrentThread.Name的值，或者当Thread.CurrentThread.IsThreadPoolThread属性值为true时，返回“WorkerThread”。

因为System.Timers.Timer和System.Threading.Timer的timer事件运行在工作线程，这些timer事件处理器里的任何用户界面相关的代码就必须汇集到UI线程上等待处理。为了实现这点，我创建了一个名为ShowTimerEventFiredDelegate的代理：

private delegate void

ShowTimerEventFiredDelegate

(DateTime eventTime,

string threadName);

ShowTimerEventFiredDelegate允许ShowTimerEventFired方法在UI线程上回调自己。图6显示了处理这些的代码。

图6 ShowTimerEventFired

private void ShowTimerEventFired(DateTime eventTime,

string threadName) {

//InvokeRequired will be true when using

//System.Threading.Timer or System.Timers.Timer (without a

//SynchronizationObject)...

if (lstTimerEvents.InvokeRequired) {

//Marshal this call back to the UI thread (via the form

//instance)...

BeginInvoke(new

ShowTimerEventFiredDelegate(ShowTimerEventFired),

new object[] {eventTime, threadName});

}

else

lstTimerEvents.TopIndex = lstTimerEvents.Items.Add(

String.Format("—> Timer Event {0} @ {1} on Thread:

{2}",

++_tickEventCounter, eventTime.ToLongTimeString(),

threadName));

}

通过检查控件的InvokeRequired属性，很容易判断你是否能在当前线程上安全的访问一个Windows窗体控件。在这个例子中，如果ListBox的InvokeRequired属性为true，窗体的BeginInvoke方法就被用来通过ShowTimerEventFiredDelegate再次调用ShowTimerEventFired方法。这将保证ListBox的Add方法在UI线程上执行。

如你所见，当编写异步timer事件时，有很多事情你必须知道。我建议你在使用System.Timers.Timer或System.Threading.Timer之前，阅读Ian Griffith的文章《Windows窗体：使用多线程为你的基于.NET的应用程序提供一个迅速反应的用户界面》（"Windows Forms: Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads"），这篇文章发表在MSDN杂志2003年2月期刊上。

处理timer事件的重入

在处理异步timer事件时，如由System.Timers.Timer和System.Threading.Timer产生的事件，还有一个细微之处你需要考虑。这个问题与代码的重入有关。如果你的timer事件处理器里的代码执行时间比定时器触发事件的间隔更长，而你又没有采取必要的措施阻止多线程访问你的对象和变量，那么你就会面临调试的困境。看一下如下的代码片段：

private int tickCounter = 0;

private void tmrTimersTimer_Elapsed(object sender,

System.Timers.ElapsedEventArgs e) {

System.Threading.Interlocked.Increment(ref tickCounter);

Thread.Sleep(5000);

MessageBox.Show(tickCounter.ToString());

}

假设你的定时器的Interval属性设置为1000毫秒，你会很惊奇的发现弹出的第一个消息框显示的值是5.这是由于在第一个timer事件休眠的5秒钟内，定时器继续在不同的工作线程上产生Elapsed事件。因此，在第一个timer事件执行完之前，tickCounter变量的值被增加了5次。注意我使用了Interlocked.Increment方法以线程安全的方式增加tickCounter变量的值。也有其他的方法可以实现，但是Interlocked.Increment方法是为这种操作专门设计的。

解决这种重入问题的一个简单方法是，在timer事件处理器代码中，临时禁用定时器，然后再启用定时器，如下面的例子所示：

private void tmrTimersTimer_Elapsed(object sender,

System.Timers.ElapsedEventArgs e) {

tmrTimersTimer.Enabled = false;

System.Threading.Interlocked.Increment(ref tickCounter);

Thread.Sleep(5000);

MessageBox.Show(tickCounter.ToString());

tmrTimersTimer.Enabled = true;

}

有了这段代码，消息框就会每个5秒钟显示一次，并且像你期望的那样，tickCounter的值每次增加1.另一个选择是使用Monitor或mutex这样原始的同步对象，保证所有后来的事件都排队等候，直到当前事件处理执行完成。

结论

通过图7中三个类的比较，可以快速回顾我对.NET Framework中三个Timer类的看法。当使用定时器时，你需要考虑的一点是，是否能用Windows调度程序（或者AT命令）定时运行一个标准的可执行程序，来更简单的解决你的问题。

图7 .NET Framework类库中的Timer类

	System.Windows.Forms	System.Timers	System.Threading
Timer事件运行于哪个线程?	UI 线程	UI 或工作线程	工作线程
实例是否线程安全?	否	是	否
熟悉、直观的对象模型?	是	是	否
需要 Windows 窗体?	是	否	否
节拍器似的高质量的拍子?	否	是*	是*
Timer事件是否支持状态对象（state object）?	否	否	是
是否能指定首次 timer 事件触发的时间?	否	否	是
类是否支持继承?	是	是	否
* 取决于系统资源（例如，工作线程）的可用性。