asp dotnet core 记一次应用拒绝响应调试开启线程等待同步用光线程池

我有一个上古的库，我使用这个库用来上报日志，而刚才日志服务挂了。然后我就发现了我的应用拒绝响应了，通过 VisualStudio 断点调试可以发现线程池的线程全部被占用了。因为没有可用线程因此所有对 asp dotnet core 应用的访问全部都不会收到响应，为什么我的另一个应用日志服务挂了会让我的业务应用拒绝响应？为什么我的业务应用会使用线程池所有的线程，为什么线程池的所有线程被占用将会让应用拒绝响应

很好复现这个坑，在开始复现之前，需要聊一下背景

我有一个业务应用和一个日志服务，基本上可以认为日志服务和业务没有任何关联，而且我从上层业务调用可以看到，都是异步使用。而在日志服务全部挂掉的时候，开始业务应用还能使用，但是当请求大概访问了 100 次，就发现后续的访问都没有任何返回。同时在业务应用的本机控制台和日志文件里面都没有任何记录，而控制台也没有收到 50x 等错误，也就是业务应用还在工作，但是没有任何响应

我在本地上可以复现，使用 VisualStudio 开启所有异常，也什么都没收到。在应用配置文件 appsettings.json 文件里面将日志配置设置为 Debug 也没有拿到任何有用的信息

原本每次的请求都会在默认的 asp dotnet core 日志输出至少一条日志，但是此时什么日志都没有输出

而此时的业务应用的 cpu 和内存占用都很少，在没有请求的时候，可以看到 cpu 几乎没有占用

在点击 VisualStudio 暂停的时候，可以看到业务应用创建了大量的线程

其实调试到线程的时候，大概半个下午了，哈哈

其实我不知道如果一个 asp dotnet core 应用对所有的请求都没有返回，也没有报错的时候可以如何调试

在看到有大量的线程被创建的时候，此时可以调试的是打开调试->窗口->并行堆栈这个工具可以辅助调查所有线程问题

如果一个应用创建了大量线程，如果这些线程都是通过 Task.Run 创建，那么意味着线程池里面的线程全部都使用了。也就是此时的下一次调用 Task.Run 需要等待线程池重新分配或创建线程。如果线程池没有空闲的可以分配需要等待一段时间才能创建新的线程，于是此时的应用就会卡住没有返回值

而根据 Eleven 老师的 asp dotnet core 源代码分析课程可以了解到，在 asp dotnet core 服务主机里面的线程是主线程固定的，但是调用到对应的控制器需要通过线程池调度。当然更多细节还请小伙伴关注 Eleven 老师的社区

在用光线程池的线程，此时的请求可以被主机处理，因此不会抛出远程服务器拒绝请求。但是主机通过线程池调度到对应控制器，因为线程池没有足够的线程，因此将会进入很长的等待。特别是有后续请求，那么将需要不断排队。这就是为什么我看到的业务应用拒绝服务

进一步的调试可以通过并行堆栈找到最多相同的堆栈，也就是有多少线程都在相同的堆栈里，那么证明这部分逻辑有锅

我在调试中看到如下代码

我的底层库给我的方法是异步的上报日志方法，但是这个日志上报方法的核心是通过 Task.Run 一个线程进行同步调用

其实在 asp dotnet core 的性能优化中，要尽量不使用 Task.Run 方法，在 ASP.NET Core Performance Best Practices 官方文档和译文 ASP.NET Core 性能优化最佳实践 - Newbe36524 - 博客园都有提到，原因还请小伙伴看这两篇博客

那么为什么上面的代码将会让线程池的线程都在等待？原因是 GetResponse 是一句同步的代码，同步的代码等待网络的返回，而此时我的日志服务大概写了如下代码

        [HttpGet]
        [Route("/")]
        public async Task<IActionResult> Get()
        {
            await Task.Task;

            return Ok();
        }

        private static readonly TaskCompletionSource<bool> Task = new TaskCompletionSource<bool>();