反應式程式設計承諾具有較低記憶體要求的企業Java應用程式的更高效能。通過避免阻塞始終導致作業系統中的程式和上下文切換的呼叫來實現此承諾。這種上下文切換具有高CPU和儲存器開銷，當然，這些開關減少了更少。然而，這種反應式程式設計的效能提升是以軟體可維護性較差為代價的。但更高的效能是否物有所值？有哪些替代品？這是本文仔細研究一下。

反應式程式設計有一些嚴重的缺點：寫入函式和執行程式碼的分離導致讀取和編寫程式碼的難度增加。為這種非同步程式碼編寫單元測試也很複雜。除錯程式碼更加困難。

Project Reactor是Spring的Reactive Web Framework的基礎，它已經有許多輔助構造，支援測試，除錯和上下文傳播（請參閱測試，除錯和上下文部分）。然而，僅僅需要這種輔助結構這一事實已經揭示了反應式程式設計的複雜性。因此，問題在於是否存在其他可行的替代方案來解決Java執行緒的昂貴上下文切換問題。

反應式程式設計解決了由使用本機執行緒和“每個請求一個執行緒”範例引起的效能問題。但是，此解決方案伴隨著更高的開發和維護複雜性，因為測試和除錯等變得更加複雜。

綠色執行緒是避免作業系統中的程式交換機造成的效能損失的可能方法。這些在Java 1.1中可用，但已經在Java 1.3中被丟棄，因為它們不允許使用多核或多處理器系統的好處。在JDK中引入另一種Green Threads（所謂的Fibers）的新嘗試是Project Loom。這個提議將伴隨著對Java作為一種衍生產品的延續的支援。此功能在其他程式語言（如Kotlin和Go，名稱為Coroutines）中是已知的。

如果將Project Loom整合到JDK中，以及它對Reactive Programming的分發有何影響，您可能會感到好奇。從效能的角度來看，這可能會使Java世界變得多餘：要實現Fibers，Java中執行緒的執行將分為兩部分，即continuation和scheduler。延續表示執行狀態，即要執行的程式碼，包括執行上下文，例如呼叫引數，堆疊等。然後，排程程式確保所有延續均勻執行。