放弃等待，故障到来：少一个 await 引发的 tcp 连接泄漏故障

更新：后来升级至 .NET Core 2.2 Preview 3 ，并将 System.Net.Http 升级至 4.3.4 之后没出现这个问题，问题与 https://github.com/dotnet/corefx/pull/32568 有关。

以下内容是当时的错误判断。

今天上午的故障之后，我们 review 了代码，通过压力测试重现问题，分析验证，最终找到了问题的真正原因 —— 在 ASP.NET Core 程序中调用 async 方法时没加 await 。

public async Task<IActionResult> GetRecommDocuments()
{
    //...
    ShowItem(docs, app); //async方法，其中用到了HttpClient
    return Ok(docs);
}

就是上面的代码中“漏”写了 await ，不是粗心漏写，是故意为之。我们不关心调用 ShowItem 的结果，只要能执行就行，即使执行失败也可以接受。不加 await 可以让 GetRecommDocuments 方法调用 ShowItem 之后无需等待继续执行从而提高响应速度，但是没想到这一招偷工减料，竟然抽空了服务器的 TCP 连接资源，让整个服务器大厦轰然倒塌。

以下删除线部分的分析是错误的，真正原因有待进一步追踪。

开始从 async/await 的角度怎么也想不通 —— 少一个 await 怎么会如此严重后果，后来突然想到罪魁祸首不在 async/await 而在依赖注入（DI）。GetRecommDocuments 中的 HttpClient 实例是通过构造函数的 IHttpClientFactory 注入的，注入的 HttpClient 实例的生命周期是 Scoped （当前请求范围），本来正常情况下一个请求处理结束，HttpClient 实例会被 DI 容器 Dispose，所使用的 Socket 连接会被放回连接池，但是由于没加 await ，让 ShowItem 不走正常路，DI 容器在请求处理结束时跟踪不到 ShowItem 中的 HttpClient 实例，也就不会进行 Dispose 。结果来一个请求，IHttpClientFactory 就创建一个 HttpClient 实例，每个 HttpClient 实例都占用一个新的 TCP 连接，直至拖垮服务器。

随着软件开发技术的发展，开发效率越来越高了，要写的代码越来越少了，但要考虑的问题却越来越多了。虽然我们每天都在用着 .NET Core ，但由于其内部工作机制不够熟悉，原以为“巧夺天工”的一招却酿成大错，我们会牢记这次教训，进一步地对 .NET Core 刨根问底 。