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

一：背景

1. 讲故事

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

二：为什么会容易饥饿

1. 测试代码

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


    internal class Program
    {
        static void Main(string[] args)
        {
            UseAwaitAsync();

            Console.ReadLine();
        }

        static async Task<string> UseAwaitAsync()
        {
            string filePath = "D:\\dumps\\trace-1\\GenHome.DMP";
            Console.WriteLine($"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss:fff")} 请求发起...");
            using (FileStream fileStream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 16, useAsync: true))
            {
                byte[] buffer = new byte[fileStream.Length];

                int bytesRead = await fileStream.ReadAsync(buffer, 0, buffer.Length);

                string content = Encoding.UTF8.GetString(buffer, 0, bytesRead);

                var query = $"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss:fff")} 获取到结果:{content.Length}";

                Console.WriteLine(query);

                return query;
            }
        }
    }

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

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

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

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

2. 如何眼见为实

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

观察第一阶段

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


    internal sealed class PortableThreadPool
    {
        private unsafe void Poll()
        {
            int num;
            while (Interop.Kernel32.GetQueuedCompletionStatusEx(this._port, this._nativeEvents, 1024, out num, -1, false))
            {
                for (int i = 0; i < num; i++)
                {
                    Interop.Kernel32.OVERLAPPED_ENTRY* ptr = this._nativeEvents + i;
                    if (ptr->lpOverlapped != null)
                    {
                        this._events.BatchEnqueue(new PortableThreadPool.IOCompletionPoller.Event(ptr->lpOverlapped, ptr->dwNumberOfBytesTransferred));
                    }
                }
                this._events.CompleteBatchEnqueue();
            }
            ThrowHelper.ThrowApplicationException(Marshal.GetHRForLastWin32Error());
        }
    }

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

观察第二阶段

当IO线程将数据丢到队列之后，接下来就需要用 Worker线程去取了，这里就有了一个重大隐患，这个隐患在于如果当前存在线程饥饿，而线程的动态注入又比较慢，所以这个event存在不能及时取出来的情况。

按照模型图描述，这个阶段是从 event 中拆解出 ValueTaskSourceAsTask，这中间还涉及到了 ThreadPoolBoundHandleOverlapped 的解包逻辑，我在上篇
聊一聊 C#异步中的Overlapped是如何寻址的

和大家聊过，这里就不赘述了，接下来在
ManualResetValueTaskSourceCore<TResult>.SignalCompletion()
上下一个断点观察。

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

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


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

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

观察第三阶段

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

3. .NET6 会这样吗

很多朋友可能会说 .NET8 是这样，那之前的版本也是这样吗？也有一些朋友可能会说，我的饥饿发生在
网络IO
，并没有看到类似
文件IO
的情况。

在我的dump分析之旅中，确实几乎所有的饥饿都发生在
网络IO
上，并且 .NET6 和 .NET8 在
网络IO
上的行为已经完全不一样了。

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

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


    internal class Program
    {
        static async Task Main(string[] args)
        {
            var task = await GetContentLengthAsync("http://baidu.com");

            Console.ReadLine();
        }
        static async Task<int> GetContentLengthAsync(string url)
        {
            using (HttpClient client = new HttpClient())
            {
                var content = await client.GetStringAsync(url);

                Debug.WriteLine($"线程编号:{Environment.CurrentManagedThreadId}, content.length={content.Length}");

                Debugger.Break();

                return content.Length;
            }
        }
    }

.NET6 下的WinDbg观察

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

.NET8 下的WinDbg观察

从卦中可以看到
tid=9
后面是
Threadpool Worker
标记，这就说明复杂了哈。。。

三：总结

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

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

一：背景

1. 讲故事

二：为什么会容易饥饿

1. 测试代码

2. 如何眼见为实

3. .NET6 会这样吗

三：总结

添加新评论

最新文章

最近回复

分类

归档

其它

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

一：背景

1. 讲故事

二：为什么会容易饥饿

1. 测试代码

2. 如何眼见为实

3. .NET6 会这样吗

三：总结

添加新评论

最新文章

最近回复

分类

归档

其它

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