如何让ASP.NET应用强制单线程处理请求（Docker+Kestrel环境）

你当前用Monitor在单个端点加锁的方式能实现/test端点的单请求处理，但存在局限性——仅对该端点生效，且同步锁在异步场景下容易引发问题。针对你的需求（模拟遗留系统单线程处理、Docker+Kestrel部署），以下是几种更优雅的全局实现方案：

方案1：直接配置Kestrel限制线程与连接数 #

这种方式从服务器层面强制限制并发，最贴近"单线程运行"的本质，无需在应用层加锁：

public static void Main(string[] args)
{
    var builder = WebApplication.CreateBuilder(args);

    // 配置Kestrel强制单线程单连接
    builder.WebHost.ConfigureKestrel(options =>
    {
        // 设置线程池最大/最小线程数为1
        options.ThreadPoolMinThreads = 1;
        options.ThreadPoolMaxThreads = 1;
        // 限制最大并发连接数为1
        options.Limits.MaxConcurrentConnections = 1;
        // 限制WebSocket等升级连接的并发数为1
        options.Limits.MaxConcurrentUpgradedConnections = 1;
    });

    // 其余服务注册代码不变
    builder.Services.AddAuthorization();
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
    builder.Services.AddApplicationInsightsTelemetry();

    var app = builder.Build();

    // 管道配置不变
    if (app.Environment.IsDevelopment())
    {
        app.UseSwagger();
        app.UseSwaggerUI();
    }

    app.UseAuthorization();

    app.MapGet("/test", () => 
        $"Hello From Container: {System.Environment.MachineName}");

    app.Run();
}

优势：全局生效，无需修改业务代码，完全由Kestrel管控请求并发，性能开销最小。
注意：Docker部署时需保证单容器实例，多容器会打破单线程限制。

方案2：全局中间件+SemaphoreSlim异步锁 #

如果需要在应用层灵活控制（比如后续要调整并发数），可以用SemaphoreSlim实现全局请求排队，且支持异步场景：

public static void Main(string[] args)
{
    var builder = WebApplication.CreateBuilder(args);

    // 注册全局信号量，初始计数1，最大计数1（单线程）
    builder.Services.AddSingleton(new SemaphoreSlim(1, 1));

    // 其余服务注册代码不变
    builder.Services.AddAuthorization();
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
    builder.Services.AddApplicationInsightsTelemetry();

    var app = builder.Build();

    // 管道配置不变
    if (app.Environment.IsDevelopment())
    {
        app.UseSwagger();
        app.UseSwaggerUI();
    }

    // 添加全局锁中间件，放在Authorization之前
    app.Use(async (context, next) =>
    {
        var semaphore = context.RequestServices.GetRequiredService<SemaphoreSlim>();
        try
        {
            // 等待6秒获取锁，超时则直接跳过（根据需求调整）
            if (await semaphore.WaitAsync(TimeSpan.FromSeconds(6)))
            {
                // 模拟处理耗时（异步方式，避免阻塞线程池）
                await Task.Delay(5000);
                await next();
            }
            else
            {
                // 超时处理，比如返回503
                context.Response.StatusCode = StatusCodes.Status503ServiceUnavailable;
                await context.Response.WriteAsync("Service busy, please try again later.");
            }
        }
        finally
        {
            // 确保释放锁
            semaphore.Release();
        }
    });

    app.UseAuthorization();

    app.MapGet("/test", () => 
        $"Hello From Container: {System.Environment.MachineName}");

    app.Run();
}

优势：异步友好，全局控制所有请求，可灵活调整并发数（只需修改SemaphoreSlim的初始计数），还能添加超时处理逻辑。
对比你的现有方案：你的代码仅控制/test端点，且用Thread.Sleep同步阻塞线程，而此方案用Task.Delay异步等待，更符合ASP.NET Core的异步编程模型。

现有方案的局限性 #

你当前的实现仅对/test端点生效，如果应用有其他端点，这些端点仍能并行处理请求。此外，Monitor是同步锁，若后续端点改为异步（比如用async/await），可能会出现锁释放线程与获取线程不一致的问题，引发异常。

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