Existe-t-il un délai d'expiration par défaut pour les threads en attente d'une méthode synchronisée en Java? Certains threads de mon application ne se terminent pas comme prévu. Est-il de toute façon de vérifier si les threads sont morts à la suite de délais d'attente?Existe-t-il un délai d'attente pour les threads en attente d'une méthode synchronisée en Java?
Si une méthode attend un objet de synchronisation, elle ne devrait jamais mourir, mais elle pourrait attendre très longtemps (comme, "forever") si quelque chose ne va pas. Peut-être que votre programme ne libère jamais un verrou sur une ressource?
Le JLS ne spécifie aucune temporisation pour les sections synchronized. Il mentionne simplement
Alors que le thread exécutant possède le verrou , aucun autre thread peut acquérir le verrou .
Vous pouvez définir un délai d'expiration sur la méthode join() pour vous assurer que vous n'attendez pas indéfiniment. Je voudrais jeter un coup d'oeil aux paquets java.util.concurrent pour voir si de nouvelles fonctionnalités ont été ajoutées pour aider votre situation.
Je recommande également "Java Concurrency In Practice" par Brian Goetz. (Je dois le relire moi-même.)
Bon point: il faut aussi noter que le terme "deadlock" signifie que deux threads attendent l'un l'autre. S'il y avait un timeout, le terme "deadlock" ne serait pas disponible. – Pindatjuh
duffymo - si un thread commence un autre thread, avec le second thread devant rapporter sa progression au premier, mais le premier thread meurt avant que le second ne soit terminé, que voulez-vous qu'il se passe? – MalcomTucker
Je ne sais pas. Il semble que ce soit une communication bidirectionnelle, mais ce n'est pas le cas. Vous avez besoin de rappels ici. C'est pourquoi je recommande d'aller au-delà de java.lang.Thread brut et de regarder dans les paquets java.util.concurrent, car il y a de nouvelles fonctionnalités qui pourraient être applicables. – duffymo
Les threads en Java ne meurent pas soudainement. Soit ils ne progressent pas (bloqués sur un verrou ou boucle infinie ou similaire), ou si une exception est levée et n'est pas gérée, alors l'exécution du thread s'arrêtera lorsque l'exception se propagera au niveau supérieur (qui devrait alors imprimer l'exception pile trace à System.err). Si votre application est en interblocage, un moyen de découvrir la raison est de faire un vidage de thread. La JVM peut également détecter elle-même de simples blocages, auquel cas elle les signalera dans le fichier de vidage.
Vous pouvez générer une sauvegarde de thread sous Linux en exécutant kill -QUIT <pid> et sous Windows en appuyant sur Ctrl + Break dans la fenêtre de la console. Ou encore plus simple, utilisez VisualVM, StackTrace ou un outil similaire.
Je vous suggère d'utiliser kill -3 pour voir un vidage de thread, puis voir ce que sont les threads problématiques.
Merci, je ne * pense * pas qu'il y ait des blocages, mais cela pourrait être la cause .. – MalcomTucker