[转].Net中的几个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类，帮组你理解如何及何时该使用哪个类。
目录
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自动生成，或者也可以自己手工实例化、初始化这个类。
633636559115928750.gif)
图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是我在这篇文章中引用的例子程序的屏幕截图。这个程序将帮助你更清晰的认识这几个类。你可以从文章上方的链接下载完整代码，并用它做试验。
633636559116397500.gif)
图2 例子程序
如果你在找一个节拍器，你就找错地方了。这个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...
}
.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秒。
第三个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 事件触发的时间?
否
否
是
类是否支持继承?
是
是
否
* 取决于系统资源（例如，工作线程）的可用性。
相关文章：
Windows Forms: Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads
背景信息：
Programming the Thread Pool in the .NET Framework: Using Timers
作者简介：
Alex Calvo 是一个微软认证的.NET解决方案开发者。当他没有读书、编码或沉思时，他一定是在弹吉他。你可以通过Email（acalvo@hotmail.com.）联系他。
译者小记：
这篇文章的原文刊登在MSDN杂志2004年2月期刊中，网上早有了中文版本。Flyjimi做这个重复劳动，并不是因为之前的翻译版本不够好，而是看完原文后，突然很想自己翻译过来，借以磨砺一下生锈的英文。
