.NET Core异步IO为何生成大量线程？Windows环境技术疑问

首先得明确一个关键差异：你代码里记录的threads集合，只捕获了CLR线程池工作线程在执行你业务代码片段时的ID，但资源监视器显示的是整个进程的所有线程——这里面包含了大量你没记录到的、由.NET运行时或HttpClient底层组件创建的后台线程，这就是数量差异的核心原因。

下面具体拆解那些额外线程的来源，以及为什么.NET Core 2.0的线程数比.NET Framework多这么多：

1. HttpClient底层的SocketsHttpHandler线程池（.NET Core 2.0专属） #

.NET Core 2.0开始，HttpClient默认使用SocketsHttpHandler作为底层处理器（而.NET Framework默认用的是基于WinHTTP的HttpClientHandler）。SocketsHttpHandler会维护自己独立的IO线程池，用来处理网络请求的异步IO操作——这些线程不属于CLR管理的ThreadPool，所以你的threads集合根本不会记录到它们。

当你发起大量并发HTTP请求时，SocketsHttpHandler会自动创建更多的IO线程来处理连接、读写数据，这就是.NET Core进程里多出大量线程的主要原因。而.NET Framework的WinHTTP模型线程复用效率更高，创建的线程数自然少很多。

2. CLR运行时的后台线程 #

不管是.NET Core还是Framework，CLR本身都会创建一系列后台线程来处理核心任务，比如：

• GC后台线程（用于后台垃圾回收，避免阻塞前台业务）
• JIT编译线程（实时编译IL代码为机器码）
• 线程池的IO完成端口线程（注意：你设置的ThreadPool.SetMaxThreads(10,10)里的第二个参数是CLR线程池的IO线程上限，但SocketsHttpHandler并没有使用这个线程池，所以这个设置对它无效）
• 运行时宿主线程（控制台程序的Core运行时也会有少量宿主管理线程）

这些线程都是进程总线程数的一部分，但不会被你的业务代码捕获到。

3. 为什么ThreadPool.SetMaxThreads不起作用？ #

你设置的是CLR线程池的工作线程和IO线程上限，但那些额外的线程要么是SocketsHttpHandler自己的线程池，要么是CLR运行时的系统线程，根本不受这个配置的约束，所以即使你设置了上限，总线程数还是不会减少。

如何验证和控制？ #

• 验证线程来源：可以用Visual Studio的诊断工具（Debug -> Show Diagnostic Tools）或者Process Explorer查看每个线程的调用栈，就能清楚看到哪些是SocketsHttpHandler的线程，哪些是GC、JIT等系统线程。
• 控制SocketsHttpHandler线程数：如果你想减少这些线程，可以手动创建SocketsHttpHandler并配置连接数上限，然后传入HttpClient：

var handler = new SocketsHttpHandler
{
    MaxConnectionsPerServer = 10, // 限制每个服务器的并发连接数
    PooledConnectionLifetime = TimeSpan.FromMinutes(5) // 控制连接池的连接生命周期
};
var httpClient = new HttpClient(handler) { Timeout = TimeSpan.FromMilliseconds(10000) };

这样可以降低底层IO线程的创建数量。

关于你日志里的线程数 #

你记录的10个distinct线程是正常的：Task.Run会复用CLR线程池的工作线程，await异步操作时线程会被释放回线程池，所以实际活跃的工作线程数量不多，线程池会高效复用这些线程，因此你捕获到的唯一线程数只有10个。

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