用 Go 語言的小伙伴對協(xié)程應該都非常熟悉了，而 Java 直到 2022 年 9 月 20 日，JDK19 才終于提供了協(xié)程（官方說法是 Virtual Thread 虛擬線程，不過看介紹就是協(xié)程 Coroutine）的測試版本功能。

在 Java 中，我們一直依賴線程作為并發(fā)服務器應用程序的構建基礎。每個方法中的每個語句都在線程內(nèi)執(zhí)行，并且每個線程都提供一個堆棧來存儲局部變量和協(xié)調方法調用，以及出錯時的上下文，開發(fā)人員可以使用線程的堆棧來跟蹤程序的具體執(zhí)行過程。

以下參考 OpenJDK 官方文檔：https://openjdk.org/jeps/425

Thread-Per-Request

Thread-Per-Request，翻譯過來就是一個請求一個線程。服務器應用程序通常處理相互獨立的并發(fā)用戶請求，因此應用程序通過在某個請求的持續(xù)時間內(nèi)將一個線程專門用于處理這個請求是非常有意義且必要的。這種 thread-per-request 風格易于理解、易于編程、易于調試和分析，因為它使用平臺的并發(fā)單元來表示應用程序的線程數(shù)量，比如你有 100 個并發(fā)請求，那就對應 100 個線程。

但是，服務器應用程序的可伸縮性受 Little 定律支配，它與延遲、并發(fā)性和吞吐量相關，這里我簡單介紹下 Little 定律，不是什么重點知識，大伙兒隨便看下就行：

Little 定律是由 John Little 在 1961 年提出的，在一個具有穩(wěn)定流量和容量的隊列中，平均用戶數(shù)等于平均流量和平均服務時間的乘積。

具體來說，假設我們有一個隊列，它有一定的容量，同時有一定的流量在進出隊列。如果我們令隊列中平均用戶數(shù)為 L，平均流量為 λ，平均服務時間為 W，則 Little 定律可以表示為：

這個定律適用于任何類型的任務，包括服務請求、進程、線程、作業(yè)、數(shù)據(jù)包等等。它可以用來預測系統(tǒng)的吞吐量、延遲和并發(fā)性，并且在系統(tǒng)設計和性能優(yōu)化中非常有用。

• 所謂平均服務時間 W -> 其實就是請求處理的時間
• 平均用戶數(shù) L -> 就是同時處理的請求數(shù)量
• 平均流量 λ -> 就是吞吐量

如果我們想要在平均服務時間 W（請求處理時間）不變的情況下，增大平均流量 λ（吞吐量），那么平均用戶數(shù)（L）勢必要同比例增長，換句話說，對于給定的請求處理持續(xù)時間（即延遲），應用程序同時處理的請求數(shù)（即并發(fā)性）必須與吞吐量成比例增長。

例如，假設一個平均延遲為 50ms（W = 0.05） 的應用程序通過并發(fā)處理 10 個請求（L = 10）來實現(xiàn)每秒 200 個請求的吞吐量（λ = 200）。為了使該應用程序擴展到每秒 2000 個請求的吞吐量（λ = 2000），它需要并發(fā)處理 100 個請求（L = 100）。

如果每個請求都需要一個單獨的線程進行處理，那么隨著吞吐量的增加，線程數(shù)量將會急劇增加。

不幸的是，可用線程的數(shù)量是有限的，因為 JDK 線程的本質其實是操作系統(tǒng)線程，詳細可看下這篇文章 Java 線程和操作系統(tǒng)的線程有啥區(qū)別？，而操作系統(tǒng)線程成本很高，所以我們不可能擁有太多線程，這使得 Thread-Per-Request 風格難以實現(xiàn)。如果每個請求在其持續(xù)時間內(nèi)消耗一個 Java 線程，并因此消耗一個操作系統(tǒng)線程，那么在其他資源（例如 CPU 或網(wǎng)絡連接）耗盡之前，線程的數(shù)量必定會成為性能限制的重要因素，所以 JDK 當前的線程實現(xiàn)使得應用程序的吞吐量被限制在遠低于硬件可以支持的水平，有同學可能會說不是有線程池嗎？即使線程被池化也會發(fā)生這種情況，因為池化雖然有助于避免啟動新線程的高成本，但并不會增加線程總數(shù)。

使用異步

為了充分利用硬件，開發(fā)者們放棄了 Thread-Per-Request 的風格，轉而采用線程共享（Thread-Sharing）。不是在一個線程上從頭到尾處理一整個請求，而是在等待 I/O 操作完成時將該線程返回到線程池中，以便該線程可以為其他請求提供服務， I/O 操作完成后再利用回調函數(shù)進行通知。

通俗來說，在異步風格中，請求的每個階段可能在不同的線程上執(zhí)行，并且每個線程以交錯的方式運行屬于不同請求的階段。這種細粒度的線程共享允許大量并發(fā)操作而不會消耗大量線程，消除了操作系統(tǒng)線程稀缺對吞吐量的限制。

舉個例子，假設有一個網(wǎng)絡服務器程序，需要處理來自客戶端的請求并進行數(shù)據(jù)庫查詢，然后將結果返回給客戶端。如果使用傳統(tǒng)的線程池來處理請求，每當有一個請求到來時，就需要從線程池中取出一個線程進行處理。但是在請求過程中，當線程需要等待數(shù)據(jù)庫查詢結果時，它就會被阻塞，無法進行其他的請求處理，浪費了一個線程資源。如果使用異步 IO 操作，當線程需要進行數(shù)據(jù)庫查詢時，它可以將這個線程釋放給線程池中的其他請求，等到數(shù)據(jù)庫查詢完成后，再將線程恢復執(zhí)行，將查詢結果返回給客戶端。這樣，一個線程就可以處理多個請求，從而提高并發(fā)能力。

但是由于不是一個線程處理一整個請求，這就導致我們必須將請求處理邏輯分解為小階段，通常編寫為 lambda 表達式，然后使用 API 將它們組合成一個順序管道（比如 CompletableFuture）。

如果實際用過 lambda 表達式的同學肯定會深有感觸，這簡直是對 Debug 的災難性打擊：

• 堆棧跟蹤不提供可用的上下文
• 調試器無法單步執(zhí)行請求處理邏輯
• 分析器無法將操作的成本與其調用者相關聯(lián)

并且，從另一個角度來說，這種編程風格與 Java 平臺不一致，因為應用程序的并發(fā)單元（異步管道）不再是平臺的并發(fā)單元（簡單來說就是 100 個并發(fā)請求不是對應 100 個線程了，可能就對應 10 個線程）。

使用協(xié)程

除開上述兩種編程風格的缺點考慮，使用進程/線程模型還有一個不容忽視的弊端，那就是上下文切換的開銷。而協(xié)程的上下文切換代價較小，其優(yōu)勢在于可以將一個線程切換為多個協(xié)程，每個協(xié)程之間可以輕松地進行切換，從而提高應用程序的吞吐量。

舉個例子，我們只需要啟動 100 個線程，每個線程上運行 100 個協(xié)程，這樣不僅減少了線程切換開銷，而且還能夠同時處理 100 * 100 = 10000 個請求。

所以什么是協(xié)程（Coroutine）？

1. 協(xié)程是一種運行在線程之上的「用戶態(tài)」模型，也稱為纖程（Fiber），協(xié)程并沒有增加線程數(shù)量，只是在線程的基礎之上通過分時復用（并發(fā)）的方式運行多個協(xié)程。
2. 協(xié)程的切換在用戶態(tài)完成（完全由用戶控制，這一點就顯著區(qū)別于進程/線程模型），它是一種非搶占式的調度方式，當一個協(xié)程執(zhí)行完成后，可以選擇主動讓出，讓另一個協(xié)程運行在當前線程之上。協(xié)程擁有自己的寄存器上下文和棧，協(xié)程調度切換時，將寄存器上下文和棧保存到線程的堆區(qū)，在切回來的時候，恢復先前保存的寄存器上下文和棧，直接操作棧則基本沒有內(nèi)核切換的開銷，可以不加鎖的訪問全局變量，所以上下文的切換非?？欤染€程從用戶態(tài)到內(nèi)核態(tài)的代價小很多，

分析下協(xié)程相對于進程/線程的好處：

1. 輕量性：協(xié)程只需要保存少量的上下文信息，占用的資源更少，可以創(chuàng)建更多的協(xié)程。相比之下，線程/進程需要占用較大的內(nèi)核資源，創(chuàng)建線程的開銷也更大。
2. 高效性：協(xié)程切換不需要內(nèi)核態(tài)/用戶態(tài)切換，可以在用戶態(tài)直接切換上下文，速度更快。
3. 靈活性：協(xié)程的切換由程序員主動控制，可以靈活地在不同協(xié)程之間切換，實現(xiàn)并發(fā)執(zhí)行。而線程/進程的切換由操作系統(tǒng)內(nèi)核進行調度，限制了并發(fā)度和靈活性。
4. 可維護性：由于協(xié)程是在代碼層面進行控制，可以更容易地編寫和維護。而線程之間的同步和共享資源需要復雜的鎖機制和線程間通信。

使用協(xié)程的注意事項

協(xié)程運行在線程之上，所以必然受到線程的限制。

如果協(xié)程調用了一個阻塞 IO 操作，由于操作系統(tǒng)并不知道協(xié)程的存在（因為協(xié)程運行在用戶態(tài)），它只知道線程，因此在協(xié)程調用阻塞 IO 操作的時候，操作系統(tǒng)會讓協(xié)程之上對應的線程陷入阻塞狀態(tài)，也就是說當前的協(xié)程和其它綁定在該線程之上的協(xié)程都會陷入阻塞而得不到調度。

因此在協(xié)程中要么就別調用導致線程阻塞的操作，要么就采用異步編程的方式。