[Feature] Refactor VirtualThreadPool to use a pooled virtual thread model

[funky-eyes]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

Currently, several third-party libraries rely on ThreadLocal-based caching pools for their internal buffers. If Dubbo's thread pool is switched to virtual threads without any pooling mechanism (i.e., creating a new virtual thread for each task), these libraries — such as FastJSON, Aerospike Java client, etc. — will allocate several KB-sized byte buffers in the ThreadLocal of each new virtual thread.
Since virtual threads are not pooled in this scenario, the ThreadLocal caches become ineffective: each virtual thread gets its own fresh cache instance instead of reusing pooled ones. This leads to a massive increase in short-lived object allocations, causing significantly higher GC pressure — even with generational ZGC, the increased GC frequency still puts noticeable load on the CPU.

example：
https://github.com/aerospike/aerospike-client-java/blob/master/client/src/com/aerospike/client/util/ThreadLocalData.java

Related issues

current

public class VirtualThreadPool implements ThreadPool {
    @Override
    public Executor getExecutor(URL url) {
        String name =
                url.getParameter(THREAD_NAME_KEY, (String) url.getAttribute(THREAD_NAME_KEY, DEFAULT_THREAD_NAME));
        return Executors.newThreadPerTaskExecutor(
                Thread.ofVirtual().name(name, 1).factory());
    }
}

after

public class VirtualThreadPool implements ThreadPool {
    @Override
    public Executor getExecutor(URL url) {
        String name =
                url.getParameter(THREAD_NAME_KEY, (String) url.getAttribute(THREAD_NAME_KEY, DEFAULT_THREAD_NAME));
        return new ThreadPoolExecutor(200, Integer.MAX_VALUE, 60, java.util.concurrent.TimeUnit.SECONDS,
            new SynchronousQueue<>(), Thread.ofVirtual().name(name, 1).factory());
    }
}

We can take inspiration from the design of FixedThreadPool, but with the following adjustments for virtual threads:

Set the maximum thread count to Integer.MAX_VALUE
Use a SynchronousQueue as the work queue

This way, when the number of threads is insufficient, the pool can still automatically expand by creating new virtual threads — behaving just like an unpooled virtual thread executor.
At the same time, the keepAliveTime mechanism ensures that excess virtual threads are eventually reclaimed, effectively limiting how many threads get created and preventing unbounded growth.
Since virtual threads are extremely lightweight, pooling a reasonable number of them has negligible impact on memory usage.

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[RainYuY]

I don’t believe this should be an issue for Dubbo. This is because virtual threads are not meant to be pooled. The root cause of this problem is that a third-party dependency misuses ThreadLocal—though I do acknowledge that this issue does exist, as there are actually many developers who tend to do this kind of thing. How about not modifying the current code, but instead creating a new ThreadLocal implementation and using SPI to make it an optional feature?

[funky-eyes]

public static void main(String[] args) throws InterruptedException {
    // Create an executor that spawns a new virtual thread for each task
    Executor executor = Executors.newThreadPerTaskExecutor(
            Thread.ofVirtual().name("test-", 1).factory());

    // Create a virtual-thread-based thread pool with large max size and SynchronousQueue
    // This allows unbounded growth when needed, but reuses idle threads up to keepAliveTime
    Executor executor2 = new ThreadPoolExecutor(
            200,                       // core pool size
            Integer.MAX_VALUE,         // maximum pool size (effectively unbounded)
            60,                        // keep-alive time
            java.util.concurrent.TimeUnit.SECONDS,
            new SynchronousQueue<>(),  // handoff queue — forces new thread creation when pool is busy
            Thread.ofVirtual().name("test-threadpool-", 1).factory());

    // Warm-up / pre-heat phase to allow JIT compilation and thread creation
    for (int i = 0; i < 10100; i++) {
        executor.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });

        executor2.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    // Wait long enough to ensure JIT compilation and warm-up are complete
    Thread.sleep(5000);

    long start = System.currentTimeMillis();
    CountDownLatch countDownLatch = new CountDownLatch(5000000);

    for (int i = 0; i < 5000000; i++) {
        executor.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
                countDownLatch.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    countDownLatch.await();
    System.out.println("thread time: " + (System.currentTimeMillis() - start) + " ms");

    start = System.currentTimeMillis();
    CountDownLatch countDownLatch2 = new CountDownLatch(5000000);

    for (int i = 0; i < 5000000; i++) {
        executor2.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
                countDownLatch2.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    countDownLatch2.await();  // Fixed: should await countDownLatch2 (not the first one)
    System.out.println("thread pool time: " + (System.currentTimeMillis() - start) + " ms");
}

Test results are in: the pooled virtual thread pool shows better performance.

thread time: 10349 ms
thread pool time: 3364 ms

[funky-eyes]

I don’t believe this should be an issue for Dubbo. This is because virtual threads are not meant to be pooled. The root cause of this problem is that a third-party dependency misuses ThreadLocal—though I do acknowledge that this issue does exist, as there are actually many developers who tend to do this kind of thing. How about not modifying the current code, but instead creating a new ThreadLocal implementation and using SPI to make it an optional feature?

We could introduce a configuration option for the core pool size (e.g., corePoolSize), defaulting to null.
When the user does not configure it (i.e., null), the virtual thread pool would not be pooled — falling back to the non-pooled behavior.
This way, we avoid the need to create and maintain a separate ThreadLocal implementation.