触发并忘记异步任务与 Task.Run

Question

我在开发一些 ASP.Net 应用程序时看到一些空引用问题。例外情况如下：

Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
   at System.Threading.Tasks.AwaitTaskContinuation.<ThrowAsyncIfNecessary>b__1(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

通过谷歌和SO搜索后，很可能是我的一些代码以这种方式触发并忘记了异步任务：

public interface IRepeatedTaskRunner
{
    Task Start();
    void Pause();
}

public class RepeatedTaskRunner : IRepeatedTaskRunner
{
    public async Task Start() //this is returning Task
    {
        ...
    }
}

public class RepeatedTaskRunnerManager{
    private IRepeatedTaskRunner _runner;
    public void Foo(){
        _runner.Start(); //this is not awaited.
    }
}

我认为这与这个问题"Fire and forget async method in asp.net mvc" 非常相似，但并不完全相同，因为我的代码不在控制器上并接受请求。我的代码专门用于运行后台任务。

与上面的 SO 问题一样，通过将代码更改为下面的代码来解决问题，但我只想知道为什么以及从 Task.Run 返回的任务和触发和忘记异步任务有什么区别：

public interface IRepeatedTaskRunner
{
    Task Start();
    void Pause();
}

public class RepeatedTaskRunner : IRepeatedTaskRunner
{
    public Task Start() // async is removed.
    {
        ...
    }
}

public class RepeatedTaskRunnerManager{
    private IRepeatedTaskRunner _runner;
    public void Foo(){
        Task.Run(() => _runner.Start()); //this is not waited.
    }
}

从我的角度来看，这两个代码都只是创建了一个任务而忘记了它。唯一的区别是第一个任务没有等待。这会导致行为上的差异吗？

从另一个 SO 问题中，我知道火灾和遗忘模式的局限性和不良影响。

Answer 1

我只是想知道为什么和从 Task.Run 返回的任务与触发和忘记异步任务有什么区别

区别在于AspNetSynchronizationContext是否被捕获，即“请求上下文”（包括当前文化、会话状态等）。

直接调用时，Start 在该请求上下文中运行，await 默认情况下将捕获该上下文并在该上下文中恢复（更多信息on my blog）。这可能会导致“有趣”的行为，例如，如果 Start 尝试在请求上下文中恢复已完成的请求。

使用Task.Run 时，Start 在没有请求上下文的不同线程池线程上运行。因此，await 不会捕获上下文，而是会在任何可用的线程池线程上恢复。

我知道您已经知道这一点，但我必须向 Google 员工重申：请记住，以这种方式排队的任何工作都不可靠。至少，你应该使用HostingEnvironment.QueueBackgroundWorkItem（或者我的AspNetBackgroundTasks library，如果你还没有使用4.5.2）。这些都非常相似；他们会将后台工作排队到线程池（实际上是我的库的BackgroundTaskManager.Run does call Task.Run），但是这两种解决方案也将采取额外的步骤注册 与 ASP.NET 运行时一起工作。这还不足以使后台工作真正意义上的“可靠”，但它确实最大限度地减少您丢失工作的机会。