Project Loom:Reactive模型和協程進行時(翻譯)

Java 15將發布Project Loom的第一個版本。我相信這將改變JVM。在這篇文章中,我想深入探討一下導致我相信這一點的原因。

首先,我們需要了解核心問題。然後,我將嘗試描述以前的技術如何解決它。之後,我們將看到Project Loom採取的方法。最後,我將推斷後者可能對生態系統產生什麼影響。

Project Loom

我們首先必須記住,很長一段時間以來,計算機只有一個內核。即使這樣,還是需要同時運行多個程序:這至少要運行兩個操作系統和適當的程序。

為了實現并行性的幻覺,它依賴於一個技巧。它運行一個程序,如果該程序沒有在特定的時間範圍內完成,它將存儲其狀態以供以後使用。然後,它運行下一個要運行的程序。有幾種算法可用來調度下一個程序:循環調度,加權循環調度等。好處是,所有這些都可以通過操作系統線程的概念很好地從開發人員中抽象出來。該操作系統通吃繁重的護理,包括存儲執行的狀態。但是,線程有兩個缺點:

  • 線程很重,因為它帶有很多狀態
  • 線程需要大量的機器資源來創建
    在所有情況下,現代OS都允許M個線程,其中M是數千個線程。現代機器是多核的,提供N個核,比M少兩個數量級。擁有多個內核(無論是物理內核還是虛擬內核)並不會從根本上改變底層機制:M遠高於N,並且OS負責從線程到內核的映射。

阻塞線程

面的模型在傳統方案中效果很好,但在網絡方案中效果不佳。假設有一個Web服務器需要響應HTTP請求。在過去不太好的時候,CGI是處理請求的一種方法。它將每個請求映射到一個流程,以便處理創建整個新流程所需的請求,並在發送響應后將其清除。

Java EE應用程序服務器極大地改善了這種情況,因為實現將線程保留在池中以供以後重用。但是,想象一下響應的生成需要時間,例如因為它需要訪問數據庫以讀取數據。在數據庫返回數據之前,線程需要等待。

這意味着線程實際上正在等待其生命周期的大部分時間。一方面,此類線程自己不使用任何CPU。另一方面,它使用其他種類的資源,尤其是內存。

同樣,太多線程是操作系統的負擔:操作系統必須在數量有限的CPU內核上平衡大量線程。這花費了寶貴的CPU周期,因此,操作系統正在與應用程序競爭CPU。

現在,併發請求的數量可以遠遠超過服務器可用的線程數量。因此,阻塞的線程浪費資源,並使服務器無響應。為了解決這個問題,可以添加更多的Web服務器來處理負載:這是水平縮放。

在大多數情況下,水平縮放就足夠了。等待阻塞線程所花費的時間是浪費的,但是沒有任何相關的費用…除非一個人的基礎架構位於’雲’中。在那種情況下,人們要為未使用的資源付費:這絕不是一個明智的主意。

單線程,反應式和Kotlin協程模型

對於開發人員來說,管理多個線程很複雜。例如,如果您一直在使用(或開發)Swing應用程序,則可能知道“灰色矩形效果”。當用戶與窗口的交互(例如單擊)啟動長時間運行的任務時,就會發生這種情況。如果將另一個窗口移到Swing窗口上,然後再移出,Swing不會重畫另一個窗口與Swing窗口相交的區域,而不會留下難看的灰色矩形。原因是長時間運行的任務是在“ 事件調度線程”上啟動的,而不是在專用線程上啟動的。而且這很容易避免,甚至不涉及在共享的可變狀態上進行同步!

為了避免這種情況,某些堆棧完全禁止開發人員使用多個線程。例如,Node.js的API僅提供一個非阻塞事件循環線程:提交的函數採用回調的形式。請注意,這不會阻止實現使用多個線程。

該反應的方法是另一種選擇,其實頗為相似。儘管它擺脫了單線程API的限制,並提供了反壓力機制,但它仍然需要非阻塞代碼。由於OS線程很昂貴,因此Reactive將它們池化,並在整個應用程序生命周期中重複使用它們。核心過程是從池中獲取空閑線程,讓其執行代碼,然後將線程釋放回池中。這就是為什麼它需要非阻塞代碼的原因:如果代碼阻塞了,那麼執行線程將不會被釋放,並且池將在某一點或另一點耗盡。

我感興趣地觀察了Reactive模型如何像篝火一樣在Spring生態系統中傳播,儘管我選擇站在一邊。恕我直言,反應式有幾個缺點:

  • 編寫(和閱讀!)反應式代碼的思維方式與編寫傳統代碼的思維方式非常不同。我願意承認改變心態只需要時間,持續時間取決於每個開發人員。
  • 儘管真正的開發人員不會調試,但我知道很多人會調試-包括我自己。由於上述線程切換的魔力,要跟蹤一段代碼及其相關的狀態並不容易。這需要足夠的工具,例如帶有相關插件的 IntelliJ IDEA 。
  • 最後,出於相同的原因,傳統的堆棧跟蹤也無濟於事。一些黑魔法可以繞開它。但是,這不是為了膽小者。有關選項的完整列表,請查看此文檔。

Kotlin語言提供了Reactive方法的替代方法:協程。簡而言之,當使用suspend關鍵字時,Kotlin編譯器會在字節碼中生成一個有限狀態機。好處是在協程塊中調用的函數看起來像是順序執行的,儘管它們是并行執行的-更確切地說,取決於確切的範圍,有可能會執行。

Project Loom和虛擬線程

Reactive模型和Kotlin協程都在客戶端代碼和JVM線程之間添加了一個額外的抽象層。框架/庫的職責是動態地將一個映射到另一個。問題的癥結在於JVM線程是OS線程的薄包裝:請記住,OS線程創建起來很昂貴,並且數量限製為數千個。

Project Loom的目標是實際上將JVM線程與OS線程解耦
當我第一次意識到該倡議時,其想法是創建一個稱為Fiber(線程,Project Loom,您能抓住麻煩嗎?)的抽象。一個Fiber責任是讓一個操作系統線程,使其運行代碼,釋放回池,就像無棧一樣。

當前的建議有很大的不同:Fiber它沒有使用新的類,而是重新使用了Java開發人員非常熟悉的一個類- java.lang.Thread!

因此,在新的JVM版本中,某些Thread對象可能是重量級的並映射到OS線程,而另一些對象可能是虛擬線程。

Project Loom發布的後續影響

主要問題是,既然JVM API提供了對OS線程的抽象,那麼其他抽象(例如響應式和協程)又會變成什麼樣呢?我對預測不滿意,但以下是Reactive /協程背後的公司可能採取的一些態度:

  • 正面態度,他們意識到自己的框架不再帶來任何附加值,而只是重複。他們停止了開發工作,僅向現有客戶提供維護版本。他們幫助說客戶遷移到新的ThreadAPI,一些幫助可能是以付費諮詢的形式。
  • 反面態度,他們在各自的框架中投入了大量的精力之後,他們決定繼續進行,好像什麼也沒有發生。例如,Spring框架負責實際設計一個共享的Reactive API,稱為Reactive Streams,沒有Spring依賴項。當前有兩種實現,RxJava v2和Pivotal的Project Reactor。另一方面,JetBrains宣傳Kotlin的協程是并行運行代碼的最簡單方法。
  • 中間態度。這兩個框架都將繼續其生命,但是會將它們各自的基礎實現更改為使用虛擬線程。
    由於沉沒成本的謬誤,排在第一位的可能性極小:銷售和市場營銷將努力保持其“競爭優勢”-無論在他們眼中意味着什麼。儘管有些工程師出於相同的原因希望保留現有代碼,但其他一些工程師則將努力使用新的API。因此,我也不相信第二名也會發生。但是,我認為這兩個工程派之間都發揮着力量,然後它們與市場營銷/銷售之間將在#3之間找到平衡。

結論

Project Looms將現有的Thread實現方式從OS線程的映射更改為可以表示此類線程或虛擬線程的抽象。就其本身而言,這是一個有趣的舉動,它在一個平台上歷來比創新更重視向後兼容性。與其他最新的Java版本相比,此功能是真正的遊戲規則改變者。一般而言,開發人員應儘快開始熟悉它。打算學習Reactive和協程的開發人員可能應該退後一步,並評估他們是否應該學習新的ThreadAPI- 是否需要。

翻譯原文

https://blog.frankel.ch/project-loom-reactive-coroutines/

擴展閱讀

Project Loom地址: https://github.com/openjdk/loom
Project Loom現有狀態: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

您可能也會喜歡…