You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "funky-eyes (via GitHub)" <gi...@apache.org> on 2026/01/23 03:31:43 UTC
[I] [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model [dubbo]
funky-eyes opened a new issue, #16042:
URL: https://github.com/apache/dubbo/issues/16042
### Pre-check
- [x] I am sure that all the content I provide is in English.
### Search before asking
- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement.
### Apache Dubbo Component
Java SDK (apache/dubbo)
### Descriptions
目前有部分三方库都是用的threadlocal方式的缓存池实现，导致如果将dubbo的线程池改为虚拟线程，当前的实现是不池化任何虚拟线程，将导致三方库，如fastjson，aerospike-client等会再线程的threadlocal中构建几kb大小的byte缓存，当使用不池化的虚拟线程池时，缓存池将失效，导致gc激增，即便使用分代zgc，由于gc次数上升，对cpu影响也会较大。
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.
### 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?
- [x] Yes I am willing to submit a pull request on my own!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model [dubbo]
Posted by "funky-eyes (via GitHub)" <gi...@apache.org>.
funky-eyes commented on issue #16042:
URL: https://github.com/apache/dubbo/issues/16042#issuecomment-3788515886
> 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model [dubbo]
Posted by "zrlw (via GitHub)" <gi...@apache.org>.
zrlw closed issue #16042: [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model
URL: https://github.com/apache/dubbo/issues/16042
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model [dubbo]
Posted by "RainYuY (via GitHub)" <gi...@apache.org>.
RainYuY commented on issue #16042:
URL: https://github.com/apache/dubbo/issues/16042#issuecomment-3788031853
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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [I] [Feature] Refactor VirtualThreadPool to use a pooled virtual thread model [dubbo]
Posted by "funky-eyes (via GitHub)" <gi...@apache.org>.
funky-eyes commented on issue #16042:
URL: https://github.com/apache/dubbo/issues/16042#issuecomment-3788506971
```
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
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org