无需全量重构同步代码 仅将Controller方法改为异步的简便方法

结论：仅修改Controller层为异步形式无法解决线程耗尽问题，甚至可能带来额外性能损耗 #

你当前的同步Controller写法如下：

public HttpResponseMessage DoSmth() {
    doingSmth();
}

异步在ASP.NET服务端的核心价值是当代码遇到IO等待（如数据库查询、远程接口调用）时，将当前线程释放回线程池处理其他请求，等待IO完成后再拿线程池线程继续执行后续逻辑，这个收益的前提是整条调用链的IO操作都是异步实现的。
如果业务层、数据访问层全是同步实现，就算你把Controller方法改成async Task<HttpResponseMessage>，调用下层同步方法时依然会阻塞当前请求线程，线程根本没法释放回线程池，完全没有异步的收益。如果你为了凑async的写法强行用Task.Run(() => doingSmth())再await，反而会额外消耗一个线程池线程来执行同步逻辑，相同并发下线程消耗翻倍，反而更容易触发线程耗尽。

可行优化方案 #

• 先做性能验证：如果你的服务接口多是CPU密集型逻辑，或者当前实际并发量远低于线程池默认阈值，线程耗尽的问题大概率不会出现，保持现有同步写法即可，无需强行改造异步。
• 优先改造核心路径：如果确有高并发IO密集型接口存在线程耗尽风险，不需要全量重构所有代码，只需要优先改造Top N高频、IO等待占比高的接口对应的下层IO逻辑，每改造一部分就能拿到对应的异步收益，投入产出比最高。
• 临时调优线程池配置：如果短期内无法改造代码，可以适当调高ASP.NET线程池的最小线程数，缓解突发高并发下的线程池扩容延迟问题，注意这只是临时缓解方案，不能从根本上解决高并发下的线程耗尽问题。

禁止操作 #

• 不要在Controller层用Task.Run包裹同步方法伪装异步实现
• 不要在异步代码中调用.Result/.Wait()等阻塞方法，会大概率引发线程死锁
• 不要使用async void类型的Controller方法，会导致异常无法捕获直接crash进程

内容的提问来源于stack exchange，提问作者Alex