反应式宣言：非阻塞代码与阻塞代码？答案

【问题标题】：Reactive manifesto: non blocking code vs blocking code?反应式宣言：非阻塞代码与阻塞代码？
【发布时间】：2016-01-18 23:40:09
【问题描述】：

这些天似乎每个人都在谈论反应式应用程序，反应式宣言似乎鼓励非阻塞/异步代码。我在 youtube 上看过很多视频，演讲者都在鼓励非阻塞代码，但没有人说编写非阻塞代码比阻塞更有好处

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

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

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

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

我了解在执行任务期间的某个时间点，需要执行多个并发任务，因此线程/非阻塞/异步代码在这里会有所帮助。但是为什么 Reactive 宣言鼓励非阻塞应用程序从头开始呢？除了让应用程序中的一大堆 Futures 和 Promises 使代码更复杂和更难调试之外，还有什么好处？

【问题讨论】：

【解决方案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 吗？

这些概念应该适用于大多数平台。

【讨论】：

非常有帮助的答案。我不知道异步 IO 在回调中转换代码。但是IO是指磁盘读写，对吗？所以我的异步代码只会在磁盘或 RAM 相关任务的回调中上交？但是，如果我只是在我的代码中运行异步而不是 RAM 或磁盘密集型，那将不会作为回调执行？
任何在 CPU/RAM 上运行的东西都不需要异步调用（除非它是为了解锁 GUI 线程）。您可以根据具体情况决定异步调用什么。最好的地方是那些等待时间长、频率高的地方。通常，只有使网络事物异步才有意义。
因此，如果只有使网络事物异步和一些需要并发/并行执行代码的明显情况才有意义，除此之外，异步只会增加应用程序的复杂性，人们建议实现异步整个应用程序不会以任何其他方式提高应用程序性能或帮助？
不，在大多数情况下，它不会导致任何吞吐量提高。大多数这样做的人都被误导了。特别是所有套接字教程出于某种原因使用异步 IO，即使只有 10 个左右的客户端也是如此。完全浪费开发时间。在这种特殊情况下，Stack Overflow 很容易产生群体思维。