Java虛擬線程

翻譯自 screencapture-pradeesh-kumar-medium-an-era-of-virtual-threads-java

flowchart LR introduction-->a(why thread)-->b(parallel and concurrent execution)-->c(why threads?)-->d(how does thread work)-->e(java thread model)-->f(virtual thread)-->g(why virtual thread)-->h(comparasion) a-->c d-->f

簡介

“虛擬線程”的概念越來越火，很多編程語言都嘗試將其加入到線程庫中，Java也不例外。JDK19中便加入了虛擬線程（預覽版）JEP425。本文主要深入淺出介紹線程的前世今身，以及虛擬線程帶來的全新體驗和優勢，最后會對幾種不同的線程實現方式進行對比

線程(Thread)簡介

一個電腦程序，本質上就是實現特定任務任務的一系列指令。當你加載一個程序時，操作系統加載程序文件，并將其放置在一個指定區域（地址空間），然后執行它所包含的指令。這時候，它就被作為了一個“進程”。換句話說，一個進程就是一個程序運行在電腦中的實例。

一個線程就是進程里的一系列可以獨立運行的指令，通常線程在CPU的一個核上運行。一個進程可以擁有多個線程，允許多個線程同時執行即同時執行多個任務，這樣可以更好的利用CPU資源，提高任務吞吐量。例如，當你加載谷歌瀏覽器，系統便創建了一個谷歌瀏覽器的進程。你可以同事做很多事情，比如說同時下載文件和瀏覽網頁，因為這些功能運行在不同的線程之上。線程也可以叫做輕量級進程，因為線程之間共享了進程的地址空間。

flowchart LR disk--load-->memory--assign-->process process--include-->thread1 process--include-->thread2 process--include-->thread3 process--include-->thread4

并行(parallel)與并發(concurrent)執行

并行執行：同時執行多個任務。例如，一臺四核的機器，可以每個核執行一個任務。所有的任務是同時執行的。

并發執行：：電腦制造了一種同時執行任務數比CPU核數更多的錯覺。例如，一個四核的電腦，可以執行8個不同的任務。因為你只有四核，所以必須做上下文切換來執行8個任務。在這里操作系統制造了一種并行執行8個任務的錯覺。然而，實際上只有四個任務可以并行執行，因為只有四核。

并行執行圖例：

flowchart LR core1-->thread1 core2-->thread2 core3-->thread3 core4-->thread4

并發執行圖例：

flowchart LR core1-->a1(thread1)-->a2(thread4)-->a3(thread1)-->a4(thread8)-->a5(thread4) core2-->b1(thread2)-->b2(thread7)-->b3(thread2)-->b4(thread7)-->b5(thread2) core3-->c1(thread3)-->c2(thread5)-->c3(thread10)-->c4(thread3)-->c5(thread5) core4-->d1(thread5)-->d2(thread9)-->d3(thread5)-->d4(thread11)-->d5(thread1)

為什么要使用多線程？

首先，讓我們研究一下線程是怎樣提高我們的系統效率的。

假如你現在有一臺四核的電腦，你要寫一個兩數之和的程序，同時要求必須執行在12個線程中。

代碼如下：

public class SumOfNums {
    static void sum() {
        int a = 1;
        int b = 2;
        int sum = a + b;
        System.out.println(sum);
    }

    public static void main(String[] args) {
        for (int i = 0; i < 12; i++) {
            Thread t = new Thread(SumOfNums::sum);
            t.start();
        }
    }
}

那么有多少線程可以并行執行呢？是否12個線程都可以并行執行？我們創建了12個線程，是否意味著12個線程是同時開始執行的？答案是否定的。我們的CPU只有四核，意味著我們并行執行的線程數上線就是四核。每個線程都必須分配到一個指定的核去執行，通過上下文切換來完成12個線程的并發執行。

那么為什么一個應用會有數百個線程？有什么用處？為什么我們不創建恰好等于CPU核數的線程？讓我們更深入的研究一下。

任務通常有兩種類型：CPU密集型以及IO密集型。

CPU密集型：任務執行高度依賴CPU，例如算術，邏輯，關聯關系等，這些任務都是CPU密集型；

IO密集型：任務執行高度依賴輸入/輸出操作，例如網絡交互，讀取/存儲文件，這些任務都是IO密集型；

那么我們上面提到的sum任務屬于哪一種呢？我們創建并初始化了兩個變量a和b，將他們求和并輸出到命令行。從始至終都沒有任何的IO操作，數值計算是一個CPU操作，將結果寫到兩一個文件就是一個IO操作了。

通常來說，一個任務會混合CPU和IO操作。例如讀取一個文本文件，并計算出其中所有的不同的單詞，然后將結果寫入到另一個文本文件。在這種情況下，讀取和寫入文件是一個IO操作，計算不同的單詞是一個CPU操作。

多線程如何影響系統的效率？

再思考一下上面的CPU密集型求和代碼。我們使用了12個線程并發執行這段代碼。CPU內部切換前后臺線程，這樣就可以用4個核心完成12個線程的任務。如果還沒有完成一個任務的時候，CPU會切換到另一個線程。

12個線程真的會提升效率嗎？并非如此。當前的情況下，這里浪費了很多時間在切換上下文上。對于CPU密集型任務，最好使用和核心數統統的并發線程數，以達到最高的效率。

對于唯一詞計算效率又該如何呢？

考慮這樣一種情況，需要讀取20個文本文件。CPU在讀取文件時處于空閑狀態，因為文件讀取發生在硬盤驅動器上。所以只有當文件上下文都獲取到了之后，CPU才會開始計算然后將結果寫入到另一個文件。再寫入過程中，CPU始終處于空閑狀態，等待硬盤驅動器。

也就是說，我們執行的是如下圖所示的單線程操作。

flowchart LR a(CPU)--wait-->b(__________IO__________)--hook-->c(CPU calculation)--wait-->d(____________IO__________)--hook-->e(CPU)

如上圖所示，CPU在IO進行的時候都是空閑的。這導致了CPU的核心始終跑不滿100%占用率。

現在，我們考慮一下當我們在4核心CPU上跑4個線程。如下圖所示：

flowchart LR a1(CPU)--wait-->b1(__________IO__________)--hook-->c1(CPU calculation)--wait-->d1(____________IO__________)--hook-->e1(CPU) a2(CPU)--wait-->b2(__________IO__________)--hook-->c(CPU calculation)--wait-->d2(____________IO__________)--hook-->e2(CPU) a3(CPU)--wait-->b3(__________IO__________)--hook-->c3(CPU calculation)--wait-->d3(____________IO__________)--hook-->e3(CPU) a4(CPU)--wait-->b4(__________IO__________)--hook-->c4(CPU calculation)--wait-->d4(____________IO__________)--hook-->e4(CPU)

每一個線程被賦予了一個指定的核以并發執行。結果就導致了四核出現了與上面單核一樣占用率不滿的問題，IO期間核心依然是空閑的。

增加線程是否可以解決這個問題呢？

然我們來看一下如果我們使用八個線程會怎樣：

flowchart LR core1-->a1(thread1)-->a2(thread2__)-->a3(_____thread1______)-->a4(__thread2__)-->a5(thread1) core2-->b1(thread3)-->b2(____thread4____)-->b3(thread3)-->b4(thread4)-->b5(thread2) core3-->c1(thread6)-->c2(thread5)-->c3(thread10)-->c4(thread3)-->c5(thread5) core4-->d1(thread5)-->d2(thread6)-->d3(thread5)-->d4(thread8)-->d5(thread1)

首先來看第一個核core1，當thread1進行IO操作時，core1此時是空閑的。然而，當存在多個未執行線程時，核心會切換到另一個線程開始執行，直到thread1完成了IO操作。這種方式可以最大化利用資源，提升多線程時的表現。

所以，在我們的第一個求和任務中，我們使用了比核心更多的線程數量沒有獲得效率提升，是因為浪費了過多的資源在上下文切換上。但是這里，8個線程提高了執行效率。我們從中可以學到，選擇線程的數量，取決于IO操作頻率和時間占用。IO操作占比越高，就需要越多的線程來提高執行效率。

線程內部是怎樣工作的？

在我們繼續研究虛擬線程前，必須要知道線程有哪些分類，以及他們怎么工作。

通常，現在操作系統中有兩種不同的線程：核心線程以及用戶線程

1. 核心線程

通常也叫做系統線程。核心線程通常由操作系統內核來安排管理。每個內核中的線程線程有一個TCB（Thread Control Block)，其中包括了線程的優先級，狀態，以及其它配置信息。核心線程是重量級的，需要系統調用來創建，調度，以及同步。

2. 用戶線程

用戶線程一般使用用戶線程庫進行管理和調度，不需要操作系統內核的干涉。內核不能意識到用戶線程的變化。每個用戶線程代表了一個應用中不同的數據結構，包括線程的狀態信息和配置信息。用戶線程是輕量級的，創建和銷毀比系統線程更快。但是，依然會收到一些明確的限制，例如不能夠享受到多處理器或者多核的優秀性能。

簡單講，當一個進程啟動時，會啟動一個默認線程，執行應用入口的main方法。隨后，進程會創建自己需要的額外線程。用戶線程是不能直接執行的，必須映射到一個指定的內核線程，然后通過內核線程執行執行。用戶線程和內核線程的映射關系有以下三種：

  • M:1：所有的用戶線程對應到一個內核線程上，通過庫調度器進行調度；
  • 1:1：每個用戶線程對應一個內核線程；
  • M:M：所有的用戶線程映射到了一個內核線程池；

Java內部線程實現模式

綠色線程（Green Thread）：遠古時期，Java使用綠色線程模式。這個模式下，多線程的調度和管理有JVM完成。綠色線程模式才作用M:1線程映射模型。這里就有一個問題，Java不能夠規?；芾磉@種線程，也就無法充分發揮硬件性能。同樣的實現綠色線程也是一件非常有挑戰性的事情，因為它需要非常底層的支持才能夠良好運行。隨后java移除了綠色線程，轉而使用本地線程。這使得Java的線程執行比綠色線程更慢。

本地線程（Native Thread）：從Java1.2開始從綠色線程切換到了本地線程模式。在操作系統的幫助下，JVM得以控制本地線程。本地線程的執行效率很高，但是開啟和關閉他們的資源消耗較大。這就是為什么我們現在要使用線程池。這個模型遵循著1：1線程映射，即一個Java線程映射到一個內核線程。當一個java線程被創建時，相應的一個對應的內核線程也會被創建，用來執行線程代碼。自此之后，本地線程模型的做法就延續到了今天。

當前Java線程模型有什么問題嗎？

上面的章節中中，我們知道Java已經使用了本地線程模式。讓哦我們看看這個模式有什么問題：

  • Java的線程庫已經很老舊了；
  • 只是對于本地線程的一個簡單包裝；
  • 本地線程的創建和管理資源消耗較大；
  • 本地線程需要保存他們的調用棧在內存中，大概2MB~20MB的預留空間。如果你有4GB內存，如果每個線程占用20MB內存，那么你就只能創建大概200個線程；
  • 因為本地線程是一種系統資源，加載一個新的本地線程大概需要1毫秒；
  • 上下文切換代價昂貴，需要一個到內核的系統調用；
  • 上面這些強制性的限制會限制線程創建的數量，同時會導致性能下降和過度的內存消耗。因為我們不能創建更多的線程；
  • 我們不能通過增加更多的線程來增應用規模，因為上下文切換和內存占用的代價高昂；

現實世界的例子

考慮一臺16GB內存的網絡服務器。對于每個服務請求，都分配一個不同的線程。我們假設每個線程需要20MB內存空間，那么這臺機器可以支持800個線程。當前，后端的API一般使用REST/SOAP調用方式，例如數據庫操作和API信息轉發這些IO密集型操作。由此可見，后端服務的主要是IO密集型而不是CPU密集型。

接著假設一下，一個IO操作需要100微秒，請求執行（IO密集型）需要100微秒，以及返回結果也需要100微秒。同時，當每秒有800個請求時，線程數得到了最大容量。

讓我們來計算一下單個請求的CPU占用時間

CPU時間　＝　請求準備時間 +　返回結果準備時間
		＝　0.1ms +　0.1ms
		= 0.2ms

對于800個請求呢？

800個線程的請求時間= 800 * 0.2ms
				= 160ms

受限于我們的內存容量，我們只能創建800個請求，也就導致了我們CPU使用率并不高

PUC使用率=160ms / 1000ms
		= 16%

那么如何才能使CPU的利用率到達90%呢？

16% = 800個線程
90% = X個線程
X = 4500

但是我們當前因為內存的限制不能創建那么多的線程，除非我們能突破這個限制，擁有90G內存。

90G的內存是一個比較離譜的數字，所以說創建本地線程很明顯不能充分利用硬件資源。

虛擬線程（Virtual Thread)

虛擬線程是一個Java線程的輕量級實現版本，最早于JDK19中出現，當前仍是預覽狀態，可以通過Jvm配置項開啟。

虛擬線程是JVM項目loom的一部分

虛擬線程解決了傳遞和維護本地線程的瓶頸問題，同時可以用之編寫高吞吐的并發應用，榨干硬件資源的潛力。

與本地線程不同，虛擬線程并不有操作系統控制，虛擬線程是一個有JVM管理的用戶態線程。對比于本地線程的高資源占用，每個虛擬線程只需要幾個字節的內存空間。這是的它更適合控制管理大量的用戶訪問，或者說處理IO密集型任務。

在創建虛擬線程的數量上幾乎沒有限制，甚至可以創建一百萬個，因為虛擬線程并不需要來自內核的系統調用。

在虛擬線程如此輕量化的條件下，線程池不再成為必須品，只需要在需要的時候盡情創建虛擬線程就好。

虛擬線程和傳統的本地線程操作完全兼容，例如本地線程變量，同步塊，線程中斷，等等。

虛擬線程如何工作

JVM管理著一個本地線程的線程池。一個虛擬線程想要進行CPU操作時，就把自己關聯到一個池中本地線程的隊列中。當虛擬線程中的CPU操作執行完畢后，JVM會自動解除關聯并掛起該虛擬線程，同時切換到并執行另一個虛擬線程。這就是為什么我們可以創建很多的虛擬線程，并且他們是如此的輕量級。

JVM使用M:N來完成虛擬線程與本地線程的映射。

Java虛擬線程實例

  1. 在現存的線程使用新的ofVirtual()工廠方法：
for (int i = 0; i < 5; i++) {
    Thread vThread = Thread.ofVirtual().start(() -> System.out.println("Hellow World!!!"));
}
  1. 使用新的Executors工廠的newVirtualThreadExecutor()方法：
public static void main(String[] args) throws InterruptedException {
    var executor = Executors.newVirtualThreadPerTaskExecutor();
    for (int i = 0; i < 16; i++) {
        executor.submit(()-> System.out.println("Hello World!!!"));
    }
    executor.awaitTermination(1, TimeUnit.SECONDS);
    System.out.println("Finished");
}

綠色線程 VS 虛擬線程

線程類型 簡介 映射
綠色線程 在一個系統線程上運行多個綠色線程 M:1
平臺線程（Java當前使用） 系統線程的包裝 1:1
虛擬線程 在多個系統線程中運行多個虛擬線程 M:N(M>N)

總結

總而言之，虛擬線程的新特性先對于傳統多線程擁有很多優勢。通過在用戶空間提供的輕量化并發模型，虛擬線程使得編寫并發程序更容易，使得大規模的線程并發成為可能。

參考

[1] screencapture-pradeesh-kumar-medium-an-era-of-virtual-threads-java