Azure Function项目Timer触发运行时阻塞Http触发请求如何处理

你遇到的阻塞行为不是Azure Functions的预期设计，同一个Function App项目完全支持包含Timer Trigger、HTTP Trigger在内的多类触发器共存并行运行，没有官方限制禁止该用法。

问题本质是你代码中的同步阻塞逻辑 + 默认并发配置不足共同导致的线程池耗尽：

• Timer函数中使用的Thread.Sleep(10000)是同步阻塞调用，会长期占用.NET线程池的工作线程
• 本地调试或低配置实例默认的线程池最小数量很低，线程被Timer函数占满后，Runtime没有多余线程处理HTTP请求、甚至无法维持端口监听，就会返回ECONNREFUSED错误

1. 替换同步阻塞逻辑为异步实现（最优方案） #

将Timer函数的同步阻塞代码改为异步非阻塞写法，避免长期占用工作线程：

public static class Timer
{
    [FunctionName("Timer")]
    public static async Task Run([TimerTrigger("0 */5 * * * *", RunOnStartup =true)]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        // 用异步等待替代同步Sleep，不会占用工作线程
        await Task.Delay(10000);
        log.LogInformation($"C# Timer trigger function executed done");
    }
}

2. 调整host.json并发配置 #

在项目根目录的host.json中为不同触发器配置独立的并发上限，避免单类触发器占用所有资源：

{
  "version": "2.0",
  "http": {
    "maxConcurrentRequests": 50,
    "dynamicThrottlesEnabled": true
  },
  "timer": {
    "maxDegreeOfParallelism": 1
  }
}

3. 调整线程池最小线程数（适配本地调试场景） #

如果仅在本地调试时出现该问题，可以在函数类的静态构造函数中提前扩容线程池，避免线程池扩容延迟导致的临时阻塞：

public static class Timer
{
    static Timer()
    {
        // 将最小工作线程、IO线程数调整为20，可按需调高
        ThreadPool.SetMinThreads(20, 20);
    }

    // 原有Run逻辑
}

配置完成后，不管是本地调试还是部署到Azure环境，两类触发器都可以正常并行运行，不会出现HTTP请求被阻塞的问题。

内容的提问来源于stack exchange，提问作者user1515791