基于服务器的计时器允许指定在应用程序中引发事件的重复时间间隔。然后可通过处理这个事件来提供常规处理。例如,假设您有一台关键的服务器,必须保持一周 7 天、一天 24 小时连续运行。您可以创建一个服务,通过使用计时器来定期检查关键的服务器,确保系统启动并运行。如果该系统没有响应,此服务可以尝试重新启动服务器或通知系统管理员。
注意 以毫秒为单位指定服务器计时器的时间间隔。
服务器计时器、Windows 计时器和线程计时器
在 Visual Studio .NET 和 .NET Framework 中有三种计时器控件:基于服务器的计时器,位于“工具箱”的“组件”选项卡上;基于 Windows 的标准计时器,位于“工具箱”的“Windows 窗体”选项卡上,以及仅可在编程时使用的线程计时器。基于 Windows 的计时器从 Visual Basic 的 1.0 版起就存在于该产品中并且基本上保持不变。该计时器已经为在 Windows 窗体应用程序中使用而进行了优化。基于服务器的计时器是传统的计时器为了在服务器环境上运行而优化后的更新版本。线程计时器是一种简单的、轻量级计时器,使用回调方法而不是事件,并由线程池线程提供。
在 Win32 体系结构中有两种类型的线程:UI 线程和辅助线程。UI 线程绝大多数时间处于空闲状态,等待消息循环中的消息到来。一旦接收到消息,它们就进行处理并等待下一个消息到来。另外,辅助线程用来执行后台处理而且不使用消息循环。Windows 计时器和基于服务器的计时器在运行时都使用 Interval 属性。线程计时器的时间间隔在 Timer 构造函数中设置。计时器的设计目的各不相同,它们的线程处理明确地指出了这一点:
Windows 计时器是为单线程环境设计的,其中,UI 线程用于执行处理。Windows 计时器的精度限定为 55 毫秒。这些传统计时器要求用户代码有一个可用的 UI 消息泵,而且总是在同一个线程中操作,或者将调用封送到另一个线程。对于 COM 组件来说,这样会降低性能。
基于服务器的计时器是为在多线程环境下与辅助线程一起使用而设计的。由于它们使用不同的体系结构,因此基于服务器的计时器可能比 Windows 计时器精确得多。服务器计时器可以在线程之间移动来处理引发的事件。
对消息不在线程上发送的方案中,线程计时器是非常有用的。例如,基于 Windows 的计时器依赖于操作系统计时器的支持,如果不在线程上发送消息,与计时器相关的事件将不会发生。在这种情况下,线程计时器就非常有用。
Windows 计时器位于 System.Windows.Forms 命名空间中,服务器计时器位于 System.Timers 命名空间中,而线程计时器位于 System.Threading 命名空间中。
以下问答:
那么:
System.Timers.Timer会依赖于服务器?(windows server2000和windows server2003才可以?)
如果依赖服务器,那么是否可以减轻当前进程的负担?
是不是说System.Timers.Timer就是最耗资源的呢?
如果我要创建的计时器可能达1000个,是否应该使用System.Threading.Timer而不应该使用System.Timers.Timer呢?
我的理解是如果达到1000个以上的话,就应该使用占用资源较少的线程计时器
我也是认为应该用线程计时器,我有点担心在线程很多的时候计时器会不会变得很不精确。当然,测一下就知道了,有空了我去测一下
System.Windows.Forms.Timer是单线程的。。。通俗的说使用这个计时器执行方法的时候画面会卡住
而另2个你不需要,为了执行效率,为其执行的方法开线程。
这些Timer的分配本身都是不在一个线程中的,但其实这不重要,因为System.Threading.Timer本身就是在系统线程池中分配的线程执行的。System.Timers.Timer应该也是。
to zhy0101(香蕉):
要进行实时计费,只有开一个Timer每分钟检查一次。还有个方法是不停的遍历链表(计费信息放在链表中),我担心不停的遍历会对系统开销太大,对Socket连接产生影响。如果隔一段时间遍历一次又达不到实时效果。
谢谢大家。望大侠继续赐教。目前我是使用的System.Threading.Timer,感觉不是很精确。
感觉上,Windows计时器就是命令Windows在多久之后为自己发一条消息,然后再被自己的消息循环捕获。
那么缺点是很显而易见的,就是如果消息队列中的消息太多,或者当前主线程被阻塞的时候,这条计时消息就可能在很晚的时候才被处理。
而服务器Timer很明显是另开一个线程计时,每一个Timer是一个独立的线程,独立的计时,所以精度非常高,并且Elapsed事件是在独立的线程上触发的。