【代码品鉴】从“线程池枯竭”到“并发可控”——使用 `SemaphoreSlim` 实现优雅限流

一、 我们遇到了什么问题？
        在异步编程中，我们习惯使用 `Task` 来执行各种操作。但在高并发场景下，如果不加控制，瞬间创建的大量 `Task` 会耗尽线程池中的线程。

        这会导致：
        - 线程池饥饿：新请求无法及时获取线程，只能排队等待。
         - 系统吞吐量急剧下降：请求延迟增加，响应变慢。
         - 服务雪崩：整个系统被拖垮，甚至不可用。

        简单来说：就像一条只有10个收费口的高速公路，突然涌来1000辆车，结果就是所有车都堵死。

二、 解决方案是什么？
        我们的目标是：控制并发度，确保同时执行的 `Task` 数量在一个安全范围内。

        .NET 为我们提供了一个轻量、高效的利器——`SemaphoreSlim`。

         你可以把它想象成一个 “俱乐部保安”：
        - 俱乐部容量有限（比如10人）。
        - 保安只允许10个人同时进入。
        - 出来一个，才能再放进去一个。
        - 其他人在门口有序排队，不会冲垮场内秩序。

三、 代码对比：一看就懂

 1、无控制的风险代码

结果：进程线程数持续飙升，系统不稳定。

2、有控制的优雅代码

结果：无论总任务量多大，同一时刻只有10个在执行。线程数稳定在20+，系统吞吐量平稳。

四、 核心要点与最佳实践

        (1)核心优势
        使用 SemaphoreSlim 这一轻量级同步原语，精准控制同时执行的 Task 数量上限，有效避免了高并发场景下可能导致的线程池饥饿问题。确保系统在高压下依然保持稳定、可预测的性能，防止因资源耗尽而导致的服务雪崩。

        (2)规范的资源操作保障
        采用 try-finally 代码块确保 _parallelismLimiter.Release() 无论如何都会被执行。这是使用此类可计数量器时的最佳实践，从根本上避免了资源泄漏，保证了系统的长期健壮性。

        (3)可借鉴的设计思想
        并发控制模式：将Wait()放在任务创建前，Release()放在finally块中
        性能优化：并发度设置为Environment.ProcessorCount，符合 CPU 密集型任务特点
        扩展性：此模式可应用于任何需要控制并发度的场景

总结
`SemaphoreSlim` 是一个简单而强大的并发控制原语。通过充当“并发闸门”，它帮助我们以极低的成本实现了从 “线程池枯竭” 到 “并发可控” 的优雅转变，是构建高弹性、高稳定性的微服务系统中不可或缺的工具。

————————————————————————————————

案例推荐： 架构师团队
代码提供：  平台技术部 张昆
知识资产贡献：产品赋能部