Si vous plonger dans le code SwingWorker
vous verrez la constante suivante définie:
/**
* number of worker threads.
*/
private static final int MAX_WORKER_THREADS = 10;
Par conséquent, le nombre de threads d'arrière-plan ne peut jamais dépasser cette valeur quel que soit le nombre d'entre vous de SwingWorker
réellement créer . Une façon de faire varier le modèle de thread de fond serait de brancher votre propre ExecutorService
dans le AppContext
associé à la classe SwingWorker
. Cependant, ceci est légèrement douteux étant donné que AppContext
appartient à sun.awt
et ne fait donc pas partie de l'API JDK officielle.
// Create single thread executor to force all background tasks to run on the same thread.
ExecutorService execService = Executors.newSingleThreadExecutor();
// Retrieve the AppContext. *CAUTION*: This is part of the sun.awt package.
AppContext ctxt = AppContext.getAppContext();
// Verify that nothing is already associated with SwingWorker.class within the context.
Object obj = ctxt.get(SwingWorker.class);
if (obj != null) {
throw new IllegalStateException("Object already associated with SwingWorker: " + obj);
}
// Install ExecutorService. Will be retrieved by the SwingWorker when execute() is called.
ctxt.put(SwingWorker.class, ctxt);
Aha. C'est bon à savoir. Je n'ai pas remarqué ça. – RCC
Notez également que SwingWorker étant un Runnable, vous pouvez exécuter SwingWorkers via votre propre ExecutorService si vous avez besoin de plus de contrôle sur leur thread. – Sbodd