2010-05-03 17 views
3

J'ai une application qui utilise 2 tâches SwingWorker de longue durée et je viens de rencontrer quelques ordinateurs Windows avec des JVM mises à jour qui n'en démarrent qu'une seule. Il n'y a pas d'erreur indiquée, donc je dois supposer que le pool de threads par défaut n'a qu'un seul thread et que le second objet SwingWorker est mis en file d'attente lorsque j'essaie de l'exécuter. Donc, (1) comment vérifier le nombre de threads disponibles dans le pool de threads SwingWorker par défaut et (2) comment ajouter des threads si j'en ai besoin de plus?Comment gérer le pool de threads Java SwingWorker par défaut?

Autre chose que je devrais savoir? Cette situation de thread-pool apparent unique va à l'encontre de toutes mes attentes.

J'installe un ThreadPoolExecutor mais cela semble si mal ...

Répondre

1

Le pool de threads SwingWorker par défaut a en fait 10 threads (défini dans la SwingWorker.MAX_WORKER_THREADS variable privée). Si vous voyez seulement l'une de vos tâches commencer, je vérifierais l'état de l'autre thread avec JConsole ou un autre outil similaire.

Il n'y a pas de moyen facile de jouer avec le pool de threads SwingWorker par défaut (il est privé et n'est exposé par aucune des méthodes publiques). L'ajout de SwingWorkers à votre propre pool de threads est la manière prévue de le gérer si le pool par défaut ne fonctionne pas.

+0

alors comment pourrions-nous mettre fin à ces discussions? Parce que le pool va être plein .... :( – gumuruh

+0

Tant que vos SwingWorkers finissent par finir, un ExecutorService correctement créé va réutiliser et éventuellement nettoyer vos threads lui-même.Si vos SwingWorkers sont délibérément infinis, alors vous avez juste besoin d'une piscine Si vous avez plus de problèmes, postez une nouvelle question et quelqu'un peut essayer d'aider – Sbodd

0

Sous JDK 6, le numéro par défaut de threads de travail est 10.

Vous ne devez normalement pas créer un ThreadPoolExecutor, le pool de threads par défaut utilisé par travailleur swing est généralement suffisant. La création d'un ThreadPoolExecutor peut être dangreuse, car certaines méthodes statiques ne créent qu'un pool avec un seul thread.

Vous pouvez ajouter la journalisation à ces threads, s'ils ne sont pas déjà présents, et inspecter les journaux. Il se peut qu'un autre problème de synchronisation arrête votre deuxième tâche d'arrière-plan.

+0

Concernant la journalisation, je n'ai pas diagnostiqué un problème de pool de threads jusqu'à ce que j'ajoute un System.out. instruction println() en haut de la méthode doInBackground() de chaque SwingWorker Cette instruction échoue à imprimer pour la deuxième tâche sur les 2 machines à problèmes BTW, j'ai fini par utiliser un pool créé avec Executors.newCachedThreadPool() et ça marche Mais je suis d'accord pour dire que s'il y a 10 threads, alors il y a un problème différent, donc j'essaierai de revenir à –

2

Peut-être un peu en retard mais, il y a un bogue dans les versions Java récentes: SwingWorker deadlocks due one thread in the swingworker-pool

+1

Merci pour la pointe sur ce point, car il semble encore être apparent aujourd'hui. Un rapport de bogue connexe http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6925575 indique que vous pouvez travailler en utilisant votre propre 'ExecutorService'. Je l'ai fait et ça a bien marché. http://www.deitel.com/articles/java_tutorials/20051126/JavaMultithreading_Tutorial_Part4.html – jocull