在我们 2015 年开始的从 .NET Framework 向 .NET Core 迁移的工程中, 遇到的最大的坑就是标题中所说的 -- 同步方法中调用异步方法发生 "死锁". 虽然在 .NET Framework 时代就知道不能在同步方法中调用异步方法, 但我们却明知路有坑, 偏向此路行. 不是我们自讨苦吃, 而是被迫无奈, 因为在 .NET Core 2.0 之前, BCL(基础类库)中有些 API 只有异步实现没有同步实现, 比如用于将主机名解析为 IP 地址的 API -- Dns.GetHostAddressesAsync() .
但最终 "被迫无奈" 变成 "血的教训", 这根本不是坑, 而是无底洞. 无论在开发与测试环境中多么正常, 只要一发布到生产环境有一定并发量就会发生 "死锁" -- 大量请求无响应, 一直处于等待状态, 线程池发飙, 线程数持续不断地增长, 内存随之增长, 直至撑爆服务器(详见当时的一篇随笔 .NET Core 中遇到奇怪的线程死锁问题: 内存与线程数不停地增长).
我们想尽一切方法, 用尽网上能找到的同步方法调用异步方法避免死锁的办法, 都于事无补, 唯有去掉同步方法调用异步方法的代码. 当我们意识这是一个无底洞后, 赶紧绕道而行, 全面放弃在同步方法中调用异步方法, 并将 "千万千万不要在同步方法中调用异步方法" 作为一条 .NET Core 开发准则.
这段踩坑踩到无底洞的血泪史, 每当想起都很心痛, 心痛不是当时的任何努力都是那么的苍白无力, 而是对问题背后原因的困惑 -- 为什么同步方法中 Wait 异步方法会产生如此致命的后果? 如果真的千万千万不能这么干, 那 .NET Core 为什么不直接在编译时就报错?"死锁" 的背后究竟发生了什么?
...
来源: https://www.cnblogs.com/dudu/p/9860959.html