“阻塞”与“等待”的区别

在并发编程中，"阻塞"和"等待"的含义确实有些相似，但在异步编程的上下文中，它们有着不同的含义。

在操作系统中，线程是最小的执行单元。当我们说一个操作是"阻塞"的，我们的意思是这个操作会停止线程的执行，直到某个条件得到满足。例如，在传统的同步I/O中，一个读操作会阻塞线程，直到数据可用为止。在阻塞期间，线程不能做任何其他的事情，它只是停在那里，等待读操作完成。

然而，在异步编程中，我们使用了一种不同的模型。当我们说一个操作是"等待"的，我们的意思是这个操作会让出线程的控制权，直到某个条件得到满足。例如，在异步I/O中，一个读操作（如ReadAsync）会立即返回一个任务，代表这个操作的完成情况。在等待这个任务时，线程可以去做其他的事情。这就是所谓的"非阻塞"行为。

在Unity的主线程中调用ReadAsync时，主线程就是调用线程。当我们在主线程中使用await关键字等待ReadAsync的结果时，主线程会立即返回，可以去做其他的事情，而不是被阻塞，等待数据可用。

所以，尽管ReadAsync在没有数据可读的时候会"等待"，但这并不意味着它会"阻塞"调用线程。相反，它会立即返回一个表示操作完成情况的任务，这让调用线程有机会去做其他的事情。当数据可用时，ReadAsync的任务会完成，然后调用线程可以继续从那里执行。这就是异步编程的优势，它可以提高程序的响应性和效率。

参考：GPT4