Java 官方文檔明確指出：

“Do not pool virtual threads.

虛擬線程不是昂貴資源，永遠不應該被池化。

應該為每個任務創建一個新的虛擬線程，它們應該是短暫的、任務級別的。

這是為什么呢？為什么只有虛擬線程 Virtual Thread，卻沒有虛擬線程池 Virtual Thread Pool 呢？

主要原因

之所以只有虛擬線程是因為，虛擬線程創建成本極低，低到其創建成本遠小于線程池的管理成本。

“也就是說，線程池的管理成本遠遠大于虛擬線程的創建成本，所以使用虛擬線程池是一個不劃算的操作。

具體來說，傳統平臺線程的創建涉及分配大量的棧內存（通常~1MB）并與操作系統交互，開銷很大。池化是為了復用這些“昂貴”的線程，避免反復申請資源。而虛擬線程由 JVM 在用戶態管理，初始棧空間很小（約幾百字節），創建和銷毀的代價極低，池化帶來的收益遠小于管理池本身的復雜度。

用完就扔”比“池化復用”更高效、更簡單。一個線程約等于幾千個虛擬線程。

一任務一虛線程的理念

官方推薦并為每個任務創建一個全新的虛擬線程，例如通過 Executors.newVirtualThreadPerTaskExecutor()，任務完成后虛擬線程即被丟棄。這種模式代碼更清晰，避免了因線程復用可能帶來的線程局部變量（ThreadLocal）污染等問題，也無需擔心池的大小調優等問題。

最佳實現代碼：

// 無需池化 - 直接創建
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        });
    });
} // 自動關閉（所有虛擬線程完成即銷毀）

ExecutorService 并不是一個傳統意義上的“池”，你可以把它理解為一個虛擬線程工廠。每次 submit 一個任務，它都會立即創建一個新的虛擬線程來執行該任務，它內部并不維護（一個可復用的）線程隊列。

如何限制并發？

在單進程百萬虛擬線程的情況下， JVM 內存是完全無壓力的。如果你還是擔心太多的虛擬線程會導致程序崩潰，在特定的場景可以使用 Semaphore 等技術來實現局部限流，例如以下代碼這樣：

// 使用信號量而非線程池來限制對某個資源的并發訪問
Semaphore semaphore = new Semaphore(100000); // 限制最大并發數為100000

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 10_000; i++) {
        executor.submit(() -> {
            semaphore.acquire(); // 獲取許可，若已達上限則阻塞等待
            try {
                // 訪問受保護的資源或執行需要限流的操作
                callLimitedService();
            } finally {
                semaphore.release(); // 釋放許可
            }
        });
    }
}

小結

虛擬線程 Virtual Thread 因為其創建成本極低（約幾百字節），所以不會完全不需要使用池化技術來實現，因為池化技術的本質是復用那些“昂貴”的線程，避免反復申請資源的。如果要局部限流虛擬線程可以使用 Semaphore 來實現。