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 用法），后果比单纯性能下降严重得多。
