代码之家  ›  专栏  ›  技术社区  ›  Guerrilla

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

  •  1
  • Guerrilla  · 技术社区  · 7 年前

    例如,在我的应用程序中,我有由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();
    

    我理解在启动大量并发任务时使用async Wait模式,但是当代码源于静态方法并且必须按这样的顺序运行时,有什么好处吗?我该怎么写?

    1 回复  |  直到 7 年前
        1
  •  5
  •   usr    7 年前

    正如他所说的,他无法解释为什么要在引擎盖下进行优化

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

    大多数应用程序完全不受正在运行的线程数量的限制。对于这些应用程序,异步IO增加了零吞吐量,它需要额外的CPU并使代码复杂化。我知道,因为我已经测量了吞吐量和可伸缩性。我做过很多申请。

    特别是,IO本身不会变得更快。唯一改变的是调用的启动和完成方式。这里没有任何IO优化。

    如果您觉得方便,或者有证据表明正在运行的线程数量会出现问题,请使用async。 默认情况下不要使用它,因为生产率会降低。还有其他添加bug的方法。工具更糟糕,代码更长,调试和分析更困难。