The number of threads created does not exceed the number of threads that plugins are requesting to concurrently use. If an unreasonable number of threads are live this means you have an unreasonable number of plugins sleeping inside their async tasks. This is a plugin not a server issue, check it out with a command like jstack. Limiting the number of threads breaks the API contract as the tasks will be blocked.

As mentioned above, CachedThreadPool is good because it will always do its job, but there is a price for everything, at the same time, when threads switch frequently, execution efficiency will be reduced and the threads themselves eat a lot of resources. We are sure you (and us - plugin developers) will not have enough threads in the pool = the number of hardware threads. Are you sure that most tasks will not be completed in 1 tick? As a last resort, I suggest that you still limit the number of threads created using ThreadPoolExecutor to 40-50, for example, as for me, this is the golden mean. This will prevent the pool from growing too much, but tasks will not be blocked either.

I don't see how any other option but CachedThreadPool works. CachedThreadPool only creates up to the amount of concurrently executing async tasks. You need this otherwise async tasks will end up being blocked by other async tasks. FixedThreadPool is the complete wrong choice in this regard and I'm not sure ForkJoinPool has any benefits given the tick oriented nature of the scheduler.

This seems to me like a weird request that misunderstands the scheduler and/or cached thread pool. Like the name says CachedThreadPool is cached and so there is no 'thoughtless' creation of threads for each task.