欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

淺析Java中的虛擬線程

 更新時間:2023年10月27日 10:44:58   作者:翟睿  
在本篇文章中,小編將帶大家深入了解Java虛擬線程的原理、如何使用、使用的注意事項以及其他相似技術的差別,感興趣的小伙伴可以跟隨小編一起學習一下

在最近發(fā)布的JDK 21 LTS版本中,加入了許多新特性。其中對我們開發(fā)人員影響最大的應該是分代ZGC以及Java的虛擬線程。在本篇文章中,我將帶大家深入了解Java虛擬線程的原理、如何使用、使用的注意事項以及其他相似技術的差別。

什么是虛擬線程

首先,我們需要了解什么是虛擬線程。

在平時的開發(fā)過程中,我們所使用的多線程往往意味著平臺線程。平臺線程代表著JVM直接與操作系統(tǒng)交互,創(chuàng)建了一個一個的線程,并且在JVM中還要為這個線程單獨開辟內(nèi)存使用。一般在JVM中創(chuàng)建一個平臺線程,開銷大約在1M左右。為了避免創(chuàng)建線程和銷毀線程帶來的巨大開銷,我們通常選擇使用池化技術來維護一些活躍的線程。

此外,線程的數(shù)量也需要嚴格控制。如果在一個線程池中維護成千上百個線程,往往效率并不盡如人意。因為線程在切換時涉及到CPU上下文的切換,如果線程數(shù)過多,反而會降低執(zhí)行效率。因此,如何控制線程池的大小也是考驗工程師經(jīng)驗的難點。

平臺線程與系統(tǒng)線程關系如下

為了解決這個問題,虛擬線程應運而生,虛擬線程并不是Java的首創(chuàng),它在很多其他語言中被稱為協(xié)程、纖程、綠色線程、用戶態(tài)線程等,虛擬線程相對平臺線程,并不直接與操作系統(tǒng)交互,虛擬線程的數(shù)據(jù)是維護在堆內(nèi)存中,由JVM創(chuàng)建的平臺線程來持有,由平臺線程來決定什么時候來切換虛擬線程,大概圖如下

雖然圖中只畫了幾個虛擬線程,但是在實際使用中,我們可以創(chuàng)建成百上千的虛擬線程而不用擔心資源消耗的問題

首先原因在于虛擬線程的開銷極其廉價,一個虛擬線程可能才使用幾百字節(jié),所以幾遍創(chuàng)建成百上千也不會消耗太多內(nèi)存資源

其次雖然我們有極多的虛擬線程,但是實際上執(zhí)行線程依舊只有幾個平臺線程,所以在線程使用中不會由于CPU上下文的切換導致的額外開銷。

使用

接下來我們用代碼來實踐一下虛擬線程,JDK的工程師為了方便我們快速進行虛擬線程的升級,可以使用Thread來快速創(chuàng)建虛擬線程

Thread vt = Thread.startVirtualThread(() -> {
    Thread.sleep(1000);
});

這種方法創(chuàng)建的虛擬線程會立刻啟動,那么如果我們想創(chuàng)建一個需要手動啟動的虛擬線程,可以參考如下的方式

// 創(chuàng)建VirtualThread
Thread.ofVirtual().unstarted(() -> {
    Thread.sleep(1000);
});
// 運行
vt.start();

還可以創(chuàng)建虛擬線程的工廠來使用

// 創(chuàng)建ThreadFactory:
ThreadFactory tf = Thread.ofVirtual().factory();
// 創(chuàng)建VirtualThread:
Thread vt = tf.newThread(() -> {
    Thread.sleep(1000);
});
// 運行:
vt.start();

我們將線程的上下文信息打印出來看看

VirtualThread[#21]/runnable@ForkJoinPool-1-worker-1

從這個打印內(nèi)容可以大概看出,虛擬線程底層采用了ForkJoinPool來維護平臺線程,而后面的worker-1則代表具體的平臺線程的名稱,前面的#21代表當前虛擬線程的數(shù)量,那么可能有同學就會問了 那如果我全局有成千上百個虛擬線程,我怎么知道是哪塊業(yè)務的線程除了問題呢。

我們可以對線程工廠進行命名,使用該線程工廠命名后,在線程上下文中就會打印對應虛擬線程工廠的信息。

ThreadFactory factory = Thread.ofVirtual().name("myVirtual").factory();
        try(ExecutorService executor = Executors.newThreadPerTaskExecutor(factory)) {
            for (int i=0; i<100000; i++) {
                // 也可以直接傳入Runnable或Callable:
                executor.submit(() -> {
                    System.out.println(Thread.currentThread());
                    Thread.sleep(1000);
                    return true;
                });
            }
        }

VirtualThread[#23,myVirtual]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#275,myVirtual]/runnable@ForkJoinPool-1-worker-7
VirtualThread[#282,myVirtual]/runnable@ForkJoinPool-1-worker-5
VirtualThread[#285,myVirtual]/runnable@ForkJoinPool-1-worker-4
VirtualThread[#288,myVirtual]/runnable@ForkJoinPool-1-worker-3
VirtualThread[#234,myVirtual]/runnable@ForkJoinPool-1-worker-10

從日志中不難看出,我們已經(jīng)成功在線程上下文標記了這一塊虛擬線程屬于哪個工廠,并且通過信息后綴中的worker-10可以看出底層的ForkJoinPool已經(jīng)創(chuàng)建了10個平臺線程來操作虛擬線程,因為我這臺電腦是10核的,所以底層的線程池會創(chuàng)建與核心數(shù)相等的線程來操作虛擬線程,在我的實踐中發(fā)現(xiàn),無論你創(chuàng)建多少調(diào)度器,所有底層的虛擬線程都是由同一個平臺線程池來操控的。

而且在示例代碼中,我創(chuàng)建了十萬個虛擬線程,如果我是用的是平臺線程,且不說執(zhí)行效率,但是內(nèi)存分配就已經(jīng)使項目OOM了。

注意事項

ThreadLocal支持

有同學可能會問,在虛擬線程中能否使用ThreadLocal對象呢?官方給出的答案是,能夠使用但不建議。在過去,我們在維護線程池時,線程的數(shù)量是固定的且相對較少。我們通過手動清理的方式來重用ThreadLocal對象。然而,在使用虛擬線程后,我們不再關注具體的線程數(shù),這導致ThreadLocal對象的數(shù)量無法控制,從而占用了額外的內(nèi)存。需要注意的是,虛擬線程與平臺線程不共享同一個ThreadLocal。

永遠不要池化虛擬線程

之前我們提到過,虛擬線程的開銷非常低,每個虛擬線程可能只消耗幾百字節(jié)的內(nèi)存。這意味著我們不需要為虛擬線程創(chuàng)建所謂的線程池。相應地,根據(jù)我們之前的編碼習慣,如果某個功能只能接受20個并發(fā)請求,我們可能會創(chuàng)建一個固定大小為20的線程池來進行限流。然而,如果使用虛擬線程,我們應盡量改用類似信號量的方式來實現(xiàn)。

協(xié)程、IO多路復用與虛擬線程的關系

有很多同學可能對對這幾個概念相對比較混淆,我們可以來梳理下這幾個概念之間的異同,首先協(xié)程與虛擬線程從概念上是相同的,只是不同語言之間的實現(xiàn)方式是不同的,都是在用戶態(tài)線程中維護多個子線程進行切換,只是如Python語言可能需要手動去喚起協(xié)程,而Java中的虛擬線程都是交由JVM調(diào)度的。

而IO多路復用,我們以Netty為例,它內(nèi)部使用了IO多路復用技術來管理和處理大量的并發(fā)IO操作。Netty的IO多路復用機制可以有效地管理和調(diào)度多個連接,提高系統(tǒng)的吞吐量和性能。它基于事件驅(qū)動的設計模型,通過選擇器(Selector)來同時監(jiān)控多個IO通道的狀態(tài),當有IO事件就緒時,通過回調(diào)機制來進行處理。而虛擬線程通常用于解決IO阻塞的問題,通過在IO操作或時間等待點上主動釋放執(zhí)行權,來實現(xiàn)更好的并發(fā)性能。虛擬線程可以減少線程切換的開銷,但它仍然是在應用程序內(nèi)部執(zhí)行的,并不能直接替代IO多路復用來管理和處理大量的并發(fā)IO操作??梢哉f術業(yè)有專攻,但是虛擬線程確實會對多IO操作有效率提升的。

到此這篇關于淺析Java中的虛擬線程的文章就介紹到這了,更多相關Java虛擬線程內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

相關文章

  • Kotlin 接口與 Java8 新特性接口詳解

    Kotlin 接口與 Java8 新特性接口詳解

    這篇文章主要介紹了Kotlin 接口與 Java8 新特性接口,Kotlin的接口是可以包含屬性聲明。Kotlin默認的聲明是fianl 和public的。 Kotlin里嵌套的類默認并不是內(nèi)部內(nèi),不包含對器外部類的隱式調(diào)用。下面我們來一起學習一下吧
    2019-06-06
  • Java super和this的對比及使用

    Java super和this的對比及使用

    這篇文章主要介紹了Java super和this的對比及使用的相關資料,java中this與super會經(jīng)常在使用的時候混淆,需要的朋友可以參考下
    2017-08-08
  • SpringBoot2零基礎到精通之數(shù)據(jù)與頁面響應

    SpringBoot2零基礎到精通之數(shù)據(jù)與頁面響應

    SpringBoot是一種整合Spring技術棧的方式(或者說是框架),同時也是簡化Spring的一種快速開發(fā)的腳手架
    2022-03-03
  • MyBatis-Plus 分頁查詢以及自定義sql分頁的實現(xiàn)

    MyBatis-Plus 分頁查詢以及自定義sql分頁的實現(xiàn)

    這篇文章主要介紹了MyBatis-Plus 分頁查詢以及自定義sql分頁的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-08-08
  • Spring Eureka 未授權訪問漏洞修復問題小結

    Spring Eureka 未授權訪問漏洞修復問題小結

    項目組使用的 Spring Boot 比較老,是 1.5.4.RELEASE ,最近被檢測出 Spring Eureka 未授權訪問漏洞,這篇文章主要介紹了Spring Eureka 未授權訪問漏洞修復問題小結,需要的朋友可以參考下
    2024-04-04
  • Java設計模式之工廠模式實現(xiàn)方法詳解

    Java設計模式之工廠模式實現(xiàn)方法詳解

    這篇文章主要介紹了Java設計模式之工廠模式實現(xiàn)方法,結合實例形式較為詳細的分析了工廠模式的分類、原理、實現(xiàn)方法與相關注意事項,需要的朋友可以參考下
    2017-12-12
  • SpringBoot 搭建架構5種方法示例詳解

    SpringBoot 搭建架構5種方法示例詳解

    SpringBoot是基于Spring框架的便捷開發(fā)框架,通過約定優(yōu)于配置實現(xiàn)快速構建獨立應用,文章介紹了五種搭建SpringBoot項目的方法,包括使用IntelliJ IDEA、Spring官網(wǎng)、阿里云官網(wǎng)以及將現(xiàn)有Maven項目轉(zhuǎn)換為SpringBoot項目,感興趣的朋友跟隨小編一起看看吧
    2025-03-03
  • SpringBoot注入配置文件的3種方法詳解

    SpringBoot注入配置文件的3種方法詳解

    這篇文章主要介紹了SpringBoot注入配置文件的3種方法詳解,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
    2019-10-10
  • SpringCloud OpenFeign與Ribbon客戶端配置詳解

    SpringCloud OpenFeign與Ribbon客戶端配置詳解

    在springcloud中,openfeign是取代了feign作為負載均衡組件的,feign最早是netflix提供的,他是一個輕量級的支持RESTful的http服務調(diào)用框架,內(nèi)置了ribbon,而ribbon可以提供負載均衡機制,因此feign可以作為一個負載均衡的遠程服務調(diào)用框架使用
    2022-11-11
  • 淺談Java中SimpleDateFormat 多線程不安全原因

    淺談Java中SimpleDateFormat 多線程不安全原因

    SimpleDateFormat是Java中用于日期時間格式化的一個類,本文主要介紹了淺談Java中SimpleDateFormat 多線程不安全原因,感興趣的可以了解一下
    2024-01-01

最新評論