Timer 控件中的Elapsed事件与tick事件的区别

public System.Timers.Timer Timer1 = new System.Timers.Timer();

elsapsed事件是在另一个线程中引发的 。如果 elapsed事件中的代码是耗时的代码

当事件引发后，调用Timer1.Stop() 方法, 但elapsed 事件线程中的代码还在执行，直到该次elapse事件中的代码全执行完。

Timer 控件没有Elapsed事件吧，System.Timers类才有。

Visual Studio 和 .NET Framework 中包含三个计时器控件：

可添加到“工具箱”中的基于服务器的计时器

始终位于“工具箱”中的基于 Windows 的计时器

可通过编程方式使用的线程计时器

基于 Windows 的计时器针对在 Windows 窗体应用程序中使用而进行了优化。基于服务器的计时器是传统的计时器为了在服务器环境上运行而优化后的更新版本。线程计时器是一种简单的、轻量级计时器，它使用回调方法而不是使用事件，并由线程池线程提供支持。

在 Win32 体系结构中有两种类型的线程：UI 线程和辅助线程。UI 线程绝大多数时间处于空闲状态，等待消息循环中的消息到来。一旦接收到消息，它们就进行处理并等待下一个消息到来。另外，辅助线程用来执行后台处理而且不使用消息循环。Windows 计时器和基于服务器的计时器在运行时都使用 Interval 属性。线程计时器的时间间隔在 Timer 构造函数中设置。计时器的设计目的各不相同，它们的线程处理明确地指出了这一点： 

Windows 计时器是为单线程环境设计的，其中，UI 线程用于执行处理。Windows 计时器的精度限定为 55 毫秒。这些传统计时器要求用户代码有一个可用的 UI 消息泵，而且总是在同一个线程中操作，或者将调用封送到另一个线程。对于 COM 组件来说，这样会降低性能。 

基于服务器的计时器是为在多线程环境下与辅助线程一起使用而设计的。由于它们使用不同的体系结构，因此基于服务器的计时器可能比 Windows 计时器精确得多。服务器计时器可以在线程之间移动来处理引发的事件。 

对消息不在线程上发送的方案中，线程计时器是非常有用的。例如，基于 Windows 的计时器依赖于操作系统计时器的支持，如果不在线程上发送消息，与计时器相关的事件将不会发生。在这种情况下，线程计时器就非常有用。

Windows 计时器位于 System.Windows.Forms 命名空间中，服务器计时器 System.Timers 命名空间中，线程计时器位于 System.Threading 命名空间中。

首先简单介绍一下timer，这里所说的timer是指的System.Timers.timer，顾名思义，就是可以在指定的间隔是引发事件。官方介绍在这里，摘抄如下：

如果想了解跟其他的timer有啥区别，可以看这里，里面有详细的介绍，不再多说了（其实我也不知道还有这么多）。那使用这个计时器有啥好处呢？主要因为它是通过.NET Thread Pool实现的、轻量、计时精确、对应用程序及消息没有特别的要求。

★使用

 
下面就简单介绍一下，这个Timer是怎么使用的，其实很简单，我就采用微软提供的示例来进行测试，直接上代码了：

运行的结果如下，计时蛮准确的：

★重入问题重现及分析

 
什么叫重入呢？这是一个有关多线程编程的概念：程序中，多个线程同时运行时，就可能发生同一个方法被多个进程同时调用的情况。当这个方法中存在一些非线程安全的代码时，方法重入会导致数据不一致的情况。Timer方法重入是指使用多线程计时器，一个Timer处理还没有完成，到了时间，另一Timer还会继续进入该方法进行处理。下面演示一下重入问题的产生（可能重现的不是很好，不过也能简单一下说明问题了）：

下面显示一下输出结果：

 

是不是感觉上面输出结果很奇怪，首先是线程1输出为1，没有问题，然后隔了2秒后线程1自增1后输出为2，这就有问题了，中间为什么还出现了线程2的输出？更奇怪的是线程2刚开始输出为1，自增1后尽然变成了3！其实这就是重入所导致的问题。别急，咱们分析一下就知道其中的缘由了。

 
首先timer启动计时后，开启一个线程1执行方法，当线程1第一次输出之后，这时线程1休眠了2秒，此时timer并没有闲着，因为设置的计时间隔为1秒，当在线程1休眠了1秒后，timer又开启了线程2执行方法，线程2才不管线程1是执行中还是休眠状态，所以此时线程2的输出也为1，因为线程1还在休眠状态，并没有自增。然后又隔了1秒，这时发生同时发生两个事件，线程1过了休眠状态自增输出为2，timer同时又开启一个线程3，线程3输出的为线程1自增后的值2，又过了1秒，线程2过了休眠状态，之前的输出已经是2，所以自增后输出为3，又过了1秒……我都快晕了，大概就是这意思吧，我想表达的就是：一个Timer开启的线程处理还没有完成，到了时间，另一Timer还会继续进入该方法进行处理。

 
那怎么解决这个问题呢？解决方案有三种，下面一一道来，适应不同的场景，不过还是推荐最后一种，比较安全。

★重入问题解决方案

 
1、使用lock(Object)的方法来防止重入，表示一个Timer处理正在执行，下一个Timer发生的时候发现上一个没有执行完就等待执行，适用重入很少出现的场景（具体也没研究过，可能比较占内存吧）。

 
代码跟上面差不多，在触发的方法中加入lock，这样当线程2进入触发的方法中，发现已经被锁，会等待锁中的代码处理完在执行，代码如下：

执行结果：

 

2、设置一个标志，表示一个Timer处理正在执行，下一个Timer发生的时候发现上一个没有执行完就放弃（注意这里是放弃，而不是等待哦，看看执行结果就明白啥意思了）执行，适用重入经常出现的场景。代码如下：

执行结果：

 

3、在多线程下给inTimer赋值不够安全，Interlocked.Exchange提供了一种轻量级的线程安全的给对象赋值的方法（感觉比较高上大，也是比较推荐的一种方法），执行结果与方法2一样，也是放弃执行。Interlocked.Exchange用法参考这里。

执行结果：

★总结

 
终于码完字了，真心不容易啊。写博客是个挺耗精力的事情，真心佩服那些大牛们笔耕不辍，致敬！在这里稍微总结一下，timer是一个使用挺简单的类，拿来即用，这里主要总结了使用timer时重入问题的解决，以前也没思考过这个问题，解决方案也挺简单，在这里列出了三种，主要参考在这里，不知道还有没有其他的方式。这里的解决方案同时也适用多线程的重入问题。时间不早了，洗洗睡了。