ASP.NET Core Web API调用WCF超时后线程数持续上涨问题求助

1. 线程泄露与线程池状态排查 #

• 进程Dump分析：在线程数超过200且持续上涨时，用dotnet-dump collect或DebugDiag抓取进程Dump，重点分析所有线程的托管/非托管调用栈，排查是否存在大量卡在WCF调用等待、异常处理逻辑阻塞的僵尸线程，同时确认是否存在异步调用未配置ConfigureAwait(false)导致的同步上下文阻塞泄漏。
• WCF客户端生命周期排查：检查是否存在每次调用WCF都新建客户端实例，且异常场景下未调用Abort()方法强制释放底层信道资源的情况，未正确释放的WCF信道会长期占用线程池资源挂起。
• 线程池参数监控：用dotnet-counters monitor实时观测线程池工作线程、IO线程计数及全局队列长度，你观测到的每秒1个的线程上涨速度符合.NET线程池默认的新线程创建速率，说明此时线程池工作线程已耗尽，请求持续在全局队列中排队，线程池只能按最低速率创建新线程处理，即使WCF服务恢复，排队的存量请求+新增请求也会持续消耗线程资源，无法自行恢复。

2. 流量控制与容错逻辑排查 #

• 熔断降级策略检查：确认是否对WCF调用配置了失败率阈值限制，若无对应策略，WCF异常时大量请求会持续打到WCF客户端，即使服务恢复后，累积的排队请求也会持续占满线程池资源，形成恶性循环。
• IIS与运行时配置检查：确认IIS应用池的maxConcurrentRequestsPerCPU、queueLength配置是否合理，以及.NET Core是否配置了足够的最小线程数，避免瞬时高并发时线程池创建线程速度跟不上请求速度，导致请求持续堆积。

• 调整WCF调用超时配置：将WCF客户端的打开、关闭、发送、接收四类超时阈值统一调整为业务可接受的范围（建议5~10秒），避免单次调用长时间占用线程资源。
• 新增WCF调用熔断降级逻辑：集成Polly等容错库配置CircuitBreakerPolicy，当WCF调用失败率达到设定阈值（如50%）时主动熔断一段时间，直接返回降级结果，避免持续调用不可用的WCF服务导致请求堆积。
• 优化WCF客户端调用逻辑：
  • 所有异步WCF调用统一添加ConfigureAwait(false)，避免同步上下文阻塞。
  • WCF客户端采用单例或池化方式管理，不要每次调用新建实例，异常场景下统一调用Abort()释放信道，不要依赖GC自动回收资源。
• 调整线程池配置：在程序启动入口调用ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100)，数值可根据平时峰值线程数上调20%，提升线程池应对瞬时高并发的响应速度，避免请求排队。
• 配置自动健康回收策略：给IIS应用池配置健康检测规则，当线程数超过阈值、请求响应超时率超过阈值时自动回收应用池，避免服务完全不可用影响业务。

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