Project Loom fibers與RPC陷阱是一樣，試圖用同步方式封裝非同步操作，非常危險，它會淘汰Java Future嗎？ -SoftwareMill

banq發表於2020-02-02
ProjectOOMRPC封裝非同步JavaREM

Loom的Fiber類似Scala和Kotlin的纖程，可以解決我們的併發問題，它與Java JDK的Futures 相比，解決了控制流丟失，上下文和virality丟失的問題。可悲的是，編寫併發程式還不止這些！
Fiber仍然是一個類似執行緒的構造，這意味著，如果我們要同時執行多個纖程，則需要某種方式進行協調。就像執行緒一樣。纖程需要在正確的時間建立，錯誤需要處理等。這也反映在提案中：作者不僅寫道continuations是一個低階的構造，而且纖程也是低階的。
因此，儘管光纖成功實現了座右銘“ 像同步一樣的程式碼，卻像非同步一樣工作 ”，但它們卻無法實現“ 簡化併發性 ”。
也許併發是一個固有的複雜問題？如果這是併發的本質，那麼我們將不得不忍受它。併發絕非易事。相反，我們可以嘗試使併發變得可理解。

人們已經嘗試多次實現“透明” RPC（遠端過程呼叫）。正如Martin Kleppmann在他的《設計資料密集型應用程式》一書中寫道：

RPC模型試圖在同一過程內（以這種抽象稱為位置透明性）使對遠端網路服務的請求看上去與用程式語言呼叫函式或方法相同。儘管乍一看RPC似乎很方便，但是該方法從根本上來說是有缺陷的。網路請求與本地函式呼叫有很大不同：

RPC和一般的任何網路呼叫都具有與普通函式呼叫明顯不同的特徵。它們是不可預測的：可以任意失敗，而不管輸入引數的值如何。他們可能需要花費任意時間才能完成，而正常功能會完成，失敗或迴圈。即使網路呼叫似乎失敗了，但從其他系統的角度來看，它仍然可能成功。

人們多次成為錯誤的RPC抽象的受害者。這就是為什麼我們必須對Loom的纖維之類的抽象格外謹慎。將所有內容都視為同步呼叫是很誘人的。但有時您必須抵制誘惑。
.....
因此，儘管Project Loom不會取代我們在Java中進行併發的方式，但它可能會在我們的工具箱中提供另一個工具。它肯定會被濫用，因為其他所有構造都在那​​裡。

點選標題見原文。

相關文章