如何限制GRPC请求的并发线程数（完成即启动新请求）

方案1：使用Parallel.ForEach（适配同步SendOverGrpc方法） #

如果你的SendOverGrpc是同步方法，直接用Parallel.ForEach并指定最大并发度即可——它会自动调度任务，完成一个就启动下一个，无需手动管理线程：

Parallel.ForEach(elements, new ParallelOptions { MaxDegreeOfParallelism = 10 }, element =>
{
    SendOverGrpc(element);
});

关键说明 #

• MaxDegreeOfParallelism = 10 明确限制同时执行的任务数为10
• 框架会自动处理线程复用与任务调度，避免无限制创建线程导致的资源浪费

方案2：使用SemaphoreSlim（适配异步SendOverGrpcAsync方法） #

如果GRPC客户端提供异步方法（比如SendOverGrpcAsync，推荐用异步处理IO密集型的GRPC请求），SemaphoreSlim是更灵活的并发控制方式：

// 初始化信号量，允许同时处理10个请求
var semaphore = new SemaphoreSlim(10);
var tasks = new List<Task>();

foreach (var element in elements)
{
    // 异步等待信号量释放名额
    await semaphore.WaitAsync();
    
    tasks.Add(Task.Run(async () =>
    {
        try
        {
            await SendOverGrpcAsync(element);
        }
        finally
        {
            // 无论请求成功/失败，都释放信号量，让下一个请求进入
            semaphore.Release();
        }
    }));
}

// 等待所有请求完成
await Task.WhenAll(tasks);

关键说明 #

• SemaphoreSlim(10) 设置初始并发额度为10
• WaitAsync() 异步等待，不会阻塞线程，更适合高并发场景
• finally块确保信号量一定会被释放，避免出现死锁

原代码问题分析 #

你原来的代码会为每个element直接创建新线程，完全没有并发限制。当elements数量较大时，会瞬间创建大量线程，消耗系统内存与CPU资源，甚至引发性能瓶颈。上面两种方案都能严格控制并发数在10，且自动调度后续请求。

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