揭秘 Task.Wait

简介

Task.Wait 是 Task 的一个实例方法,用于等待 Task 完成,如果 Task 未完成,会阻塞当前线程。

非必要情况下,不建议使用 Task.Wait,而应该使用 await。

本文将基于 .NET 6 的源码来分析 Task.Wait 的实现,其他版本的实现也是类似的。

csharp 复制代码
var task = Task.Run(() =>
{
    Thread.Sleep(1000);
    return "Hello World";
});

var sw = Stopwatch.StartNew();
Console.WriteLine("Before Wait");
task.Wait();
Console.WriteLine("After Wait: {0}ms", sw.ElapsedMilliseconds);

Console.WriteLine("Result: {0}, Elapsed={1}ms", task.Result, sw.ElapsedMilliseconds);

输出:

ini 复制代码
Before Wait
After Wait: 1002ms
Result: Hello World, Elapsed=1002ms

可以看到,task.Wait 阻塞了当前线程,直到 task 完成。

其效果等效于:

  1. task.Result (仅限于 Task<TResult>)

  2. task.GetAwaiter().GetResult()

task.Wait 共有 5 个重载

csharp 复制代码
public class Task<TResult> : Task
{
}

public class Task
{
    // 1. 无参数,无返回值,阻塞当前线程至 task 完成
    public void Wait()
    {
        Wait(Timeout.Infinite, default);
    }

    // 2. 无参数,有返回值,阻塞当前线程至 task 完成或 超时
    // 如果超时后 task 仍未完成,返回 False,否则返回 True
    public bool Wait(TimeSpan timeout)
    {
        return Wait((int)timeout.TotalMilliseconds, default);
    }

    // 3. 和 2 一样,只是参数类型不同
    public bool Wait(int millisecondsTimeout)
    {
        return Wait(millisecondsTimeout, default);
    }

    // 4. 无参数,无返回值,阻塞当前线程至 task 完成或 cancellationToken 被取消
    // cancellationToken 被取消时抛出 OperationCanceledException
    public void Wait(CancellationToken cancellationToken)
    {
        Wait(Timeout.Infinite, cancellationToken);
    }

    // 5. 无参数,有返回值,阻塞当前线程至 task 完成或 超时 或 cancellationToken 被取消
    // 如果超时后 task 仍未完成,返回 False,否则返回 True
    // cancellationToken 被取消时抛出 OperationCanceledException
    public bool Wait(int millisecondsTimeout, CancellationToken cancellationToken)
    {
        ThrowIfContinuationIsNotNull();
        return InternalWaitCore(millisecondsTimeout, cancellationToken);
    }
}

下面是一个使用 bool Wait(int millisecondsTimeout) 的例子:

csharp 复制代码
var task = Task.Run(() =>
{
    Thread.Sleep(1000);
    return "Hello World";
});

var sw = Stopwatch.StartNew();
Console.WriteLine("Before Wait");
bool completed = task.Wait(millisecondsTimeout: 200);
Console.WriteLine("After Wait: completed={0}, Elapsed={1}", completed, sw.ElapsedMilliseconds);

Console.WriteLine("Result: {0}, Elapsed={1}", task.Result, sw.ElapsedMilliseconds);

输出:

ini 复制代码
Before Wait
After Wait: completed=False, Elapsed=230
Result: Hello World, Elapsed=1001

因为指定的 millisecondsTimeout 不足以等待 task 完成,所以 task.Wait 返回 False,继续执行后续代码。

但是,task.Result 仍然会阻塞当前线程,直到 task 完成。

关联的方法还有 Task.WaitAll 和 Task.WaitAny。同样也是非必要情况下,不建议使用。

背后的实现

task.Wait、task.Result、task.GetAwaiter().GetResult() 这三者背后的实现其实是一样的,都是调用了 Task.InternalWaitCore 这个实例方法。

借助 Rider 的类库 debug 功能,来给大家展示一下这三种方法的调用栈。

csharp 复制代码
Task<string> RunTask()
{
    return Task.Run(() =>
    {
        Thread.Sleep(1000);
        return "Hello World!";
    });
}

var task1 = RunTask();
task1.Wait();

var task2 = RunTask();
task2.GetAwaiter().GetResult();

var task3 = RunTask();
_ = task3.Result;

Task.InternalWaitCore 是 Task 的一个私有实例方法。

github.com/dotnet/runt...

csharp 复制代码
public class Task
{
    internal bool InternalWait(int millisecondsTimeout, CancellationToken cancellationToken) =>
        InternalWaitCore(millisecondsTimeout, cancellationToken);

    private bool InternalWaitCore(int millisecondsTimeout, CancellationToken cancellationToken)
    {
        // 如果 Task 已经完成,直接返回 true
        bool returnValue = IsCompleted;
        if (returnValue)
        {
            return true;
        }

        // 如果调用的是 Task.Wait 的无参重载方法,且Task 已经完成或者在内联执行后完成,直接返回 true,不会阻塞 Task.Wait 的调用线程。
        // WrappedTryRunInline 的意思是尝试在捕获的 TaskScheduler 中以内联的方式执行 Task,此处不展开
        if (millisecondsTimeout == Timeout.Infinite && !cancellationToken.CanBeCanceled &&
            WrappedTryRunInline() && IsCompleted) 
        {
            returnValue = true;
        }
        else
        {
            // Task 未完成,调用 SpinThenBlockingWait 方法,阻塞当前线程,直到 Task 完成或超时或 cancellationToken 被取消
            returnValue = SpinThenBlockingWait(millisecondsTimeout, cancellationToken);
        }

        return returnValue;
    }

    private bool SpinThenBlockingWait(int millisecondsTimeout, CancellationToken cancellationToken)
    {
        bool infiniteWait = millisecondsTimeout == Timeout.Infinite;
        uint startTimeTicks = infiniteWait ? 0 : (uint)Environment.TickCount;
        bool returnValue = SpinWait(millisecondsTimeout);
        if (!returnValue)
        {
            var mres = new SetOnInvokeMres();
            try
            {
                // 将 mres 作为 Task 的 Continuation,当 Task 完成时,会调用 mres.Set() 方法
                AddCompletionAction(mres, addBeforeOthers: true);
                if (infiniteWait)
                {
                    bool notifyWhenUnblocked = ThreadPool.NotifyThreadBlocked();
                    try
                    {
                        // 没有指定超时时间,阻塞当前线程,直到 Task 完成或 cancellationToken 被取消
                        returnValue = mres.Wait(Timeout.Infinite, cancellationToken);
                    }
                    finally
                    {
                        if (notifyWhenUnblocked)
                        {
                            ThreadPool.NotifyThreadUnblocked();
                        }
                    }
                }
                else
                {
                    uint elapsedTimeTicks = ((uint)Environment.TickCount) - startTimeTicks;
                    if (elapsedTimeTicks < millisecondsTimeout)
                    {
                        bool notifyWhenUnblocked = ThreadPool.NotifyThreadBlocked();
                        try
                        {
                            // 指定了超时时间,阻塞当前线程,直到 Task 完成或 超时 或 cancellationToken 被取消
                            returnValue = mres.Wait((int)(millisecondsTimeout - elapsedTimeTicks), cancellationToken);
                        }
                        finally
                        {
                            if (notifyWhenUnblocked)
                            {
                                ThreadPool.NotifyThreadUnblocked();
                            }
                        }
                    }
                }
            }
            finally
            {
                // 如果因为超时或 cancellationToken 被取消,而导致 Task 未完成,需要将 mres 从 Task 的 Continuation 中移除
                if (!IsCompleted) RemoveContinuation(mres);
            }
        }
        return returnValue;
    }

    private bool SpinWait(int millisecondsTimeout)
    {
        if (IsCompleted) return true;

        if (millisecondsTimeout == 0)
        {
            // 如果指定了超时时间为 0,直接返回 false
            return false;
        }

        // 自旋至少一次,总次数由 Threading.SpinWait.SpinCountforSpinBeforeWait 决定
        // 如果 Task 在自旋期间完成,返回 true
        int spinCount = Threading.SpinWait.SpinCountforSpinBeforeWait;
        SpinWait spinner = default;
        while (spinner.Count < spinCount)
        {
            // -1 表示自旋期间不休眠,不会让出 CPU 时间片
            spinner.SpinOnce(sleep1Threshold: -1);

            if (IsCompleted)
            {
                return true;
            }
        }

        // 自旋结束后,如果 Task 仍然未完成,返回 false
        return false;
    }

    private sealed class SetOnInvokeMres : ManualResetEventSlim, ITaskCompletionAction
    {
        // 往父类 ManualResetEventSlim 中传入 false,表示 ManualResetEventSlim 的初始状态为 nonsignaled
        // 也就是说,在调用 ManualResetEventSlim.Set() 方法之前,ManualResetEventSlim.Wait() 方法会阻塞当前线程
        internal SetOnInvokeMres() : base(false, 0) { }
        public void Invoke(Task completingTask) { Set(); }
        public bool InvokeMayRunArbitraryCode => false;
    }
}

Task.Wait 的两个阶段

SpinWait 阶段

用户态锁,不能维持很长时间的等待。线程在等待锁的释放时忙等待,不会进入休眠状态,从而避免了线程切换的开销。它在自旋等待期间会持续占用CPU时间片,如果自旋等待时间过长,会浪费CPU资源。

BlockingWait 阶段

内核态锁,在内核态实现的锁机制。当线程无法获得锁时,会进入内核态并进入休眠状态,将CPU资源让给其他线程。线程在内核态休眠期间不会占用CPU时间片,从而避免了持续的忙等待。当锁可用时,内核会唤醒休眠的线程并将其调度到CPU上执行。

BlockingWait 阶段 主要借助 SetOnInvokeMres 实现, SetOnInvokeMres 继承自 ManualResetEventSlim。 它会阻塞调用线程直到 Task 完成 或 超时 或 cancellationToken 被取消。

当前线程,Task 完成时,SetOnInvokeMres.Set() 方法会被当做 Task 的回调被调用从而解除阻塞。

Task.Wait 可能会导致的问题

到目前为止,我们已经了解到 Task.Wait 阻塞当前线程等待 Task 完成的原理,但是我们还是没有回答最开始的问题:为什么不建议使用 Task.Wait。

可能会导致线程池饥饿

线程池饥饿是指线程池中的可用线程数量不足,无法执行任务的现象。

在 ThreadPool 的设计中,如果已经创建的线程达到了一定数量,就算有新的任务需要执行,也不会立即创建新的线程(每 500ms 才会检查一次是否需要创建新的线程)。

更详细的介绍可以参考我的另一篇文章:www.cnblogs.com/eventhorizo...

如果我们在一个 ThreadPool 线程中调用 Task.Wait,而 Task.Wait 又阻塞了这个线程,无法执行其他任务,这样就会导致线程池中的可用线程数量不足,从而阻塞了任务的执行。

可能会导致死锁

除此之外 Task.Wait 也可能会导致死锁,这里就不展开了。具体可以参考:www.cnblogs.com/eventhorizo...

.NET 6 对 Task.Wait 的优化

细心的同学会注意到 SpinThenBlockingWait 的 BlockingWait 阶段,会调用 ThreadPool.NotifyThreadBlocked() 方法,这个方法会通知线程池当前线程被阻塞了,新的线程会被立即创建出来。

但这也不代表 Task.Wait 就可以放心使用了,ThreadPool 中的线程被大量阻塞,就算借助 ThreadPool.NotifyThreadBlocked() 能让新任务继续执行,但这会导致线程频繁的创建和销毁,导致性能下降。

总结

  1. Task.Wait 对调用线程的阻塞分为两个阶段:SpinWait 阶段 和 BlockingWait 阶段。如果 Task 完成较快,就可以在性能较好的 SpinWait 阶段完成等待。

  2. 滥用 Task.Wait 会导致线程池饥饿或死锁。

  3. .NET 6 对 Task.Wait 进行了优化,如果 Task.Wait 阻塞了 ThreadPool 中的线程,会立即创建新的线程,避免了线程池中的可用线程数量不足的问题。但是这也会导致线程频繁的创建和销毁,导致性能下降。

相关推荐
customer081 小时前
【开源免费】基于SpringBoot+Vue.JS周边产品销售网站(JAVA毕业设计)
java·vue.js·spring boot·后端·spring cloud·java-ee·开源
Yaml42 小时前
智能化健身房管理:Spring Boot与Vue的创新解决方案
前端·spring boot·后端·mysql·vue·健身房管理
小码编匠3 小时前
一款 C# 编写的神经网络计算图框架
后端·神经网络·c#
AskHarries3 小时前
Java字节码增强库ByteBuddy
java·后端
佳佳_3 小时前
Spring Boot 应用启动时打印配置类信息
spring boot·后端
许野平5 小时前
Rust: 利用 chrono 库实现日期和字符串互相转换
开发语言·后端·rust·字符串·转换·日期·chrono
BiteCode_咬一口代码6 小时前
信息泄露!默认密码的危害,记一次网络安全研究
后端
齐 飞6 小时前
MongoDB笔记01-概念与安装
前端·数据库·笔记·后端·mongodb