Proposal: Refactor ThreadPool Creation with a Unified ThreadPoolFactory for Future Virtual Thread Support #7623
Description
Check Ahead
-
I have searched the issues of this repository and believe that this is not a duplicate.
-
I am willing to try to implement this feature myself.
Why you need it?
- Background & Problem
Currently, in both the Seata client and server components, various modules (such as TM, RM, TC, Netty RPC, etc.) independently create and manage their own thread pools using new ThreadPoolExecutor(...). This decentralized approach presents several limitations:
Maintenance Difficulty: Thread pool configurations (core size, max size, queue type, rejection policy, etc.) are scattered throughout the codebase, making them hard to manage, optimize, and audit consistently.
Technical Debt: With the evolution of Java, particularly the introduction of virtual threads in Project Loom (Java 21+), the current hard-coded approach creates a significant barrier to adoption. It would be extremely cumbersome to migrate all existing platform thread pools to virtual threads without a single point of control.
Inconsistency: It's challenging to enforce best practices (like standardized thread naming for monitoring) and ensure consistent behavior across all thread pools and different Java versions.
How it could be?
No response
Other related information
No response