Project Loom EA搶先體驗版本釋出

banq發表於2022-04-07
ProjectOOM

Build 19-loom+5-429 (2022/4/4)：此構建基於 JDK 19的不完整版本。
與之前的版本相比，沒有任何API變化。有很多 
有很多變化，特別是在GC和執行時領域有很多變化，有幾個重要的修正。
特別是在GC和執行時領域有許多變化，並有幾個重要的修正。該版本 包括Doug Lea最近在併發興趣列表上宣佈的ForkJoinPool的更新。
最近宣佈的ForkJoinPool的更新--這個更新提高了 在訊息傳遞等情況下的效能。

下載：


注意：

  • 早期訪問（EA）的功能可能永遠不會進入一般可用性（GA）版本。
  • EA功能可能在任何時候被改變或刪除。
  • EA構建的存在並不意味著被測試的功能會出現在任何特定的GA版本中。
  • 支援的平臺和GA構建的包裝選項可能與EA構建的不同。
  • EA構建的測試水平與Oracle測試GA構建的水平不一樣。EA構建的目的是為了收集反饋。用於任何其他目的的風險由您自己承擔。
  • EA 構建可能缺少 GA 構建或其他 OpenJDK 專案中的安全漏洞修復。
  • Oracle 不為 EA 構建提供支援。


虛擬執行緒是java.lang.Thread的一個例項，它不與特定的作業系統執行緒相聯絡。
相比之下，以前的平臺執行緒是以傳統方式實現的java.lang.Thread的一個例項，作為作業系統執行緒的一個薄的包裝。

支援每次請求一個執行緒風格的應用程式碼現在可以在請求的整個過程中都在虛擬執行緒中執行，但虛擬執行緒只在CPU上執行計算時消耗一個作業系統執行緒。
其結果是與非同步風格相同的可擴充套件性，只是它是以透明方式實現的。
當在虛擬執行緒中執行的程式碼呼叫java.* API中的阻塞I/O操作時，執行時會執行一個非阻塞的作業系統呼叫，並自動暫停虛擬執行緒，直到以後可以恢復。
這對Java開發者來說，虛擬執行緒只是建立成本低且幾乎無限多的執行緒。硬體利用率接近最佳，允許高水平的併發，因此，高吞吐量，而應用程式仍然與Java平臺的多執行緒設計及其工具相協調。

虛擬執行緒的革命性
虛擬執行緒很便宜，而且數量很多，因此不再需要被放入集中的執行緒池：應該為每個應用任務建立一個新的虛擬執行緒。
因此，大多數虛擬執行緒都是短命的，而且呼叫棧很淺，只執行一次HTTP客戶端呼叫或一次JDBC查詢。
相比之下，傳統平臺執行緒是重量級和昂貴的，因此往往必須是池化的。它們往往壽命很長，有很深的呼叫棧，並在許多工之間共享。

總之，虛擬執行緒保留了與Java平臺設計相協調的可靠的每請求執行緒風格，同時最佳化了硬體的利用。
使用虛擬執行緒不需要學習新的概念，儘管它可能需要你改變之前為應對傳統執行緒高成本而養成的習慣。（如不再需要執行緒池，Tomcat內建common-pool執行緒池不再需要）
虛擬執行緒不僅能幫助應用開發者-：還能幫助框架設計者提供易於使用的API，這些API與平臺的設計相容，同時又不影響擴充套件性。
 

網友討論
有.NET網友認為：在 .NET 中遇到了Mono和執行緒池死鎖問題，而這個 Java 解決方案非常完美。

那麼為什麼不將async和await與.NET 一起使用呢？實現的相同功能目標？也就是說async/await與虛擬執行緒有啥區別？
在實踐中 async/await 與綠色執行緒（虛擬執行緒）非常相似，它們有效地完成了相同的基本目標，但是 async/await 的問題是……一旦你開始使用它們，它就會汙染幾乎所有它接觸到的東西（非常值得注意在 Javascript / Typescript 中）。
虛擬執行緒更方便一點，因為當您需要開始使用它們時，您不會將整個程式碼庫顛倒過來（特別是據我所知，您只需分配一個執行虛擬執行緒的虛擬執行緒池）。（虛擬執行緒侵入性很小，使用 async/await 過於強勢，程式碼需要圍繞它為核心轉，破壞了程式碼本身的業務邏輯性或原本實現的功能思路），參考：你的函式是什麼顏色？

相關文章