.NET 中如何实现高精度定时器

听雨眠

发布时间：2026-08-25 | 179人浏览过

原创

前言

在 .NET 里，普通定时器通常只能提供 15ms 到 55ms 左右的精度，放到高频采样、低延迟控制或细粒度调度场景里，很容易出现节拍漂移。要把定时器做得更准，关键不是只盯着某个 API，而是把计时、等待和触发模式分开设计，再根据 CPU 占用、系统调度和任务耗时做选择。

在 .NET 里，系统自带的多种定时器足够覆盖大多数业务场景，但一旦把目标压到 10ms 甚至更细的间隔，误差和抖动就会很快暴露出来。要把高精度定时器真正做稳，关键不只是“更快触发”，而是把计时方式、等待策略和任务触发节奏拆开看清楚，再根据任务耗时与系统调度特性做取舍。

这篇文章按这三个问题展开：先看 .NET 里能依赖什么做高精度计时，再比较自旋、阻塞和多媒体定时器的差异，最后解释不同触发模式会把任务节奏带向哪里。读完后，你可以更明确地判断：自己的场景究竟该优先追求绝对精度、CPU 占用，还是执行节拍的一致性。

高精度定时器先要解决什么

一个可用的高精度定时器，至少要处理三件事：计时、等待、触发模式。

计时：持续检查当前时间，并据此修正后续等待时长。
等待：让线程跨过指定时间间隔，尽量减少误差。
触发模式：决定每次 Tick 是对齐固定时间点，还是以“上次任务完成后再等一段时间”为准。

例如把定时器间隔设为 10ms，而任务本身耗时 7ms，这时就会出现一个实际问题：是每隔 10ms 尽量触发一次任务，还是等任务执行完后再等待 10ms 进入下一轮。这个选择会直接影响任务节拍、累计偏移以及系统负载。

计时：用 Stopwatch 获取高精度时间基准

Windows 提供了适合高精度时间戳和间隔测量的 API，即 QueryPerformanceCounter (QPC)。在 .NET 中，对应的高层实现就是 System.Diagnostics.Stopwatch，其内部同样基于 QueryPerformanceCounter (QPC)。

QueryPerformanceCounter (QPC) 的底层依赖硬件计数器，通常可以拆成三个部分：

时钟周期生成器
负责累计时钟周期的计数器
读取计数器当前值的方法

这三部分共同决定了 QueryPerformanceCounter (QPC) 的分辨率、精度、准确性和稳定性。它的精度可达到几十纳秒，用它作为高精度定时器的计时基础基本没有问题。

换句话说，在 .NET 中自己实现高精度定时器时，计时环节通常不需要从零开始造轮子，优先使用 Stopwatch 就够了。真正棘手的部分往往在“如何等待”。

等待：自旋、阻塞与多媒体定时器怎么选

等待策略通常可以分成两类：

高精度定时器中不同等待策略的对比信息图 — **等待策略对比**用对比图梳理自旋、Sleep 修正和多媒体定时器的精度、CPU 代价与适用场景。

自旋：线程持续占用 CPU，空转直到时间到达。
阻塞：线程主动让出 CPU，等待系统把它重新调度回来。

自旋等待：精度高，但 CPU 代价很大

自旋可以通过 Thread.SpinWait(int iteration) 实现，参数 iteration 表示迭代次数。问题在于，CPU 频率可能是动态变化的，因此很难直接把 iteration 稳定换算成真实耗时。更稳妥的方式，是把它和 Stopwatch 结合起来使用：

void Spin(Stopwatch w, int duration)
{
    var current = w.ElapsedMilliseconds;
    while ((w.ElapsedMilliseconds - current) < duration)
        Thread.SpinWait(5);
}

这种写法的优势是简单直接，短时间内可以获得很细的等待粒度；代价同样明显：线程一直在忙等，CPU 基本会维持在接近 100% 的占用状态。

因此，自旋更适合非常短的等待窗口，或者作为最后一小段误差修正手段使用。若定时器需要长期运行，单纯依赖自旋通常不划算。

阻塞等待：更省 CPU，但受系统调度影响

阻塞等待的前提，是操作系统能在合适的时间把线程调度回来。默认情况下，Windows 的计时器精度大约是 15ms。线程一旦阻塞并让出时间片，之后能被重新调度执行的时间通常至少要跨过一个时间片，也就是 15ms 左右。

如果要通过阻塞手段逼近高精度计时，就要先缩短这个时间片。Windows 提供了 timeBeginPeriod，可以把计时器精度调整到 1ms；对应地，在使用完定时器服务后，需要调用 timeEndPeriod 恢复设置，并且二者必须成对出现。

这里还有一个版本差异需要注意：

在 Windows 10, version 2004 之前，timeBeginPeriod 会影响整个系统，所有进程都会使用调整后的计时精度。
从 Windows 10, version 2004 开始，影响范围收敛到调用它的进程。

提高精度的收益，是等待函数的超时间隔更准确；代价则是系统线程切换更频繁，整体性能可能下降，同时还可能影响 CPU 进入节能状态。需要强调的是，调高系统计时分辨率，并不会提升高分辨率性能计数器本身的准确性。

实际开发中，常见做法是用 Thread.Sleep 挂起线程。虽然它的参数最小可以写成 1ms，但实际表现并不稳定，测试里往往更接近阻塞 2ms。为了缩小误差，可以把 Sleep(0) 或 Thread.Yield 与 Stopwatch 组合使用：

void wait(Stopwatch w, int duration)
{
    var current = w.ElapsedMilliseconds;
    while ((w.ElapsedMilliseconds - current) < duration)
        Thread.Sleep(0);
}

不过这类方式在 CPU 高负载时会变得很不稳定，误差反而可能放大。所以如果确实要做误差修正，通常还是更适合用短暂自旋来收尾。

多媒体定时器：1ms 级别精度的可用方案

除了普通阻塞等待，还有一种更常被拿来讨论的方式：多媒体定时器 timeSetEvent。它来自 winmm.dll，稳定性和精度都比较高，通常可以提供 1ms 级别的精度。

官方文档虽然将 timeSetEvent 标为过时，并建议使用 CreateTimerQueueTimer 代替，但就精度和稳定性而言，CreateTimerQueueTimer 并不如多媒体定时器。对于确实需要高精度的场景，timeSetEvent 仍然是更实际的选择。

下面是一份基于 winmm.dll 的简单封装示例：

public enum TimerError
{
    MMSYSERR_NOERROR = 0,
    MMSYSERR_ERROR = 1,
    MMSYSERR_INVALPARAM = 11,
    MMSYSERR_NOCANDO = 97,
}

public enum RepeateType
{
    TIME_ONESHOT=0x0000,
    TIME_PERIODIC = 0x0001
}

public enum CallbackType
{
    TIME_CALLBACK_FUNCTION = 0x0000,
    TIME_CALLBACK_EVENT_SET = 0x0010,
    TIME_CALLBACK_EVENT_PULSE = 0x0020,
    TIME_KILL_SYNCHRONOUS = 0x0100
}

public class HighPrecisionTimer
{
    private delegate void TimerCallback(int id, int msg, int user, int param1, int param2);

    [DllImport("winmm.dll", EntryPoint = "timeGetDevCaps")]
    private static extern TimerError TimeGetDevCaps(ref TimerCaps ptc, int cbtc);

    [DllImport("winmm.dll", EntryPoint = "timeSetEvent")]
    private static extern int TimeSetEvent(int delay, int resolution, TimerCallback callback, int user, int eventType);

    [DllImport("winmm.dll", EntryPoint = "timeKillEvent")]
    private static extern TimerError TimeKillEvent(int id);

    private static TimerCaps _caps;
    private int _interval;
    private int _resolution;
    private TimerCallback _callback;
    private int _id;

    static HighPrecisionTimer()
    {
        TimeGetDevCaps(ref _caps, Marshal.SizeOf(_caps));
    }

    public HighPrecisionTimer()
    {
        Running = false;
        _interval = _caps.periodMin;
        _resolution = _caps.periodMin;
        _callback = new TimerCallback(TimerEventCallback);
    }

    ~HighPrecisionTimer()
    {
        TimeKillEvent(_id);
    }

    public int Interval
    {
        get { return _interval; }
        set
        {
            if (value < _caps.periodMin || value > _caps.periodMax)
                throw new Exception("invalid Interval");
            _interval = value;
        }
    }

    public bool Running { get; private set; }

    public event Action Ticked;

    public void Start()
    {
        if (!Running)
        {
            _id = TimeSetEvent(_interval, _resolution, _callback, 0,
                (int)RepeateType.TIME_PERIODIC | (int)CallbackType.TIME_KILL_SYNCHRONOUS);
            if (_id == 0) throw new Exception("failed to start Timer");
            Running = true;
        }
    }

    public void Stop()
    {
        if (Running)
        {
            TimeKillEvent(_id);
            Running = false;
        }
    }

    private void TimerEventCallback(int id, int msg, int user, int param1, int param2)
    {
        Ticked?.Invoke();
    }
}

从这段代码可以看出，这个封装的核心点主要有三个：