Redmi Pad評(píng)測(cè)：紅米充滿(mǎn)野心的一次嘗試
從Note系列到K系列，從藍(lán)牙耳機(jī)到筆記本電腦，紅米不知不覺(jué)之間也已經(jīng)形成了自己頗有競(jìng)爭(zhēng)力的產(chǎn)品體系，在中端和次旗艦市場(chǎng)上甚至要比小米新機(jī)的表現(xiàn)來(lái)得更好，正所謂“大丈夫生居
聊虛線程之前我們先說(shuō)一下JDK19之前的標(biāo)準(zhǔn)線程，在JDK19中為了區(qū)分虛線程，給它起名叫平臺(tái)線程。它是對(duì)具體操作系統(tǒng)(OS)線程的包裝，每當(dāng)在JVM中創(chuàng)建一個(gè)平臺(tái)線程，在OS中就一定有一個(gè)操作系統(tǒng)線程與之對(duì)應(yīng)，任務(wù)代碼通過(guò)平臺(tái)線程在底層操作系統(tǒng)線程上運(yùn)行。由于在平臺(tái)線程的整個(gè)生命周期過(guò)程中，要不停地捕獲操作系統(tǒng)線程，也就是說(shuō)平臺(tái)線程要真實(shí)的綁定一個(gè)系統(tǒng)線程，因此應(yīng)用中平臺(tái)線程的數(shù)量取決于操作系統(tǒng)的線程數(shù)量。
圖1 平臺(tái)線程調(diào)用示意
平臺(tái)線程適用所有類(lèi)型任務(wù)，無(wú)論是IO密集型還是計(jì)算密集型，但由于平臺(tái)線程和操作系統(tǒng)線程綁定，當(dāng)平臺(tái)線程執(zhí)行IO密集型任務(wù)時(shí)(需要大量等待)，操作系統(tǒng)線程也要跟著等待，浪費(fèi)很多時(shí)間在等待上，而且為了維系這種綁定關(guān)系，平臺(tái)線程需要維護(hù)大型線程堆棧，操作系統(tǒng)也需要為平臺(tái)線程維護(hù)其他資源，因此創(chuàng)建、調(diào)度平臺(tái)線程成本很高。
總之一句話(huà)，平臺(tái)線程好用，但很“貴”。
JDK19開(kāi)始提供虛線程的預(yù)覽功能，在JDK19中虛線程仍是一個(gè)java.lang.Thread實(shí)例，仍然可以使用 Thread 類(lèi)和 Thread.Builder 接口創(chuàng)建虛擬線程，甚至在Executors上提供newVirtualThreadPerTaskExecutor方法用于創(chuàng)建虛擬線程，雖然創(chuàng)建出來(lái)的不是線程池。由此可見(jiàn)官方非常希望用戶(hù)在JDK后續(xù)版本中使用虛線程替換平臺(tái)線程。
虛線程雖然也是Thread實(shí)例，但它的創(chuàng)建不與OS線程綁定。它是由jvm負(fù)責(zé)創(chuàng)建調(diào)度，不需要維護(hù)大型堆棧，更不需要底層操作系統(tǒng)為其維護(hù)資源。
雖然虛線程不與OS線程綁定，但是提交給虛線程的任務(wù)代碼仍然是跑在OS線程上的。當(dāng)JVM調(diào)度一個(gè)虛線程開(kāi)始任務(wù)時(shí)，會(huì)將它與一個(gè)平臺(tái)線程綁定，平臺(tái)線程稱(chēng)為虛線程的載體，虛線程開(kāi)始執(zhí)行任務(wù)，直到虛線被IO阻塞時(shí)，JVM再次調(diào)度虛線程，將它從平臺(tái)線程掛起，此時(shí)空閑下來(lái)的平臺(tái)線程就又可以與其他虛線程綁定，完成其它工作。
這種設(shè)計(jì)的好處有：（1） 虛線程的的創(chuàng)建、掛起、恢復(fù)成本很低；（2） 虛線程數(shù)量不受操作系統(tǒng)線程數(shù)量限制；（3） 線程切換放在虛線程那一層級(jí)，盡量減少了平臺(tái)線程的切換。
圖2 虛線程調(diào)用示意
測(cè)試目的主要為了觀察平臺(tái)線程與虛線程的創(chuàng)建成本以及調(diào)度成本，設(shè)計(jì)測(cè)試代碼如下：
圖片
代碼很簡(jiǎn)單，構(gòu)建一個(gè)task(主要是為了測(cè)試創(chuàng)建、切換線程的成本，因此task中不添加其他邏輯)，分別創(chuàng)建5萬(wàn)個(gè)虛線程和平臺(tái)線程處理task。
橫坐標(biāo)為測(cè)試代碼的時(shí)間線，綠色面積圖為CPU使用率，藍(lán)色柱狀圖為內(nèi)存分配事件。
(虛線程跑5w個(gè)任務(wù)
(平臺(tái)線程跑5w個(gè)任務(wù))
從上面的圖表可以看出，平臺(tái)線程的創(chuàng)建、切換對(duì)CPU、內(nèi)存的消耗遠(yuǎn)高于虛線程。
吞吐量測(cè)試邏輯，測(cè)試在相同平臺(tái)線程數(shù)、相同時(shí)間內(nèi)哪一種線程執(zhí)行的任務(wù)數(shù)量多。
JVM提供了2個(gè)參數(shù)用以控制虛線程能調(diào)度的平臺(tái)線程數(shù)：
jdk.virtualThreadScheduler.parallelism 控制提供多少個(gè)平臺(tái)線程用以虛線程調(diào)度。
jdk.virtualThreadScheduler.maxPoolSize 控制最多多少個(gè)平臺(tái)線程用以虛線程調(diào)度。
通過(guò)設(shè)置
-Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1參數(shù)控制，虛線程只能創(chuàng)建1個(gè)平臺(tái)線程。
設(shè)計(jì)測(cè)試代碼一如下：
圖片
結(jié)果如下：
圖片
通過(guò)結(jié)果可以看出在IO密集型任務(wù)上，虛線程的吞吐量明顯高于平臺(tái)線程。
測(cè)試邏輯與3.2一樣，只是把任務(wù)邏輯改成模擬計(jì)算密集型。
測(cè)試代碼如下：
圖片
運(yùn)行結(jié)果：
圖片
在計(jì)算密集型的任務(wù)中，平臺(tái)線程與虛線程表現(xiàn)差不多，說(shuō)明虛線程并不會(huì)比平臺(tái)線程更快。
各種數(shù)據(jù)源通過(guò)Kafka接入到數(shù)據(jù)平臺(tái)層，數(shù)據(jù)平臺(tái)講明細(xì)數(shù)據(jù)存入數(shù)據(jù)存儲(chǔ)層的ClickHouse中，明細(xì)數(shù)據(jù)的存活時(shí)間可以根據(jù)業(yè)務(wù)需求設(shè)置。同時(shí)可以根據(jù)業(yè)務(wù)報(bào)表查詢(xún)的不同維度，利用ClickHouse的物化視圖形成預(yù)聚合數(shù)據(jù)，提高數(shù)據(jù)查詢(xún)效率。由數(shù)據(jù)服務(wù)層的定時(shí)任務(wù)周期性地從ClickHouse的預(yù)聚合數(shù)據(jù)中查詢(xún)業(yè)務(wù)所需的展示數(shù)據(jù)，把展示數(shù)據(jù)存入MySQL。由數(shù)據(jù)服務(wù)層的報(bào)表服務(wù)向數(shù)據(jù)展示層提供查詢(xún)服務(wù)，報(bào)表服務(wù)直接查詢(xún)MySQL中的結(jié)果數(shù)據(jù)，保證了查詢(xún)效率和并發(fā)性。
(1)虛線程相對(duì)于平臺(tái)線程更加輕量，由JVM創(chuàng)建、調(diào)度；
(2)虛線程的調(diào)度過(guò)程中需要依賴(lài)一個(gè)平臺(tái)線程(掛載、卸載)；
(3)虛線程在IO密集型任務(wù)中比平臺(tái)線程更有優(yōu)勢(shì)；
(4)虛線程目的不是讓系統(tǒng)更快，而是讓系統(tǒng)有更高的吞吐量。
本文鏈接：http://www.www897cc.com/showinfo-26-16290-0.htmlJDK19虛線程探究
聲明：本網(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)