.NET Framework 4.5中HttpClient连接失败时_SSLStream内存泄漏排查

这个泄漏是.NET Framework 4.5版本底层实现缺陷+异常场景触发共同导致的，核心逻辑如下：

• 正常请求成功场景：内部创建的_SSLStream会绑定到HttpResponseMessage的内容流上，你在finally块中Dispose响应对象时，会顺带着释放底层SSLStream资源，资源要么归还连接池要么被GC回收，所以不会出现内存累积。
• API无法连通的异常场景：如果请求在TCP连接建立后、TLS握手阶段/请求发送阶段失败，_SSLStream已经完成初始化，但还没绑定到最终返回的HttpResponseMessage对象上，此时SendAsync直接抛出异常，你的代码拿到的responseMessage是null，根本无法触发这部分资源的释放。而.NET Framework 4.5的原生逻辑存在bug，这部分半初始化的_SSLStream会被长期存活的ServicePoint对象持有引用，既不会被归还到连接池，也不会被GC回收，每分钟一次失败请求就会残留一个SSLStream对象，长期运行内存就会持续上涨。
• 你代码中catch (Exception ex) { throw ex; }的写法不会直接导致泄漏，但会丢失异常原始堆栈，不利于排查连接失败的具体原因，属于额外的代码缺陷。

按优先级排序：

1. 优先将项目运行时升级到.NET Framework 4.6及以上版本，微软在4.6版本中正式修复了异步HTTP请求失败时SslStream/TlsStream未被正确释放的已知bug，升级后不需要修改现有HttpClient复用逻辑即可解决泄漏问题。
2. 如果暂时无法升级框架版本，需要全局配置ServicePointManager的资源回收策略，强制回收失效连接关联的资源：

   // 全局配置：服务点最大空闲时间30秒，超过则自动回收
   ServicePointManager.MaxServicePointIdleTime = 30000;
   ServicePointManager.UseNagleAlgorithm = false;
   ServicePointManager.Expect100Continue = false;
   // 开启TCP保活，避免僵死连接长期持有资源
   ServicePointManager.SetTcpKeepAlive(true, 15000, 3000);
   
   // 针对目标API的根地址，单独配置连接租约超时为1分钟
   var targetServicePoint = ServicePointManager.FindServicePoint(new Uri("https://your-api-base-address/"));
   targetServicePoint.ConnectionLeaseTimeout = 60000;
   

3. 补全HttpClient基础配置，减少异常场景的资源挂起概率：

   public Sample() {
       System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
       this.Client = new HttpClient();
       // 显式设置30秒请求超时，避免异常请求长期挂起
       this.Client.Timeout = TimeSpan.FromSeconds(30);
       // 固定Authorization头不需要每次请求都创建，直接配置到客户端默认头即可
       this.Client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "SomeAccessToken");
   }
   

4. 修正异常处理逻辑，把throw ex替换为throw，保留原始异常堆栈方便排查连接故障。

注：你当前复用单例HttpClient的写法本身是.NET Framework下的正确实践，不需要改成每次请求新建HttpClient的模式，后者反而会引发更严重的端口耗尽问题。

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