虛擬線程是在 Java 21 版本中實現的一種輕量級線程。它由 JVM 進行創建以及管理。虛擬線程和傳統線程（我們稱之為平臺線程）之間的主要區別在于，我們可以輕松地在一個 Java 程序中運行大量、甚至數百萬個虛擬線程。

由于虛擬線程的數量眾多，也就賦予了 Java 程序強大的力量。虛擬線程適合用來處理大量請求，它們可以更有效地運行 “一個請求一個線程” 模型編寫的 web 應用程序，可以提高吞吐量以及減少硬件浪費。

由于虛擬線程是 java.lang.Thread 的實現，并且遵守自 Java SE 1.0 以來指定 java.lang.Thread 的相同規則，因此開發人員無需學習新概念即可使用它們。

但是虛擬線程才剛出來，對我們來說有一些陌生。由于 Java 歷來版本中無法生成大量平臺線程（多年來 Java 中唯一可用的線程實現），已經讓程序員養成了一套關于平臺線程的使用習慣。這些習慣做法在應用于虛擬線程時會適得其反，我們需要摒棄。

此外虛擬線程和平臺線程在創建成本上的巨大差異，也提供了一種新的關于線程使用的方式。Java 的設計者鼓勵使用虛擬線程而不必擔心虛擬線程的創建成本。

本文無意全面涵蓋虛擬線程的每個重要細節，目的是給大家使用虛擬線程提供一套使用指南，幫助大家能更好使用的虛擬線程，發揮其作用并避免踩坑。

本文完整大綱如下，

使用信號量限制并發

在某些場景下，我們需要限制某個操作的并發數。例如某些外部服務可能無法同時處理超過 10 個并發請求。

由于平臺線程是一種寶貴的資源，通常在線程池中進行管理，因此線程池的使用對于如今的程序員相當普遍。

比如上面例子要限制并發請求數，某些人會使用線程池來處理，代碼如下，

ExecutorService es = Executors.newFixedThreadPool(10);
...
Result foo() {
    try {
        var fut = es.submit(() -> callLimitedService());
        return f.get();
    } catch (...) { ... }
}

上面代碼示例可以確保外部服務最多只有 10 個并發請求，因為我們的線程池中只有最多 10 個線程。

限制并發只是使用線程池的副產品。線程池旨在共享稀缺資源，而虛擬線程并不稀缺，因此永遠不應該池化虛擬線程！

使用虛擬線程時，如果要限制訪問某些服務的并發請求，則應該使用專門為此目的設計的 Semaphore 類。示例代碼如下，

Semaphore sem = new Semaphore(10);
...
Result foo() {
    sem.acquire();
    try {
        return callLimitedService();
    } finally {
        sem.release();
    }
}

在這個示例中，同一時刻只有 10 個虛擬線程可以進入 foo() 方法取得鎖，而其他虛擬線程將會被阻塞。

簡單地使用信號量阻塞某些虛擬線程可能看起來與將任務提交到固定數量線程池有很大不同，但事實并非如此。

將任務提交到等待任務池會將它們排隊處理，信號量在內部(或任何其他阻塞同步構造)構造了一個阻塞線程隊列，這些任務在阻塞線程隊列上也會進行排隊處理。

我們可以將平臺線程池認作是從等待任務隊列中提取任務進行處理的工作人員，然后將虛擬線程視為任務本身，在任務或者線程可以執行之前將會被阻塞，但它們在計算機中的底層表示上實際是相同的。

這里想告訴大家的就是不管是線程池的任務排隊，還是信號量內部的線程阻塞，它們之間是由等效性的。在虛擬線程某些需要限制并發數場景下，直接使用信號量即可。

不要在線程局部變量中緩存可重用對象

虛擬線程支持線程局部變量，就像平臺線程一樣。通常線程局部變量用于將一些特定于上下文的信息與當前運行的代碼關聯起來，例如當前事務和用戶 ID。

對于虛擬線程來說，使用線程局部變量是完全合理的。但是如果考慮更安全、更有效的線程局部變量，可以使用 Scoped Values。

更多有關 Scoped Values 介紹，請參閱 https://docs.oracle.com/en/java/javase/21/core/scoped-values.html#GUID-9A4565C5-82AE-4F03-A476-3EAA9CDEB0F6

線程局部變量有一種用途與虛擬線程是不太適合的，那就是緩存可重用對象。

可重用對象的創建成本通常很高，通常消耗大量內存且可變，還不是線程安全的。它們被緩存在線程局部變量中，以減少它們實例化的次數以及它們在內存中的實例數量，好處是它們可以被線程上不同時間運行的多個任務重用，避免昂貴對象的重復創建。

例如 SimpleDateFormat 的實例創建成本很高，而且不是線程安全的。為了解決創建成本、線程不安全問題，通常是將此類實例緩存在 ThreadLocal 中，如下例所示：

static final ThreadLocal<SimpleDateFormat> cachedFormatter =
       ThreadLocal.withInitial(SimpleDateFormat::new);

void foo() {
  ...
	cachedFormatter.get().format(...);
	...
}

僅當線程（以及因此在線程本地緩存的昂貴對象）被多個任務共享和重用時（就像平臺線程被池化時的情況一樣），這種緩存才有用。許多任務在線程池中運行時可能會調用 foo，但由于池中僅包含幾個線程，因此該對象只會被實例化幾次（每個池線程一次）并被緩存和重用。

但是虛擬線程永遠不會被池化，也不會被不相關的任務重用。因為每個任務都有自己的虛擬線程，所以每次從不同任務調用 foo 都會觸發新 SimpleDateFormat 的實例化。而且由于可能有大量的虛擬線程同時運行，昂貴的對象可能會消耗相當多的內存。這些結果與線程本地緩存想要實現的結果恰恰相反。

對于線程局部變量緩存可重用對象的問題，沒有什么好的通用替代方案，但對于 SimpleDateFormat，我們應該將其替換為 DateTimeFormatter。DateTimeFormatter 是不可變的，因此單個實例就可以由所有線程共享，

static final DateTimeFormatter formatter = DateTimeFormatter….;

void foo() {
  ...
	formatter.format(...);
	...
}

需要注意的是，使用線程局部變量來緩存共享的昂貴對象有時是由一些異步框架在幕后完成的，其隱含的假設是這些可重用對象只會由極少數池線程使用。

所以混合虛擬線程和異步框架一起使用可能不是一個好主意，對某些方法的調用可能會導致可重用對象被重復創建。

避免長時間和頻繁的 synchronized

當前虛擬線程實現由一個限制是，在同步塊或方法內執行 synchronized 阻塞操作會導致 JDK 的虛擬線程調度程序阻塞寶貴的操作系統線程，而如果阻塞操作是在同步塊或方法外完成的，則不會被阻塞。我們稱這種情況為 “Pinning”。

如果阻塞操作既長期又頻繁，則 “Pinning” 可能會對服務器的吞吐量產生不利影響。如果阻塞操作短暫（例如內存中操作）或不頻繁則可能不會產生不利影響。

為了檢測可能有害的 “Pinning” 實例，（JDK Flight Recorder (JFR) 在 “Pinning” 阻塞時間超過 20 毫秒時，會發出 jdk.VirtualThreadPinned 事件。

或者我們可以使用系統屬性 jdk.tracePinnedThreads 在線程被 “Pinning” 阻塞時發出堆棧跟蹤。

啟動 Java 程序時添加 -Djdk.tracePinnedThreads=full 運行，會在線程被 “Pinning” 阻塞時打印完整的堆棧跟蹤，突出顯示本機幀和持有監視器的幀。使用 -Djdk.tracePinnedThreads=short 運行，會將輸出限制為僅有問題的幀。

如果這些機制檢測到既長期又頻繁 “Pinning” 的地方，請在這些特定地方將 synchronized 替換為 ReentrantLock。以下是長期且頻繁使用 synchronized 的示例，

synchronized(lockObj) {
    frequentIO();
}

我們可以將其替換為以下內容：

lock.lock();
try {
    frequentIO();
} finally {
    lock.unlock();
}

參考資料

• https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E

最后說兩句

針對虛擬線程的使用，相信大家心里已經有了答案。在對虛擬線程需要限制并發數的場景，使用信號量即可。在虛擬線程中使用線程局部變量時要注意避免緩存昂貴的可重用對象。對于使用到 synchronized 同步塊或者方法的虛擬線程，建議替換為 ReentrantLock，避免影響吞吐量。

關注公眾號【waynblog】每周分享技術干貨、開源項目、實戰經驗、國外優質文章翻譯等，您的關注將是我的更新動力！

總結

以上是生活随笔為你收集整理的Java 新技术：虚拟线程使用指南（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。