Project Loom fibers与RPC陷阱是一样,试图用同步方式封装异步操作,非常危险,它会淘汰Java Future吗? -SoftwareMill


Loom的Fiber类似Scala和Kotlin的纤程,可以解决我们的并发问题,它与Java JDK的Futures 相比,解决了控制流丢失,上下文和virality丢失的问题。可悲的是,编写并发程序还不止这些!
Fiber仍然是一个类似线程的构造,这意味着,如果我们要同时运行多个纤程,则需要某种方式进行协调。就像线程一样。纤程需要在正确的时间创建,错误需要处理等。这也反映在提案中:作者不仅写道continuations是一个低级的构造,而且纤程也是低级的。
因此,尽管光纤成功实现了座右铭“ 像同步一样的代码,却像异步一样工作 ”,但它们却无法实现“ 简化并发性 ”。
也许并发是一个固有的复杂问题?如果这是并发的本质,那么我们将不得不忍受它。并发绝非易事。相反,我们可以尝试使并发变得可理解。

人们已经尝试多次实现“透明” RPC(远程过程调用)。正如Martin Kleppmann在他的《设计数据密集型应用程序》一书中写道:

RPC模型试图在同一过程内(以这种抽象称为位置透明性)使对远程网络服务的请求看上去与用编程语言调用函数或方法相同。尽管乍一看RPC似乎很方便,但是该方法从根本上来说是有缺陷的。网络请求与本地函数调用有很大不同:

RPC和一般的任何网络调用都具有与普通函数调用明显不同的特征。它们是不可预测的:可以任意失败,而不管输入参数的值如何。他们可能需要花费任意时间才能完成,而正常功能会完成,失败或循环。即使网络调用似乎失败了,但从其他系统的角度来看,它仍然可能成功。

人们多次成为错误的RPC抽象的受害者。这就是为什么我们必须对Loom的纤维之类的抽象格外谨慎。将所有内容都视为同步调用是很诱人的。但有时您必须抵制诱惑。
.....
因此,尽管Project Loom不会取代我们在Java中进行并发的方式,但它可能会在我们的工具箱中提供另一个工具。它肯定会被滥用,因为其他所有构造都在那​​里。

点击标题见原文。