虛擬線程原理及性能分析
一、背景
JDK21 在 9 月 19 號正式發布，帶來了較多亮點，其中虛擬線程備受矚目，毫不夸張的說，它改變了高吞吐代碼的編寫方式，只需要小小的變動就可以讓目前的 IO 密集型程序的吞吐量得到提升，寫出高吞吐量的代碼不再困難。
本文將詳細介紹虛擬線程的使用場景，實現原理以及在 IO 密集型服務下的性能壓測效果。
二、為了提升吞吐性能，我們所做的優化
在講虛擬線程之前，我們先聊聊為了提高吞吐性能，我們所做的一些優化方案。
串行模式
在當前的微服務架構下，處理一次用戶/上游的請求，往往需要多次調用下游服務、數據庫、文件系統等，再將所有請求的數據進行處理最終的結果返回給上游。
圖片
圖片
在這種模式下，使用串行模式去查詢數據庫，下游 Dubbo/Http 接口，文件系統完成一次請求，接口整體的耗時等于各個下游的返回時間之和，這種寫法雖然簡單，但是接口耗時長、性能差，無法滿足 C 端高 QPS 場景下的性能要求。
線程池+Future異步調用
為了解決串行調用的低性能問題，我們會考慮使用并行異步調用的方式，最簡單的方式便是使用線程池 +Future 去并行調用。
圖片
典型代碼如下：
圖片
這種方式雖然解決了大部分場景下的串行調用低性能問題，但是也存在著嚴重的弊端，由于存在 Future 的前后依賴關系，當使用場景存在大量的前后依賴時，會使得線程資源和 CPU 大量浪費在阻塞等待上，導致資源利用率低。
線程池+CompletableFuture異步調用
為了降低 CPU 的阻塞等待時間和提升資源的利用率，我們會使用CompletableFuture對調用流程進行編排，降低依賴之間的阻塞。
CompletableFuture 是由 Java8 引入的，在 Java8 之前一般通過 Future 實現異步。Future 用于表示異步計算的結果，如果存在流程之間的依賴關系，那么只能通過阻塞或者輪詢的方式獲取結果，同時原生的 Future 不支持設置回調方法，Java8 之前若要設置回調可以使用 Guava 的 ListenableFuture，回調的引入又會導致回調地獄，代碼基本不具備可讀性。
而 CompletableFuture 是對 Future 的擴展，原生支持通過設置回調的方式處理計算結果，同時也支持組合編排操作，一定程度解決了回調地獄的問題。
使用 CompletableFuture 的實現方式如下：
圖片
CompletableFuture 雖然一定程度上面緩解了 CPU 資源大量浪費在阻塞等待上的問題，但是只是緩解，核心的問題始終沒有解決。這兩個問題導致 CPU 無法充分被利用，系統吞吐量容易達到瓶頸。
線程資源浪費瓶頸始終在 IO 等待上，導致 CPU 資源利用率較低。目前大部分服務是 IO 密集型服務，一次請求的處理耗時大部分都消耗在等待下游 RPC，數據庫查詢的 IO 等待中，此時線程仍然只能阻塞等待結果返回，導致 CPU 的利用率很低。
線程數量存在限制， 為了增加并發度，我們會給線程池配置更大的線程數，但是線程的數量是有限制的，Java 的線程模型是 1:1 映射平臺線程的，導致 Java 線程創建的成本很高，不能無限增加。同時隨著 CPU 調度線程數的增加，會導致更嚴重的資源爭用，寶貴的 CPU 資源被損耗在上下文切換上。
三、一請求一線程的模型
在給出最終解決方案之前，我們先聊一聊 Web 應用中常見的一請求一線程的模型。
在 Web 中我們最常見的請求模型就是使用一請求一線程的模型，每個請求都由單獨的線程處理。此模型易于理解和實現，對編碼的可讀性，Debug 都非常友好，但是，它有一些缺點。當線程執行阻塞操作（如連接到數據庫或進行網絡調用）時，線程會被阻塞，直到操作完成，這意味著線程在此期間將無法處理任何其他請求。
圖片
當遇到大促或突發流量等場景導致服務承受的請求數增大時，為了保證每個請求在盡可能短的時間內返回，減少等待時間，我們經常會采用以下方案：
- 擴大服務最大線程數，簡單有效，由于存在下列問題，導致平臺線程有最大數量限制，不能大量擴充。
系統資源有限導致系統線程總量有限，進而導致與系統線程一一對應的平臺線程有限。
平臺線程的調度依賴于系統的線程調度程序，當平臺線程創建過多，會消耗大量資源用于處理線程上下文切換。
每個平臺線程都會開辟一塊大小約 1m 私有的棧空間，大量平臺線程會占據大量內存。
圖片
- 垂直擴展，升級機器配置，水平擴展，增加服務節點，也就是俗稱的升配擴容大法，效果好，也是最常見的方案，缺點是會增加成本，同時有些場景下擴容并不能 100% 解決問題。
- 采用異步/響應式編程方案，例如 RPC NIO 異步調用，WebFlux，Rx-Java 等非阻塞的基于 Ractor 模型的框架，使用事件驅動使得少量線程即可實現高吞吐的請求處理，擁有較好的性能與優秀的資源利用，缺點是學習成本較高兼容性問題較大，編碼風格與目前的一請求一線程的模型差異較大，理解難度大，同時對于代碼的調試比較困難。
那么有沒有一種方法可以易于編寫，方便遷移，符合日常編碼習慣，同時性能很不錯，CPU 資源利用率較高的方案呢?
JDK21 中的虛擬線程可能給出了答案， JDK 提供了與 Thread 完全一致的抽象 Virtual Thread 來應對這種經常阻塞的情況，阻塞仍然是會阻塞，但是換了阻塞的對象，由昂貴的平臺線程阻塞改為了成本很低的虛擬線程的阻塞，當代碼調用到阻塞 API 例如 IO，同步，Sleep 等操作時，JVM 會自動把 Virtual Thread 從平臺線程上卸載，平臺線程就會去處理下一個虛擬線程，通過這種方式，提升了平臺線程的利用率，讓平臺線程不再阻塞在等待上，從底層實現了少量平臺線程就可以處理大量請求，提高了服務吞吐和 CPU 的利用率。
四、虛擬線程
線程術語定義
操作系統線程（OS Thread）：由操作系統管理，是操作系統調度的基本單位。
平臺線程（Platform Thread）：Java.Lang.Thread 類的每個實例，都是一個平臺線程，是 Java 對操作系統線程的包裝，與操作系統是 1:1 映射。
虛擬線程（Virtual Thread）：一種輕量級，由 JVM 管理的線程。對應的實例 java.lang.VirtualThread 這個類。
載體線程（Carrier Thread）：指真正負責執行虛擬線程中任務的平臺線程。一個虛擬線程裝載到一個平臺線程之后，那么這個平臺線程就被稱為虛擬線程的載體線程。
虛擬線程定義
JDK 中 java.lang.Thread 的每個實例都是一個平臺線程。平臺線程在底層操作系統線程上運行 Java 代碼，并在代碼的整個生命周期內獨占操作系統線程，平臺線程實例本質是由系統內核的線程調度程序進行調度，并且平臺線程的數量受限于操作系統線程的數量。
而虛擬線程(Virtual Thread)它不與特定的操作系統線程相綁定。它在平臺線程上運行 Java 代碼，但在代碼的整個生命周期內不獨占平臺線程。這意味著許多虛擬線程可以在同一個平臺線程上運行他們的 Java 代碼，共享同一個平臺線程。同時虛擬線程的成本很低，虛擬線程的數量可以比平臺線程的數量大得多。
圖片
虛擬線程創建
方法一：直接創建虛擬線程
Thread vt = Thread.startVirtualThread(() -> {
System.out.println("hello wolrd virtual thread");
});方法二：創建虛擬線程但不自動運行，手動調用start()開始運行
Thread.ofVirtual().unstarted(() -> {
System.out.println("hello wolrd virtual thread");
});
vt.start();方法三：通過虛擬線程的 ThreadFactory 創建虛擬線程
ThreadFactory tf = Thread.ofVirtual().factory();
Thread vt = tf.newThread(() -> {
System.out.println("Start virtual thread...");
Thread.sleep(1000);
System.out.println("End virtual thread. ");
});
vt.start();
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
executor.submit(() -> {
System.out.println("Start virtual thread...");
Thread.sleep(1000);
System.out.println("End virtual thread.");
return true;
});虛擬線程實現原理
虛擬線程是由 Java 虛擬機調度，而不是操作系統。虛擬線程占用空間小，同時使用輕量級的任務隊列來調度虛擬線程，避免了線程間基于內核的上下文切換開銷，因此可以極大量地創建和使用。
簡單來看，虛擬線程實現如下：virtual thread =continuation+scheduler+runnable
虛擬線程會把任務（java.lang.Runnable實例）包裝到一個 Continuation 實例中:
- 當任務需要阻塞掛起的時候，會調用 Continuation 的 yield 操作進行阻塞，虛擬線程會從平臺線程卸載。
- 當任務解除阻塞繼續執行的時候，調用 Continuation.run 會從阻塞點繼續執行。
Scheduler 也就是執行器，由它將任務提交到具體的載體線程池中執行。
- 它是 java.util.concurrent.Executor 的子類。
- 虛擬線程框架提供了一個默認的 FIFO 的 ForkJoinPool 用于執行虛擬線程任務。
Runnable 則是真正的任務包裝器，由 Scheduler 負責提交到載體線程池中執行。
JVM 把虛擬線程分配給平臺線程的操作稱為 mount（掛載），取消分配平臺線程的操作稱為 unmount（卸載）：
mount 操作：虛擬線程掛載到平臺線程，虛擬線程中包裝的 Continuation 堆棧幀數據會被拷貝到平臺線程的線程棧，這是一個從堆復制到棧的過程。
unmount 操作：虛擬線程從平臺線程卸載，此時虛擬線程的任務還沒有執行完成，所以虛擬線程中包裝的 Continuation 棧數據幀會會留在堆內存中。
從 Java 代碼的角度來看，其實是看不到虛擬線程及載體線程共享操作系統線程的，會認為虛擬線程及其載體都在同一個線程上運行，因此，在同一虛擬線程上多次調用的代碼可能會在每次調用時掛載的載體線程都不一樣。JDK 中使用了 FIFO 模式的 ForkJoinPool 作為虛擬線程的調度器，從這個調度器看虛擬線程任務的執行流程大致如下：
- 調度器（線程池）中的平臺線程等待處理任務。
圖片
- 一個虛擬線程被分配平臺線程，該平臺線程作為載體線程執行虛擬線程中的任務。
圖片
- 虛擬線程運行其 Continuation，Mount(掛載)平臺線程后，最終執行 Runnable 包裝的用戶實際任務。
圖片
- 虛擬線程任務執行完成，標記 Continuation 終結，標記虛擬線程為終結狀態，清空上下文，等待 GC 回收，解除掛載載體線程會返還到調度器（線程池）中等待處理下一個任務。
圖片
上面是沒有阻塞場景的虛擬線程任務執行情況，如果遇到了阻塞(例如 Lock 等)場景，會觸發 Continuation 的 yield 操作讓出控制權，等待虛擬線程重新分配載體線程并且執行，具體見下面的代碼：
ReentrantLock lock = new ReentrantLock();
Thread.startVirtualThread(() -> {
lock.lock();
});
// 確保鎖已經被上面的虛擬線程持有
Thread.sleep(1000);
Thread.startVirtualThread(() -> {
System.out.println("first");
會觸發Continuation的yield操作
lock.lock();
try {
System.out.println("second");
} finally {
lock.unlock();
}
System.out.println("third");
});
Thread.sleep(Long.MAX_VALUE);
}- 虛擬線程中任務執行時候調用 Continuation#run() 先執行了部分任務代碼，然后嘗試獲取鎖，該操作是阻塞操作會導致 Continuation 的 yield 操作讓出控制權，如果 yield 操作成功，會從載體線程 unmount，載體線程棧數據會移動到 Continuation 棧的數據幀中，保存在堆內存中，虛擬線程任務完成，此時虛擬線程和 Continuation 還沒有終結和釋放，載體線程被釋放到執行器中等待新的任務；如果 Continuation 的 yield 操作失敗，則會對載體線程進行 Park 調用，阻塞在載體線程上，此時虛擬線程和載體線程同時會被阻塞，本地方法，Synchronized 修飾的同步方法都會導致 yield 失敗。
圖片
- 當鎖持有者釋放鎖之后，會喚醒虛擬線程獲取鎖，獲取鎖成功后，虛擬線程會重新進行 mount，讓虛擬線程任務再次執行，此時有可能是分配到另一個載體線程中執行，Continuation 棧會的數據幀會被恢復到載體線程棧中，然后再次調用Continuation#run() 恢復任務執行。
圖片
- 虛擬線程任務執行完成，標記 Continuation 終結，標記虛擬線程為終結狀態，清空上下文變量，解除載體線程的掛載載體線程返還到調度器（線程池）中作為平臺線程等待處理下一個任務。
Continuation 組件十分重要，它既是用戶真實任務的包裝器，同時提供了虛擬線程任務暫停/繼續的能力，以及虛擬線程與平臺線程數據轉移功能，當任務需要阻塞掛起的時候，調用 Continuation 的 yield 操作進行阻塞。當任務需要解除阻塞繼續執行的時候，則調用 Continuation 的 run 恢復執行。
通過下面的代碼可以看出 Continuation 的神奇之處，通過在編譯參數加上--add-exports java.base/jdk.internal.vm=ALL-UNNAMED 可以在本地運行。
ContinuationScope scope = new ContinuationScope("scope");
Continuation continuation = new Continuation(scope， () -> {
System.out.println("before yield開始");
Continuation.yield(scope);
System.out.println("after yield 結束");
});
System.out.println("1 run");
// 第一次執行Continuation.run
continuation.run();
System.out.println("2 run");
// 第二次執行Continuation.run
continuation.run();
System.out.println("Done");
圖片
通過上述案例可以看出，Continuation 實例進行 yield 調用后，再次調用其 run 方法就可以從 yield 的調用之處繼續往下執行，從而實現了程序的中斷和恢復。
虛擬線程內存占用評估
單個平臺線程的資源占用：
- 根據 JVM 規范，預留 1 MB 線程棧空間。
- 平臺線程實例，會占據 2000+ byte 數據。
單個虛擬線程的資源占用：
- Continuation 棧會占用數百 byte 到數百 KB 內存空間，是作為堆棧塊對象存儲在 Java 堆中。
- 虛擬線程實例會占據 200 - 240 byte 數據。
從對比結果來看，理論上單個平臺線程占用的內存空間至少是 KB 級別的，而單個虛擬線程實例占用的內存空間是 byte 級別，兩者的內存占用差距較大，這也是虛擬線程可以大批量創建的原因。
下面通過一段程序去測試平臺線程和虛擬線程的內存占用：
private static final int COUNT = 4000;
/**
* -XX:NativeMemoryTracking=detail
*
* @param args args
*/
public static void main(String[] args) throws Exception {
for (int i = 0; i < COUNT; i++) {
new Thread(() -> {
try {
Thread.sleep(Long.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}， String.valueOf(i)).start();
}
Thread.sleep(Long.MAX_VALUE);
}上面的程序運行后啟動 4000 平臺線程，通過 -XX:NativeMemoryTracking=detail 參數和 JCMD 命令查看所有線程占據的內存空間如下：
圖片
內存占用大部分來自創建的平臺線程，總線程棧空間占用約為 8096 MB，兩者加起來占據總使用內存（8403MB）的 96% 以上。
用類似的方式編寫運行虛擬線程的程序：
private static final int COUNT = 4000;
/**
* -XX:NativeMemoryTracking=detail
*
* @param args args
*/
public static void main(String[] args) throws Exception {
for (int i = 0; i < COUNT; i++) {
Thread.startVirtualThread(() -> {
try {
Thread.sleep(Long.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
});
}
Thread.sleep(Long.MAX_VALUE);
}上面的程序運行后啟動 4000 虛擬線程：
圖片
堆內存的實際占用量和總內存的實際占用量都不超過 300 MB，可以證明虛擬線程在大量創建的前提下也不會去占用過多的內存，且虛擬線程的堆棧是作為堆棧塊對象存儲在 Java 的堆中的，可以被 GC 回收，又降低了虛擬線程的占用。
虛擬線程的局限及使用建議
- 虛擬線程存在 native 方法或者外部方法 (Foreign Function & Memory API，jep 424 ) 調用不能進行 yield 操作，此時載體線程會被阻塞。
- 當運行在 synchronized 修飾的代碼塊或者方法時，不能進行 yield 操作，此時載體線程會被阻塞，推薦使用 ReentrantLock。
- ThreadLocal 相關問題，目前虛擬線程仍然是支持 ThreadLocal 的，但是由于虛擬線程的數量非常多，會導致 Threadlocal 中存的線程變量非常多，需要頻繁 GC 去清理，對性能會有影響，官方建議盡量少使用 ThreadLocal，同時不要在虛擬線程的 ThreadLocal 中放大對象，目前官方是想通過 ScopedLocal 去替換掉 ThreadLocal，但是在 21 版本還沒有正式發布，這個可能是大規模使用虛擬線程的一大難題。
- 無需池化虛擬線程 虛擬線程占用的資源很少，因此可以大量地創建而無須考慮池化，它不需要跟平臺線程池一樣，平臺線程的創建成本比較昂貴，所以通常選擇去池化，去做共享，但是池化操作本身會引入額外開銷，對于虛擬線程池化反而是得不償失，使用虛擬線程我們拋棄池化的思維，用時創建，用完就扔。
虛擬線程適用場景
- 大量的 IO 阻塞等待任務，例如下游 RPC 調用，DB 查詢等。
- 大批量的處理時間較短的計算任務。
- Thread-per-request (一請求一線程)風格的應用程序，例如主流的 Tomcat 線程模型或者基于類似線程模型實現的 SpringMVC 框架 ，這些應用只需要小小的改動就可以帶來巨大的吞吐提升。
五、虛擬線程壓測性能分析
在下面的測試中，我們將模擬最常使用的場景-使用 Web 容器去處理 Http 請求。
場景一：在 Spring Boot 中使用內嵌的 Tomcat 去處理 Http 請求，使用默認的平臺線程池作為 Tomcat 的請求處理線程池。
場景二：使用 Spring -WebFlux 創建基于事件循環模型的應用程序，進行響應式請求處理。
場景三：在 Spring Boot 中使用內嵌的 Tomcat 去處理 Http 請求，使用虛擬線程池作為 Tomcat 的請求處理線程池 (Tomcat已支持虛擬線程)。
測試流程
- Jmeter 開啟 500 個線程去并行發起請求。每個線程將等待請求響應后再發起下一次請求，單次請求超時時間為 10s，測試時間持續 60s。
- 測試的 Web Server 將接受 Jmeter 的請求，并調用慢速服務器獲取響應并返回。
- 慢速服務器以隨機超時響應。最大響應時間為 1000ms。平均響應時間為 500ms。
圖片
衡量指標
Tomcat+普通線程池
默認情況下，Tomcat 使用一請求一線程模型處理請求，當 Tomcat 收到請求時，會從線程池中取一個線程去處理請求，該分配的線程將一直保持占用狀態，直到請求結束才會釋放。當線程池中沒有線程時，請求會一直阻塞在隊列中，直到有請求結束釋放線程。默認隊列長度為 Integer.MAX。默認線程池默認情況下，線程池最多包含 200 個線程。這基本上意味著單個時間點最多處理 200 個請求。對于每個請求服務都會以阻塞的方式調用平均 RT500ms 的慢速服務器。因此，可以預期每秒 400 個請求的吞吐量，最終壓測結果非常接近預期值，為 388 req/sec。
增加線程池
生產環境為了吞吐考慮,一般不會使用默認值,會把線程池增大到 server.tomcat.threads.max=500+，調整到 500+ 之后的壓測結果如下：
可以看出最終的吞吐量和線程數量呈比例上升，同時由于線程數的增加，請求等待減少，平均 RT 趨向于慢速服務器的響應平均 RT。
但是需要注意的是，平臺線程的創建受到內存和 Java 線程映射模型的限制，不能無限擴展，同時大量線程會導致 CPU 資源大量消耗在上下文切換時，整體性能反而降低。
WebFlux
WebFlux 跟傳統的 Tomcat 線程模型不一樣，他不會為每個請求分配一個專用線程，而是使用事件循環模型通過非阻塞 I/O 操作同時處理多個請求，這使得它能夠用有限的線程數量處理大量的并發請求。
在壓測的場景下，使用 WebClient 來進行一個非阻塞的 Http 調用慢速處理器，并使用 RouterFunction 來做請求映射和處理。
@Bean
public WebClient slowServerClient() {
return WebClient.builder()
.baseUrl("http://127.0.0.1:8000")
.build();
}
@Bean
public RouterFunction<ServerResponse> routes(WebClient slowServerClient) {
return route(GET("/")， (ServerRequest req) -> ok()
.body(
slowServerClient
.get()
.exchangeToFlux(resp -> resp.bodyToFlux(Object.class))，
Object.class
));
}WebFlux 壓測結果如下：
圖片
可以看到，WebFlux 的請求完全沒有阻塞，僅用了 25 個線程就達到了 964 req/sec 的吞吐。
Tomcat+虛擬線程池
與平臺線程相比，虛擬線程的內存占用量要低得多，運行程序大量的創建虛擬線程，而不會耗盡系統資源；同時當遇到 Thread.sleep()，CompletableFuture.await()，等待 I/O，獲取鎖時，虛擬線程會自動卸載，JVM 可以自動切換到另外的等待就緒的虛擬線程，提升單個平臺線程的利用率，保證平臺線程不會浪費在無意義的阻塞等待上。
要想使用虛擬線程，需要先在啟動參數中加上 --enable-preview，同時 Tomcat 在 10 版本已支持虛擬線程，我們只需要替換 Tomcat 的平臺線程池為虛擬線程池即可。
@Bean
public TomcatProtocolHandlerCustomizer<?> protocolHandler() {
return protocolHandler ->
protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
}
private final RestTemplate restTemplate;
@GetMapping
public ResponseEntity<Object> callSlowServer(){
return restTemplate.getForEntity("http://127.0.0.1:8000"， Object.class);
}最終壓測結果如下：
圖片
可以看到虛擬線程的壓測結果實際上與 WebFlux 的情況相同，但我們根本沒有使用任何復雜的響應式編程技術。同時對慢速服務器的調用，也使用常規的阻塞 RestTemplate。我們所做的只是用虛擬線程執行器替換線程池就達到更復雜的 Webflux 寫法相同的效果。
總的壓測結果如下：
通過以上壓測結果，我們可以得出以下結論：
- 傳統的線程池模式效果差強人意，可以通過提高線程數量可以提升吞吐，但是需要考慮到系統容量和資源限制，但是對于大部分場景來說使用線程池去處理阻塞操作仍然是主流且不錯的選擇。
- WebFlux 的效果非常好，但是考慮到需要完全按照響應式風格進行開發，成本及難度較大，同時 WebFlux 與現有的一些主流框架存在一些兼容問題，例如 Mysql 官方 IO 庫不支持 NIO、Threadlocal 兼容問題等等。現有應用的遷移基本要重寫所有代碼，改動量和風險都不可控。
- 虛擬線程的效果非常好，最大的優勢就是我們沒有修改代碼或采用任何反應式技術，唯一更改是將線程池替換為虛擬線程。雖然改動較小，但與使用線程池相比，性能結果得到了顯著改善。
基于上述的壓測結果，可以較為樂觀的認為虛擬線程會顛覆我們目前的服務和框架中的請求處理方法。
六、總結
過去很長時間，在編寫服務端應用時，我們對于每個請求，都使用獨占的線程來處理，請求之間是相互獨立的，這就是 一請求一線程的模型這種方式易于理解和編程實現，也易于調試和性能調優。
然而，一請求一線程風格并不能簡單地使用平臺線程來實現，因為平臺線程是操作系統中線程的封裝。操作系統的線程會申請成本較高，存在數量上限。對于一個要并發處理海量請求的服務器端應用來說，對每個請求都創建一個平臺線程是不現實的。在這種前提下，涌現出一批非阻塞 I/O 和異步編程框架，如 WebFlux ，RX-Java。當某個請求在等待 I/O 操作時，它會暫時讓出線程，并在 I/O 操作完成之后繼續執行。通過這種方式，可以用少量線程同時處理大量的請求。這些框架可以提升系統的吞吐量，但是要求開發人員必須熟悉所使用的底層框架，并按照響應式的風格來編寫代碼，響應式框架的調試困難，學習成本，兼容問題使得大部分人望而卻步 。
在使用虛擬線程之后，一切都將改變，開發人員可以使用目前最習慣舒服的方式來編寫代碼，高性能和高吞吐由虛擬線程自動幫你完成，這極大地降低了編寫高并發服務應用的難度。
