尝试理解任务。运行异步等待（）/Result

Question

我试图了解 Task.Run Wait（） 异步等待是如何工作的。
我已经阅读了这个页面：了解在一行中使用Task.Run Wait（）异步等待的使用，但不太理解它。

在我的代码中，我从Microsoft EventHub接收事件，并使用实现IEventProcessor的类处理它们。我在 ConvertToEntity（） 中调用 DoOtherWork（） 方法，这是一个异步方法，这是一个同步方法。由于该方法是异步的，因此我使用 Task.Run（） 和异步来委派。（即 Task.Run（async （） =

我的问题是：
*两者之间有什么区别
*哪种代码是合适的和/或安全的（=不会导致死锁）
*在什么情况下会导致僵局
*为什么任务。Run（）解决我遇到的死锁？（详见下文）

注:我在用。网芯3.1。

我为什么使用任务。Run()
当我们使用< code>AbcAsync()时，我的团队出现了几次死锁问题。结果或< code >。Wait()(该方法是在NET Core Web API方法中调用的，死锁大多发生在我们运行执行该方法的单元测试时)，所以我们使用了< code>Task。Run(async () =

public class EventProcessor : IEventProcessor
{
    public async Task ProcessEventsAsync(PartitionContext context, IEnumerable<EventData> messages) 
    {
        ...
        var result = await eventHandler.ProcessAsync(messages);
        ...
    }
}

public Task async ProcessAsync(IEnumerable<EventData> messages)
{
    ...
    var entities = ConvertToEntity(messages);
    ...
}

public List<Entity> ConvertToEntity(IEnumerable<EventData> messages)
{
    var serializedMessages = Serialize(messages);
    var entities = autoMapper.Map<Entity[]>(serializedMessages);

    // Task.Run(async () => entities = await DoAnotherWork(entities)).Wait(); // before change
    entities = DoAnotherWork(entities).Result; // after change

    return entities;
}    

public Task async Entity[] DoAnotherWork(Entity[] entities)
{
    // Do stuff async
    await DoMoreStuff(entities)...
}

Answer 1

两者之间有什么区别？

Task.Run 开始在线程池线程上运行委托;直接调用该方法将开始在当前线程上运行委托。

学习async时，将所有内容都分开，这样您就可以准确地看到发生了什么：

entities = DoAnotherWork(entities).Result;

相当于：

var entitiesTask = DoAnotherWork(entities);
entities = entitiesTask.Result;

和这个代码：

Task.Run(async () => entities = await DoAnotherWork(entities)).Wait();

相当于：

async Task LambdaAsMethod()
{
  entities = await DoAnotherWork(entities);
}
var runTask = Task.Run(LambdaAsMethod);
runTask.Wait();

哪种代码是合适的和/或安全的（=不会导致死锁）？

应避免在 ASP.NET 环境中使用 Task.Run，因为它会干扰线程池的 ASP.NET 处理，并在不需要线程池时强制线程切换。

如果是，在什么情况下会导致死锁？

常见的死锁场景需要两件事：

1. 阻止异步代码的代码，而不是正确使用awaid
2. 强制同步的上下文（即，一次只允许上下文中的一个代码块）

最好的解决方案是删除第一个条件；换句话说，一路使用“async”。要在这里应用它，最好的解决方案是完全删除阻塞：

public Task async ProcessAsync(IEnumerable<EventData> messages)
{
    ...
    var entities = await ConvertToEntityAsync(messages);
    ...
}

public async Task<List<Entity>> ConvertToEntityAsync(IEnumerable<EventData> messages)
{
    var serializedMessages = Serialize(messages);
    var entities = autoMapper.Map<Entity[]>(serializedMessages);

    entities = await DoAnotherWork(entities);

    return entities;
}

为什么任务。Run()解决我遇到的死锁？(详见下文)

.NET Core 根本没有“上下文”，因此它使用线程池上下文。由于 .NET Core 没有上下文，因此它会删除死锁的第二个条件，并且不会发生死锁。如果您在 ASP.NET Core 项目中运行它。

我的团队在使用AbcAsync（）时多次出现死锁问题。Result或.Wait（）（该方法是在NET Core Web API方法中调用的，死锁主要发生在我们运行执行该方法的单元测试时）

一些单元测试框架确实提供了上下文——最明显的是xUnit。xUnit提供的上下文是同步上下文，因此它的行为更像UI上下文或ASP.NET前核心上下文。因此，当您的代码在单元测试中运行时，它确实具有死锁的第二个条件，死锁可能会发生。

如上所述，最佳解决方案是完全去除堵塞；这将有助于提高服务器的效率。但是如果必须完成阻塞，那么您应该将单元测试代码包装在＜code＞Task中。运行，而不是ASP。NET核心代码。