为什么 .NET8线程池 容易引发线程饥饿

一：背景

1. 讲故事

最近时间相对比较宽裕，多写点文章来充实社区吧，这篇文章主要还是来自于最近遇到的几例线程饥饿(Task.Result)引发的一系列的反思和总结，我觉得.NET8容易引发饥饿的缘故原由，更多的在于异步回调之后底层会反复的将结果丢到线程池所致，由于数据进线程池容易，再用线程到池中去捞就没有那么简单了，可能今天的话题比较有争议，当然我个人的思索也不见得一定对，算是给大家提供一个角度吧，话不多说，开干！
二：为什么会容易饥饿

1. 测试代码

为了方便报告异步回调的路径，这里我用简单的 FileStream 的异步读取来演示，当然实际的场景更多的是网络IO，末了我再上一个 .NET6 和 .NET8 的对比，先看一下参考代码。

1.     internal class Program
2.     {
3.         static void Main(string[] args)
4.         {
5.             UseAwaitAsync();
7.             Console.ReadLine();
8.         }
10.         static async Task<string> UseAwaitAsync()
11.         {
12.             string filePath = "D:\\dumps\\trace-1\\GenHome.DMP";
13.             Console.WriteLine($"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss:fff")} 请求发起...");
14.             using (FileStream fileStream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 16, useAsync: true))
15.             {
16.                 byte[] buffer = new byte[fileStream.Length];
18.                 int bytesRead = await fileStream.ReadAsync(buffer, 0, buffer.Length);
20.                 string content = Encoding.UTF8.GetString(buffer, 0, bytesRead);
22.                 var query = $"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss:fff")} 获取到结果:{content.Length}";
24.                 Console.WriteLine(query);
26.                 return query;
27.             }
28.         }
29.     }

复制代码

卦中 await 之后的回调，很多人可能会想当然的以为是IO线程一撸到底，其实在.NET8中并不是这样的，它会经历两次 Enqueue 到线程池，步骤如下：

• IO线程 封送 event 到 线程池队列。
  
• Worker线程 读取 event 拆解出 ValueTaskSourceAsTask(ReadAsync) 再次入 线程池队列。
  
• Worker线程 读取 ValueTaskSourceAsTask(ReadAsync) 拆解出编译器天生的状态机d__1，回到用户代码。
  

这里我姑且定义成三阶段吧，可能有些朋友有点含糊，我画一张简图给大家辅助一下。

代码和图都有了，接下来就是眼见为实的阶段了。
2. 怎样眼见为实

这个相对来说比较简单，在符合的位置埋上断点，然后观察线程栈即可。

• 观察第一阶段
  

自 C# 重写了ThreadPool之后，底层会用一个单独的线程轮询IO完成端口队列（GetQueuedCompletionStatusEx），参考代码如下：

1.     internal sealed class PortableThreadPool
2.     {
3.         private unsafe void Poll()
4.         {
5.             int num;
6.             while (Interop.Kernel32.GetQueuedCompletionStatusEx(this._port, this._nativeEvents, 1024, out num, -1, false))
7.             {
8.                 for (int i = 0; i < num; i++)
9.                 {
10.                     Interop.Kernel32.OVERLAPPED_ENTRY* ptr = this._nativeEvents + i;
11.                     if (ptr->lpOverlapped != null)
12.                     {
13.                         this._events.BatchEnqueue(new PortableThreadPool.IOCompletionPoller.Event(ptr->lpOverlapped, ptr->dwNumberOfBytesTransferred));
14.                     }
15.                 }
16.                 this._events.CompleteBatchEnqueue();
17.             }
18.             ThrowHelper.ThrowApplicationException(Marshal.GetHRForLastWin32Error());
19.         }
20.     }

复制代码

从卦中看，一旦 GetQueuedCompletionStatusEx 获取到了数据就开始封送 event，并投送到线程池的高优先级队列中,我们可以在 UnsafeQueueHighPriorityWorkItemInternal 上下断点即可，然后观察线程栈，截图如下：

• 观察第二阶段
  

当IO线程将数据丢到队列之后，接下来就必要用 Worker线程 去取了，这里就有了一个巨大隐患，这个隐患在于如果当前存在线程饥饿，而线程的动态注入又比较慢，以是这个event存在不能及时取出来的情况。
按照模型图描述，这个阶段是从 event 中拆解出 ValueTaskSourceAsTask，这中间还涉及到了 ThreadPoolBoundHandleOverlapped 的解包逻辑，我在上篇聊一聊 C#异步中的Overlapped是怎样寻址的和大家聊过，这里就不赘述了，接下来在ManualResetValueTaskSourceCore.SignalCompletion() 上下一个断点观察。

上面卦中的 _continuationState 就是终极拆解的 ValueTaskSourceAsTask（ReadAsync），截图如下：

有些朋友可能会有疑惑，ReadAsync 返回的是 Task ，怎么就变成了 ValueTaskSourceAsTask 呢？这是由于 ReadAsync 的底层做了一个 ValueTask -> Task 的转换，参考代码如下：

1.         public override Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
2.         {
3.             ValueTask<int> valueTask = this.ReadAsync(new Memory<byte>(buffer, offset, count), cancellationToken);
4.             if (!valueTask.IsCompletedSuccessfully)
5.             {
6.                 return valueTask.AsTask();
7.             }
8.             return this._lastSyncCompletedReadTask.GetTask(valueTask.Result);
9.         }

复制代码

反正不管怎么说，确实是真真切切的再次将数据(ValueTaskSourceAsTask) 丢入了线程池的线程本地队列，可二次丢入又放大了饥饿的风险。

• 观察第三阶段
  

数据进了队列之后，必要线程池线程再次提取，这个逻辑就比较简单了，提取 ValueTaskSourceAsTask 中的延续字段 continuationObject 来解构状态机终极回到用户代码，要想观察直接在用户方法 UseAwaitAsync() 的 await 之后下一个断点即可。

3. .NET6 会这样吗

很多朋友可能会说 .NET8 是这样，那之前的版本也是这样吗？ 也有一些朋友可能会说，我的饥饿发生在 网络IO，并没有看到类似 文件IO 的情况。
在我的dump分析之旅中，确实几乎所有的饥饿都发生在 网络IO上，并且 .NET6 和 .NET8 在 网络IO 上的行为已经完全不一样了。

• .NET6 是IO线程 一撸到底。
  
• .NET8 则必要 Worker线程 做二次处理惩罚。
  

说了这么多，我们上一个网络IO的例子，然后观察 .NET6 和 .NET8 在处理惩罚回调上的不同，参考代码如下：

1.     internal class Program
2.     {
3.         static async Task Main(string[] args)
4.         {
5.             var task = await GetContentLengthAsync("http://baidu.com");
7.             Console.ReadLine();
8.         }
9.         static async Task<int> GetContentLengthAsync(string url)
10.         {
11.             using (HttpClient client = new HttpClient())
12.             {
13.                 var content = await client.GetStringAsync(url);
15.                 Debug.WriteLine($"线程编号:{Environment.CurrentManagedThreadId}, content.length={content.Length}");
17.                 Debugger.Break();
19.                 return content.Length;
20.             }
21.         }
22.     }

复制代码

• .NET6 下的WinDbg观察
  

从卦中可以看到 tid=10 后面有一个 Threadpool Completion Port标志，这就表明确实是 IO线程 一撸到底。

• .NET8 下的WinDbg观察
  

从卦中可以看到 tid=9 后面是 Threadpool Worker标志，这就分析复杂了哈。。。
三：总结

可以肯定的是淘汰callback重入队列次数可以尽可能的避免线程饥饿，但怎么说呢？.NET8的线程池综合性能绝对比 .NET6 要刁悍的多，但.NET8中的计划理念可能也不能达到100%的全域领跑，可能在某些1%的场景下还不如 .NET6 的简单粗暴。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。