专栏介绍与文章目录-CSDN博客

        我对高级语言的异步机制总感到理解起来比较困难。明确的创建任务、等待任务不好吗？

        执行异步调用的方法返回一个Task是很正常的，很容易理解，但是Task.Result为什么导致阻塞呢？

        一个属性，而不是一个方法，竟然导致了阻塞，你们高级语言的思路真是很高级啊。

        好吧，这只是个吐槽。

        下面这个图来自微软learn网站，用来介绍异步方法的运行机制，非常大厂风啊：

        屁大点事画个图眼花缭乱。其实里面只有两个关键点：

1. client.GetStringAsync发起一个异步任务，一般我们（C/C++派）就称之为“CreateTask...”或者“StartTask...”，这一步不会阻塞。
2. await getStringTask等待异步任务结束同时控制返回调用者，这里非常困惑，但是如果解释为unix的fork就很明白了，fork创建一个子进程并且在两个进程里分别返回，await这里功能类似但具体实现应该很巧妙（变态）。这里从控制的角度也是分裂了，一条线直接返回，一条线在这里等待Task的结果。

        为了在层层调用中发现是否存在等待而引入新的关键字是可以理解的，毕竟这样做有很大的好处（不然从层层调用里发现哪里阻塞是很头疼的）。

        但是Task的设计是很怪的。Task本身没什么不可理解的，但是Task.Result为什么会阻塞？这只是一个属性啊！检查任务结果和等待任务返回根本就是两个完全不相干的事情，怎么能混在一起呢？仅仅因为语法上支持？

        还有，并发冲突并不会因此解决，反而因为晦涩的调用而更加难以发现，await之后的代码是并行的，共享对象的访问会发生冲突，到处都是await，很难理解谁跟谁在同一个线程上。

（这里是结束）