在不需要并发时使用来自静态方法的异步等待模式

Question

当您以同步方式运行事物时，使用 async/await 模式是否有好处？

例如，在我的应用程序中，我有由 cron (hangfire) 调用的静态方法来执行各种 IO 绑定任务。一个简单的人为例子是这样的：

static void Run(string[] args)
{
    var data = Test(args);

    //..do stuff with returned data
}

public static List<string> Test(string[] args)
{
    return Db.Select(args);
}

像这样编写这段代码有什么好处：

static void Run(string[] args)
{

    var dataTask = await TestAsync(args);
    dataTask.Wait();

    //..do stuff with returned data
}

public static async Task<List<string>> TestAsync(string[] args)
{
    return await Db.SelectAsync(args);
}

我的同事告诉我，我应该始终使用这种模式并使用异步方法，如果它们可用，因为它在引擎盖优化下添加，但他无法解释为什么会这样，我也找不到任何明确的解释。

如果我在静态方法中使用这种类型的模式编写代码，它最终看起来像：

var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();

我理解在启动大量并发任务时使用异步等待模式，但是当代码源自静态方法并且必须像这样按顺序运行时，这有什么好处吗？我应该怎么写？

Answer 1

因为它在引擎盖下进行了优化，但他无法解释为什么会这样

令我惊讶的是，有多少人认为异步始终是最佳选择，但他们无法说出原因。这在社会上是一个很大的误解。不幸的是，微软正在推动这个概念。我相信他们这样做是为了简化指导。

异步 IO 有助于两件事：1) 节省线程 2) 通过取消线程管理使 GUI 应用程序更容易。

大多数应用程序完全不受正在运行的线程数量的限制。对于这些应用程序，异步 IO 增加了零吞吐量，它会消耗额外的 CPU，并使代码复杂化。我知道，因为我测量了吞吐量和可扩展性。我从事过许多应用程序。

特别是，IO 本身并没有变得更快。唯一改变的是呼叫发起和完成的方式。这里没有任何 IO 优化。

当您觉得方便或您有证据表明正在运行的线程数将成为问题时，请使用 async。默认情况下不要使用它，因为生产力会降低。还有其他方法可以添加错误。工具更糟，代码更长，调试和分析更难。

当然，如果它是工作的正确工具，那么使用它并没有错。