1、背景
在c#里关于定时器的类就有3个：
（1）定义在system.windows.forms里
（2）定义在system.threading.timer类里
（3）定义在system.timers.timer类里
timer 用于以用户定义的事件间隔触发事件。windows 计时器是为单线程环境设计的，其中，ui 线程用于执行处理。它要求用户代码有一个可用的 ui 消息泵，而且总是在同一个线程中操作，或者将调用封送到另一个线程。
使用此计时器时，请使用控件的tick事件执行轮询操作，或在指定的时间内显示启动画面。每当 enabled 属性设置为true且interval属性大于0时，将引发tick事件，引发的时间间隔基于interval属性设置。
system.windows.forms.timer是应用于winform中的，他是通过windows消息机制实现的，类似于vb或delphi中的timer控件，内部使用api settimer实现的。他的主要缺点是计时不精确，而且必须有消息循环，console application(控制台应用程式)无法使用。
system.timers.timer和system.threading.timer很类似，他们是通过.net thread pool实现的，轻量，对应用程式、消息没有特别的需要。system.timers.timer还能够应用于winform，完全取代上面的timer控件。
然而其精度都不高（一般情况下 15ms 左右），难以满足一些场景下的需求。
在进行媒体播放、绘制动画、性能分析以及和硬件交互时，可能需要 10ms 以下精度的定时器。这里不讨论这种需求是否合理，它是确实存在的问题，也有相当多的地方在讨论，说明这是一个切实的需求。然而，实现它并不是一件轻松的事情。
这里并不涉及内核驱动层面的定时器，只分析在 .net 托管环境下应用层面的高精度定时器实现。
windows 不是实时操作系统，所以任何方案都无法绝对保证定时器的精度，只是能尽量减少误差。所以，系统的稳定性不能完全依赖于定时器，必须考虑失去同步时的处理。
2、等待策略
想要实现高精度定时器，必然需要等待和计时两种基础功能。等待用来跳过一定时间间隔，计时可以进行时间检查，用以调整等待时间。
等待策略实际就是两种：
自旋等待：让 cpu 空转消耗时间，占用大量 cpu 时间，但是时间高度可控。
阻塞等待：线程进入阻塞状态，出让 cpu 时间片，在等待一定时间后再由操作系统调度回到运行状态。阻塞时不占用 cpu，然而需要操作系统调度，时间难以控制。
可以看到二者各有优劣，应该按照不同需求进行不同的实现。
而计时机制可以说能用的只有一种，就是stopwatch类。它内部使用了系统 api queryperformancecounter/ queryperformancefrequency来进行高精度计时，依赖于硬件，它的精度可以高达几十纳秒，非常适合用来实现高精度定时器。
所以难点在于等待策略，下面先分析简单的自旋等待。
2.1自旋等待
可以使用thread.spinwait(int iteration)来进行自旋，也就是让 cpu 在一个循环里空转，iteration参数是迭代次数。.net framework 中不少同步构造都用到了它，用来等待一小段时间，减少上下文切换的开销。
这里很难根据iteration来计算消耗的时间，因为 cpu 速度可能是动态的。所以需要结合使用stopwatch。伪代码如下：
我要评论
var 等待开始时间 = 当前计时;
while ((当前计时 - 等待开始时间) < 需要等待的时间)
{
自旋;
}
写成实际代码：
void spin(stopwatch w, int duration)
{
var current = w.elapsedmilliseconds;
while ((w.elapsedmilliseconds - current) < duration)
thread.spinwait(10);
}
这里的w是一个已经启动的stopwatch，为了演示简单使用了elapsedmilliseconds属性，精度是毫秒级的，使用elapsedticks属性就可以获得更高的精度（微秒级）。
然而如前所述，这样精度高但是是以消耗 cpu 时间为代价的，这样实现定时器会让一个 cpu 核心满负荷工作（如果执行的任务也没有阻塞的话）。相当于浪费了一个核心，在有些时候不太现实（比如核心很少甚至是单核的虚拟机上），所以需要考虑阻塞等待。
2.2阻塞等待
阻塞等待会把控制权交给操作系统，这样就必须确保操作系统能够及时的将定时器线程调度回运行状态。默认情况下，windows 的系统定时器精度是 15.625ms，也就是说时间切片是这个尺寸。如果线程阻塞，出让其时间片进行等待，再被调度运行的时间至少是一个切片 15.625ms。那么必须减少时间切片的长度，才有可能实现更高的精度。
可以通过系统 api timebeginperiod来修改系统定时器精度到 1ms（它内部使用了没有给出文档的ntsettimerresolution，这个 api 可以修改到 0.5ms）。不需要的时候使用timeendperiod还原。
修改系统定时器精度有副作用。它会增加上下文切换的开销，增加耗电量，降低系统整体性能。然而，很多程序都不得不这么做，因为没有其它方式能获得更高的定时器精度。比如基于 wpf 的程序（包括 visual studio）、使用 chromium 内核的应用（chrome、qq）、多媒体播放器、游戏等等很多程序都会在一定时间内把系统定时器精度修改到 1ms。（查看方法见后面）
所以实际上这个副作用在桌面环境已经成为常态。而且从 windows 8 开始，这个副作用减弱了。
在 1ms 的系统定时器精度前提下，可以使用三种方式实现阻塞等待：
（1）thread.sleep
（2）waithandle.waitone
（3）socket.poll
另外，多媒体定时器timesetevent也使用了阻塞的方式。
（1）thread.sleep
它的参数使用毫秒单位，所以最多只能精确到 1ms。不过事实上很不稳定，thread.sleep(1)会在 1ms 与 2ms 两种状态间跳动，也就是可能会产生 +1ms 多的误差。
实测发现，没有任务负载的情况下（纯粹循环调用sleep(1)），阻塞时长稳定在 2ms；而有任务负载时，则至少会阻塞 1ms。这和其它两种阻塞方式不同，详见后文。
如果需要修正这个误差，可以在阻塞 n 毫秒时，使用sleep(n-1)，并通过stopwatch计时，剩余等待时间用sleep(0)、thread.yield或自旋来补充。
sleep(0)会出让剩余的 cpu 时间片给优先级相同的线程，而thread.yield是出让剩余的 cpu 时间片给运行在同一核心上的线程。在出让的时间片结束后，其会被重新调度。一般情况下，整个过程可以在 1ms 之内完成。
thread.sleep(0)和thread.yield在 cpu 高负载情况下非常不稳定，实测可能会阻塞高达 6ms 时间，所以可能会产生更多的误差。因此误差修正最好通过自旋方式实现。
（2）waithandle.waitone
waithandle.waitone与thread.sleep类似，参数也是毫秒单位。
不同之处是，没有任务负载的情况下（纯粹循环调用waitone(1)），阻塞时长稳定在 1.5ms；而有任务负载时，则可能仅阻塞近乎于 0 的时间（猜测是它仅阻塞到当前时间片结束，尚未找到具体的文档说明）。所以它阻塞的时长范围是 0 到 2ms 多。
waithandle.waitone(0)是用来测试等待句柄状态的，它并不阻塞，所以用它来进行误差修正类似于自旋，但不如直接使用自旋可靠。
（3）socket.poll
socket.poll方法的参数是以微秒为单位，理论上，它是使用了网卡的硬件来定时，精度很高。然而，由于阻塞的实现仍然要依赖线程，所以它也只能达到 1ms 的精度。
它的优势是比thread.sleep和waithandle.waitone要更稳定，误差也更小，可以不需要修正，但要占用一个 socket 端口。
没有任务负载的情况下（纯粹循环调用poll(1)），阻塞时长稳定在 1ms；而有任务负载时，则和waitone类似，可能仅阻塞近乎于 0 的时间。所以它阻塞的时长范围是 0 到 1ms 多。
socket.poll(0)是用来测试 socket 状态的，但它会阻塞，而且可能阻塞高达 6ms，所以不能用它来进行误差修正。
2.3timesetevent
timesetevent和之前提到的timebeginperiod一样属于 winmm.dll 提供的多媒体定时器功能。它可以直接当作定时器使用，也是提供 1ms 的精度。在不需要的时候使用timekillevent来关闭。
它的稳定性和精度也很高，如果需要 1ms 的定时，而又不能使用自旋，那么这是最理想的方案。
虽然 msdn 上说timesetevent是个过时的方法，应该用createtimerqueuetimer替换。但是createtimerqueuetimer精度和稳定性都不如多媒体定时器，所以在需要高精度的时候，只能使用timesetevent。
3、定时器实现
需要注意的是，无论自旋还是阻塞，显然定时器都应该运行在独立的线程，不能干扰使用方线程工作。而对于高精度定时器来说，触发事件以执行任务的线程一般都在定时器线程内，而不是再使用独立的任务线程。
这是因为高精度定时场景下，执行任务的时间开销很可能大于定时器的时间间隔，如果默认就在其它线程执行任务，可能导致占用大量线程。所以应该把控制权交给用户，让用户在需要的时候自行调度任务执行的线程。
3.1触发模式
由于在定时器线程执行任务，所以定时器的触发就产生了三种模式。以下是它们的说明和主循环伪代码：
（1）固定时间框架
比如间隔 10ms，任务 7-12ms，则会按照等待 10ms 、任务 7ms、等待 3ms、任务 12ms（超时 2ms 失去同步）、任务 7ms、等待 1ms（回到同步）、任务 7ms、等待 3ms、… 进行。就是尽量按照设定好的时间框架来执行任务，只要任务不是始终超时，就可以回到原本的时间框架上。
var 下一帧时间 = 0;
while(定时器开启)
{
下一帧时间 += 间隔时间;
while (当前计时 < 下一帧时间)
{
等待;
}
触发任务;
}
（2）可推迟时间框架：
上面的例子会按照等待 10ms 、任务 7ms、等待 3ms、任务 12ms（超时，推迟时间框架 2ms）、任务 7ms、等待 3ms、… 进行。超时的任务会推迟时间框架。
var 下一帧时间 = 0;
while(定时器开启)
{
下一帧时间 += 间隔时间;
if (下一帧时间 < 当前计时)
下一帧时间 = 当前计时
while (当前计时 < 下一帧时间)
{
等待;
}
触发任务;
}
（3）固定等待时间
上面的例子会按照等待 10ms、任务 7ms、等待 10ms、任务 12ms、等待 10ms、任务 7ms… 进行。等待时间始终不变。
while(定时器开启)
{
var 等待开始时间 = 当前计时;
while ((当前计时 - 等待开始时间) < 间隔时间)
{
等待;
}
触发任务;
}
// 或者：
var 下一帧时间 = 0;
while(定时器开启)
{
下一帧时间 += 间隔时间;
while (当前计时 < 下一帧时间)
{
等待;
}
触发任务;
下一帧时间 = 当前计时;
}
如果使用多媒体定时器（timesetevent），它固定实现了第一种模式，而其它的等待策略能够实现全部三种模式，可以根据需求选择。
在while循环中的等待可以使用自旋或阻塞，也可以结合它们来达到精度、稳定性和 cpu 开销的平衡。
另外，由上面的伪代码可以看出，这三种模式的实现可以统一，能够做到根据情况切换。
3.2线程优先级
最好把线程优先级调高，以保证定时器能够稳定工作，减少被抢占的机会。然而需要注意，这在 cpu 资源不足时可能导致低优先级线程的饥饿。也就是说不能让高优先级线程去等待低优先级线程改变状态，很有可能低优先级线程没有机会运行，导致死锁或类似死锁的状态。（见一种类似的饥饿的例子）
线程的最终优先级和进程的优先级有关，所以有时候也需要提高进程优先级（见 c# 中的多线程系列的线程优先级说明）。
4、其它
还有两点需要注意：
（1）线程安全：定时器在独立线程运行，其暴露的成员都应该实现线程安全，否则在定时器运行时调用可能会产生问题。
（2）及时释放资源：多媒体定时器、等待句柄、线程等等这些都是系统资源，在不需要它们的时候应该及时释放/销毁。
如何查看系统定时器精度？
简单的查看可以使用sysinternals工具包中的 clockres，它会显示如下信息：
maximum timer interval: 15.625 ms minimum timer interval: 0.500 ms current timer interval: 15.625 ms // 或 maximum timer interval: 15.625 ms minimum timer interval: 0.500 ms current timer interval: 1.000 ms
如果是想查看哪些程序请求了更高的系统定时器精度，那么运行：
powercfg energy -duration 5
它会监视系统能耗 5s，然后在当前目录生成一个energy-report.html的分析报告，可以打开它查看。
找到里面的警告部分，会有平台计时器分辨率:未完成的计时器请求（platform timer resolution:outstanding timer request）信息。
如对本文有疑问， 点击进行留言回复！！
使用Visual Studio2019创建C#项目(窗体应用程序、控制台应用程序、Web应用程序)
C#实现获取本地内网(局域网)和外网(公网)IP地址的方法分析
浅谈Visual Studio 2019 Vue项目的目录结构
网友评论