Redmi Pad評(píng)測(cè)：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍(lán)牙耳機(jī)到筆記本電腦，紅米不知不覺(jué)之間也已經(jīng)形成了自己頗有競(jìng)爭(zhēng)力的產(chǎn)品體系，在中端和次旗艦市場(chǎng)上甚至要比小米新機(jī)的表現(xiàn)來(lái)得更好，正所謂“大丈夫生居
JDK21 在 9 月 19 號(hào)正式發(fā)布，帶來(lái)了較多亮點(diǎn)，其中虛擬線程備受矚目，毫不夸張的說(shuō)，它改變了高吞吐代碼的編寫(xiě)方式，只需要小小的變動(dòng)就可以讓目前的 IO 密集型程序的吞吐量得到提升，寫(xiě)出高吞吐量的代碼不再困難。
本文將詳細(xì)介紹虛擬線程的使用場(chǎng)景，實(shí)現(xiàn)原理以及在 IO 密集型服務(wù)下的性能壓測(cè)效果。
在講虛擬線程之前，我們先聊聊為了提高吞吐性能，我們所做的一些優(yōu)化方案。
在當(dāng)前的微服務(wù)架構(gòu)下，處理一次用戶(hù)/上游的請(qǐng)求，往往需要多次調(diào)用下游服務(wù)、數(shù)據(jù)庫(kù)、文件系統(tǒng)等，再將所有請(qǐng)求的數(shù)據(jù)進(jìn)行處理最終的結(jié)果返回給上游。
圖片
圖片
在這種模式下，使用串行模式去查詢(xún)數(shù)據(jù)庫(kù)，下游 Dubbo/Http 接口，文件系統(tǒng)完成一次請(qǐng)求，接口整體的耗時(shí)等于各個(gè)下游的返回時(shí)間之和，這種寫(xiě)法雖然簡(jiǎn)單，但是接口耗時(shí)長(zhǎng)、性能差，無(wú)法滿足 C 端高 QPS 場(chǎng)景下的性能要求。
為了解決串行調(diào)用的低性能問(wèn)題，我們會(huì)考慮使用并行異步調(diào)用的方式，最簡(jiǎn)單的方式便是使用線程池 +Future 去并行調(diào)用。
圖片
典型代碼如下：
圖片
這種方式雖然解決了大部分場(chǎng)景下的串行調(diào)用低性能問(wèn)題，但是也存在著嚴(yán)重的弊端，由于存在 Future 的前后依賴(lài)關(guān)系，當(dāng)使用場(chǎng)景存在大量的前后依賴(lài)時(shí)，會(huì)使得線程資源和 CPU 大量浪費(fèi)在阻塞等待上，導(dǎo)致資源利用率低。
為了降低 CPU 的阻塞等待時(shí)間和提升資源的利用率，我們會(huì)使用CompletableFuture對(duì)調(diào)用流程進(jìn)行編排，降低依賴(lài)之間的阻塞。
CompletableFuture 是由 Java8 引入的，在 Java8 之前一般通過(guò) Future 實(shí)現(xiàn)異步。Future 用于表示異步計(jì)算的結(jié)果，如果存在流程之間的依賴(lài)關(guān)系，那么只能通過(guò)阻塞或者輪詢(xún)的方式獲取結(jié)果，同時(shí)原生的 Future 不支持設(shè)置回調(diào)方法，Java8 之前若要設(shè)置回調(diào)可以使用 Guava 的 ListenableFuture，回調(diào)的引入又會(huì)導(dǎo)致回調(diào)地獄，代碼基本不具備可讀性。
而 CompletableFuture 是對(duì) Future 的擴(kuò)展，原生支持通過(guò)設(shè)置回調(diào)的方式處理計(jì)算結(jié)果，同時(shí)也支持組合編排操作，一定程度解決了回調(diào)地獄的問(wèn)題。
使用 CompletableFuture 的實(shí)現(xiàn)方式如下：
圖片
CompletableFuture 雖然一定程度上面緩解了 CPU 資源大量浪費(fèi)在阻塞等待上的問(wèn)題，但是只是緩解，核心的問(wèn)題始終沒(méi)有解決。這兩個(gè)問(wèn)題導(dǎo)致 CPU 無(wú)法充分被利用，系統(tǒng)吞吐量容易達(dá)到瓶頸。
線程資源浪費(fèi)瓶頸始終在 IO 等待上，導(dǎo)致 CPU 資源利用率較低。目前大部分服務(wù)是 IO 密集型服務(wù)，一次請(qǐng)求的處理耗時(shí)大部分都消耗在等待下游 RPC，數(shù)據(jù)庫(kù)查詢(xún)的 IO 等待中，此時(shí)線程仍然只能阻塞等待結(jié)果返回，導(dǎo)致 CPU 的利用率很低。
線程數(shù)量存在限制， 為了增加并發(fā)度，我們會(huì)給線程池配置更大的線程數(shù)，但是線程的數(shù)量是有限制的，Java 的線程模型是 1:1 映射平臺(tái)線程的，導(dǎo)致 Java 線程創(chuàng)建的成本很高，不能無(wú)限增加。同時(shí)隨著 CPU 調(diào)度線程數(shù)的增加，會(huì)導(dǎo)致更嚴(yán)重的資源爭(zhēng)用，寶貴的 CPU 資源被損耗在上下文切換上。
在給出最終解決方案之前，我們先聊一聊 Web 應(yīng)用中常見(jiàn)的一請(qǐng)求一線程的模型。
在 Web 中我們最常見(jiàn)的請(qǐng)求模型就是使用一請(qǐng)求一線程的模型，每個(gè)請(qǐng)求都由單獨(dú)的線程處理。此模型易于理解和實(shí)現(xiàn)，對(duì)編碼的可讀性，Debug 都非常友好，但是，它有一些缺點(diǎn)。當(dāng)線程執(zhí)行阻塞操作（如連接到數(shù)據(jù)庫(kù)或進(jìn)行網(wǎng)絡(luò)調(diào)用）時(shí)，線程會(huì)被阻塞，直到操作完成，這意味著線程在此期間將無(wú)法處理任何其他請(qǐng)求。
圖片
當(dāng)遇到大促或突發(fā)流量等場(chǎng)景導(dǎo)致服務(wù)承受的請(qǐng)求數(shù)增大時(shí)，為了保證每個(gè)請(qǐng)求在盡可能短的時(shí)間內(nèi)返回，減少等待時(shí)間，我們經(jīng)常會(huì)采用以下方案：
系統(tǒng)資源有限導(dǎo)致系統(tǒng)線程總量有限，進(jìn)而導(dǎo)致與系統(tǒng)線程一一對(duì)應(yīng)的平臺(tái)線程有限。
平臺(tái)線程的調(diào)度依賴(lài)于系統(tǒng)的線程調(diào)度程序，當(dāng)平臺(tái)線程創(chuàng)建過(guò)多，會(huì)消耗大量資源用于處理線程上下文切換。
每個(gè)平臺(tái)線程都會(huì)開(kāi)辟一塊大小約 1m 私有的棧空間，大量平臺(tái)線程會(huì)占據(jù)大量?jī)?nèi)存。
圖片
那么有沒(méi)有一種方法可以易于編寫(xiě)，方便遷移，符合日常編碼習(xí)慣，同時(shí)性能很不錯(cuò)，CPU 資源利用率較高的方案呢?
JDK21 中的虛擬線程可能給出了答案， JDK 提供了與 Thread 完全一致的抽象 Virtual Thread 來(lái)應(yīng)對(duì)這種經(jīng)常阻塞的情況，阻塞仍然是會(huì)阻塞，但是換了阻塞的對(duì)象，由昂貴的平臺(tái)線程阻塞改為了成本很低的虛擬線程的阻塞，當(dāng)代碼調(diào)用到阻塞 API 例如 IO，同步，Sleep 等操作時(shí)，JVM 會(huì)自動(dòng)把 Virtual Thread 從平臺(tái)線程上卸載，平臺(tái)線程就會(huì)去處理下一個(gè)虛擬線程，通過(guò)這種方式，提升了平臺(tái)線程的利用率，讓平臺(tái)線程不再阻塞在等待上，從底層實(shí)現(xiàn)了少量平臺(tái)線程就可以處理大量請(qǐng)求，提高了服務(wù)吞吐和 CPU 的利用率。
操作系統(tǒng)線程（OS Thread）：由操作系統(tǒng)管理，是操作系統(tǒng)調(diào)度的基本單位。
平臺(tái)線程（Platform Thread）：Java.Lang.Thread 類(lèi)的每個(gè)實(shí)例，都是一個(gè)平臺(tái)線程，是 Java 對(duì)操作系統(tǒng)線程的包裝，與操作系統(tǒng)是 1:1 映射。
虛擬線程（Virtual Thread）：一種輕量級(jí)，由 JVM 管理的線程。對(duì)應(yīng)的實(shí)例 java.lang.VirtualThread 這個(gè)類(lèi)。
載體線程（Carrier Thread）：指真正負(fù)責(zé)執(zhí)行虛擬線程中任務(wù)的平臺(tái)線程。一個(gè)虛擬線程裝載到一個(gè)平臺(tái)線程之后，那么這個(gè)平臺(tái)線程就被稱(chēng)為虛擬線程的載體線程。
JDK 中 java.lang.Thread 的每個(gè)實(shí)例都是一個(gè)平臺(tái)線程。平臺(tái)線程在底層操作系統(tǒng)線程上運(yùn)行 Java 代碼，并在代碼的整個(gè)生命周期內(nèi)獨(dú)占操作系統(tǒng)線程，平臺(tái)線程實(shí)例本質(zhì)是由系統(tǒng)內(nèi)核的線程調(diào)度程序進(jìn)行調(diào)度，并且平臺(tái)線程的數(shù)量受限于操作系統(tǒng)線程的數(shù)量。
而虛擬線程(Virtual Thread)它不與特定的操作系統(tǒng)線程相綁定。它在平臺(tái)線程上運(yùn)行 Java 代碼，但在代碼的整個(gè)生命周期內(nèi)不獨(dú)占平臺(tái)線程。這意味著許多虛擬線程可以在同一個(gè)平臺(tái)線程上運(yùn)行他們的 Java 代碼，共享同一個(gè)平臺(tái)線程。同時(shí)虛擬線程的成本很低，虛擬線程的數(shù)量可以比平臺(tái)線程的數(shù)量大得多。
圖片
方法一：直接創(chuàng)建虛擬線程
Thread vt = Thread.startVirtualThread(() -> { System.out.println("hello wolrd virtual thread");});方法二：創(chuàng)建虛擬線程但不自動(dòng)運(yùn)行，手動(dòng)調(diào)用start()開(kāi)始運(yùn)行
Thread.ofVirtual().unstarted(() -> { System.out.println("hello wolrd virtual thread");});vt.start();方法三：通過(guò)虛擬線程的 ThreadFactory 創(chuàng)建虛擬線程
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 虛擬機(jī)調(diào)度，而不是操作系統(tǒng)。虛擬線程占用空間小，同時(shí)使用輕量級(jí)的任務(wù)隊(duì)列來(lái)調(diào)度虛擬線程，避免了線程間基于內(nèi)核的上下文切換開(kāi)銷(xiāo)，因此可以極大量地創(chuàng)建和使用。
簡(jiǎn)單來(lái)看，虛擬線程實(shí)現(xiàn)如下：virtual thread =continuation+scheduler+runnable
虛擬線程會(huì)把任務(wù)（java.lang.Runnable實(shí)例）包裝到一個(gè) Continuation 實(shí)例中:
Scheduler 也就是執(zhí)行器，由它將任務(wù)提交到具體的載體線程池中執(zhí)行。
Runnable 則是真正的任務(wù)包裝器，由 Scheduler 負(fù)責(zé)提交到載體線程池中執(zhí)行。
JVM 把虛擬線程分配給平臺(tái)線程的操作稱(chēng)為 mount（掛載），取消分配平臺(tái)線程的操作稱(chēng)為 unmount（卸載）：
mount 操作：虛擬線程掛載到平臺(tái)線程，虛擬線程中包裝的 Continuation 堆棧幀數(shù)據(jù)會(huì)被拷貝到平臺(tái)線程的線程棧，這是一個(gè)從堆復(fù)制到棧的過(guò)程。
unmount 操作：虛擬線程從平臺(tái)線程卸載，此時(shí)虛擬線程的任務(wù)還沒(méi)有執(zhí)行完成，所以虛擬線程中包裝的 Continuation 棧數(shù)據(jù)幀會(huì)會(huì)留在堆內(nèi)存中。
從 Java 代碼的角度來(lái)看，其實(shí)是看不到虛擬線程及載體線程共享操作系統(tǒng)線程的，會(huì)認(rèn)為虛擬線程及其載體都在同一個(gè)線程上運(yùn)行，因此，在同一虛擬線程上多次調(diào)用的代碼可能會(huì)在每次調(diào)用時(shí)掛載的載體線程都不一樣。JDK 中使用了 FIFO 模式的 ForkJoinPool 作為虛擬線程的調(diào)度器，從這個(gè)調(diào)度器看虛擬線程任務(wù)的執(zhí)行流程大致如下：
圖片
圖片
圖片
圖片
上面是沒(méi)有阻塞場(chǎng)景的虛擬線程任務(wù)執(zhí)行情況，如果遇到了阻塞(例如 Lock 等)場(chǎng)景，會(huì)觸發(fā) Continuation 的 yield 操作讓出控制權(quán)，等待虛擬線程重新分配載體線程并且執(zhí)行，具體見(jiàn)下面的代碼：
ReentrantLock lock = new ReentrantLock(); Thread.startVirtualThread(() -> { lock.lock(); }); // 確保鎖已經(jīng)被上面的虛擬線程持有 Thread.sleep(1000); Thread.startVirtualThread(() -> { System.out.println("first"); 會(huì)觸發(fā)Continuation的yield操作 lock.lock(); try { System.out.println("second"); } finally { lock.unlock(); } System.out.println("third"); }); Thread.sleep(Long.MAX_VALUE); }
圖片
圖片
Continuation 組件十分重要，它既是用戶(hù)真實(shí)任務(wù)的包裝器，同時(shí)提供了虛擬線程任務(wù)暫停/繼續(xù)的能力，以及虛擬線程與平臺(tái)線程數(shù)據(jù)轉(zhuǎn)移功能，當(dāng)任務(wù)需要阻塞掛起的時(shí)候，調(diào)用 Continuation 的 yield 操作進(jìn)行阻塞。當(dāng)任務(wù)需要解除阻塞繼續(xù)執(zhí)行的時(shí)候，則調(diào)用 Continuation 的 run 恢復(fù)執(zhí)行。
通過(guò)下面的代碼可以看出 Continuation 的神奇之處，通過(guò)在編譯參數(shù)加上--add-exports java.base/jdk.internal.vm=ALL-UNNAMED 可以在本地運(yùn)行。
ContinuationScope scope = new ContinuationScope("scope");Continuation continuation = new Continuation(scope， () -> { System.out.println("before yield開(kāi)始"); Continuation.yield(scope); System.out.println("after yield 結(jié)束");});System.out.println("1 run");// 第一次執(zhí)行Continuation.runcontinuation.run();System.out.println("2 run");// 第二次執(zhí)行Continuation.runcontinuation.run();System.out.println("Done");
圖片
通過(guò)上述案例可以看出，Continuation 實(shí)例進(jìn)行 yield 調(diào)用后，再次調(diào)用其 run 方法就可以從 yield 的調(diào)用之處繼續(xù)往下執(zhí)行，從而實(shí)現(xiàn)了程序的中斷和恢復(fù)。
虛擬線程內(nèi)存占用評(píng)估
單個(gè)虛擬線程的資源占用：
從對(duì)比結(jié)果來(lái)看，理論上單個(gè)平臺(tái)線程占用的內(nèi)存空間至少是 KB 級(jí)別的，而單個(gè)虛擬線程實(shí)例占用的內(nèi)存空間是 byte 級(jí)別，兩者的內(nèi)存占用差距較大，這也是虛擬線程可以大批量創(chuàng)建的原因。
下面通過(guò)一段程序去測(cè)試平臺(tái)線程和虛擬線程的內(nèi)存占用：
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);}上面的程序運(yùn)行后啟動(dòng) 4000 平臺(tái)線程，通過(guò) -XX:NativeMemoryTracking=detail 參數(shù)和 JCMD 命令查看所有線程占據(jù)的內(nèi)存空間如下：
圖片
內(nèi)存占用大部分來(lái)自創(chuàng)建的平臺(tái)線程，總線程棧空間占用約為 8096 MB，兩者加起來(lái)占據(jù)總使用內(nèi)存（8403MB）的 96% 以上。
用類(lèi)似的方式編寫(xiě)運(yùn)行虛擬線程的程序：
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);}上面的程序運(yùn)行后啟動(dòng) 4000 虛擬線程：
圖片
堆內(nèi)存的實(shí)際占用量和總內(nèi)存的實(shí)際占用量都不超過(guò) 300 MB，可以證明虛擬線程在大量創(chuàng)建的前提下也不會(huì)去占用過(guò)多的內(nèi)存，且虛擬線程的堆棧是作為堆棧塊對(duì)象存儲(chǔ)在 Java 的堆中的，可以被 GC 回收，又降低了虛擬線程的占用。
虛擬線程的局限及使用建議
在下面的測(cè)試中，我們將模擬最常使用的場(chǎng)景-使用 Web 容器去處理 Http 請(qǐng)求。
場(chǎng)景一：在 Spring Boot 中使用內(nèi)嵌的 Tomcat 去處理 Http 請(qǐng)求，使用默認(rèn)的平臺(tái)線程池作為 Tomcat 的請(qǐng)求處理線程池。
場(chǎng)景二：使用 Spring -WebFlux 創(chuàng)建基于事件循環(huán)模型的應(yīng)用程序，進(jìn)行響應(yīng)式請(qǐng)求處理。
場(chǎng)景三：在 Spring Boot 中使用內(nèi)嵌的 Tomcat 去處理 Http 請(qǐng)求，使用虛擬線程池作為 Tomcat 的請(qǐng)求處理線程池 (Tomcat已支持虛擬線程)。
圖片
默認(rèn)情況下，Tomcat 使用一請(qǐng)求一線程模型處理請(qǐng)求，當(dāng) Tomcat 收到請(qǐng)求時(shí)，會(huì)從線程池中取一個(gè)線程去處理請(qǐng)求，該分配的線程將一直保持占用狀態(tài)，直到請(qǐng)求結(jié)束才會(huì)釋放。當(dāng)線程池中沒(méi)有線程時(shí)，請(qǐng)求會(huì)一直阻塞在隊(duì)列中，直到有請(qǐng)求結(jié)束釋放線程。默認(rèn)隊(duì)列長(zhǎng)度為 Integer.MAX。默認(rèn)線程池默認(rèn)情況下，線程池最多包含 200 個(gè)線程。這基本上意味著單個(gè)時(shí)間點(diǎn)最多處理 200 個(gè)請(qǐng)求。對(duì)于每個(gè)請(qǐng)求服務(wù)都會(huì)以阻塞的方式調(diào)用平均 RT500ms 的慢速服務(wù)器。因此，可以預(yù)期每秒 400 個(gè)請(qǐng)求的吞吐量，最終壓測(cè)結(jié)果非常接近預(yù)期值，為 388 req/sec。
增加線程池
生產(chǎn)環(huán)境為了吞吐考慮,一般不會(huì)使用默認(rèn)值,會(huì)把線程池增大到 server.tomcat.threads.max=500+，調(diào)整到 500+ 之后的壓測(cè)結(jié)果如下：
可以看出最終的吞吐量和線程數(shù)量呈比例上升，同時(shí)由于線程數(shù)的增加，請(qǐng)求等待減少，平均 RT 趨向于慢速服務(wù)器的響應(yīng)平均 RT。
但是需要注意的是，平臺(tái)線程的創(chuàng)建受到內(nèi)存和 Java 線程映射模型的限制，不能無(wú)限擴(kuò)展，同時(shí)大量線程會(huì)導(dǎo)致 CPU 資源大量消耗在上下文切換時(shí)，整體性能反而降低。
WebFlux 跟傳統(tǒng)的 Tomcat 線程模型不一樣，他不會(huì)為每個(gè)請(qǐng)求分配一個(gè)專(zhuān)用線程，而是使用事件循環(huán)模型通過(guò)非阻塞 I/O 操作同時(shí)處理多個(gè)請(qǐng)求，這使得它能夠用有限的線程數(shù)量處理大量的并發(fā)請(qǐng)求。
在壓測(cè)的場(chǎng)景下，使用 WebClient 來(lái)進(jìn)行一個(gè)非阻塞的 Http 調(diào)用慢速處理器，并使用 RouterFunction 來(lái)做請(qǐng)求映射和處理。
@Beanpublic WebClient slowServerClient() { return WebClient.builder() .baseUrl("http://127.0.0.1:8000") .build();}@Beanpublic RouterFunction<ServerResponse> routes(WebClient slowServerClient) { return route(GET("/")， (ServerRequest req) -> ok() .body( slowServerClient .get() .exchangeToFlux(resp -> resp.bodyToFlux(Object.class))， Object.class ));}WebFlux 壓測(cè)結(jié)果如下：
圖片
可以看到，WebFlux 的請(qǐng)求完全沒(méi)有阻塞，僅用了 25 個(gè)線程就達(dá)到了 964 req/sec 的吞吐。
與平臺(tái)線程相比，虛擬線程的內(nèi)存占用量要低得多，運(yùn)行程序大量的創(chuàng)建虛擬線程，而不會(huì)耗盡系統(tǒng)資源；同時(shí)當(dāng)遇到 Thread.sleep()，CompletableFuture.await()，等待 I/O，獲取鎖時(shí)，虛擬線程會(huì)自動(dòng)卸載，JVM 可以自動(dòng)切換到另外的等待就緒的虛擬線程，提升單個(gè)平臺(tái)線程的利用率，保證平臺(tái)線程不會(huì)浪費(fèi)在無(wú)意義的阻塞等待上。
要想使用虛擬線程，需要先在啟動(dòng)參數(shù)中加上 --enable-preview，同時(shí) Tomcat 在 10 版本已支持虛擬線程，我們只需要替換 Tomcat 的平臺(tái)線程池為虛擬線程池即可。
@Beanpublic TomcatProtocolHandlerCustomizer<?> protocolHandler() { return protocolHandler -> protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());}private final RestTemplate restTemplate;@GetMappingpublic ResponseEntity<Object> callSlowServer(){ return restTemplate.getForEntity("http://127.0.0.1:8000"， Object.class);}最終壓測(cè)結(jié)果如下：
圖片
可以看到虛擬線程的壓測(cè)結(jié)果實(shí)際上與 WebFlux 的情況相同，但我們根本沒(méi)有使用任何復(fù)雜的響應(yīng)式編程技術(shù)。同時(shí)對(duì)慢速服務(wù)器的調(diào)用，也使用常規(guī)的阻塞 RestTemplate。我們所做的只是用虛擬線程執(zhí)行器替換線程池就達(dá)到更復(fù)雜的 Webflux 寫(xiě)法相同的效果。
總的壓測(cè)結(jié)果如下：
通過(guò)以上壓測(cè)結(jié)果，我們可以得出以下結(jié)論：
基于上述的壓測(cè)結(jié)果，可以較為樂(lè)觀的認(rèn)為虛擬線程會(huì)顛覆我們目前的服務(wù)和框架中的請(qǐng)求處理方法。
過(guò)去很長(zhǎng)時(shí)間，在編寫(xiě)服務(wù)端應(yīng)用時(shí)，我們對(duì)于每個(gè)請(qǐng)求，都使用獨(dú)占的線程來(lái)處理，請(qǐng)求之間是相互獨(dú)立的，這就是 一請(qǐng)求一線程的模型這種方式易于理解和編程實(shí)現(xiàn)，也易于調(diào)試和性能調(diào)優(yōu)。
然而，一請(qǐng)求一線程風(fēng)格并不能簡(jiǎn)單地使用平臺(tái)線程來(lái)實(shí)現(xiàn)，因?yàn)槠脚_(tái)線程是操作系統(tǒng)中線程的封裝。操作系統(tǒng)的線程會(huì)申請(qǐng)成本較高，存在數(shù)量上限。對(duì)于一個(gè)要并發(fā)處理海量請(qǐng)求的服務(wù)器端應(yīng)用來(lái)說(shuō)，對(duì)每個(gè)請(qǐng)求都創(chuàng)建一個(gè)平臺(tái)線程是不現(xiàn)實(shí)的。在這種前提下，涌現(xiàn)出一批非阻塞 I/O 和異步編程框架，如 WebFlux ，RX-Java。當(dāng)某個(gè)請(qǐng)求在等待 I/O 操作時(shí)，它會(huì)暫時(shí)讓出線程，并在 I/O 操作完成之后繼續(xù)執(zhí)行。通過(guò)這種方式，可以用少量線程同時(shí)處理大量的請(qǐng)求。這些框架可以提升系統(tǒng)的吞吐量，但是要求開(kāi)發(fā)人員必須熟悉所使用的底層框架，并按照響應(yīng)式的風(fēng)格來(lái)編寫(xiě)代碼，響應(yīng)式框架的調(diào)試?yán)щy，學(xué)習(xí)成本，兼容問(wèn)題使得大部分人望而卻步 。
在使用虛擬線程之后，一切都將改變，開(kāi)發(fā)人員可以使用目前最習(xí)慣舒服的方式來(lái)編寫(xiě)代碼，高性能和高吞吐由虛擬線程自動(dòng)幫你完成，這極大地降低了編寫(xiě)高并發(fā)服務(wù)應(yīng)用的難度。
本文鏈接：http://www.tebozhan.com/showinfo-26-17410-0.html虛擬線程原理及性能分析
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)