盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰略發布會結束之后，Redmi總經理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
Java 21 在今年早些時候的 9 月 19 日就正式發布，并開始正式引入虛擬線程，但是作為 Java 開發生態中老大哥 Spring 并沒有立即跟進，而是在等待了兩個月后的 11 月 29 日，伴隨著 Spring Boot 3.2 版本的發布，在這個版本中也終于是引入了對虛擬線程的支持。
虛擬線程的引入標志著 Java 在現代編程世界中對編寫高吞吐量、高并發應用程序提供了更加完美的支持。
本文我就帶著大家一起深入了解一波 Tomcat 配合虛擬線程會帶來怎樣的效果以及虛擬線程對以后使用 Java 開發高吞吐量、高并發應用程序時所帶來的改變。
本文大綱如下：
在 Spring Boot 3.2 中，使用 Tomcat 作為 web 容器時，啟用虛擬線程只需要將 spring.threads.virtual.enabled 屬性設置為 true。
這樣 Spinrg Boot 在啟動 Tomcat 容器時會使用一個虛擬線程執行器來代表原有的平臺線程池。
注意這里是虛擬線程執行器，不是虛擬線程池哦。
在 Spring Boot 3.2 版本以前，Tomcat 默認的線程池使用的就是 Java 提供的 ThreadPoolExecutor 線程池，在 3.2 版本以后，Spring Boot 修改了創建線程池的方法如下所以。
Tomcat使用何種執行器：
是否使用虛擬線程執行器：
可以看到 Tomcat 會先判斷是否啟用了虛擬線程，啟用了的話就直接創建一個虛擬線程執行器 VirtualThreadExecutor。
VirtualThreadExecutor 類是 Tomcat 為了使用虛擬線程作為執行器而新增的。他的內部代碼中針對每個請求任務都是依賴 Jre21Compat 類處理的。
Jre21Compat 類則是 Tomcat 為了兼容 Java21 版本虛擬線程新增的一個兼容類。這個類利用反射方法來調用 Thread.ofVirtual().start(() -> {}) 方法，以便進行任務處理，代碼截圖如下，
VirtualThreadExecutor類源碼：
Jre21Compat類源碼：
雖然以上代碼可以啟用 Tomcat 的虛擬線程支持。但是在 Spring Boot 中其實不是這樣設置的。還記得上文提到的在 Spring Boot 3.2 中，使用 Tomcat 作為 web 容器時，啟用虛擬線程只需要將 spring.threads.virtual.enabled 屬性設置為 true 嗎？
Spring Boot 3.2 中是通過 tomcatVirtualThreadsProtocolHandlerCustomizer 方法來兼容虛擬線程啟用邏輯的，@ConditionalOnThreading(Threading.VIRTUAL) 條件用判斷 spring.threads.virtual.enabled 屬性是否啟用。代碼如下，
根據spring.threads.virtual.enabled屬性決定是否啟用虛擬線程：
讀取spring.threads.virtual.enabled屬性：
到這里其實本文所需要講的涉及源碼的部分就全部講完了。可以看到 Tomcat 引入虛擬線程并不復雜，引入后不在需要維護線程池，減輕了執行器的復雜度。
不知道大家注意到源碼中一個改變沒有，就是在 Spring Boot 3.2 中，啟用了虛擬線程后，Tomcat 默認使用的虛擬線程執行器不在需要池化。
也就是說，在 Spring Boot 3.2 以后的版本里，我們不在需要設置 server.tomcat.threads.max 以及 server.tomcat.threads.min-spare 兩個屬性以控制 Tomcat 線程池的大小了，因為它壓根沒有使用平臺線程池。
對于 Tomcat 來說，引入虛擬線程，不必在為線程池的維護而費心，還能減輕編程的復雜度。
虛擬線程由 JVM 平臺負責進行調度，它是廉價且輕量級的，Tomcat 可以使用 “每個請求一個線程” 模型，而不必擔心實際需要多少個線程。
就算請求任務在虛擬線程中調用阻塞 I/O 操作，導致運行時虛擬線程被掛起阻塞，但是只要掛起結束后該虛擬線程就可以恢復。
使用了虛擬線程后，程序員使用普通的阻塞 API，也可以讓程序對硬件的利用達到近乎完美水平，以此提供高水平的并發性，從而實現高吞吐量。
可以說，虛擬線程的引入，以后程序員就算是使用 Java 中阻塞 API 也可以開發出高性能、高吞吐量的應用程序。
在本文中，我還將給各位展示一波 newbeepro 項目升級到 Spring Boot 3.2 后啟用虛擬線程所帶來的性能提升。
測試平臺配置
newbee-mall-pro 是 newbee-mall 商城的 pro 版本實現了推薦算法、商品秒殺、優惠卷使用，滑塊驗證碼，支付寶支付，中文分詞檢索等高級功能。
項目地址：https://github.com/wayn111/newbee-mall-pro
使用 newbee-mall-pro 作為測試項目將啟用虛擬線程以及未啟用虛擬線程的兩次設置部署到測試服務器上。
啟動容器：amazoncorretto:21.0.1
啟動參數：java -jar -Xms1024m -Xmx1024m /opt/newbeemall/newbee-mall.jar
部署后測試地址：http://62.234.206.94/newbeemall/index
測試接口為秒殺接口：/newbeemall/seckill/2/c81e728d9d4c2f636f067f89cc14862c/executionFour
壓測設置：啟用 2000 個線程，每個線程循環執行 30 秒左右。一共測試五輪，先預熱 JVM 后，取吞吐量最大值。
壓測結果如下，
可以看到 CPU 占用達到百分之 142，內存占用達到百分之 35 的情況下，壓測吞吐量最大可以達到 1731。
考慮到有 2000 個線程進行壓測，所以將 Tomcat 線程池的最大線程數也設置到 2000，如下圖：
壓測結果如下：
可以看到 CPU 占用達到百分之 170，內存占用達到百分之 35 的情況下，壓測吞吐量可以達到 1492。
OK，到這里我們可以看到在 Spring Boot 3.2 版本中，使用了虛擬線程的 Tomcat 對比不用虛擬線程時，吞吐量提升差不多有 20%。
在更高并發的測試中，這個差距會越來越明顯。因為 Tomcat 使用的平臺線程過多時，上下文切換開銷會越來越大，而且虛擬線程比平臺線程占用更少的內存，一個虛擬線程只占用幾 kb 到幾十 kb 內存?？梢暂p松創建上萬虛擬線程，降低資源占用同時提高并發。
虛擬線程帶給了現代程序員新的編程體驗，使用阻塞編程也能開發出高性能應用程序，而避免了異步模型的編程復雜度，隨著更多的框架接入虛擬線程，相信虛擬線程會在未來大放異彩。
本文鏈接：http://www.www897cc.com/showinfo-26-37249-0.htmlTomcat 配合虛擬線程，一種新的編程體驗
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號