c# 高并发下System.Timers.Timer的重入（Re-entrancy）问题

来源：这里教程网时间：2026-02-21 17:37:28 作者：

System.Timers.Timer 在高并发下为什么会重入？

因为

System.Timers.Timer

的

Elapsed

事件默认在

ThreadPool

线程上触发，且**不阻塞后续计时器滴答（tick）**。如果上一次事件处理还没结束，下一次

Elapsed

就可能在另一个线程上再次进入同一事件处理器——这就是典型的重入。

这不是 bug，是设计使然：它优先保证计时精度，而非执行串行性。你在高频、耗时操作（如 IO、数据库写入、锁竞争）中直接处理

Elapsed

，就很容易撞上重入。

如何判断当前是否发生了重入？

最直接的方式是在事件处理器开头加一个原子标记：

private static readonly object _lock = new object();
private static bool _isRunning = false;
private void OnTimerElapsed(object sender, ElapsedEventArgs e)
{
    if (Interlocked.CompareExchange(ref _isRunning, 1, 0) == 1)
    {
        // 已有执行在进行，本次被跳过或记录
        Console.WriteLine("重入检测：跳过本次 Elapsed");
        return;
    }
    try
    {
        // 实际业务逻辑
        DoWork();
    }
    finally
    {
        Interlocked.Exchange(ref _isRunning, 0);
    }
}

注意：

Interlocked

比

lock(_lock)

更轻量，适合这种简单状态控制；但别用

bool

字段直接赋值判断，那不是原子的。

比手动加锁更稳妥的替代方案

重入问题本质是「定时触发」和「串行执行」需求冲突。与其在事件里硬扛，不如把调度和执行解耦：

用
System.Threading.Timer
（底层更轻，只回调一个方法，无事件封装） +
ManualResetEventSlim
控制节流改用
Task.Run(() => { ... }).ConfigureAwait(false)
包裹业务，再配合
async/await
+
SemaphoreSlim
限流对必须严格顺序执行的场景，用
ConcurrentQueue<action></action>
缓存任务，由单个后台线程逐个消费（即“定时投递 + 单线程执行”模式）

其中第三种最彻底：计时器只负责发消息，不执行；执行层完全可控，不会重入，也不会堆积线程。