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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
