反应宣言:非阻塞代码还是阻塞代码？

Question

现在似乎每个人都在谈论反应性应用程序，而反应性宣言似乎鼓励非阻塞/异步代码。我在youtube上看到了很多视频，演讲者鼓励非阻塞代码，但是没有人说写非阻塞代码比阻止其他代码更有好处。

"using futures is good because it is not blocking your code" - some speaker

这只是让“阻塞代码”听起来像是个糟糕的词。

我的问题很简单：，如果我有一个任务，并且我运行它时：

1. 阻塞代码-在其中运行一个线程上的任务
2. 非阻塞代码-其中一个线程将任务委托给另一个线程。

事实上，在上述两种情况下，我要运行的实际任务总是在一个线程上运行。第二个选项只会给应用程序增加更多的复杂性，而第一个选项更简单，而且可能更快，因为我不需要委托。

我知道，在执行任务时，需要执行多个并发任务，因此线程/非阻塞/异步代码在这里有所帮助。但是，为什么反应性宣言鼓励非阻塞应用程序搁浅呢？在您的应用程序中，除了大量的期货和承诺之外，还有什么好处呢?这使得代码变得更复杂，更难调试了？

Answer 1

非阻塞代码-其中一个线程将任务委托给另一个线程。

事实并非如此。非阻塞IO以各种形式出现，但通常在IO运行时没有线程阻塞。当IO完成时，将调用回调。

这就是为什么非阻塞/异步IO如此难以使用的原因。它将您的代码转换为回调。

非阻塞/异步IO有两个好处:所需线程较少，上下文切换较少。在某些情况下，它可以使交互式GUI编程更容易。

非阻塞/异步IO当然不应该是默认的选择，因为它会导致生产力的损失。

我已经在.NET上下文中编写了两篇标准文章，我将链接到：https://stackoverflow.com/a/25087273/122718，为什么EF 6教程使用异步调用?默认情况下，https://stackoverflow.com/a/12796711/122718应该切换为使用异步I/O吗？

这些概念应该延伸到大多数平台上。