Je veux que mon fil principal soit en cours d'exécution, car j'ai un auditeur qui écoutera les requêtes / messages dans un autre fil et je ne veux pas que mon fil principal meure.
Lequel est le meilleur
public static void main(String[] args) throws InterruptedException {
startListener();
while (true){
Thread.sleep(1000);
}
}
public static void main(String[] args) throws InterruptedException {
startListener();
CountDownLatch latch = new CountDownLatch(1);
latch.await();
}
3 Réponses :
Aucun.
Tout d'abord, si startListener () crée un nouveau thread, l'application continuera à fonctionner même si le thread principal se termine. C'est vrai tant qu'il y a au moins un thread non démon en cours d'exécution. (Ceci est différent du C / C ++ où l'application se termine par le main. Avec lequel vous pourriez confondre).
Concernant les options que vous avez présentées. Les deux créeront une boucle sans fin (sans moyen d'exister), ce qui n'est probablement pas la meilleure pratique. Mais si vous devez en choisir un, le loquet est meilleur car il ne consommera pas de CPU toutes les secondes.
En supposant que votre thread d'écoute est un thread non démon , vous pouvez laisser le thread principal se terminer. La JVM continuera à fonctionner tant qu'il y aura des threads non démon en cours d'exécution.
CountDownLatch serait une meilleure solution si vous prévoyez d'implémenter un arrêt progressif. Vous pouvez appuyer sur le loquet et laisser le thread principal se terminer en exécutant une logique de nettoyage. Pensez à la façon dont l'application va s'arrêter, par exemple vous obtenez un singal SIGTERM lorsque l'auditeur lit un message dans la file d'attente, que faire alors?
Merci, cela fonctionne sans démon! Y a-t-il un impact à en faire un non-démon, devons-nous nous occuper de quelque chose d'autre?
@Sujeet, vous pouvez jeter un œil aux DefaultMessageListenerContainer pour voir quels sont les défis de la lecture à partir de JMS.
La seule différence est que la JVM continuera à fonctionner si ce thread est actif.
Les deux méthodes proposées fonctionneraient, mais je suggère d'utiliser le fil principal dans le traitement synchrone des messages entrants. Les messages seront alors traités plus rapidement et avec moins de ressources (threads). Voir Un exemple simple de réception de messages synchrones . L'écouteur n'est donc pas nécessaire.
En fait, j'ai plusieurs types d'auditeurs différents et ils écoutent différents sujets dans leur propre fil de discussion. Je pense donc qu'un seul thread principal à l'écoute pourrait ne pas être une bonne idée dans ce cas
Comment le thread principal saura-t-il quand reprendre / continuer?
Que fait exactement l'auditeur? Entre les deux, le verrouillage du compte à rebours est meilleur, mais il peut y avoir des constructions qui correspondent encore mieux.
@daniu: listener sera un auditeur JMS qui écoutera les messages tout au long de la journée, à moins que nous n'arrêtions le processus.
@ernest_k, je ne veux rien traiter de plus dans le fil principal. Je veux qu'il soit vivant, afin que mon fil d'écoute continue à écouter les messages.
@Sujeet Je comprends qu'il s'agit de savoir comment le fil principal sera informé que le travail de vos auditeurs est terminé. Pouvez-vous afficher le code de
startListeners ()ou tout autre code qui doit se terminer avant que le thread principal ne meure?CountDownLatch.awaitest un mécanisme plus sophistiqué qui attendrait jusqu'à ce que vous ayez décompté jusqu'à 0, tandis queThread.sleepest rarement une bonne décision, en particulier lorsqu'elle est répétitive. Les deux cas sont mauvais, il n'y a aucun moyen d'arrêter l'un ou l'autre (le premier nécessite quelatchsoit passé dansstartListener, le second a besoin d'une référence au thread principal pour être capable de l'interrompre).Qu'en est-il de rejoindre ces threads dans le thread principal? Reportez-vous à l'exemple de cette réponse: stackoverflow.com/a/54022338