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

本文是繼《Java 21 新技術：虛擬線程使用指南》的第二篇文章，無意全面涵蓋虛擬線程的每個重要細節(jié)，目的是給大家使用虛擬線程提供一套使用指南，幫助大家能更好使用的虛擬線程，發(fā)揮其作用并避免踩坑。

本文完整大綱如下，

使用信號量限制并發(fā)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

static final DateTimeFormatter formatter = DateTimeFormatter….;

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

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

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

避免長時間和頻繁的 synchronized

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

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

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

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

啟動 Java 程序時添加 -Djdk.tracePinnedThreads=full 運行，會在線程被 “Pinning” 阻塞時打印完整的堆棧跟蹤，突出顯示本機幀和持有監(jiān)視器的幀。使用 -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

最后說兩句

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