System.Timers.Timer在高并发下会重入，因其Elapsed事件默认在ThreadPool线程触发且不阻塞后续tick，导致未完成的上一次处理与新触发的Elapsed同时执行；这是设计使然，优先保证计时精度而非串行性。

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 缓存任务，由单个后台线程逐个消费（即“定时投递 + 单线程执行”模式）

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

Stop() 和 AutoReset 的坑你踩过吗？

System.Timers.Timer.AutoReset = false 是常见误用点：设为 false 后，每次触发完要手动调用 Start() 才能继续，但高并发下容易漏调或重复调，反而引入竞态。

更危险的是在事件中调用 timer.Stop() + timer.Start() ——这无法阻止已排队进线程池但尚未执行的 Elapsed 回调，它们仍会运行。

真正安全的做法是：保持 AutoReset = true，靠上面说的状态标记或队列机制来控制逻辑执行节奏，而不是试图用启停干预计时器生命周期。

重入不是线程安全的全部，但它往往是压垮高并发定时任务的第一根稻草——一旦业务逻辑里有共享状态、静态缓存或非线程安全对象（比如 XmlDocument、某些旧版 HttpClient 用法），后果比单纯性能下降严重得多。