.NETC#基础教程第13天：提升并发安全

程序不再由于等待异步操作而卡住，死锁概率大幅下降，运行时也少了点不必要的开销。

说白了，就是在 await 后面加上 ConfigureAwait(false)。这么一加，编译器就不会硬性把后续代码安排回原来的同步上下文。通俗一点讲，就是把那层“粘连”给拆了，等异步任务完成后，后续能在任意可用的线程上继续跑，不用死扣着原来的那个线程不放。对非界面、后台逻辑来说，这招特别实用。

把事儿倒着说清楚比较容易理解。最后的表现是应用更稳，偶发卡死少了。具体一点：在某个方法里你用 await 去做异步加载（列如读数据的 ReadDataAsync），按默认行为，await 会把当前的同步上下文记下来，等异步完成后再把后续代码安排回去执行。这个机制对需要回到 UI 线程更新界面的场景挺好，但在别的场景里就可能出问题。

问题一般是这样冒出来的：有些地方在调用异步方法后没一路 await 下去，而是在同步方法里用 Task.Result 或 Wait 把结果给堵着等。此时如果 await 捕获了上下文，异步操作一完成想回到原来的上下文继续执行，但那根线程正被同步阻塞着，结果就出现双方互等的死锁。日志里就是看到某个线程一直在等，其他任务也被拖着，定位起来头疼。

为了解这事儿，有人会把 ConfigureAwait(false) 加在 await 后面。加上后来，await 不会再把后续执行绑回捕获的同步上下文，等数据回来后可以在线程池或者别的可用线程上继续执行，这样就不会由于原线程被同步堵住而卡住整个线程。直接效果有两点：一是死锁概率降，二是少了回跳上下文的成本，整体调度更灵活、性能更好一些。

但别以为这招放哪儿都行。任何需要在 UI 线程上更新界面的代码，还是得小心。UI 更新一般要求在原来的同步上下文上完成，盲目在 UI 层加 ConfigureAwait(false) 会把后续代码放到别的线程上跑，结果可能是直接抛异常或者界面根本没更新。因此常见的做法是：库代码、通用后台组件里默认用 ConfigureAwait(false)，UI 层则明确保留上下文，或者在必要时手动调度回界面线程去做 UI 操作。

拿 ReadDataAsync 做例子再走一遍流程会更清楚。调用方触发异步读取，内部可能走网络或磁盘 I/O，await 遇到异步操作就让出当前线程。默认情况下，它会把当前上下文记下来，数据回来时再把后续代码安排回去。如果在调用点有人用同步方式等结果，就可能造成前面说的互等局面。如果把调用改成 await ReadDataAsync(...).ConfigureAwait(false)，读取完成后就不会被强制回到原来的上下文，而是在任意可用线程上继续执行剩下的逻辑，从而避免了等待锁链，整体响应也更快。需要注意的细节是：凡是必须回到 UI 的操作，得显式切回去，别指望 ConfigureAwait(false) 会自动处理这些事儿。

这招在实践中好处不止理论上。写库或者共享组件时，默认加上 ConfigureAwait(false) 可以让你的库不去假定调用方的运行环境。打个比方，库就像是一辆通用底盘，不该硬把车载着回某个特定车库；如果库在完成后尝试绑回一个不存在或被堵住的上下文，结果就会出问题。性能上也有好处，少了一次次回跳的开销，高并发时能省不少资源。不过，这不是放之四海皆准的万能钥匙，有些代码块必须在原上下文执行，那就别用。

实践小技巧几条，平铺着写给需要的人看：后台方法里加 ConfigureAwait(false) 比较安全；写共享库时几乎可以默认加；在 UI 层用 await 时，先想清楚后面还要不要访问界面控件，如果要，别在那儿加 false，或者在非 UI 线程上跑完逻辑后再用调度器显式回到 UI 去更新；如果遇到疑似死锁的线程堆栈，回头检查有没有同步等待异步结果的地方，列如 Task.Result、Wait，这类地方和 await 捕获上下文混用最容易出问题。

有时候调试器里看到线程死在等某个任务完成，先别慌，顺着调用链查查有没有同步阻塞点。改动一般也不复杂，把 await 后面加上 ConfigureAwait(false) 或者把同步等待改成异步 await，哪怕改动不到位也能显著缓解。要是需要具体代码示例或者一份模版实现，发个私信，我把源码发你。