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

https://lindexi.gitee.io：本文来源林德熙的博客

微软MVP 林德熙：作者

      我有一个上古的库，我使用这个库用来上报日志，而刚才日志服务挂了。然后我就发现了我的应用拒绝响应了，通过 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服务主机里面的线程是主线程固定的，但是调用到对应的控制器需要通过线程池调度。

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

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

       我在调试中看到如下代码：

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

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

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

       这是我写出的最简单的日志服务的代码，这个代码的所有请求都会进入到await  Task.Task; 等待一个不会返回的任务，也就是任何的请求进来只能等待超时而刚好上面业务应用的等待是没有设置超时的，在同步的调用等待一个不会返回的请求，此时的线程就被占用了。

       如果业务应用对每次请求都需要进行如上面的从线程池获取线程然后进行同步访问，那么线程池的将会被用光。在线程池的线程都被占用的时候，下次调用 Task.Run 就会先等待一段时间，如果等待一段时间还没有线程可以调度，那么此时才会在线程池新建线程。

       所以应用如果拒绝响应，首先需要调查应用是否用光了线程池，然后再调查连接数。如果是线程池用光，那么打开并行堆栈，看线程最多的堆栈是什么，然后通过堆栈和源代码可以找到是否存在锁或者调用 IO 同步。

        如果发现这个的 asp dotnet core 应用的性能不足，因为线程开启过多，那么此时可以全局找 Task.Run 的代码，尽可能干掉这部分逻辑。

       本文的坑，可以使用将同步修改为异步的方法解决，换句话说，不需要通过线程池开启线程的方法，通过IO自带的异步方法进行异步IO请求。此时在IO的异步里面将会自动出让CPU执行，这部分是硬件的支持，因此进入异步的 IO 将不会占用线程，线程可以回到线程池给其他业务调用。

       一个可选的方法是将一些不重要但是需要慢慢执行的任务放在生产者消费者队列里面，如果这部分任务很小，可以尝试使用我的AsyncQueue 高性能低资源占用的类。

本文转自博客