I think a confusing point with SwingWorkers is that the SwingWorker.execute() method runs the workers on a default/private thread pool, which is fixed to some low number of threads. This is likely sufficient and reasonable for small/simple apps. However, make two observations to get more control over the concurrency: 1. SwingWorkers are RunnableFutures 2. SwingWorkers do NOT have to be run by calling the SwingWorker.execute() method. So, just make your own thread pool (ExecutorService) configured to your needs, and then submit() or execute() SwingWorkers there.
–
Greg MattesAug 3 '12 at 14:54

2 Answers
2

A SwingWorker is not a thread itself but a task that will be executed in a thread. Usually, you would use an ExecutorService to execute instances of SwingWorker; this interface also allows to set the number of threads:

The above code sample will allow you to have more than the default number of SwingWorkers executing. Of course it is accessing some backdoor sun.awt.AppContext class, but it is a quick workaround for those interested, and not able/willing to provide their own ExecutorService.