Timer回调中使用lock是否会引发线程饥饿？SemaphoreSlim方案可行吗？

一、你的担忧完全合理 #

线程池线程是ASP.NET这类应用的核心资源，所有请求处理、后台任务都依赖它。

• 原代码中，每个Timer触发时都会占用一个线程池线程：如果当前有其他线程持有_globalStaticLock，这个线程就会阻塞等待直到锁释放。几百个Timer的情况下，短时间内可能有大量线程池线程被卡在等待锁的状态，导致线程池没有可用线程处理核心业务请求，引发线程饥饿，严重时会让应用响应变慢甚至无响应。
• 加上DoStuff()是CPU密集型操作，持有锁的线程会持续占用CPU资源，进一步加剧线程池的压力。

二、你的解决方案存在缺陷，并非有效优化 #

1. async void 是定时炸弹 #

Timer回调用async void非常危险：

• Timer不会等待异步方法执行完成，一旦DoStuff()抛出异常，这个异常会直接绕过常规的异常捕获机制，导致进程崩溃，没有任何补救机会。
• async void方法的生命周期不受控制，难以追踪和调试。

2. 对CPU密集型任务无实质优化 #

用SemaphoreSlim.WaitAsync()替代lock，只是把阻塞等待锁变成了异步等待锁，但DoStuff()本身是CPU密集型的，执行它的时候依然会占用一个线程池线程——和原方案相比，只是等待阶段不占线程，但执行阶段的线程占用问题完全没解决。几百个Timer触发时，还是会有大量异步等待的任务，一旦拿到信号量，还是会占用线程执行CPU密集操作，线程池资源紧张的问题依然存在。

三、更合理的优化方案 #

方案1：合并所有Timer（最优） #

既然所有Timer都调用同一逻辑，完全没必要保留几百个Timer——只需要一个Timer定时执行DoStuff()即可。这样从根源上避免了大量线程池线程被占用的问题，同时lock或SemaphoreSlim的等待场景也会极少出现。

方案2：用单线程队列处理任务 #

如果必须保留多个Timer（比如每个Timer对应不同的缓存分区，但逻辑一致），可以把任务扔进一个单线程处理的队列：

// 全局单线程任务队列
private static readonly Channel<object> _evictionQueue = Channel.CreateUnbounded<object>();

// 启动一个后台线程处理队列
static YourClass()
{
    _ = Task.Run(async () =>
    {
        await foreach (var item in _evictionQueue.Reader.ReadAllAsync())
        {
            DoStuff();
        }
    });
}

private void EvictExpiredItems(object state)
{
    // Timer回调只做一件事：把任务扔进队列，不占用线程池线程
    _evictionQueue.Writer.TryWrite(null);
}

这样不管多少Timer触发，最终只有一个后台线程执行DoStuff()，不会消耗额外的线程池资源，彻底解决线程饥饿问题。

方案3：修复你的SemaphoreSlim方案（次选） #

如果坚持用SemaphoreSlim，必须改掉async void，同时做好异常处理：

// 静态信号量，初始计数1
private static readonly SemaphoreSlim _semaphoreSlim = new SemaphoreSlim(1, 1);

private void EvictExpiredItems(object state)
{
    // 用异步任务包裹，避免async void
    _ = ProcessEvictionAsync();
}

private async Task ProcessEvictionAsync()
{
    await _semaphoreSlim.WaitAsync();
    try
    {
        DoStuff();
    }
    catch (Exception ex)
    {
        // 必须捕获异常，避免进程崩溃
        // 这里可以加日志记录
    }
    finally
    {
        _semaphoreSlim.Release();
    }
}

但注意：这个方案只是解决了async void的崩溃风险，并没有解决CPU密集任务占用线程池的问题，只是等待阶段更友好，适合Timer触发频率不高的场景。

内容的提问来源于stack exchange，提问作者Alex from Jitbit