.NET多线程HttpClient并发请求性能低下问题排查与优化咨询

从你的描述和代码来看，核心问题出在每个线程都创建独立的HttpClient实例——这是.NET中使用HttpClient的典型误区，直接导致了并发场景下的性能暴跌。下面详细拆解原因并给出优化方案：

为什么多线程并发时性能下降？ #

• 连接池无法复用：每个HttpClient实例默认会创建自己的HttpMessageHandler（底层是HttpClientHandler），每个Handler维护独立的HTTP连接池。当你有几十个甚至上百个线程各持一个HttpClient时，连接池被碎片化，无法复用已建立的TCP连接，每次请求都要重新建立连接（三次握手），这会带来巨大的延迟开销。
• Socket资源耗尽：频繁创建/销毁HttpClient（即使你没有显式销毁，GC回收不及时）会导致大量Socket处于TIME_WAIT状态，系统可用端口被占满，新请求需要等待端口释放，这直接表现为请求耗时飙升。
• 服务端连锁反应：客户端的连接混乱会导致服务端接收到大量的短连接请求，服务端的线程池和连接池压力陡增，进而拉长了请求处理时间（也就是你看到的Executed Action时间从<10ms涨到50+ms）。

具体优化步骤 #

1. 复用HttpClient实例（核心优化） #

HttpClient是线程安全的，全局复用一个实例（或通过IHttpClientFactory管理，推荐.NET Core环境）是最佳实践。修改你的IServiceCommunication实现，让所有线程共享同一个HttpClient实例：

// 改为单例的IServiceCommunication实现
public class ServiceCommunication : IServiceCommunication
{
    private readonly HttpClient _httpClient;

    // 在构造函数中初始化HttpClient，并且只初始化一次
    public ServiceCommunication()
    {
        var handler = new HttpClientHandler
        {
            // 调整单目标主机的最大连接数，根据你的并发需求设置
            MaxConnectionsPerServer = 1000
        };
        _httpClient = new HttpClient(handler);
        // 可以在这里设置默认请求头、超时等
    }

    public async Task<HttpResponseMessage> SendHttpRequest(HttpRequestMessage request)
    {
        var result = await _httpClient.SendAsync(request).ConfigureAwait(false);
        return result;
    }
}

然后在你的OpenPorts方法中，将IServiceCommunication作为单例传入，而不是每个线程创建新实例：

// 假设你已经初始化了单例的serviceCommunication
private readonly IServiceCommunication _sharedServiceCommunication;

public void OpenPorts(int port)
{
    if (Logger.IsDebugEnabled) Logger.Debug("Opening port " + port);
    // 注意：这里不要用async void，改为async Task并正确管理任务
    _ = Task.Run(async () => await SocketThreadPort("tcp://*:" + port, _sharedServiceCommunication));
}

// 将async void改为async Task，避免异常无法捕获和线程泄漏
private async Task SocketThreadPort(string port, IServiceCommunication externalService)
{
    int managedThreadId = Thread.CurrentThread.ManagedThreadId;
    Console.WriteLine("ManagedThreadId = " + managedThreadId);
    while (true)
    {
        if (Logger.IsDebugEnabled) Logger.Debug("Sending on " + port);
        var reply = await externalService.SendHttpRequest(sendingData).ConfigureAwait(false);
        // 可选：根据业务场景添加小延迟，避免无限制循环占用CPU
        // await Task.Delay(1);
    }
}

2. 调整连接池与线程池参数 #

• 连接池设置：在.NET Core中，ServicePointManager.DefaultConnectionLimit不再控制HttpClient的连接数，取而代之的是HttpClientHandler.MaxConnectionsPerServer，上面的代码已经设置了这个值，你可以根据实际并发需求调整（比如1000）。
• 线程池设置：你设置的ThreadPool.SetMinThreads(20, 20)如果你的并发线程数超过20，线程池会以默认速率（每500ms新增一个线程）扩容，这可能导致短时间内线程不足。如果你的并发量稳定在较高水平，可以适当提高MinThreads的值，比如：

  ThreadPool.SetMinThreads(100, 100);
  

  注意不要设置过大，避免线程上下文切换开销增加。

3. 避免async void陷阱 #

你的SocketThreadPort方法用了async void，这在.NET中是不推荐的——async void无法被等待，异常会直接抛到线程池，可能导致程序崩溃。改为async Task后，你可以更好地控制任务的生命周期和异常处理。

现象是否正常？ #

这种现象完全不正常，是典型的HttpClient使用不当导致的性能问题。当你修复了HttpClient复用的问题后，并发场景下的请求耗时会回到单线程的水平，服务端的处理时间也会恢复正常。

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