回调如何在非阻塞设计中起作用？

Question

看了几个其他的问题,但没有找到我想要的东西.我使用Scala,但我的问题非常高,所以希望任何语言都是不可知的.

---

常规场景:

1. Thread A 运行一个函数,有一些阻塞工作要做(比如一个DB调用).
2. 该函数具有一些非阻塞代码(例如Async,Scala中的块),以使某种"工作者" Thread B(在不同的池中)获取I/O任务.
3. 该方法Thread A完成返回一个Future,它最终将包含结果并Thread A返回到其池中以快速获取另一个要处理的请求.

Q1.有些线程通常需要等待？

我对非阻塞体系结构的理解是,常见的方法是在I/O工作的某个地方仍然有一些线程等待/阻塞 - 它只是一个具有不同池的访问不同内核以便少量请求的情况处理线程可以管理大量并发请求,而无需等待CPU核心.

这是正确的一般理解吗？

Q2.回调如何运作？

在上面的场景中 - Thread B如果/当I/O工作完成时,I/O工作将运行回调函数(由线程A提供) - 这完成了Future一些Result.

线程A现在正在执行其他操作,并且不再与原始请求关联.未来的结果如何被发送回客户端套接字？我知道不同的语言有不同的这种机制的实现,但在很高的层次上,我目前的假设是(不管语言/框架)一些框架/容器对象必须始终做某种编排,以便当Future任务是完成后,Result将被发送回处理请求的原始套接字.

---

我花了几个小时试图找到可以解释这个问题的文章,但每篇文章似乎只是处理真正的低级细节.我知道我错过了一些细节,但我很难问我的问题,因为我不太确定我错过了哪些部分:)

Answer 1

我对非阻塞架构的理解是，常见的方法是在某处的 I/O 工作上仍然有一些线程等待/阻塞

如果一个线程在某处被阻塞，它就不是一个真正的非阻塞架构。所以不，这并不是对它的正确理解。这并不意味着这一定是坏事。有时您只需要处理阻塞（例如，使用 JDBC）。最好将其推送到指定用于阻塞的固定线程池中，而不是让整个应用程序遭受线程饥饿。

线程 A 现在正在做其他事情，并且不再与原始请求关联。未来的结果如何发送回客户端套接字？

使用Futures，它实际上取决于ExecutionContext. 创建 时Future，工作在哪里完成取决于ExecutionContext.

val f: Future[?] = ???
val g: Future[?] = ???

f和g立即创建，并将工作提交到ExecutionContext. 在大多数情况下，我们无法保证哪个将实际执行或首先完成。您对价值观的处理很重要。很明显如果你用anAwait来等待Futures的完成，那么我们阻塞了当前线程。如果我们对map这些值做了一些事情，那么我们又需要另一个ExecutionContext来提交任务。这为我们提供了一个任务链，每次我们操作Future.

最终需要onComplete在该链的末尾有一些来将该值传递给某个东西，无论是写入流还是其他东西。即，它可能不在原始线程的手中。